116 ROZDZIAŁ 8. SRP — ZASADA POJEDYNCZEJ ODPOWIEDZIALNOŚCI Możemy postrzegać klasę ModemImplementation jako węzeł lub brodawkę. Zauważmy jednak, że ws...

21 downloads 31 Views 102MB Size

116

ROZDZIAŁ 8. SRP — ZASADA POJEDYNCZEJ ODPOWIEDZIALNOŚCI

Możemy postrzegać klasę ModemImplementation jako węzeł lub brodawkę. Zauważmy jednak, że wszystkie zależności płyną od niej na zewnątrz. Żadna klasa nie musi zależeć od tej klasy. Żaden program, z wyjątkiem procedury main, nie musi wiedzieć, że ta klasa istnieje. W ten sposób brzydką część wystawiliśmy „za płot”. Jej brzydota nie musi wyciekać i zanieczyszczać reszty aplikacji.

Trwałość Na rysunku 8.4 pokazano typowe naruszenie zasady SRP. Klasa Employee zawiera reguły biznesowe oraz zarządza utrwalaniem obiektów. Tych dwóch zadań prawie nigdy nie należy mieszać. Reguły biznesowe zwykle często się zmieniają, a chociaż zadania utrwalania nie zmieniają się tak często, to zmieniają się z zupełnie innych powodów. Wiązanie reguł biznesowych z podsystemem utrwalania jest proszeniem się o kłopoty.

Rysunek 8.4. Sprzężony podsystem utrwalania

Na szczęście, jak przekonaliśmy się w rozdziale 4., stosowanie praktyki produkcji sterowanej testami zwykle zmusza do rozdzielenia tych dwóch odpowiedzialności na długo przedtem, zanim projekt zacznie brzydko pachnieć. Jednak w przypadkach, gdy testy nie wymuszają separacji, a zapachy sztywności i kruchości nie staną się dość silne, projekt należy zrefaktoryzować z wykorzystaniem wzorców projektowych Fasada lub Pełnomocnik. W ten sposób należy rozdzielić te dwie odpowiedzialności.

Wniosek Zasada SRP jest najprostszą z zasad i jedną z tych, których właściwe stosowanie jest najtrudniejsze. Łączenie obowiązków jest czymś, co robimy w sposób naturalny. W większości projektowanie oprogramowania sprowadza się właśnie do wyszukiwania i oddzielania tych obowiązków od siebie. Pozostałe zasady, które omówimy, w istocie w taki czy inny sposób sięgają do tej kwestii.

Bibliografia 1. Tom DeMarco, Structured Analysis and System Specification. Yourdon Press Computing Series, Englewood Cliff, NJ: 1979. 2. Meilir Page-Jones, The Practical Guide to Structured Systems Design, wydanie drugie. Englewood Cliff, NJ: Yourdon Press Computing Series, 1988.

R OZDZIAŁ 9

OCP — zasada otwarte-zamknięte

Holenderskie drzwi — (rzeczownik) drzwi podzielone na dwie części w poziomie, tak że każda z części może pozostać otwarta lub zamknięta — The American Heritage® Dictionary of the English Language, wydanie czwarte, 2000

Jak powiedział Ivar Jacobson: „Wszystkie systemy zmieniają się w czasie swojego cyklu życia. Trzeba o tym pamiętać podczas prowadzenia prac nad systemami, od których oczekuje się, że przetrwają dłużej niż ich pierwsza wersja1”. Jak można tworzyć projekty, które pozostaną stabilne w obliczu zmian i które będą trwać dłużej niż ich pierwsza wersja? Wskazówki na ten temat dał nam Bertrand Meyer w 1988 roku, kiedy wymyślił słynną dziś zasadę otwarte-zamknięte2.

OCP — zasada otwarte-zamknięte Encje oprogramowania (klasy, moduły, funkcje itp.) powinny być otwarte na rozbudowę, ale zamknięte dla modyfikacji. Gdy pojedyncza zmiana programu powoduje kaskadę zmian w modułach zależnych, to projekt wydziela woń sztywności. Zasada OCP radzi nam, aby zrefaktoryzować system tak, by dalsze zmiany tego rodzaju nie powodowały kolejnych modyfikacji. Jeśli zasada OCP zostanie właściwie zastosowana, to 1

[Jacobson 92], str. 21.

2

[Meyer 97], str. 57.

118

ROZDZIAŁ 9. OCP — ZASADA OTWARTE-ZAMKNIĘTE

nowe zmiany tego typu uzyskuje się przez dodanie nowego kodu, a nie przez zmianę starego kodu, który już działa. Stosowanie tej zasady może wydawać się nieosiągalnym ideałem — ale istnieje kilka stosunkowo prostych i skutecznych strategii zbliżania się do tego ideału.

Opis Moduły, które są zgodne z zasadą otwarte-zamknięte, charakteryzują się dwoma podstawowymi atrybutami. Są one: 1. Otwarte na rozszerzenia. Oznacza to, że zachowanie modułu może być rozszerzone. W miarę zmieniania się wymagań aplikacji możemy rozszerzać moduł o nowe zachowania, które pozwalają na sprostanie tym wymaganiom. Inaczej mówiąc, możemy zmieniać to, co moduł robi. 2. Zamknięte na modyfikacje. Rozszerzanie zachowań modułu nie skutkuje zmianami w źródłowym lub binarnym kodzie modułu. Binarna, wykonywalna wersja modułu, niezależnie od tego, czy jest to biblioteka konsolidowana, czy biblioteka DLL, czy biblioteka .jar w Javie, pozostaje nienaruszona. Mogłoby się wydawać, że te dwie cechy są sprzeczne. Normalnym sposobem rozszerzania modułu o nowe zachowania jest wprowadzanie zmian w kodzie źródłowym tego modułu. Moduł, którego nie można zmieniać, zwykle uważa się za moduł o ustalonym zachowaniu. Jak to możliwe, aby modyfikować zachowania modułu bez zmiany jego kodu źródłowego? Jak możemy zmienić to, co moduł robi, bez zmieniania modułu?

Kluczem jest abstrakcja W C++, Javie lub dowolnym innym języku OOPL3 możliwe jest tworzenie abstrakcji, które są trwałe, a jednocześnie reprezentują niepowiązaną grupę możliwych zachowań. Są to abstrakcyjne klasy bazowe, natomiast niepowiązane grupy możliwych zachowań są reprezentowane przez wszystkie możliwe klasy pochodne. Istnieje możliwość, aby moduł manipulował abstrakcją. Taki moduł może być zamknięty dla modyfikacji, ponieważ zależy od abstrakcji, która jest ustalona. Pomimo to zachowania tego modułu można rozszerzać poprzez tworzenie nowych pochodnych abstrakcji. Na rysunku 9.1 pokazano prosty projekt, który nie przestrzega zasady OCP. Zarówno klasa Client, jak i Server są konkretne. Klasa Client używa klasy Server. Gdybyśmy chcieli, aby obiekt Client używał innego obiektu serwera, to musielibyśmy zmienić klasę Client, wprowadzając w niej nazwę nowej klasy serwera.

Rysunek 9.1. Klasa Client nie jest otwarta ani zamknięta

Na rysunku 9.2 pokazano odpowiednik projektu z rysunku 9.1, ale taki, który spełnia zasadę OCP. W tym przypadku klasa ClientInterface jest klasą abstrakcyjną zawierającą abstrakcyjne funkcje składowe. Klasa Client korzysta z tej abstrakcji, jednak obiekty klasy Client będą używały obiektów pochodnych klasy Server. Gdybyśmy chcieli, aby obiekty Client używały innego obiektu serwera, to możemy utworzyć pochodną klasy ClientInterface. Klasa Client może pozostać bez zmian. 3

Język programowania obiektowego — ang. Object-oriented programming language.

APLIKACJA SHAPE

119

Klasa Client ma do wykonania pewną pracę. Może opisywać tę pracę w kategoriach abstrakcyjnego interfejsu udostępnianego przez klasę ClientInterface. Podtypy klasy ClientInterface mogą implementować ten interfejs w dowolny sposób. Tak więc zachowanie określone w klasie Client może być rozszerzane i modyfikowane poprzez stworzenie nowych klas pochodnych klasy ClientInterface.

Rysunek 9.2. Wzorzec Strategia: klasa Client jest równocześnie otwarta i zamknięta

Czytelnik może się zastanawiać, dlaczego nazwałem klasę ClientInterface w taki sposób. Dlaczego nie nazwałem jej AbstractServer? Powodem tej decyzji, jak przekonasz się później, jest fakt, że klasy abstrakcyjne są bliżej powiązane ze swoimi klientami niż z klasami, które je implementują. Alternatywną strukturę pokazano na rysunku 9.3. Klasa Policy zawiera zbiór konkretnych funkcji publicznych, które implementują określoną strategię. Podobnie do funkcji klasy Client z rysunku 9.2 te funkcje opisują pewną pracę do wykonania w kategoriach abstrakcyjnych interfejsów. Jednak w tym przypadku abstrakcyjne interfejsy są częścią samej klasy Policy. W C++ byłyby one czystymi funkcjami wirtualnymi, natomiast w Javie — metodami abstrakcyjnymi. Funkcje te są implementowane w typach podrzędnych klasy Policy. Tak więc zachowania określone wewnątrz klasy Policy mogą być rozszerzane lub modyfikowane poprzez stworzenie nowych pochodnych klasy Policy.

Rysunek 9.3. Wzorzec Metoda szablonowa — klasa bazowa jest otwarta i zamknięta

Te dwa wzorce są najbardziej popularnymi sposobami spełnienia zasady OCP. Reprezentują czytelną separację generycznej funkcjonalności od szczegółowej implementacji tej funkcjonalności.

Aplikacja Shape Przykład zaprezentowany poniżej był prezentowany w wielu książkach poświęconym projektom obiektowym. To osławiony przykład „Shape”. Zazwyczaj jest on stosowany do pokazania, jak działa polimorfizm. Jednak tym razem użyjemy go do wyjaśnienia zasady OCP. Mamy aplikację, która musi mieć możliwość rysowania okręgów i prostokątów na standardowym GUI. Okręgi i kwadraty muszą być rysowane w określonej kolejności. Po utworzeniu listy okręgów i kwadratów w odpowiedniej kolejności program powinien przeglądać tę listę w takiej samej kolejności i rysować każdy okrąg lub kwadrat.

120

ROZDZIAŁ 9. OCP — ZASADA OTWARTE-ZAMKNIĘTE

Naruszenie zasady OCP W języku C, stosując techniki proceduralne, które nie są zgodne z OCP, możemy rozwiązać ten problem tak, jak pokazano na listingu 9.1. Widzimy tam zestaw struktur danych, które mają taki sam pierwszy element, ale poza tym są różne. Pierwszy element każdej struktury jest kodem typu, który identyfikuje strukturę danych jako okrąg lub kwadrat. Funkcja DrawAllShapes przegląda tablicę wskaźników na te struktury danych, sprawdza kod typu, a następnie wywołuje właściwą funkcję (DrawCircle lub DrawSquare). Listing 9.1. Proceduralne rozwiązanie problemu kwadrat/okrąg --shape.h--------------------------------------enum ShapeType {circle, square}; struct Shape { ShapeType itsType; };

--circle.h--------------------------------------struct Circle { ShapeType itsType; double itsRadius; Point itsCenter; };

void DrawCircle(struct Circle*);

--square.h--------------------------------------struct Square { ShapeType itsType; double itsSide; Point itsTopLeft; };

void DrawSquare(struct Square*);

--drawAllShapes.cc------------------------------typedef struct Shape *ShapePointer;

void DrawAllShapes(ShapePointer list[], int n) { int i; for (i=0; iitsType) { case square: DrawSquare((struct Square*)s); break;

}

}

case circle: DrawCircle((struct Circle*)s); break; }

Funkcja DrawAllShapes nie spełnia zasady OCP, ponieważ nie można jej zamknąć dla nowych rodzajów figur. Gdybym chciał rozszerzyć tę funkcję tak, aby móc narysować listę figur, która zawiera trójkąty, musiałbym zmodyfikować tę funkcję. W rzeczywistości musiałbym zmodyfikować funkcję dla każdego nowego rodzaju figury, którą chciałbym narysować.

APLIKACJA SHAPE

121

Oczywiście ten program jest tylko prostym przykładem. W praktyce instrukcja switch w funkcji DrawAllShapes byłaby powtarzana w kółko w różnych funkcjach w aplikacji, a każda robiłaby coś innego. Mogłyby być to funkcje do przeciągania figur, rozciągania ich, przenoszenia, usuwania itp. Dodanie nowej figury do takiej aplikacji oznacza polowanie na wszystkie miejsca, w których występują takie instrukcje switch (lub ciągi instrukcji if-else), i dodawanie do każdej z instrukcji nowej figury. Co więcej, jest bardzo mało prawdopodobne, aby wszystkie instrukcje switch oraz klauzule if/else miały taką czytelną strukturę jak ta w funkcji DrawAllShapes. Jest o wiele bardziej prawdopodobne, że predykaty instrukcji if będą połączone za pomocą operatorów logicznych lub że klauzule case instrukcji switch będą ze sobą połączone tak, aby „uprościć” lokalne podejmowanie decyzji. W pewnych patologicznych sytuacjach mogą istnieć funkcje, które wykonują dokładnie te same operacje na obiektach Square co na obiektach Circle. W takich funkcjach może nawet brakować instrukcji switch/case lub łańcuchów instrukcji if/else. W takim przypadku problem znalezienia i zrozumienia wszystkich miejsc, w których trzeba dodać nową figurę, może nie być trywialny. Rozważmy także rodzaj zmian, jakie trzeba by było wprowadzić. Trzeba by dodać nową składową do typu wyliczeniowego ShapeType. Ponieważ wszystkie figury zależą od deklaracji w tym typie wyliczeniowym, trzeba by je wszystkie na nowo skompilować4. Trzeba by także skompilować wszystkie moduły, które zależą od modułu Shape. Tak więc nie tylko musielibyśmy zmienić kod źródłowy wszystkich instrukcji switch/case lub łańcuchów if/else, ale także musielibyśmy zmienić pliki binarne (poprzez ponowną kompilację) wszystkich modułów, które używają dowolnej struktury danych z modułu Shape. Zmiana plików binarnych oznacza, że wszystkie pliki DLL, biblioteki współdzielone lub inne rodzaje komponentów binarnych trzeba zainstalować na nowo. Prosty akt dodania nowej figury do aplikacji powoduje kaskadę kolejnych zmian w wielu modułach źródłowych i jeszcze więcej zmian w modułach i komponentach binarnych. Jest oczywiste, że dodanie nowej figury wywiera olbrzymi wpływ na aplikację. Zły projekt. Spróbujmy jeszcze raz przeanalizować aplikację. Rozwiązanie z listingu 9.1 jest sztywne, ponieważ dodanie funkcji Triangle powoduje konieczność ponownej kompilacji i instalacji funkcji Shape, Square, Circle i DrawAllShapes. Jest również kruche, ponieważ zawiera wiele instrukcji switch-case lub if-else, które zarówno trudno odnaleźć, jak i odszyfrować. Jest niemobilne, ponieważ każdy, kto spróbuje wykorzystać funkcję DrawAllShapes w innym programie, będzie zmuszony przenieść razem z nią funkcje Square i Circle nawet wtedy, gdy ten nowy program nie potrzebuje ich. A zatem kod z listingu 9.1 wykazuje wiele zapachów złego projektu.

Zachowanie zgodności z zasadą OCP Na listingu 9.2 pokazano rozwiązanie problemu kwadratów i okręgów, które jest zgodne z zasadą OCP. W tym przypadku napisaliśmy klasę abstrakcyjną o nazwie Shape. Ta klasa abstrakcyjna zawiera pojedynczą metodę abstrakcyjną Draw. Zarówno Circle, jak i Square są klasami pochodnymi klasy Shape. Listing 9.2. Obiektowe rozwiązanie problemu kwadrat/okrąg class Shape { public: virtual void Draw() const = 0; }; 4

Zmiany w typach wyliczeniowych mogą spowodować zmiany rozmiaru zmiennych wykorzystywanych do ich przechowywania. Dlatego w przypadku podjęcia decyzji o tym, że nie trzeba kompilować innych deklaracji figur, należy zachować szczególną ostrożność.

122

ROZDZIAŁ 9. OCP — ZASADA OTWARTE-ZAMKNIĘTE

class Square : public Shape { public: virtual void Draw() const; }; class Circle : public Shape { public: virtual void Draw() const; }; void DrawAllShapes(vector& list) { vector::iterator i; for (i=list.begin(); i != list.end(); i++) (*i)->Draw(); }

Zwróćmy uwagę, że aby rozszerzyć zachowanie funkcji DrawAllShapes z listingu 9.2 w taki sposób, by narysować nową figurę, wystarczy dodać nową pochodną klasy Shape. W tym celu nie trzeba zmieniać funkcji DrawAllShapes. A zatem funkcja DrawAllShapes jest zgodna z zasadą OCP. Jej zachowanie można rozszerzyć bez wprowadzania modyfikacji. W rzeczywistości dodanie klasy Triangle nie ma absolutnie żadnego wpływu na żaden z modułów, które są tu pokazane. Jest oczywiste, że pewne części systemu trzeba zmienić w celu obsługi klasy Triangle, ale cały kod pokazany powyżej jest odporny na zmiany. W rzeczywistej aplikacji klasa Shape miałaby znacznie więcej metod. Pomimo to dodanie nowej figury do aplikacji w dalszym ciągu jest dość proste, ponieważ wystarczy tylko utworzyć nową pochodną i zaimplementować wszystkie jej funkcje. Nie ma potrzeby przeglądania całej aplikacji i wyszukiwania miejsc, które wymagają wprowadzenia zmian. To rozwiązanie nie jest kruche. Rozwiązanie nie jest również sztywne. Nie trzeba modyfikować żadnych istniejących modułów źródłowych i, z jednym wyjątkiem, nie trzeba przebudowywać żadnych modułów binarnych. Zmodyfikować trzeba tylko ten moduł, który tworzy nową pochodną klasy Shape. Zwykle ta czynność jest wykonywana w funkcji main, w jakiejś funkcji wywoływanej przez main albo w jakiejś metodzie obiektu tworzonego przez funkcję main5. I na koniec: pokazane rozwiązanie nie jest niemobilne. Funkcja DrawAllShapes może być wykorzystana w dowolnej aplikacji i aby z niej skorzystać, nie trzeba dołączać klas Square lub Circle. A zatem zaprezentowane rozwiązanie nie wykazuje żadnego z wymienionych wcześniej atrybutów złego projektu. Ten program jest zgodny z zasadą OCP. Zmienia się go poprzez dodawanie nowego kodu, a nie poprzez zmianę istniejącego kodu. Z tego powodu w programie nie ma potrzeby wprowadzania kaskady zmian tak jak w przypadku programu, który nie jest zgodny z zasadą OCP. Jedynymi wymaganymi zmianami jest dodawanie nowego modułu oraz zmiany w funkcji main związane z tworzeniem egzemplarzy nowych obiektów.

Przyznaję się. Kłamałem Poprzedni przykład pokazuje sytuację idealną. Zastanówmy się, co by się stało z funkcją DrawAllShapes z listingu 9.2, gdybyśmy zdecydowali, że wszystkie okręgi powinny być narysowane przed wszystkimi kwadratami. Funkcja DrawAllShapes nie jest zamknięta na zmiany tego rodzaju. Aby zaimplementować taką zmianę, należy przejść do funkcji DrawAllShapes, a następnie zeskanować listę — najpierw w celu wyszukania wszystkich okręgów, a następnie ponownie w celu znalezienia wszystkich kwadratów.

Przewidywanie i „naturalna” struktura Gdybyśmy przewidzieli tego rodzaju zmianę, to moglibyśmy wymyślić abstrakcję, która ochroniłaby nas przed problemami wymienionymi wcześniej. Abstrakcje wybrane na listingu 9.2 są raczej przeszkodą dla tego typu zmian niż pomocą. Może się to wydawać zaskakujące. W końcu cóż bardziej naturalnego 5

Takie obiekty są tzw. fabrykami. Więcej informacji na ich temat można znaleźć w rozdziale 21.

APLIKACJA SHAPE

123

moglibyśmy wymyślić od klasy bazowej Shape z klasami pochodnymi Square i Circle? Dlaczego ten naturalny model nie jest najlepszym wzorcem, jaki można zastosować? Odpowiedź jest taka, że ten model nie jest naturalny w systemie, w którym kolejność jest bardziej znacząca niż typ figury. To prowadzi nas do niepokojącego wniosku. Ogólnie rzecz biorąc, bez względu na to, jak „zamknięty” jest określony moduł, zawsze będzie jakaś zmiana, w stosunku do której nie jest on zamknięty. Nie istnieje taki model, który byłby naturalny we wszystkich kontekstach. Ponieważ domknięcie nie może być pełne, musi być strategiczne. Oznacza to, że projektant musi wybrać takie rodzaje zmian, wobec których decyduje się zamknąć swój projekt. Musi odgadnąć najbardziej prawdopodobne rodzaje zmian, a następnie zbudować abstrakcje, które będą chronić go przed tymi zmianami. To wymaga pewnej umiejętności przewidywania, która pochodzi z doświadczenia. Doświadczony projektant zna użytkowników i branżę na tyle dobrze, aby właściwie ocenić prawdopodobieństwo wystąpienia różnego rodzaju zmian. Następnie stosuje zasadę OCP dla najbardziej prawdopodobnych zmian. Nie jest to łatwe. Umiejętność ta sprowadza się do odgadywania możliwych rodzajów zmian, jakie będą wprowadzane w aplikacji z biegiem czasu. Kiedy deweloper dobrze odgadnie te zmiany, jest zwycięzcą. Kiedy odgadnie nieprawidłowo, poniesie porażkę. I na pewno bardzo często będzie mu się zdarzało zgadywać źle. Co więcej, zachowanie zgodności z zasadą OCP jest kosztowne. Stworzenie odpowiednich abstrakcji wymaga czasu i wysiłku. Opracowane abstrakcje zwiększają również złożoność projektu oprogramowania. Istnieje ograniczenie liczby abstrakcji, na które deweloper może sobie pozwolić. Oczywiście chcemy ograniczyć stosowanie zasady OCP do zmian, które są prawdopodobne. Skąd wiadomo, że zmiany są prawdopodobne? Należy przeprowadzić odpowiednie analizy, zadać odpowiednie pytania oraz wykorzystać doświadczenie i zdrowy rozsądek. I przede wszystkim należy czekać do chwili, aż wystąpią zmiany.

Umieszczanie „haczyków” W jaki sposób zabezpieczyć się przed zmianami? W poprzednim wieku stosowano prostą zasadę. Umieszczano „haczyki” dla zmian, które przewidywano. Sądzono, że dzięki temu oprogramowanie stanie się elastyczne. Jednak haczyki, które wprowadzano, często były nieprawidłowe. Co gorsza, wykazywały woń zbytecznej złożoności, którą trzeba było obsłużyć i utrzymać nawet wtedy, gdy nie było dla niej zastosowania. To nie jest dobre. Nie chcemy, aby projekt był przeładowany dużą ilością niepotrzebnych abstrakcji. Przeciwnie, często czekamy, aż abstrakcja stanie się potrzebna, i dopiero wtedy ją wprowadzamy. Nabierz mnie raz... Jest takie stare powiedzenie: „Nabierz mnie raz, hańba dla ciebie. Nabierz mnie dwa razy, hańba dla mnie”. To powiedzenie niesie wielką mądrość dla projektowania oprogramowania. Aby zabezpieczyć nasze oprogramowanie przed ładowaniem niepotrzebną złożonością, możemy sobie pozwolić, by dać się nabrać raz. Oznacza to, że początkowo możemy napisać oprogramowanie tak, jakbyśmy oczekiwali, że nie będzie się ono zmieniać. Kiedy nastąpi zmiana, implementujemy abstrakcje, które chronią nas przed przyszłymi zmianami tego rodzaju. Krótko mówiąc, przyjmujemy pierwszą kulę, a następnie staramy się zadbać o to, abyśmy nie zostali trafieni żadną z kul pochodzących z tej broni. Stymulowanie zmian. Jeśli zdecydujemy się przyjąć pierwszą kulę, to z korzyścią dla nas jest sytuacja, w której kule latają wcześnie i często. Chcemy wiedzieć, jakie rodzaje zmian są prawdopodobne, zanim znajdziemy się zbyt daleko na ścieżce rozwoju. Im więcej czasu zajmie nam określenie prawdopodobnych zmian, tym trudniejsze będzie stworzenie właściwych abstrakcji.

124

ROZDZIAŁ 9. OCP — ZASADA OTWARTE-ZAMKNIĘTE

Dlatego trzeba stymulować zmiany. Robi się to za pomocą różnych mechanizmów, które omówiliśmy w rozdziale 2.  Najpierw piszemy testy. Testowanie jest jednym z rodzajów używania systemu. Dzięki pisaniu testów

   

najpierw zmuszamy system do tego, by był sprawdzalny. Dzięki temu zmiany w sprawdzalności nie zaskoczą nas później. Utworzymy bowiem abstrakcje, dzięki którym system stanie się sprawdzalny. Jak się przekonamy, wiele z tych abstrakcji będzie chronić nas później przed innymi rodzajami zmian. Produkcja oprogramowania powinna odbywać się w bardzo krótkich cyklach — rzędu dni zamiast tygodni. Tworzymy funkcjonalności przed infrastrukturą i często prezentujemy te funkcjonalności interesariuszom. Najpierw tworzymy najbardziej istotne funkcjonalności. Wersje dystrybucyjne publikujemy wcześnie i często. Prezentujemy je naszym klientom i użytkownikom tak szybko i tak często, jak to możliwe.

Stosowanie abstrakcji w celu uzyskania jawnego domknięcia A zatem przyjęliśmy pierwszą kulę. Użytkownik chce narysować wszystkie okręgi przed dowolnymi z kwadratów. Teraz chcemy się zabezpieczyć przed dowolnymi zmianami tego rodzaju w przyszłości. W jaki sposób zamknąć funkcję DrawAllShapes na zmiany w kolejności rysowania? Należy pamiętać, że domknięcie bazuje na abstrakcji. Aby więc zamknąć funkcję DrawAllShapes przed zmianami kolejności, potrzebujemy jakiejś „abstrakcji kolejności”. To abstrakcja dostarczy abstrakcyjnego interfejsu, przez który mogą być wyrażane wszelkie możliwe strategie kolejności. Strategia kolejności implikuje, że jeśli mamy dowolne dwa obiekty, to zawsze możemy określić, który z nich powinien być narysowany jako pierwszy. Możemy zdefiniować abstrakcyjną metodę klasy Shape o nazwie Precedes. Ta funkcja przyjmuje inny obiekt klasy Shape jako argument i zwraca wynik typu bool. Funkcja zwraca wynik true, jeśli obiekt Shape, który otrzymuje komunikat, powinien być narysowany przed obiektem Shape przekazanym w roli argumentu. W języku C++ taką funkcję mógłby reprezentować przeciążony operator <. Na listingu 9.3 pokazano, jak mogłaby wyglądać klasa Shape, gdyby zaimplementowano w niej metody zarządzania kolejnością. Teraz kiedy mamy sposób określenia względnej kolejności dwóch obiektów Shape, możemy je posortować i narysować we właściwej kolejności. Na listingu 9.4 pokazano kod C++, który realizuję tę funkcjonalność. Listing 9.3. Klasa Shape z metodami zarządzania kolejnością class Shape { public: virtual void Draw() const = 0; virtual bool Precedes(const Shape&) const = 0; };

bool operator<(const Shape& s) {return Precedes(s);}

Listing 9.4. Funkcja DrawAllShapes z obsługą kolejności template class Lessp // narzędzie sortowania kontenerów wskaźników. { public: bool operator()(const P p, const P q) {return (*p) < (*q);} }; void DrawAllShapes(vector& list) { vector orderedList = list;

APLIKACJA SHAPE

125

sort(orderedList.begin(), orderedList.end(), Lessp());

}

vector::const_iterator i; for (i=orderedList.begin(); i != orderedList.end(); i++) (*i)->Draw();

W ten sposób uzyskaliśmy mechanizmy porządkowania obiektów Shape oraz rysowania ich we właściwej kolejności. W dalszym ciągu nie mamy jednak odpowiedniej abstrakcji do zarządzania kolejnością. W obecnej formie pojedyncze obiekty Shape w celu określenia porządku będą musiały przesłaniać metodę Precedes. Jak mogłoby to działać? Jaki kod moglibyśmy napisać w metodzie Circle::Precedes, aby zapewnić narysowanie okręgów przed kwadratami? Rozważmy kod z listingu 9.5. Listing 9.5. Porządkowanie okręgów bool Circle::Precedes(const Shape& s) const { if (dynamic_cast(s)) return true; else return false; }

Jak można zauważyć, ta funkcja oraz wszystkie funkcje Precedes zdefiniowane w innych klasach pochodnych klasy Shape nie są zgodne z zasadą OCP. Nie ma sposobu, aby zamknąć je na nowe pochodne klasy Shape. Za każdym razem po utworzeniu nowej pochodnej klasy Shape trzeba będzie zmienić wszystkie funkcje Precedes()6. Oczywiście to nie ma znaczenia, jeśli nowe pochodne klasy Shape nigdy nie będą tworzone. Z drugiej strony, gdyby były tworzone często, to ten projekt powodowałby konieczność wykonywania sporej pracy. Tak jak wspominałem — przyjmujemy pierwszą kulę.

Zastosowanie podejścia „sterowania danymi” w celu uzyskania domknięcia Jeśli trzeba zamknąć pochodne klasy Shape przed koniecznością wiedzy o sobie nawzajem, możemy użyć podejścia bazującego na tabeli. Jedną z możliwości implementacji takiego podejścia pokazano na listingu 9.6. Listing 9.6. Mechanizm porządkowania typów bazujący na tabeli #include #include #include using namespace std; class Shape { public: virtual void Draw() const = 0; bool Precedes(const Shape&) const; bool operator<(const Shape& s) const {return Precedes(s);} private: static const char* typeOrderTable[]; }; const char* Shape::typeOrderTable[] = 6

Istnieje możliwość rozwiązania tego problem za pomocą wzorca projektowego Acykliczny wizytator (ang. Acyclic visitor) opisanego w rozdziale 29. Pokazywanie tego rozwiązania teraz byłoby trochę przedwczesne. Pod koniec rozdziału 29. przypomnę Ci, abyś powrócił do tego przykładu.

126

{

};

ROZDZIAŁ 9. OCP — ZASADA OTWARTE-ZAMKNIĘTE

typeid(Circle).name(), typeid(Square).name(), 0

// Ta funkcja wyszukuje nazwy klas w tabeli. // Tabela definiuje kolejność, w jakiej // mają być narysowane figury. Figura, której nie ma w tabeli, // zawsze poprzedza te, które w tabeli są. // bool Shape::Precedes(const Shape& s) const { const char* thisType = typeid(*this).name(); const char* argType = typeid(s).name(); bool done = false; int thisOrd = -1; int argOrd = -1; for (int i=0; !done; i++) { const char* tableEntry = typeOrderTable[i]; if (tableEntry != 0) { if (strcmp(tableEntry, thisType) == 0) thisOrd = i; if (strcmp(tableEntry, argType) == 0) argOrd = i; if ((argOrd >= 0) && (thisOrd >= 0)) done = true; } else // table entry == 0 done = true; } return thisOrd < argOrd; }

Zastosowanie takiego podejścia pozwoliło pomyślnie zamknąć funkcję DrawAllShapes przed problemami porządkowania oraz wszystkie pochodne klasy Shape przed tworzeniem nowych pochodnych klasy Shape lub zmianami w strategii porządkowania obiektów Shape (np. zmianą kolejności w taki sposób, że kwadraty będą rysowane przed okręgami). Jedynym elementem, który nie jest zamknięty przed problemami kolejności różnych obiektów Shape, jest tabela. Tabelę tę można umieścić w osobnym module, oddzielonym od innych modułów. Dzięki temu zmiany, które są w niej wprowadzone, nie mają wpływu na żadne inne moduły. W języku C++ moglibyśmy wybrać tabelę, która ma być zastosowana w fazie konsolidacji.

Wniosek Pod wieloma względami zasada OCP stanowi centrum projektowania obiektowego. Zgodność z tą zasadą daje największe korzyści, jakie przynosi zastosowanie technologii obiektowej (np. elastyczność, wymienność i łatwość konserwacji). Jednak zgodności z tą zasadą nie uzyskuje się wyłącznie dzięki zastosowaniu obiektowego języka programowania. Nie jest też dobrym pomysłem stosowanie szalonych abstrakcji do każdej części aplikacji. Deweloperzy powinni dążyć do tego, aby abstrakcje były stosowane tylko do tych części programu, które często się zmieniają. Przeciwdziałanie przedwczesnym abstrakcjom jest tak samo ważne jak same abstrakcje.

Bibliografia 1. Ivar Jacobson, et al. Object-Oriented Software Engineering, Reading, MA: Addison-Wesley, 1992. 2. Bertrand Meyer, Object-Oriented Software Construction, wydanie drugie, Upper Saddle River, NJ: Prentice Hall, 1997.

R OZDZIAŁ 10

LSP — zasada podstawiania Liskov

Podstawowymi mechanizmami stojącymi za zasadą OCP są abstrakcja i polimorfizm. W językach o typowaniu statycznym, takich jak C++ i Java, jednym z kluczowych mechanizmów wspierających abstrakcję i polimorfizm jest dziedziczenie. To dzięki dziedziczeniu możemy tworzyć klasy pochodne, które implementują abstrakcyjne metody klas bazowych. Jakie są zasady projektowania, które regulują to konkretne zastosowanie dziedziczenia? Jakie są cechy najlepszych hierarchii dziedziczenia? Jakie są pułapki mogące spowodować, że utworzone hierarchie nie są zgodne z zasadą OCP? Odpowiedzią na te pytania jest zasada podstawiania Liskov (ang. Liskov Substitution Principle — LSP).

LSP — zasada podstawiania Liskov Zasadę LSP można wyrazić następująco: Musi być możliwość podstawienia typów pochodnych za ich typy bazowe. Barbara Liskov po raz pierwszy zapisała tę zasadę w 1988 roku1. Napisała: Poszukujemy następującej właściwości podstawiania: Jeśli dla każdego obiektu o 1 typu S istnieje obiekt o2 typu T taki, że dla wszystkich programów P zdefiniowanych w kategoriach T zachowanie P pozostanie niezmienione, gdy o1 zostanie podstawione za o2, to S jest podtypem T. Znaczenie tej zasady staje się oczywiste, jeśli weźmie się pod uwagę konsekwencje jej naruszenia. Załóżmy, że mamy funkcję f, która pobiera jako argument wskaźnik lub referencję do jakiejś klasy bazowej B. Załóżmy również, że istnieje jakaś pochodna D klasy B, która gdy zostanie przekazana do f w „przebraniu” B, powoduje, że funkcja f zachowuje się nieprawidłowo. W takim przypadku klasa D narusza zasadę LSP. Jest oczywiste, że klasa D jest krucha w obecności f. 1

[Liskov 88].

128

ROZDZIAŁ 10. LSP — ZASADA PODSTAWIANIA LISKOV

Autorzy funkcji f mogą ulec pokusie stworzenia pewnego rodzaju testu dla D tak, aby funkcja f zachowywała się poprawnie, gdy zostanie do niej przekazany obiekt klasy D. Taki test narusza zasadę OCP, ponieważ funkcja f nie jest zamknięta na wszystkie pochodne klasy B. Tego rodzaju testy są świadectwem brzydkiego zapachu kodu, który powstał w wyniku błędu niedoświadczonych deweloperów (lub, co gorsza, deweloperów, którzy się śpieszą) w reakcji na naruszenie zasady LSP.

Prosty przykład naruszenia zasady LSP Naruszenie zasady LSP często wynika z wykorzystania informacji o typie dostępnej w fazie wykonywania programu (ang. Run-Time Type Information — RTTI) w sposób rażąco naruszający zasadę OCP. Bardzo często do określenia typu obiektu w celu wybrania zachowania odpowiedniego do tego typu wykorzystywane są jawne instrukcje if lub łańcuchy instrukcji if-else. Rozważmy kod z listingu 10.1. Listing 10.1. Naruszenie zasady LSP powodujące naruszenie zasady OCP struct Point {double x,y;}; struct Shape { enum ShapeType {square, circle} itsType; Shape(ShapeType t) : itsType(t) {} }; struct Circle : public Shape { Circle() : Shape(circle) {}; void Draw() const; Point itsCenter; double itsRadius; }; struct Square : public Shape { Square() : Shape(square) {}; void Draw() const; Point itsTopLeft; double itsSide; }; void DrawShape(const Shape& s) { if (s.itsType == Shape::square) static_cast(s).Draw(); else if (s.itsType == Shape::circle) static_cast(s).Draw(); }

Jest oczywiste, że funkcja DrawShape z listingu 10.1 narusza zasadę OCP. Musi „wiedzieć” o każdej możliwej pochodnej klasy Shape i musi być zmieniana po utworzeniu każdej nowej pochodnej klasy Shape. Rzeczywiście, wiele osób słusznie uzna strukturę tej funkcji za przeciwieństwo dobrego projektu. Co mogłoby skłonić programistę do napisania takiej funkcji? Spróbujmy wcielić się w postać inżyniera Jerzego. Jerzy studiuje techniki obiektowe i doszedł do wniosku, że koszty stosowania polimorfizmu są zbyt wysokie 2. Z tego powodu zdefiniował klasę Shape bez żadnych funkcji wirtualnych. Klasy (struktury) Square i Circle są pochodnymi klasy Shape i mają funkcje Draw(), ale nie przesłaniają one funkcji z klasy Shape. Ponieważ nie można podstawić obiektów Circle i Square za Shape, funkcja DrawShape musi sprawdzać argument wejściowy Shape, określić jego typ, a następnie wywołać odpowiednią metodę Draw. 2

Na stosunkowo szybkiej maszynie te koszty są rzędu 1 ns na jedno wywołanie metody. Trudno zatem zgodzić się z punktem widzenia Jerzego.

KWADRATY I PROSTOKĄTY — BARDZIEJ SUBTELNE NARUSZENIE ZASADY LSP

129

To, że obiektów Square i Circle nie można podstawić za Shape, jest naruszeniem zasady LSP. To naruszenie wymusza naruszenie zasady OCP przez funkcję DrawShape. A zatem naruszenie zasady LSP jest ukrytym naruszeniem zasady OCP.

Kwadraty i prostokąty — bardziej subtelne naruszenie zasady LSP Oczywiście istnieją inne, o wiele bardziej subtelne sposoby naruszania zasady LSP. Rozważmy aplikację, która wykorzystuje klasę Rectangle zamieszczoną na listingu 10.2. Listing 10.2. Klasa Rectangle class Rectangle { public: void SetWidth(double w) void SetHeight(double h) double GetHeight() const double GetWidth() const private: Point itsTopLeft; double itsWidth; double itsHeight; };

{itsWidth=w;} {itsHeight=w;} {return itsHeight;} {return itsWidth;}

Wyobraźmy sobie, że ta aplikacja dobrze działa i jest zainstalowana w wielu miejscach. Tak jak w przypadku wszystkich programów, które odniosły sukces, jej użytkownicy od czasu do czasu żądają zmian. Pewnego dnia użytkownicy zaczęli domagać się możliwości manipulowania kwadratami oprócz prostokątów. Często uważa się, że dziedziczenie jest relacją IS-A. Innymi słowy, jeśli o nowym rodzaju obiektu można powiedzieć, że spełnia relację IS-A z obiektem starego typu, to klasa nowego obiektu powinna być pochodną klasy starego obiektu. Dla wszystkich normalnych zastosowań i celów kwadrat jest prostokątem. W związku z tym logiczne jest postrzeganie klasy Square jako pochodnej klasy Rectangle (patrz rysunek 10.1).

Rysunek 10.1. Klasa Square dziedziczy po klasie Rectangle

Takie zastosowanie relacji IS-A czasami uważa się za jedną z podstawowych technik analizy obiektowej3: kwadrat jest prostokątem, a zatem klasa Square powinna dziedziczyć po klasie Rectangle. Jednak takie myślenie może prowadzić do pewnych subtelnych, a jednak znaczących problemów. Ogólnie rzecz biorąc, tego typu problemy nie są przewidywane do czasu, aż widzimy je w kodzie. Pierwszą wskazówką informującą, że coś poszło nie tak, może być fakt, że klasa Square nie potrzebuje obydwu zmiennych składowych itsHeight oraz itsWidth. Pomimo tego odziedziczy je z klasy Rectangle. Oczywiście jest to marnotrawstwo. W wielu przypadkach to marnotrawstwo jest bez znaczenia. Ale jeśli trzeba tworzyć setki tysięcy obiektów Square (np. w programie CAD/CAE, w którym każdy pin każdego komponentu złożonego układu jest rysowany jako kwadrat), to marnotrawstwo może być znaczące. 3

Termin ten jest często używany, ale rzadko definiowany.

130

ROZDZIAŁ 10. LSP — ZASADA PODSTAWIANIA LISKOV

Załóżmy na chwilę, że nie bardzo interesuje nas ekonomiczna gospodarka pamięcią. Są też inne problemy, które wynikają z faktu dziedziczenia klasy Square z klasy Rectangle. Klasa Square odziedziczy funkcje SetWidth i SetHeight. Funkcje te są nieodpowiednie dla klasy Square, ponieważ szerokość i wysokość kwadratu są identyczne. To wyraźnie wskazuje na występowanie problemu. Istnieje jednak sposób, aby ominąć ten problem. Można przesłonić metody SetWidth i SetHeight w następujący sposób: void Square::SetWidth(double w) { Rectangle::SetWidth(w); Rectangle::SetHeight(w); } void Square::SetHeight(double h) { Rectangle::SetHeight(h); Rectangle::SetWidth(h); }

Teraz gdy ktoś ustawi szerokość obiektu Square, jego wysokość odpowiednio się zmieni. Z kolei gdy ktoś ustawi wysokość, razem z nią zmieni się także szerokość. A zatem niezmienniki4 klasy Square pozostają nienaruszone. Obiekt Square pozostanie poprawnym kwadratem z punktu widzenia matematyki. Square s; s.SetWidth(1); // Na szczęście ustawia także wysokość na 1. s.SetHeight(2); // Ustawia szerokość i wysokość na 2. To dobrze.

Rozważmy jednak następującą funkcję: void f(Rectangle& r) { r.SetWidth(32); // wywołuje Rectangle::SetWidth }

Jeśli do tej funkcji przekażemy referencję do obiektu Square, to obiekt Square znajdzie się w nieprawidłowym stanie, ponieważ wysokość się nie zmieni. To jawne naruszenie zasady LSP. Funkcja f nie działa z obiektami będącymi pochodnymi jej argumentów. Powodem niepowodzenia był fakt, że metody SetWidth i SetHeight nie zostały zadeklarowane w klasie Rectangle jako wirtualne. Z tego powodu nie są one polimorficzne. Można to łatwo naprawić. Jednak gdy utworzenie klasy pochodnej powoduje konieczność wprowadzania zmian w klasie bazowej, często oznacza to, że projekt jest wadliwy. Z pewnością projekt narusza zasadę OCP. Można by na to odpowiedzieć, że prawdziwą wadą projektu było niezadeklarowanie metod SetWidth i SetHeight jako wirtualnych i że teraz to naprawiamy. Jest to jednak trudne do udowodnienia, ponieważ ustawienie wysokości i szerokości prostokąta to niezwykle prymitywne operacje. Nie istnieje sensowne wytłumaczenie, aby były zadeklarowane jako wirtualne, skoro nie przewidzieliśmy istnienia klasy Square. Załóżmy, że zaakceptowaliśmy ten argument i naprawiliśmy klasy. Otrzymaliśmy kod pokazany na listingu 10.3. Listing 10.3. Wewnętrznie spójne klasy Rectangle i Square class Rectangle { public: virtual void SetWidth(double w) {itsWidth=w;} virtual void SetHeight(double h) {itsHeight=h;} double GetHeight() const {return itsHeight;} double GetWidth() const {return itsWidth;} private: 4

Są to właściwości, które zawsze muszą być prawdziwe, niezależnie od stanu.

KWADRATY I PROSTOKĄTY — BARDZIEJ SUBTELNE NARUSZENIE ZASADY LSP

};

131

Point itsTopLeft double itsHeight; double itsWidth;

class Square : public Rectangle { public: virtual void SetWidth(double w); virtual void SetHeight(double h); }; void Square::SetWidth(double w) { Rectangle::SetWidth(w); Rectangle::SetHeight(w); } void Square::SetHeight(double h) { Rectangle::SetHeight(h); Rectangle::SetWidth(h); }

Prawdziwy problem Wydaje się, że klasy Square i Rectangle działają teraz właściwie. Niezależnie od operacji, jaką wykonujemy na obiekcie Square, pozostanie on prawidłowym matematycznie kwadratem. Niezależnie od operacji, jaką wykonamy na obiekcie Rectangle, pozostanie on prawidłowym matematycznie prostokątem. Co więcej, można przekazać obiekt Square do funkcji, która akceptuje wskaźnik lub referencję do obiektu Rectangle, a obiekt Square nadal będzie zachowywał się jak kwadrat i pozostanie wewnętrznie spójny. Tak więc można wyciągnąć wniosek, że projekt jest teraz wewnętrznie spójny i prawidłowy. Jednak ten wniosek będzie nieprawdziwy. Projekt, który jest wewnętrznie spójny, niekoniecznie jest spójny z poziomu wszystkich jego użytkowników! Przeanalizujmy następującą funkcję g: void g(Rectangle& r) { r.SetWidth(5); r.SetHeight(4); assert(r.Area() == 20); }

Ta funkcja wywołuje metody SetWidth i SetHeight z argumentem, który z jej punktu widzenia jest obiektem klasy Rectangle. Funkcja działa prawidłowo dla obiektów Rectangle, ale w przypadku przekazania obiektu Square zgłasza błąd asercji. A zatem istnieje realny problem. Autor funkcji g założył, że zmiana szerokości obiektu Rectangle nie zmieni jego wysokości. Założenie, że zmiana szerokości prostokąta nie wpływa na jego wysokość, jest oczywiście rozsądne! Pomimo tego nie wszystkie obiekty, które mogą być przekazane jako obiekty Rectangle, spełniają to założenie. Jeśli przekażemy egzemplarz klasy Square do takiej funkcji jak g (której autor przyjął takie założenie), to funkcja ta nie będzie działać prawidłowo. Funkcja g jest krucha pod względem hierarchii Square-Rectangle. Funkcja g pokazuje, że istnieją funkcje, które pobierają wskaźniki bądź referencje do obiektów Rectangle, a pomimo to nie potrafią prawidłowo działać na obiektach klasy Square. Ponieważ dla tych funkcji obiektów Square nie można podstawić za Rectangle, relacja pomiędzy klasami Square i Rectangle narusza zasadę LSP. Można by się sprzeczać, że problem tkwi w funkcji g — że jej autor nie miał prawa przyjmować założenia o niezależności wysokości i szerokości. Autor funkcji g nie zgodziłby się z tym. Funkcja g pobiera obiekt klasy Rectagle jako swój argument. Istnieją niezmienniki, deklaracje prawdy, które oczywiście

132

ROZDZIAŁ 10. LSP — ZASADA PODSTAWIANIA LISKOV

mają zastosowanie do klasy o nazwie Rectangle. Jeden z tych niezmienników mówi nam, że wysokość jest niezależna od szerokości. Autor funkcji g miał pełne prawo do asercji tego niezmiennika. To autor klasy Square naruszył reguły wymienionego niezmiennika. Co ciekawe, autor klasy Square nie naruszył niezmienników klasy Square. Poprzez dziedziczenie klasy Square z klasy Rectangle autor klasy Square naruszył niezmiennik klasy Rectangle!

Poprawność nie jest wrodzona Zasada LSP prowadzi do bardzo ważnej konkluzji: Poprawność modelu analizowanego w odosobnieniu nie może być sensownie zweryfikowana. Poprawność modelu może być wyrażona wyłącznie w kategoriach jego klientów. Na przykład gdy analizowaliśmy ostateczną wersję klas Square i Rectangle w izolacji od siebie, doszliśmy do wniosku, że są one wewnętrznie spójne i prawidłowe. Jednak gdy spojrzeliśmy na nie z punktu widzenia programisty, który przyjął rozsądne założenia dotyczące klasy bazowej, model okazał się błędny. Kiedy rozważamy, czy dany projekt jest odpowiedni, czy nie, nie możemy analizować rozwiązania w izolacji. Trzeba analizować je pod kątem racjonalnych założeń przyjętych przez użytkowników tego projektu5. Kto wie, jakie rozsądne założenia przyjmą użytkownicy projektu? Większość takich założeń nie jest łatwa do przewidzenia. Rzeczywiście, gdybyśmy starali się je wszystkie przewidzieć, skończyłoby się na stworzeniu systemu z zapachem niepotrzebnej złożoności. Z tego względu podobnie jak w przypadku innych zasad często lepiej poczekać ze wszystkimi naruszeniami zasady LSP oprócz oczywistych do czasu wykrycia odpowiedniej wrażliwości.

Relacja IS-A dotyczy zachowania A zatem co się stało? Dlaczego z pozoru rozsądny model klas Square i Rectangle zawiódł? Czyż kwadrat nie jest prostokątem? Czy nie zachodzi pomiędzy nimi relacja IS-A? Otóż nie z punktu widzenia autora funkcji g! Kwadrat rzeczywiście jest prostokątem, ale z punktu widzenia funkcji g obiekt Square definitywnie nie jest obiektem Rectangle. Dlaczego tak jest? Ponieważ zachowanie obiektu Square nie jest spójne z oczekiwaniami funkcji g w zakresie zachowania obiektu Rectangle. Pod względem zachowania obiekt Square nie jest obiektem Rectangle, a to jest zachowanie, które ma dla tego oprogramowania kluczowe znaczenie. Zasada LSP wyraźnie pokazuje, że w projekcie obiektowym relacja IS-A dotyczy zachowania, jakie można rozsądnie założyć i od jakiego klienci są uzależnieni.

Projektowanie według kontraktu Wielu deweloperów może czuć się nieswojo z pojęciem zachowania, które jest „rozsądnie założone”. Skąd możemy wiedzieć, czego naprawdę oczekują klienci? Istnieje technika podejmowania takich rozsądnych założeń, a tym samym egzekwowania zasady LSP jawnie. Ta technika nosi nazwę projekt według kontraktu (ang. design by contract — DBC) i została opisana przez Bertranda Meyera6. W przypadku zastosowania techniki DBC autor klasy wyraźnie formułuje kontrakt dla tej klasy. Kontrakt informuje autora kodu dowolnego klienta o zachowaniach, na których można polegać. Kontrakt określa się poprzez deklarację warunków wstępnych i końcowych dla każdej metody. Warunki 5

Często można zauważyć, że te rozsądne założenia są przyjmowane w testach jednostkowych pisanych dla klasy bazowej. To kolejny dobry powód, by stosować techniki programowania sterowanego testami.

6

[Meyer 97], rozdział 11., str. 331.

REALNY PRZYKŁAD

133

wstępne muszą być spełnione, aby można było wykonać metodę. Po zakończeniu działania metoda gwarantuje spełnienie warunków końcowych. Warunek końcowy metody Rectangle::SetWidth(double w) można sformułować następująco: assert((itsWidth == w) && (itsHeight == old.itsHeight));

W tym przykładzie old jest wartością obiektu Rectangle przed wywołaniem metody SetWidth. Według Meyera dla warunków wstępnych i końcowych klas pochodnych zachodzi następująca reguła: Ponowna deklaracja reguły (w klasie potomnej) może zastępować pierwotny warunek wstępny tylko warunkiem równym lub słabszym, natomiast warunek końcowy tylko warunkiem równym lub mocniejszym7. Innymi słowy, w przypadku korzystania z obiektu za pośrednictwem interfejsu jego klasy bazowej użytkownik zna jedynie warunki wstępne i końcowe klasy bazowej. Tak więc obiekty pochodne nie mogą oczekiwać od użytkowników przestrzegania warunków wstępnych, które są silniejsze niż te, które wynikają z klasy bazowej. Oznacza to, że muszą one akceptować wszystko to, co może akceptować klasa bazowa. Ponadto klasy pochodne muszą spełniać wszystkie warunki końcowe klasy bazowej. Oznacza to, że ich zachowania i wyjścia nie mogą naruszać żadnego z ograniczeń ustanowionych dla klasy bazowej. Użytkownicy klasy bazowej nie mogą być zmyleni wynikami zwracanymi przez klasę pochodną. Warunek końcowy metody Square::SetWidth(double w) jest oczywiście słabszy8 od warunku końcowego metody Rectangle::SetWidth(double w), ponieważ nie wymusza on ograniczenia (itsHeight == old.its Height). A zatem metoda SetWidth klasy Square narusza kontrakt klasy bazowej. Niektóre języki, na przykład Eiffel, zawierają bezpośrednie wsparcie dla warunków wstępnych i końcowych. Wystarczy je zadeklarować, a zadanie ich egzekwowania będzie należało do systemu wykonawczego. Taka własność nie jest dostępna ani w języku C++, ani w Javie. W tych językach musimy ręcznie rozpatrzyć warunki wstępne i końcowe dla każdej z metod i zadbać o to, aby reguła Meyera nie została naruszona. Co więcej, bardzo pomocne może być udokumentowanie tych warunków wstępnych i końcowych w komentarzach dla każdej metody.

Specyfikowanie kontraktów w testach jednostkowych Kontrakty można również definiować poprzez pisanie testów jednostkowych. Dzięki dokładnemu testowaniu zachowania klasy testy jednostkowe sprawiają, że zachowanie klasy staje się czytelne. Autorzy kodu klientów mogą przeglądać testy jednostkowe, aby się dowiedzieć, co można racjonalnie założyć na temat wykorzystywanych klas.

Realny przykład Dość kwadratów i prostokątów! Czy zasada LSP może mieć wpływ na realne oprogramowanie? Przyjrzyjmy się studium przypadku pochodzącego z projektu, w którym pracowałem kilka lat temu.

Motywacja Na początku lat dziewięćdziesiątych kupiłem zewnętrzną bibliotekę, w której było kilka klas kontenerowych. Kontenery w przybliżeniu odpowiadały konstrukcjom Bag i Set z języka Smalltalk. Dostępne były dwie odmiany struktury Set i dwie podobne odmiany struktury Bag. Odmiana pierwsza nosiła nazwę „ograniczonej” (ang. bounded) i bazowała na tablicach. Druga odmiana była określana jako „nieograniczona” (ang. unbounded) i bazowała na listach. 7

[Meyer 97], str. 573. Reguła ponownej deklaracji asercji (1).

8

Określenie „słabszy” może być mylące. X jest słabszy niż Y, jeśli X nie wymusza wszystkich ograniczeń Y. Nie ma znaczenia, jak wiele nowych ograniczeń wymusza X.

134

ROZDZIAŁ 10. LSP — ZASADA PODSTAWIANIA LISKOV

W konstruktorze klasy BoundedSet była określona maksymalna liczba elementów, jakie może zawierać zbiór. Pamięć na te elementy była alokowana jako tablica wewnątrz obiektu BoundedSet. Zatem jeśli tworzenie obiektu BoundedSet zakończyło się powodzeniem, można było mieć pewność, że ilość pamięci jest wystarczająca. Ponieważ rozwiązanie bazowało na tablicy, było bardzo szybkie. Podczas normalnego działania nie były wykonywane żadne operacje alokacji pamięci. Ponieważ pamięć była rezerwowana z góry, można było mieć pewność, że operacje na obiektach BoundedSet nie spowodują przepełnienia sterty. Z drugiej strony, było to marnotrawstwo pamięci, gdyż rzadko można było całkowicie wykorzystać całą przestrzeń, która została zarezerwowana. Z kolei dla klasy UnboundedSet nie deklarowano maksymalnej liczby elementów. Obiekt klasy UnboundedSet akceptował elementy, jeśli tylko była dostępna pamięć na stercie. Z tego powodu rozwiązanie było bardzo elastyczne. Było ekonomiczne również pod tym względem, że zużywało tylko tyle pamięci, ile było niezbędne do przechowania elementów, które obiekt zawierał w danym momencie. Struktura była jednak wolna, ponieważ w ramach normalnej pracy musiały być wykonywane operacje rezerwowania i zwalniania pamięci. I wreszcie istniało niebezpieczeństwo, że podczas normalnego działania może dojść do wyczerpania miejsca na stercie. Nie byłem zadowolony z interfejsów tych zewnętrznych klas. Nie chciałem, aby kod mojej aplikacji był od nich zależny, ponieważ przewidywałem, że będę chciał je zastąpić później lepszymi klasami. Z tego powodu opakowałem zewnętrzne kontenery własnym abstrakcyjnym interfejsem, jak pokazano na rysunku 10.2.

Rysunek 10.2. Warstwa adaptera klasy kontenerowej

Stworzyłem klasę abstrakcyjną o nazwie Set, która udostępniała czysto wirtualne metody Add, Delete i IsMember, jak pokazano na listingu 10.4. Struktura ta unifikowała nieograniczone i ograniczone odmiany dwóch klas z biblioteki zewnętrznej i pozwalała na dostęp do nich za pośrednictwem wspólnego interfejsu. A zatem niektóre klienty mogły przyjmować argument typu Set& i mogły nie przejmować się tym, czy zbiór, z którym pracują, to odmiana ograniczona, czy nieograniczona (patrz funkcja PrintSet na listingu 10.5). Listing 10.4. Abstrakcyjna klasa Set template
T>

void Add(const T&) = 0; void Delete(const T&) = 0; bool IsMember(const T&) const = 0;

Listing 10.5. Funkcja PrintSet template void PrintSet(const Set& s) {

REALNY PRZYKŁAD

}

135

for (Iteratori(s); i; i++ cout << (*i) << endl;

Dużą zaletą tego rozwiązania jest brak konieczności zwracania uwagi na to, jaki typ obiektu Set jest wykorzystywany. Oznacza to, że programista może zdecydować, jakiego rodzaju obiekt Set jest potrzebny, w każdym konkretnym przypadku. Decyzja ta nie ma wpływu na żadne z funkcji klienckich. Programista może wybrać wersję UnboundedSet w przypadku, gdy istnieją ograniczenia pamięci, a szybkość działania nie ma kluczowego znaczenia, oraz wybrać wersję BoundedSet, kiedy ma dużo pamięci, a podstawowe znaczenie ma szybkość. Funkcje klienckie będą operować na tych obiektach za pośrednictwem interfejsu klasy bazowej Set i dlatego nie będą „wiedziały” o konkretnym typie wykorzystywanego obiektu Set i nie będzie on miał dla nich znaczenia.

Problem Do tej hierarchii chciałem dodać klasę PersistentSet. Klasa PersistentSet miała reprezentować zbiór, który można zapisać do strumienia, a następnie ponownie go odczytać, na przykład przez inną aplikację. Niestety, jedyny kontener z biblioteki zewnętrznej, do którego miałem dostęp, a który równocześnie zapewniał funkcje utrwalania, nie był klasą template. Zamiast tego przyjmował obiekty pochodne abstrakcyjnej klasy bazowej PersistentObject. Utworzyłem hierarchię, którą pokazano na rysunku 10.3.

Rysunek 10.3. Hierarchia z klasą PersistentSet

Zwróćmy uwagę, że klasa PersistentSet zawiera egzemplarz klasy reprezentującej trwały zbiór z biblioteki zewnętrznej, do którego deleguje wszystkie swoje metody. Jeśli więc wywołamy metodę Add na obiekcie PersistentSet, spowoduje to oddelegowanie tego wywołania do odpowiedniej metody obiektu klasy zewnętrznej. Z pozoru takie rozwiązanie może wydawać się właściwe. Istnieje jednak dość kłopotliwy problem. Elementy dodawane do trwałego zbioru muszą być pochodnymi klasy PersistentObject. Ponieważ klasa PersistentSet po prostu deleguje wywołania do zewnętrznego trwałego zbioru, to dowolny element dodawany do obiektu PersistentSet musi być pochodną klasy PersistentObject. Jednak interfejs klasy Set nie ma takiego ograniczenia. Kiedy klient dodaje składowe do klasy bazowej Set, nie może mieć pewności, czy obiekt Set jest w rzeczywistości typu PersistentSet. W związku z tym klient nie ma możliwości dowiedzenia się, czy elementy, które dodaje, powinny być pochodnymi klasy PersistentObject. Rozważmy kod metody PersistentSet::Add() z listingu 10.6. Listing 10.6. template void PersistentSet::Add(const T& t) { PersistentObject& p = dynamic_cast(t); itsThirdPartyPersistentSet.Add(p); }

136

ROZDZIAŁ 10. LSP — ZASADA PODSTAWIANIA LISKOV

Z tego kodu wynika, że próba dodania obiektu, który nie jest pochodną klasy PersistentObject, do mojego obiektu PersistentSet spowoduje błąd wykonania. Wywołanie dynamic_cast spowoduje zgłoszenie wyjątku bad_cast. Żaden z istniejących klientów abstrakcyjnej klasy bazowej Set nie przewiduje zgłaszania wyjątków przez metodę Add. Ponieważ funkcje te nie potrafią prawidłowo obsłużyć pochodnej klasy Set, to ta zmiana w hierarchii narusza zasadę LSP. Czy to jest problem? Oczywiście, że tak. Funkcje, które wcześniej nie zawodziły, gdy przekazywano do nich pochodne klasy Set, mogą teraz generować błędy wykonania, gdy zostanie do nich przekazany obiekt PersistentSet. Debugowanie tego rodzaju problemu jest stosunkowo trudne, ponieważ błąd wykonania występuje bardzo daleko od rzeczywistej logicznej usterki. Wadą w logice jest decyzja o przekazaniu obiektu PersistentSet do funkcji albo dodanie do obiektu PersistentSet funkcji, która nie jest pochodną klasy PersistentObject. W każdym przypadku rzeczywista decyzja może być oddalona o wiele milionów instrukcji od właściwego wywołania metody Add. Znalezienie tego błędu może być bardzo trudne. Jego naprawa może być jeszcze trudniejsza.

Rozwiązanie niezgodne z zasadą LSP Jak rozwiązać ten problem? Kilka lat temu rozwiązałem go poprzez zastosowanie pewnej konwencji. Oznacza to, że nie rozwiązałem go w kodzie źródłowym. Zamiast tego przyjąłem konwencję, zgodnie z którą obiekty PersistentSet i PersistentObject były nieznane dla aplikacji jako całości. Były one znane tylko dla konkretnego modułu. Ten moduł był odpowiedzialny za odczyt i zapis wszystkich kontenerów do trwałego magazynu i z powrotem. Kiedy zachodziła konieczność zapisu kontenera, jego zawartość była kopiowana do właściwych pochodnych klasy PersistentObject, a później dodawana do obiektów PersistentSet zapisywanych do strumienia. Kiedy zachodziła potrzeba odczytu kontenera ze strumienia, proces był odwracany. Obiekt PersistentSet był odczytywany ze strumienia, a następnie obiekty PersistentObject były usuwane z obiektu PersistentSet i kopiowane do zwykłych obiektów (nietrwałych), które następnie były dodawane do zwykłego zbioru Set. To rozwiązanie może wydawać się zbyt restrykcyjne, ale był to jedyny sposób, który potrafiłem wymyślić, aby nie dopuścić do pojawiania się obiektów PersistentSet na interfejsach funkcji, które chciałyby dodać do obiektów PersistentSet nietrwałe zbiory. Co więcej, to rozwiązanie wprowadzało zależność reszty aplikacji od mechanizmu utrwalania. Czy rozwiązanie sprawdziło się? Niekoniecznie. Konwencja została naruszona w kilku miejscach aplikacji przez deweloperów, którzy nie rozumieli konieczności jej stosowania. Na tym polega problem z konwencjami — stale trzeba je tłumaczyć wszystkim programistom. Jeśli deweloper nie zapoznał się z konwencją lub nie zgadza się z nią, to może dojść do jej naruszenia. A jedno naruszenie może spowodować problem w całej strukturze.

Rozwiązanie zgodne z zasadą LSP W jaki sposób rozwiązałbym ten problem teraz? Zadbałbym o to, aby klasa PersistentSet nie była związana relacją IS-A z klasą Set, ponieważ nie jest to właściwa pochodna klasy Set. Zatem rozdzieliłbym hierarchie, ale nie zrobiłbym tego całkowicie. Niektóre cechy klas Set i PersistentSet są wspólne. W rzeczywistości tylko metoda Add stwarza problemy z zasadą LSP. W konsekwencji stworzyłbym hierarchię, w której zarówno klasa Set, jak i PersistentSet byłyby rodzeństwem znajdującym się pod abstrakcyjnym interfejsem, który pozwala na testowanie przynależności, iteracje itp. (patrz rysunek 10.4). To pozwoliłoby na iterowanie po obiektach PersistentSet, testowanie przynależności itp. Jednak hierarchia ta nie pozwoliłaby na dodawanie obiektów, które nie są pochodnymi klasy PersistentObject, do klasy PersistentSet.

WYDZIELANIE ZAMIAST DZIEDZICZENIA

137

Rysunek 10.4. Rozwiązanie zgodne z zasadą LSP

Wydzielanie zamiast dziedziczenia Kolejnym ciekawym i dość zagadkowym przykładem dziedziczenia jest przypadek klas Line i LineSegment9. Rozważmy kod z listingów 10.7 i 10.8. Z pozoru te dwie klasy wydają się być naturalnymi kandydatami do publicznego dziedziczenia. Klasa LineSegment potrzebuje deklaracji wszystkich składowych i funkcji, które są zadeklarowane w klasie Line. Oprócz tego klasa LineSegment zawiera nową, własną funkcję składową GetLength oraz przesłania znaczenie funkcji IsOn. Pomimo tego klasy te naruszają zasadę LSP w subtelny sposób. Listing 10.7. geometry/line.h #ifndef GEOMETRY_LINE_H #define GEOMETRY_LINE_H #include "geometry/point.h" class Line { public: Line(const Point& p1, const Point& p2); double double Point Point virtual bool

GetSlope() GetIntercept() GetP1() GetP2() IsOn(const Point&)

const; const; // Y Intercept const {return itsP1;}; const {return itsP2;}; const;

private: Point itsP1; Point itsP2;

}; #endif

Listing 10.8. geometry/lineseg.h #ifndef GEOMETRY_LINESEGMENT_H #define GEOMETRY_LINESEGMENT_H class LineSegment : public Line { public: LineSegment(const Point& p1, const Point& p2); double GetLength() const; virtual bool IsOn(const Point&) const; }; #endif 9

Pomimo podobieństwa tego przykładu do przykładu z kwadratami i okręgami ten przykład pochodzi z rzeczywistej aplikacji i był przedmiotem dyskusji dotyczącej realnych problemów.

138

ROZDZIAŁ 10. LSP — ZASADA PODSTAWIANIA LISKOV

Użytkownik klasy Line ma prawo oczekiwać, że wszystkie punkty współliniowe należą do obiektu Line. Na przykład punkt zwracany przez funkcję Intercept to punkt, w którym linia przecina oś Y. Ponieważ jest to punkt współliniowy, to użytkownicy klasy Line mogą oczekiwać, że jest spełniony warunek IsOn(Intercept()) == true. Jednak w przypadku wielu egzemplarzy klasy LineSegment to twierdzenie nie jest spełnione. Dlaczego to takie ważne? Czy nie można zastosować dziedziczenia klasy LineSegment z klasy Line i zaakceptować tych subtelnych problemów? To indywidualna decyzja. Istnieją rzadkie przypadki, gdy bardziej wskazane jest zaakceptowanie subtelnej wady polimorficznego zachowania niż podejmowanie prób manipulowania projektem, aby osiągnąć pełną zgodność z zasadą LSP. Przyjęcie kompromisu zamiast dążenia do doskonałości jest dylematem inżynierów. Dobry inżynier wie, kiedy kompromis przynosi większy zysk od dążenia do perfekcji. Jednak ze zgodności z zasadą LSP nie powinno się rezygnować z błahych powodów. Uzyskanie gwarancji, że klasa potomna zawsze będzie działać, gdy są używane jej klasy bazowe, jest skutecznym sposobem zarządzania złożonością. Gdy nie ma takiej gwarancji, to każdą klasę potomną trzeba rozpatrywać indywidualnie. W przypadku klas Line i LineSegment istnieje proste rozwiązanie, które ilustruje ważne narzędzie programowania obiektowego. Jeśli mamy dostęp zarówno do klasy Line, jak i LineSegment, to możemy wydzielić ich wspólne elementy do abstrakcyjnej klasy bazowej. Na listingach od 10.9 do 10.11 pokazano sposób wyodrębnienia klasy bazowej LinearObject z klas Line i LineSegment. Listing 10.9. geometry/linearobj.h #ifndef GEOMETRY_LINEAR_OBJECT_H #define GEOMETRY_LINEAR_OBJECT_H #include "geometry/point.h" class LinearObject { public: LinearObject(const Point& p1, const Point& p2); double GetSlope() const; double GetIntercept() const; Point GetP1() const {return itsP1;}; Point GetP2() const {return itsP2;}; virtual int IsOn(const Point&) const = 0; // metoda abstrakcyjna. private: Point itsP1; Point itsP2;

}; #endif

Listing 10.10. geometry/line.h #ifndef GEOMETRY_LINE_H #define GEOMETRY_LINE_H #include "geometry/linearobj.h" class Line : public LinearObject { public: Line(const Point& p1, const Point& p2); virtual bool IsOn(const Point&) const; }; #endif

Listing 10.11. geometry/lineseg.h #ifndef GEOMETRY_LINESEGMENT_H #define GEOMETRY_LINESEGMENT_H #include "geometry/linearobj.h"

HEURYSTYKI I KONWENCJE

139

class LineSegment : public LinearObject { public: LineSegment(const Point& p1, const Point& p2);

}; #endif

double GetLength() const; virtual bool IsOn(const Point&) const;

Klasa LinearObject reprezentuje zarówno klasę Line, jak i LineSegment. Dostarcza większości funkcjonalności i składowych danych do obu klas potomnych. Wyjątkiem jest metoda IsOn, która jest czysto wirtualna. Klientom klasy LinearObject nie wolno zakładać, że całkowicie rozumieją zakres obiektu, którego używają. W związku z tym mogą otrzymywać zarówno obiekty klasy Line, jak i LineSegment. Ponadto klienty klasy Line nigdy nie będą korzystać z klasy LineSegment. Wyodrębnianie jest narzędziem projektowym, które najłatwiej stosować, zanim zostaną napisane duże ilości kodu. Gdyby było dużo klientów klasy Line pokazanej na listingu 10.7, wyodrębnienie klasy LinearObject z pewnością nie byłoby łatwe. Jednak kiedy wyodrębnianie jest możliwe, daje ono potężne możliwości. Jeśli można wydzielić cechy z dwóch klas potomnych, to istnieje duże prawdopodobieństwo, że później powstaną inne klasy, które także będą potrzebowały tych cech. Oto co o technice wyodrębniania napisali Rebecca Wirfs-Brock, Brian Wilkerson i Lauren Wiener: Można stwierdzić, że jeśli zbiór klas obsługuje wspólny zakres odpowiedzialności, to powinny one dziedziczyć ten zakres odpowiedzialności ze wspólnej klasy nadrzędnej. Jeśli wspólna klasa nadrzędna nie istnieje, należy ją stworzyć, a następnie przenieść do niej wspólny zakres odpowiedzialności. Jest oczywiste, że taka klasa jest przydatna — już udowodniliśmy, że jej odpowiedzialność będzie dziedziczona przez inne klasy. Czyż nie można prognozować, że w wyniku późniejszej rozbudowy systemu mogą powstać nowe podklasy, które będą spełniać te same obowiązki w nowy sposób? Najczęściej nową nadklasę implementuje się jako klasę abstrakcyjną 10. Na listingu 10.12 pokazano możliwy sposób wykorzystania atrybutów klasy LinearObject przez nieprzewidzianą klasę Ray. Klasę Ray można podstawić za klasę LinearObject i żaden użytkownik klasy LinearObject nie będzie miał problemów z jej obsługą. Listing 10.12. geometry/ray.h #ifndef GEOMETRY_RAY_H #define GEOMETRY_RAY_H class Ray : public LinearObject { public: Ray(const Point& p1, const Point& p2); virtual bool IsOn(const Point&) const; }; #endif

Heurystyki i konwencje Istnieje kilka prostych heurystyk, które mogą dać nam wskazówki dotyczące naruszeń zasady LSP. Wszystkie dotyczą klas pochodnych, które w jakiś sposób usuwają funkcjonalności ze swoich klas bazowych. Klasy pochodnej, która realizuje mniej operacji niż jej klasa bazowa, zwykle nie da się podstawić za tę klasę bazową, dlatego stanowi ona naruszenie zasady LSP.

10

[WirfsBrock 90], str. 113.

140

ROZDZIAŁ 10. LSP — ZASADA PODSTAWIANIA LISKOV

Zdegenerowane funkcje w klasach pochodnych Rozważmy kod z listingu 10.13. Funkcja f jest zaimplementowana w klasie Base. Jednak w klasie Derived jest ona zdegenerowana. Przypuszczalnie autor klasy Derived stwierdził, że funkcja f nie pełni żadnej użytecznej roli w klasie Derived. Niestety, użytkownicy klasy Base nie wiedzą, że nie powinni wywoływać f, dlatego taka implementacja jest naruszeniem zasady LSP. Listing 10.13. Zdegenerowana funkcja w klasie pochodnej public class Base { public void f() {/*jakiś kod*/} } public class Derived extends Base { public void f() {} }

Obecność zdegenerowanych funkcji w klasach pochodnych nie zawsze wskazuje na naruszenie zasady LSP. Warto jednak przyjrzeć się tym funkcjom, jeśli występują.

Zgłaszanie wyjątków z klas pochodnych Inną formą naruszenia zasady LSP jest dodanie do metod klas pochodnych wyjątków, których klasy bazowe nie zgłaszają. Jeśli użytkownicy klas bazowych nie oczekują wyjątków, to w przypadku dodania ich do metod klas pochodnych tych klas pochodnych nie można podstawić za klasę bazową. Albo należy zmodyfikować oczekiwania użytkowników, albo klasy pochodne nie powinny zgłaszać wyjątków.

Wniosek Zasada OCP stanowi centralny punkt wielu własności projektowania obiektowego. Zastosowanie się do tej zasady poprawia łatwość utrzymania aplikacji, możliwości wielokrotnego wykorzystywania komponentów oraz elastyczność. A zatem naruszenie zasady LSP jest ukrytym naruszeniem zasady OCP. Dzięki możliwości podstawiania podtypów moduł, który jest zaimplementowany w kontekście klasy bazowej, można rozszerzać bez modyfikowania. Programiści zwykle oczekują takiej zamienności domyślnie. W związku z tym kontrakt typu bazowego musi być dobrze i wyraźnie rozumiany, a najlepiej jeśli jest wyraźnie egzekwowany przez kod. Definicja relacji IS-A jest zbyt szeroka, aby mogła służyć za określenie podtypu. Prawdziwa definicja podtypu to „możliwość podstawienia”, gdzie podstawienie jest zdefiniowane za pomocą jawnego lub niejawnego kontraktu.

Bibliografia 1. Bertrand Meyer, Object-Oriented Software Construction, wydanie drugie, Upper Saddle River, NJ: Prentice Hall, 1997. 2. Rebecca Wirfs-Brock et al., Designing Object-Oriented Software, Englewood Cliffs, NJ: Prentice Hall, 1990. 3. Barbara Liskov, Data Abstraction and Hierarchy, „SIGPLAN Notices”, 23(5) (maj 1988).

R OZDZIAŁ 11

DIP — zasada odwracania zależności

Nigdy więcej nie pozwól, aby ważne interesy kraju zależały od tysięcy chwiejnych możliwości — ludzkich słabości — sir Thomas Noon Talfourd (1795 – 1854)

DIP — zasada odwracania zależności a. Moduły wysokopoziomowe nie powinny zależeć od modułów niskopoziomowych. I jedne, i drugie powinny zależeć od abstrakcji. b. Abstrakcje nie powinny zależeć od szczegółów. To szczegóły powinny zależeć od abstrakcji. Przez lata wiele osób pytało mnie, dlaczego używam słowa „odwracanie” w nazwie tej zasady. To dlatego, że w bardziej tradycyjnych metodykach wytwarzania oprogramowania, takich jak analiza i projektowanie strukturalne, obowiązuje tendencja do tworzenia struktur, w których moduły wysokopoziomowe zależą od modułów niskopoziomowych, natomiast strategie zależą od szczegółów. Jednym z celów tych metodyk jest określenie hierarchii podprogramów, która opisuje sposób, w jaki moduły wysokopoziomowe wywołują moduły niskopoziomowe. Dobrym przykładem takiej hierarchii jest pierwotny projekt programu Copy zaprezentowany na rysunku 7.1. Struktura zależności dobrze zaprojektowanego programu obiektowego jest „odwrócona” w stosunku do struktury zależności, która zwykle wynika z tradycyjnych metod proceduralnych. Rozważmy konsekwencje zależności modułów wysokopoziomowych od modułów niskopoziomowych. To moduły wysokopoziomowe zawierają ważne decyzje dotyczące strategii oraz modele biznesowe aplikacji. Moduły te określają tożsamość aplikacji. Jednak gdy moduły te zależą od modułów niskopoziomowych, to zmiany w modułach niższego poziomu mogą mieć bezpośredni wpływ na moduły na wyższym poziomie i mogą wymusić wprowadzenie zmian w tych modułach.

142

ROZDZIAŁ 11. DIP — ZASADA ODWRACANIA ZALEŻNOŚCI

Taka sytuacja jest absurdem! To moduły wysokopoziomowe, te, które zawierają ważne decyzje dotyczące strategii, powinny mieć wpływ na moduły niskopoziomowe zawierające szczegóły. Moduły, które zawierają wysokopoziomowe reguły biznesowe, powinny mieć pierwszeństwo przed modułami zawierającymi szczegóły implementacji i powinny być od nich niezależne. Moduły wysokopoziomowe po prostu nie powinny w żaden sposób zależeć od modułów niskopoziomowych. Co więcej, chcemy mieć możliwość wielokrotnego używania modułów wysokopoziomowych — tych, które tworzą strategię. Dziś dość dobrze potrafimy używać wielokrotnie modułów niskopoziomowych. Zwykle mają one postać bibliotek podprogramów. Gdy moduły wysokopoziomowe zależą od modułów niskopoziomowych, użycie tych modułów wysokopoziomowych w różnych kontekstach staje się bardzo trudne. Jednak gdy moduły wysokopoziomowe są niezależne od modułów niskiego poziomu, wówczas moduły wysokopoziomowe mogą być dość łatwo wykorzystywane wielokrotnie. Zasada ta stanowi centrum projektowania frameworków.

Podział na warstwy Według Boocha „... wszystkie dobrze zorganizowane architektury obiektowe mają jasno określone warstwy; każda warstwa zapewnia określony spójny zestaw usług za pośrednictwem dobrze zdefiniowanego i kontrolowanego interfejsu”1. Naiwna interpretacja tego stwierdzenia może prowadzić projektanta do stworzenia struktury podobnej do przedstawionej na rysunku 11.1. Na tym diagramie wysokopoziomowa warstwa Strategia wykorzystuje warstwę niższego poziomu Mechanizm, a ta z kolei wykorzystuje warstwę szczegółów Narzędzia. Choć na pierwszy rzut oka taka struktura może się wydawać właściwa, ma ona ukrytą cechę wrażliwości warstwy Strategia na zmiany w warstwie Narzędzia. Zależność jest przechodnia. Warstwa Strategia zależy od czegoś, co zależy od warstwy Narzędzia, a zatem warstwa Strategia w przechodni sposób zależy od warstwy Narzędzia. To bardzo niefortunne.

Rysunek 11.1. Naiwny podział na warstwy

Bardziej prawidłowy model pokazano na rysunku 11.2. Każda z warstw wyższego poziomu deklaruje abstrakcyjny interfejs dla usług, które są jej niezbędne. Warstwy niższego szczebla są następnie realizowane na podstawie tych abstrakcyjnych interfejsów. Każda klasa wyższego poziomu wykorzystuje kolejną w hierarchii warstwę za pośrednictwem abstrakcyjnego interfejsu. Dzięki temu górne warstwy nie zależą od warstw niższych. Zamiast tego niższe warstwy zależą od abstrakcyjnych interfejsów usług zadeklarowanych w warstwach wyższych. Powoduje to wyeliminowanie nie tylko zależności warstwy Strategia od warstwy Narzędzia, ale nawet bezpośredniej zależności warstwy Strategia od warstwy Mechanizm.

Odwrócenie własności Zwróćmy uwagę, że inwersja w tym przypadku nie dotyczy tylko zależności, ale także własności interfejsu. Często uważamy, że biblioteki narzędziowe posiadają własne interfejsy. Ale kiedy zastosujemy zasadę DIP, to okazuje się, że klienty mają tendencję do posiadania abstrakcyjnych interfejsów, które są wykorzystywane przez ich serwery. 1

[Booch 96], str. 54.

PODZIAŁ NA WARSTWY

143

Rysunek 11.2. Odwrócone warstwy

Czasami przypomina to zasadę obowiązującą w Hollywood: „Nie dzwoń do nas. To my zadzwonimy do ciebie”2. Moduły niższego poziomu dostarczają implementacji interfejsów, które są zadeklarowane w modułach wyższego poziomu i stamtąd są wywoływane. Dzięki zastosowaniu tej odwróconej własności na warstwę Strategia nie mają wpływu żadne zmiany w warstwach Mechanizm lub Narzędzia. Co więcej, warstwę strategii można wykorzystać w dowolnym kontekście, który definiuje moduły niższego poziomu oraz jest zgodny z interfejsem usług strategii. Tak więc przez odwrócenie zależności stworzyliśmy strukturę, która jest jednocześnie bardziej elastyczna, trwała i mobilna.

Zależność od abstrakcji Nieco naiwną, ale dającą duże możliwości interpretacją zasady DIP jest prosta heurystyka: „Stosuj zależność od abstrakcji”. Krótko mówiąc, ta heurystyka mówi, że nie powinniśmy zależeć od konkretnej klasy oraz że wszystkie relacje w programie powinny kończyć się na klasie abstrakcyjnej lub interfejsie. Zgodnie z tą heurystyką:  Żadna zmienna nie powinna zawierać wskaźnika lub referencji do konkretnej klasy.  Żadna klasa nie powinna być klasą pochodną konkretnej klasy.  Żadna metoda nie powinna przesłaniać zaimplementowanej metody żadnej ze swoich klas bazowych.

Oczywiście ta heurystyka jest naruszana zwykle przynajmniej raz w każdym programie. Gdzieś trzeba stworzyć egzemplarze konkretnych klas. Niezależnie od tego, w jakim module to zrobimy, moduł ten będzie zależał od tych konkretnych klas3. Ponadto nie wydaje się, aby istniały racjonalne powody 2

[Sweet 85].

3

W rzeczywistości istnieją sposoby obejścia tego ograniczenia, jeśli do stworzenia klas można użyć ciągów znaków. Takie możliwości daje na przykład Java. Podobne mechanizmy istnieją również w kilku innych językach. W takich językach nazwy konkretnych klas mogą być przekazywane do programu jako dane konfiguracji.

144

ROZDZIAŁ 11. DIP — ZASADA ODWRACANIA ZALEŻNOŚCI

przestrzegania tej heurystyki w odniesieniu do klas, które są konkretne, ale nieulotne. Jeśli konkretna klasa nie będzie się zbytnio zmieniać i nie przewidujemy tworzenia podobnych do niej klas pochodnych, to zależność od takiej klasy nie przynosi zbyt wielkiej szkody. Na przykład w większości systemów klasa opisująca ciąg znaków jest konkretna. W Javie istnieje konkretna klasa String. Ta klasa jest nieulotna. Oznacza to, że nie zmienia się zbyt często. Z tego powodu nie ma problemu, aby moduły od niej zależały. Jednak większość konkretnych klas, które piszemy w ramach aplikacji, to klasy ulotne. Należy unikać bezpośrednich zależności od tych konkretnych klas. Ich zmienność można wyizolować za pomocą abstrakcyjnego interfejsu. Nie jest to rozwiązanie kompletne. Czasami interfejs zmiennej klasy musi się zmienić. Taka zmiana musi być propagowana do abstrakcyjnego interfejsu, który reprezentuje klasę. Zmiany tego rodzaju naruszają izolację abstrakcyjnego interfejsu. To jest powód, dla którego przytoczona powyżej heurystyka jest nieco naiwna. Z drugiej strony, jeśli przyjmiemy szerszą perspektywę, zgodnie z którą klasy klienckie deklarują potrzebne im interfejsy usług, to jedynym momentem, gdy interfejs się zmieni, będzie sytuacja, w której klient potrzebuje tej zmiany. Zmiany w klasach, które implementują abstrakcyjny interfejs, nie mają wpływu na klientów.

Prosty przykład Inwersję zależności można zastosować wszędzie tam, gdzie jedna klasa przesyła komunikat do innej klasy. Dla przykładu rozważmy przypadek obiektu Button i obiektu Lamp. Obiekt Button komunikuje się ze środowiskiem zewnętrznym. Po otrzymaniu komunikatu Poll określa, czy użytkownik go „wcisnął”. Nie ma dla niego znaczenia, jaki jest mechanizm wykrywania. Może to być ikona przycisku w graficznym interfejsie użytkownika, fizyczny przycisk wciskany palcem lub nawet czujnik ruchu w domowym systemie zabezpieczeń. Obiekt Button wykrywa, że użytkownik go uaktywnił bądź zdezaktywował. Obiekt Lamp wywiera wpływ na zewnętrzne środowisko. Po otrzymaniu komunikatu TurnOn włącza światło. W przypadku otrzymania komunikatu TurnOn obiekt Lamp wyłącza światło. Fizyczny mechanizm tej operacji jest nieistotny. Może to być dioda LED na konsoli komputera, lampy rtęciowa na parkingu, a nawet laser w drukarce laserowej. W jaki sposób należy zaprojektować system, aby obiekt Button zarządzał obiektem Lamp? Naiwny projekt pokazano na rysunku 11.3. Obiekt Button otrzymuje komunikaty Poll, sprawdza, czy przycisk jest wciśnięty, a następnie wysyła do obiektu Lamp komunikat TurnOn lub TurnOff.

Rysunek 11.3. Naiwny model zależności klas Button i Lamp

Dlaczego ten model jest naiwny? Przeanalizujmy kod w Javie, który wynika z tego modelu (listing 11.1). Zwróćmy uwagę, że klasa Button zależy bezpośrednio od klasy Lamp. Z tej zależności wynika, że zmiany w klasie Lamp będą miały wpływ na klasę Button. Co więcej, nie będzie możliwości wykorzystania klasy Button do sterowania klasą Motor. W takim projekcie obiekty Button kontrolują obiekty Lamp i tylko obiekty Lamp. Listing 11.1. Button.java public class Button { private Lamp itsLamp; public void poll()

PROSTY PRZYKŁAD

{

}

}

145

if (/*jakiś warunek*/) itsLamp.turnOn();

Pokazane rozwiązanie narusza zasadę DIP. Wysokopoziomowa strategia aplikacji nie została oddzielona od niskopoziomowej implementacji. Abstrakcje nie zostały oddzielone od szczegółów. Bez takiej separacji wysokopoziomowa strategia automatycznie zależy od modułów niskopoziomowych, natomiast abstrakcje automatycznie zależą od szczegółów.

Wyszukiwanie potrzebnych abstrakcji Czym jest wysokopoziomowa strategia? Jest to abstrakcja, która leży u podstaw aplikacja — zbiór prawd, które się nie zmieniają, gdy zmieniają się szczegóły. To jest system wewnątrz systemu — to jego metafora. W przykładzie z klasami Button i Lamp abstrakcją bazową jest wykrycie gestu użytkownika oznaczającego włączenie (wyłączenie) i przekazanie tego gestu do obiektu docelowego. Jaki mechanizm jest wykorzystywany do wykrywania gestu użytkownika? To nieistotne. Jaki jest obiekt docelowy? Nieistotne. Są to szczegóły, które nie mają wpływu na abstrakcję. Projekt z rysunku 11.3 można poprawić poprzez odwrócenie zależności od obiektu Lamp. Na rysunku 11.4 możemy zobaczyć, że klasa Button zawiera teraz powiązanie do klasy określonej jako ButtonServer. ButtonServer dostarcza abstrakcyjnych metod, które klasa Button może wykorzystać, aby coś włączyć bądź wyłączyć. Klasa Lamp implementuje interfejs ButtonServer. Zatem teraz klasa Lamp wykonuje operacje zależne. Inne klasy od niej nie zależą.

Rysunek 11.4. Zasada odwracania zależności zastosowana do klasy Lamp

Projekt pokazany na rysunku 11.4 umożliwia obiektowi klasy Button sterowanie dowolnym urządzeniem, które implementuje interfejs ButtonServer. Taki układ daje nam olbrzymią elastyczność. Oznacza on również, że obiekty Button mogą być wykorzystane do sterowania obiektami, które jeszcze nie istnieją. Jednak to rozwiązanie wprowadza również ograniczenie na dowolny obiekt, który ma być sterowany za pomocą obiektu Button. Taki obiekt musi implementować interfejs ButtonServer. Jest to niefortunne, ponieważ takie obiekty być może powinny być również sterowane przez obiekt Switch albo jakiś inny obiekt niż Button. Dzięki odwróceniu kierunku zależności i zdefiniowaniu obiektu Lamp jako zależnego od innych (a nie odwrotnie, gdy to inne obiekty zależały od klasy Lamp) spowodowaliśmy zależność obiektu Lamp od innego szczegółu — obiektu Button. Czy na pewno? Klasa Lamp rzeczywiście zależy od interfejsu ButtonServer, ale interfejs ButtonServer nie zależy od klasy Button. Obiektem Lamp może sterować dowolny obiekt, który „wie”, jak operować na interfejsie ButtonServer. A zatem zależność istnieje tylko w nazwie. Problem ten można rozwiązać, zmieniając nazwę ButtonServer na bardziej ogólną, na przykład SwitchableDevice. Możemy także zadbać o to, aby klasy Button i interfejs SwitchableDevice były przechowywane w osobnych bibliotekach. Dzięki temu użycie interfejsu SwitchableDevice nie będzie musiało wiązać się z użyciem klasy Button.

146

ROZDZIAŁ 11. DIP — ZASADA ODWRACANIA ZALEŻNOŚCI

W tym przypadku żadna klasa nie jest właścicielem interfejsu. Mamy ciekawą sytuację, w której interfejs może być używany przez wiele różnych klientów i implementowany przez wiele różnych serwerów. Zatem interfejs może pozostać niezależny — nie musi należeć do żadnej z grup. W języku C++ należałoby go umieścić w osobnej przestrzeni nazw i bibliotece. W Javie należałoby stworzyć odrębny pakiet4.

Przykład programu Furnace Spróbujmy przyjrzeć się bardziej interesującemu przykładowi. Rozważmy oprogramowanie, które steruje piecem. Program może odczytać aktualną temperaturę z kanału We-Wy i wysłać instrukcję włączenia bądź wyłączenia pieca poprzez wysłanie polecenia do innego kanału We-Wy. Struktura algorytmu mogłaby wyglądać podobnie do kodu zamieszczonego na listingu 11.2. Listing 11.2. Prosty algorytm termostatu #define #define #define #define

TERMOMETER 0x86 FURNACE 0x87 ENGAGE 1 DISENGAGE 0

void Regulate(double minTemp, double maxTemp) { for(;;) { while (in(THERMOMETER) > minTemp) wait(1); out(FURNACE,ENGAGE);

}

}

while (in(THERMOMETER) < maxTemp) wait(1); out(FURNACE,DISENGAGE);

Wysokopoziomowy zamiar algorytmu jest czytelny, ale kod jest zaśmiecony dużą ilością niskopoziomowych szczegółów. Takiego kodu nigdy nie można by wykorzystać w innym sprzęcie sterującym. Być może nie jest to duża strata, ponieważ ten kod nie jest zbyt rozbudowany. Ale nawet w tym przypadku szkoda tracić algorytm, który można by wykorzystać wielokrotnie. Powinniśmy raczej odwrócić zależności i stworzyć projekt podobny do tego, który pokazano na rysunku 11.5.

Rysunek 11.5. Uniwersalny regulator 4

W językach dynamicznych, takich jak Smalltalk, Python czy Ruby, taki interfejs nie istniałby jako osobna jednostka w kodzie źródłowym.

PRZYKŁAD PROGRAMU FURNACE

147

Z powyższego rysunku widać, że funkcja regulatora pobiera dwa argumenty. Obydwa są interfejsami. Interfejs Thermometer pozwala na czytanie, natomiast interfejs Heater może być uaktywniany i dezaktywowany. To wszystko, czego potrzebuje algorytm Regulate. Teraz można go zapisać tak, jak pokazano na listingu 11.3. Listing 11.3. Uniwersalny regulator void Regulate(Thermometer& t, Heater& h, double minTemp, double maxTemp) { for(;;) { while (t.Read() > minTemp) wait(1); h.Engage();

}

}

while (t.Read() < maxTemp) wait(1); h.Disengage();

W zaprezentowanym kodzie odwrócono zależności. Dzięki temu wysokopoziomowa strategia regulacji nie jest uzależniona od żadnego z konkretnych szczegółów termometru lub pieca. Algorytm można bez trudu wykorzystać wielokrotnie.

Polimorfizm dynamiczny i statyczny Udało nam się odwrócić zależności i przekształcić funkcję Regulate tak, aby była uniwersalna, dzięki wykorzystaniu dynamicznego polimorfizmu (tzn. abstrakcyjnych klas bądź interfejsów). Istnieje jednak inny sposób. Można skorzystać ze statycznej formy polimorfizmu dzięki użyciu szablonów języka C++. Rozważmy kod z listingu 11.4. Listing 11.4. Wykorzystanie polimorfizmu statycznego do odwrócenia zależności template class Regulate(THERMOMETER& t, HEATER& h, double minTemp, double maxTemp) { for(;;) { while (t.Read() > minTemp) wait(1); h.Engage();

}

}

while (t.Read() < maxTemp) wait(1); h.Disengage();

Za pomocą tego kodu uzyskaliśmy to samo odwrócenie zależności bez narzutu (lub elastyczności) polimorfizmu dynamicznego. W języku C++ wszystkie metody Read, Engage i Disengage mogą być niewirtualne. Co więcej, wszystkie klasy, które deklarują te metody, mogą być wykorzystane przez szablon. Klasy te nie muszą dziedziczyć ze wspólnej klasy bazowej. Ponieważ Regulate jest szablonem, to nie zależy od żadnej konkretnej implementacji tych funkcji. Wystarczy tylko, aby klasa podstawiona za HEATER miała metody Engage i Disengage, natomiast klasa podstawiona za THERMOMETER miała funkcję Read. Tak więc te klasy muszą implementować interfejs zdefiniowany przez szablon. Inaczej mówiąc, zarówno szablon Regulate, jak i klasy wykorzystywane przez Regulate muszą uzgodnić ten sam interfejs. Obie strony kontraktu zależą od tego uzgodnienia.

148

ROZDZIAŁ 11. DIP — ZASADA ODWRACANIA ZALEŻNOŚCI

Polimorfizm statyczny dobrze nadaje się do eliminowania zależności od kodu źródłowego, ale to nie rozwiązuje tylu problemów co polimorfizm dynamiczny. Wady zastosowania szablonów to: (1) typów HEATER i THERMOMETER nie można zmienić w czasie wykonywania programu oraz (2) wykorzystanie nowego typu HEATER lub THERMOMETER zmusza do ponownej kompilacji i instalacji. Zatem jeśli nie istnieją bardzo rygorystyczne wymagania co do szybkości, to powinniśmy preferować polimorfizm dynamiczny.

Wniosek Tradycyjne programowanie proceduralne tworzy strukturę zależności, w której strategia zależy od szczegółów. Jest to niefortunne, ponieważ strategia jest wtedy wrażliwa na zmiany w szczegółach. Programowanie obiektowe odwraca tę strukturę zależności w taki sposób, że zarówno szczegóły, jak i strategie zależą od abstrakcji, a klienty często dysponują interfejsami usług. To odwrócenie zależności jest znakiem rozpoznawczym dobrego projektu obiektowego. Nie ma znaczenia, w jakim języku jest napisany program. Jeśli jego zależności są odwrócone, to ma on projekt obiektowy. Jeśli zależności nie są odwrócone, to ma projekt proceduralny. Zasada odwrócenia zależności jest podstawowym niskopoziomowym mechanizmem, który gwarantuje uzyskanie wielu korzyści oferowanych przez technologie obiektowe. Właściwe stosowanie tej zasady jest niezbędne do stworzenia frameworków wielokrotnego użytku. Jest to również bardzo ważne w przypadku budowy kodu, który jest odporny na zmiany. Ponieważ abstrakcje i szczegóły są od siebie odizolowane, kod jest znacznie łatwiejszy w utrzymaniu.

Bibliografia 1. Grady Booch, Object Solutions, Menlo Park, CA: Addison-Wesley, 1996. 2. Gamma, et al., Design Patterns, Reading, MA: Addison-Wesley, 19955. 3. Richard Sweet, The Mesa Programming Environment, „SIGPLAN Notices”, 20(7) (lipiec 1988), 216 – 229.

5

Wydanie polskie: Wzorce projektowe. Elementy programowania obiektowego wielokrotnego użytku, Wydawnictwa Naukowo-Techniczne, 2005 — przyp. tłum.

R OZDZIAŁ 12

ISP — zasada segregacji interfejsów Stosowanie tej zasady służy eliminacji wad wynikających z „grubych” interfejsów. Klasy, które mają „grube” interfejsy, to klasy, których interfejsy nie są spójne. Innymi słowy, interfejsy takich klas mogą być podzielone na grupy metod. Każda grupa obsługuje inny zbiór klientów. Zatem niektóre klienty wykorzystują jedną grupę funkcji składowych, natomiast inne korzystają z innych grup. Zasada ISP potwierdza, że istnieją obiekty, które wymagają niespójnych interfejsów. Sugeruje jednak, że klienty nie powinny „wiedzieć” o nich, że należą one do jednej klasy. Zamiast tego powinny posługiwać się abstrakcyjnymi klasami bazowymi, które mają spójne interfejsy.

Zaśmiecanie interfejsów Rozważmy przykład systemu zabezpieczeń. W tym systemie mamy obiekty Door — można je zamykać i otwierać, a ponadto „wiedzą” one, czy są otwarte, czy zamknięte (patrz listing 12.1). Listing 12.1. Klasa Door class Door { public: virtual void Lock() = 0; virtual void Unlock() = 0; virtual bool IsDoorOpen() = 0; };

Ta klasa jest abstrakcyjna, dzięki czemu klienty mogą korzystać z obiektów, które są zgodne z interfejsem Door i nie muszą zależeć od konkretnej implementacji klasy Door. Przypuśćmy teraz, że jedna z takich implementacji, klasa TimedDoor, musi wygenerować alarm dźwiękowy, kiedy drzwi pozostaną otwarte zbyt długo. Aby to osiągnąć, obiekt TimedDoor komunikuje się z innym obiektem o nazwie Timer (patrz listing 12.2). Listing 12.2. Obiekt Timer class Timer { public: void Register(int timeout, TimerClient* client); }; class TimerClient { public: virtual void TimeOut() = 0; };

Kiedy obiekt chce uzyskać informację o zbyt długim czasie otwarcia, wywołuje funkcję Register obiektu Timer. Argumentami tej funkcji jest długość limitu czasowego oraz wskaźnik na obiekt TimerClient, którego funkcja TimeOut będzie wywołana w przypadku, gdy upłynie limit czasu.

150

ROZDZIAŁ 12. ISP — ZASADA SEGREGACJI INTERFEJSÓW

W jaki sposób można skłonić obiekt klasy TimerClient do komunikacji z obiektem TimedDoor tak, aby kod wewnątrz klasy TimedDoor uzyskał informację o tym, że upłynął limit czasu? Jest na to kilka sposobów. Naiwny projekt pokazano na rysunku 12.1. Wymuszamy w nim, aby klasa Door, a w związku z tym także klasa TimedDoor, dziedziczyła po klasie TimerClient. W ten sposób obiekt klasy TimerClient może się zarejestrować w obiekcie klasy Timer i otrzymać komunikat TimeOut.

Rysunek 12.1. Interfejs TimerClient na szczycie hierarchii

Chociaż takie rozwiązanie jest powszechnie stosowane, to są z nim związane pewne problemy. Jednym z najważniejszych jest to, że klasa Door zależy teraz od klasy TimerClient. Nie wszystkie odmiany klasy Door wymagają mechanizmu czasowego. Pierwotna abstrakcja klasy Door nie ma z nim nic wspólnego. W przypadku tworzenia pochodnych klasy Door niewymagających odmierzania czasu należałoby dostarczyć zdegenerowanych implementacji metody TimeOut, co stanowi potencjalne naruszenie zasady LSP. Co więcej, aplikacje wykorzystujące te pochodne będą musiały zaimportować definicję klasy TimerClient, mimo że nie jest ona używana. Takie rozwiązanie wydaje zapach niepotrzebnej złożoności i niepotrzebnej redundancji. Jest to przykład zaśmiecania interfejsu — problemu, który jest powszechnie znany w językach o typowaniu statycznym, takich jak C++ i Java. Interfejs klasy Door został zanieczyszczony metodą, której nie potrzebował. Metoda została włączona do interfejsu, mimo że wymagała jej tylko jedna klasa pochodna. Gdybyśmy konsekwentnie stosowali tę praktykę, to za każdym razem, gdy klasa pochodna wymagałaby jakiejś metody, dodawalibyśmy ją do klasy bazowej. To jeszcze bardziej zaśmieciłoby interfejs klasy bazowej, przez co stałby się on „gruby”. Co więcej, każdorazowe dodanie metody do klasy bazowej spowodowałoby konieczność zaimplementowania tej metody w klasach potomnych (lub zgody na wywołanie metody domyślnej z klasy bazowej). Rzeczywiście, popularną praktyką jest dodawanie tych interfejsów do klasy bazowej i definiowanie zdegenerowanych implementacji. Tylko grupa klas, które rzeczywiście wymagają specyficznej implementacji, taką implementację definiuje. Dzięki temu klasy pochodne nie są obciążone koniecznością implementacji zbędnych interfejsów. Jak dowiedzieliśmy się wcześniej, taka praktyka narusza zasadę LSP, co prowadzi do problemów z utrzymaniem oraz z wielokrotnym wykorzystywaniem oprogramowania.

Odrębne klienty oznaczają odrębne interfejsy Door i TimerClient to interfejsy, które są używane przez całkowicie różne klienty. Z interfejsu TimerClient korzysta klasa Timer, natomiast interfejs Door jest używany przez klasy wykonujące operacje na drzwiach.

Ponieważ klienty są odrębne, interfejsy także powinny być oddzielne. Dlaczego? Ponieważ klienty wywierają wpływ na interfejsy, które one wykorzystują.

ISP — ZASADA SEGREGACJI INTERFEJSÓW

151

Siła oddziaływania klientów na interfejsy Kiedy mówimy o siłach, które powodują zmiany w oprogramowaniu, zwykle myślimy o tym, jaki wpływ na użytkowników będą miały zmiany w interfejsach. Na przykład jeśli zmieni się interfejs TimerClient, będziemy zainteresowani zmianami we wszystkich użytkownikach interfejsu TimerClient. Istnieje jednak siła działająca w przeciwnym kierunku. Czasami to użytkownik wymusza zmiany w interfejsie. Na przykład niektórzy użytkownicy klasy Timer mogą zarejestrować więcej niż jedno żądanie zarządzania czasem. Rozważmy sposób działania obiektu klasy TimedDoor. Kiedy wykryje sytuację otwarcia drzwi, wysyła komunikat Register do obiektu Timer z żądaniem obsługi limitu czasu. Zanim jednak upłynie ten limit czasu, drzwi zamykają się, pozostają przez chwilę zamknięte, a następnie otwierają się ponownie. To sprawia, że rejestrowane jest nowe żądanie obsługi limitu czasu, zanim upłynie poprzednie. W końcu upływa pierwszy limit czasu i następuje wywołanie funkcji Timeout interfejsu TimedDoor. Obiekt klasy Door zgłasza fałszywy alarm. Problem ten można skorygować, stosując konwencję pokazaną na listingu 12.3. Do każdej operacji rejestracji limitu czasowego dołączono unikatowy identyfikator timeOutId. Ten identyfikator powtórzono w wywołaniu TimeOut interfejsu TimerClient. Dzięki temu każda pochodna interfejsu TimerClient ma informację o tym, na jakie żądanie obsługi limitu czasu odpowiada. Listing 12.3. Klasa Timer z identyfikatorem class Timer { public: void Register(int timeout, int timeOutId, TimerClient* client); }; class TimerClient { public: virtual void TimeOut(int timeOutId) = 0; };

Bez wątpienia ta zmiana będzie dotyczyć wszystkich użytkowników interfejsu TimerClient. Akceptujemy tę niedogodność, ponieważ brak identyfikatora timeOutId jest przeoczeniem, które wymaga korekty. Jednak zastosowanie projektu pokazanego na rysunku 12.1 spowoduje także, że wprowadzenie korekty będzie miało wpływ na interfejs Door oraz na wszystkich klientów interfejsu Door! Takie rozwiązanie wykazuje cechy sztywności i lepkości. Dlaczego błąd w interfejsie TimerClient ma jakikolwiek wpływ na pochodne interfejsu Door, które nie wymagają obsługi limitu czasu? Kiedy zmienna w jednej części programu ma wpływ na inne, pozornie niezwiązane z nią części programu, koszt i reperkusje takich zmian są nieprzewidywalne, a ryzyko popełnienia niezamierzonego błędu przy okazji wprowadzania zmiany dramatycznie wzrasta.

ISP — zasada segregacji interfejsów Klienty nie powinny być zmuszone do zależności od metod, których nie używają. Kiedy klasy klienckie są zmuszane do zależności od metod, z których nie korzystają, to te klasy klienckie muszą dostosowywać się do zmian w tych metodach. Powoduje to zbędne sprzężenia pomiędzy wszystkimi klientami. Mówiąc inaczej, gdy klient zależy od klasy zawierającej metody, których ten klient nie używa, ale używają ich inne klienty, to na tego klienta będą miały wpływ zmiany w klasie wymuszane przez te inne klienty. Chcielibyśmy uniknąć takich sprzężeń, o ile to możliwe, dlatego staramy się oddzielać od siebie interfejsy.

152

ROZDZIAŁ 12. ISP — ZASADA SEGREGACJI INTERFEJSÓW

Interfejsy klas a interfejsy obiektów Rozważmy ponownie klasę TimedDoor. Mamy tu do czynienia z obiektem, który ma dwa odrębne interfejsy używane przez dwie osobne klasy klienckie — Timer oraz użytkowników interfejsu Door. Te dwa interfejsy muszą być zaimplementowane w tym samym obiekcie, ponieważ implementacja obu interfejsów operuje na tych samych danych. Zatem w jaki sposób można zapewnić zgodność z zasadą ISP? W jaki sposób można oddzielić od siebie interfejsy, kiedy muszą być zaimplementowane łącznie? Kluczem do rozwiązania tego problemy jest fakt, że klienty obiektu nie wymagają dostępu do niego za pośrednictwem interfejsu tego obiektu. Zamiast tego mogą one uzyskać dostęp do obiektu za pomocą delegacji albo klasy bazowej obiektu.

Separacja przez delegację Jednym z rozwiązań może być stworzenie obiektu potomnego implementującego interfejs TimerClient, który będzie delegował wywołania do klasy TimedDoor. Takie rozwiązanie przedstawiono na rysunku 12.2.

Rysunek 12.2. Adapter obsługi limitu czasowego

Kiedy obiekt klasy TimedDoor chce zarejestrować żądanie obsługi limitu czasowego w klasie Timer, tworzy egzemplarz klasy DoorTimerAdapter i rejestruje go w klasie Timer. Kiedy obiekt klasy Timer wysyła komunikat TimeOut do obiektu klasy DoorTimerAdapter, to ten obiekt deleguje komunikat do obiektu klasy TimedDoor. Takie rozwiązanie jest zgodne z zasadą ISP i zapobiega sprzęganiu klientów interfejsu Door z interfejsem Timer. Nawet gdyby w interfejsie Timer wprowadzono zmianę pokazaną na listingu 12.3, to nie miałoby to wpływu na żadnego z użytkowników interfejsu Door. Co więcej, klasa TimedDoor nie musi mieć takiego samego interfejsu jak klasa TimerClient. Klasa DoorTimerAdapter może przetłumaczyć interfejs TimerClient na interfejs TimedDoor. Zatem jest to bardzo uniwersalne rozwiązanie (patrz listing 12.4). Listing 12.4. TimedDoor.cpp class TimedDoor : public Door { public: virtual void DoorTimeOut(int timeOutId); }; class DoorTimerAdapter : public TimerClient { public: DoorTimerAdapter(TimedDoor& theDoor) : itsTimedDoor(theDoor) {} virtual void TimeOut(int timeOutId)

PRZYKŁAD INTERFEJSU UŻYTKOWNIKA BANKOMATU

153

{itsTimedDoor.DoorTimeOut(timeOutId);}

};

private: TimedDoor& itsTimedDoor;

Przedstawione rozwiązanie jest jednak trochę nieeleganckie. Wymaga ono stworzenia nowego obiektu za każdym razem, gdy rejestrujemy obsługę limitu czasowego. Ponadto delegacja wymaga bardzo niewielkich, ale jednak niezerowych zasobów w postaci czasu wykonywania i pamięci. W niektórych dziedzinach (na przykład we wbudowanych systemach czasu rzeczywistego) te zasoby są na tyle cenne, że może to stanowić problem.

Separacja przez wielokrotne dziedziczenie Na rysunku 12.3 i listingu 12.5 pokazano, jak można użyć dziedziczenia wielokrotnego do zapewnienia zgodności z zasadą ISP. W tym modelu interfejs TimedDoor dziedziczy zarówno po interfejsie Door, jak i po interfejsie TimerClient. Chociaż klienty obu klas bazowych mogą korzystać z interfejsu TimedDoor, żaden z nich nie jest zależny od tego interfejsu. Oznacza to, że klienty korzystają z tego samego obiektu za pośrednictwem odrębnych interfejsów.

Rysunek 12.3. Interfejs TimedDoor z wielokrotnym dziedziczeniem Listing 12.5. TimedDoor.cpp class TimedDoor : public Door, public TimerClient { public: virtual void TimeOut(int timeOutId); };

Według mnie to rozwiązanie jest najlepsze. Rozwiązanie z rysunku 12.2 byłoby lepsze od tego, które pokazano na rysunku 12.3, tylko wtedy, gdyby tłumaczenie interfejsów za pośrednictwem obiektu DoorTimerAdapter było konieczne lub gdyby były potrzebne różne tłumaczenia w różnych sytuacjach.

Przykład interfejsu użytkownika bankomatu Rozważmy teraz nieco bardziej rozbudowany przykład — tradycyjny problem dotyczący bankomatów (ang. Automatic Teller Machine — ATM). Interfejs użytkownika bankomatu musi być bardzo elastyczny. Wyjście musi być tłumaczone na wiele języków. Może być prezentowane na ekranie lub na tablecie brajlowskim. Może być też czytane za pomocą syntezatora mowy. Oczywiście można to osiągnąć poprzez stworzenie abstrakcyjnej klasy bazowej, która ma metody abstrakcyjne dla wszystkich komunikatów, które muszą być zaprezentowane przez interfejs (rysunek 12.4).

154

ROZDZIAŁ 12. ISP — ZASADA SEGREGACJI INTERFEJSÓW

Rysunek 12.4. Różne typy interfejsów użytkowników bankomatu

Załóżmy również, że każda transakcja, którą może wykonywać bankomat, jest zamknięta jako pochodna klasy Transaction. Możemy mieć więc takie klasy jak DepositTransaction, WithdrawalTransaction oraz TransferTransaction. Każda z klas wywołuje metody interfejsu UI. Na przykład aby zwrócić się do użytkownika o wprowadzenie kwoty do wpłaty, obiekt DepositTransaction wywołuje metodę RequestDepositAmount klasy UI. Podobnie aby zapytać użytkownika o kwotę, jaką chce przelać pomiędzy rachunkami, obiekt TransferTransaction wywołuje metodę RequestTransferAmount klasy UI. Model ten zaprezentowano na diagramie na rysunku 12.5.

Rysunek 12.5. Hierarchia transakcji wykonywanych przez bankomat

Zwróćmy uwagę, że przedstawiona sytuacja jest dokładnie taka, jakiej każe nam unikać zasada ISP. Każda z transakcji wywołuje metodę interfejsu UI, z której nie korzysta żadna inna klasa. Stwarza to możliwość, że zmiany wprowadzone w jednej z pochodnych klasy Transaction wymuszą odpowiednie zmiany w interfejsie UI, co wpłynie na wszystkie inne pochodne klasy Transaction oraz wszystkie inne klasy, które zależą od interfejsu UI. Takie rozwiązanie wykazuje cechy sztywności i kruchości. Na przykład gdybyśmy chcieli dodać klasę PayGasBillTransaction, musielibyśmy dodać nowe metody do interfejsu UI, aby obsłużyć unikatowe komunikaty wyświetlane w tej transakcji. Niestety, ponieważ klasy DepositTransaction, WithdrawalTransaction i TransferTransaction zależą od interfejsu UI, to wszystkie trzy trzeba na nowo skompilować. Co gorsza, jeśli operacje były dystrybuowane jako komponenty w osobnych bibliotekach DLL lub bibliotekach współdzielonych, to składniki te będą musiały być zainstalowane na nowo, pomimo że nie zmieniła się w nich logika. Wyraźnie czuć woń lepkości.

PRZYKŁAD INTERFEJSU UŻYTKOWNIKA BANKOMATU

155

Tego niefortunnego sprzężenia można uniknąć przez rozdzielenie interfejsu UI do odrębnych interfejsów, takich jak DepositUI, WithdrawUI oraz TransferUI. Te oddzielone interfejsy mogą być wielokrotnie dziedziczone i tworzyć ostateczny interfejs UI. Opisany model pokazano na rysunku 12.6 i listingu 12.6.

Rysunek 12.6. Rozdzielony interfejs użytkownika bankomatu Listing 12.6. Rozdzielony interfejs użytkownika bankomatu class DepositUI { public: virtual void RequestDepositAmount() = 0; }; class DepositTransaction : public Transaction { public: DepositTransaction(DepositUI& ui) : itsDepositUI(ui) {}

};

virtual void Execute() { ... itsDepositUI.RequestDepositAmount(); ... } private: DepositUI& itsDepositUI;

class WithdrawalUI { public:

156

};

ROZDZIAŁ 12. ISP — ZASADA SEGREGACJI INTERFEJSÓW

virtual void RequestWithdrawalAmount() = 0;

class WithdrawalTransaction : public Transaction { public: WithdrawalTransaction(WithdrawalUI& ui) : itsWithdrawalUI(ui) {}

};

virtual void Execute() { ... itsWithdrawalUI.RequestWithdrawalAmount(); ... } private: WithdrawalUI& itsWithdrawalUI;

class TransferUI { public: virtual void RequestTransferAmount() = 0; }; class TransferTransaction : public Transaction { public: TransferTransaction(TransferUI& ui) : itsTransferUI(ui) {}

};

virtual void Execute() { ... itsTransferUI.RequestTransferAmount(); ... } private: TransferUI& itsTransferUI;

class UI : public DepositUI , public WithdrawalUI , public TransferUI { public: virtual void RequestDepositAmount(); virtual void RequestWithdrawalAmount(); virtual void RequestTransferAmount(); };

Każde utworzenie nowej pochodnej klasy Transaction wymaga odpowiedniej klasy bazowej abstrakcyjnego interfejsu UI, a zatem interfejs UI oraz wszystkie jego pochodne muszą się zmienić. Jednak interfejsy te nie są często stosowane. Prawdopodobnie są one używane tylko przez program główny lub inny proces odpowiedzialny za zainicjowanie systemu i stworzenie konkretnego egzemplarza UI. Zatem wpływ dodania nowych klas bazowych UI na resztę aplikacji jest minimalny. Uważna analiza listingu 12.6 pokazuje jeden z problemów ze zgodnością z ISP, który nie był oczywisty w przykładzie TimedDoor. Zwróćmy uwagę, że każda transakcja musi w jakiś sposób dowiedzieć się o swojej konkretnej wersji interfejsu UI. Klasa DepositTransaction musi wiedzieć o interfejsie DepositUI, klasa WithdrawTransaction musi wiedzieć o interfejsie WithdrawUI itp. Na listingu 12.6 problem ten rozwiązałem poprzez wymuszenie konstruowania każdej transakcji z referencją do określonego interfejsu UI. Zauważmy, że to pozwala na zastosowanie idiomu z listingu 12.7.

PRZYKŁAD INTERFEJSU UŻYTKOWNIKA BANKOMATU

157

Listing 12.7. Idiom inicjalizacji interfejsu UI Gui; // obiekt globalny; void f() { DepositTransaction dt(Gui); }

To rozwiązanie jest wygodne, ale zmusza do tego, by każda transakcja przechowywała składową oznaczającą referencję do swojego interfejsu UI. Innym sposobem rozwiązania tego problemu jest stworzenie zbioru globalnych stałych, jak pokazano na listingu 12.8. Stosowanie zmiennych globalnych nie zawsze jest objawem złego projektu. W tym przypadku zmienne globalne dają wyraźną korzyść łatwego dostępu. Ponieważ są to referencje, to nie można ich w żaden sposób zmienić. W związku z tym nie mogą być zmieniane w sposób, który mógłby zaskoczyć innych użytkowników. Listing 12.8. Wydzielenie globalnych wskaźników // w jakimś module, który będzie skonsolidowany // z resztą aplikacji. static UI Lui; // obiekt nieglobalny; DepositUI& GdepositUI = Lui; WithdrawalUI& GwithdrawalUI = Lui; TransferUI& GtransferUI = Lui;

// W module depositTransaction.h class WithdrawalTransaction : public Transaction { public:

};

virtual void Execute() { ... GwithdrawalUI.RequestWithdrawalAmount(); ... }

W języku C++ można by ulec pokusie umieszczenia wszystkich zmiennych globalnych z listingu 12.8 w pojedynczej klasie, tak aby zapobiec zaśmiecaniu globalnej przestrzeni nazw. Takie podejście zaprezentowano na listingu 12.9. Rozwiązanie to ma jednak niefortunny efekt. Aby skorzystać z interfejsu UIGlobals, trzeba włączyć plik nagłówkowy ui_globals.h. To z kolei powoduje włączenie nagłówków depositUI.h, withdrawUI.h i transferUI.h. Oznacza to, że każdy moduł, który zamierza skorzystać z dowolnego z interfejsów UI w przechodni sposób, zależy od nich wszystkich. To jest dokładnie taka sytuacja, której staramy się unikać poprzez stosowanie zasady ISP. Jeśli zostanie wprowadzona zmiana do dowolnego z interfejsów UI, trzeba ponownie skompilować wszystkie moduły zawierające instrukcję #include "ui_globals.h". Klasa UIGlobals spowodowała ponowne scalenie interfejsów, które z tak wielkim trudem rozdzieliliśmy! Listing 12.9. Opakowanie obiektów globalnych w klasie // w pliku ui_globals.h #include "depositUI.h" #include "withdrawalUI.h" #include "transferUI.h" class UIGlobals {

158

};

ROZDZIAŁ 12. ISP — ZASADA SEGREGACJI INTERFEJSÓW

public: static WithdrawalUI& withdrawal; static DepositUI& deposit; static TransferUI& transfer

// w pliku ui_globals.cc static UI Lui; // obiekt nieglobalny; DepositUI& UIGlobals::deposit = Lui; WithdrawalUI& UIGlobals::withdrawal = Lui; TransferUI& UIGlobals::transfer = Lui;

Poliady i monady Rozważmy funkcję g, która wymaga dostępu zarówno do interfejsu DepositUI, jak i TransferUI. Weźmy pod uwagę także to, że chcemy przekazać do tej funkcji referencje do interfejsów użytkownika. Czy powinniśmy zapisać taką funkcję w następujący sposób: void g(DepositUI&, TransferUI&);

Czy też powinniśmy zapisać ją tak: void g(UI&);

Pokusa, aby zapisać funkcję w tej drugiej postaci (monadycznej), jest bardzo silna. W końcu wiemy, że w pierwszej (poliadycznej) formie oba argumenty odwołują się do tego samego obiektu. Ponadto gdybyśmy użyli formy poliadycznej, jej wywołanie mogłoby wyglądać następująco: g(ui, ui);

Taki przykład nie wydaje się właściwy. Tak czy inaczej, forma poliadyczna jest często bardziej preferowana od monadycznej. Forma monadyczna wymusza od funkcji g zależności od wszystkich interfejsów, które zawiera interfejs UI. A zatem zmiana interfejsu WithdrawUI będzie miała wpływ na funkcję g oraz wszystkich klientów funkcji g. To znacznie gorsze niż wywołanie g(ui,ui)! Ponadto nie możemy mieć pewności, że obydwa argumenty funkcji g będą zawsze odwoływały się do tego samego obiektu! W przyszłości obiekty interfejsów mogą być rozdzielone z jakiegoś powodu. Funkcja g nie musi wiedzieć, że wszystkie interfejsy zostały połączone w jeden obiekt. Z tego powodu osobiście wolę stosować formę poliadyczną dla takich funkcji. Grupowanie klientów. Klienty często mogą być grupowane według metod usługowych, które wywołują. Takie grupowanie umożliwia tworzenie oddzielnych interfejsów dla każdej grupy zamiast dla każdego klienta. To znacznie zmniejsza liczbę interfejsów, które usługa musi zaimplementować, a także zapobiega sytuacji, w której usługa zależy od każdego typu klienta. Czasami metody wywoływane przez różne grupy klientów nakładają się na siebie. Jeśli ten zakład jest niewielki, to interfejsy dla grup powinny pozostać oddzielne. Wspólne funkcje powinny być zadeklarowane we wszystkich nakładających się na siebie interfejsach. Klasa serwera odziedziczy wspólne funkcje z każdego z tych interfejsów, ale zaimplementuje je tylko raz. Zmieniające się interfejsy. W czasie utrzymywania aplikacji obiektowych interfejsy do istniejących klas i komponentów często się zmieniają. Czasami zmiany te mają ogromny wpływ na system. Zmuszają do ponownej kompilacji i wdrażania bardzo dużej części systemu. Wpływ ten można złagodzić poprzez dodawanie nowych interfejsów do istniejących obiektów zamiast zmieniania interfejsów istniejących. Klienty starego interfejsu, które chcą uzyskać dostęp do metod nowego interfejsu, mogą odpytać obiekt o ten interfejs tak, jak pokazano na listingu 12.10.

BIBLIOGRAFIA

159

Listing 12.10. Odpytywanie obiektów o określony interfejs void Client(Service* s) { if (NewService* ns = dynamic_cast(s)) { }

}

// użycie nowego interfejsu usługi

Tak jak w przypadku wszystkich zasad należy uważać, aby nie przesadzić z ich stosowaniem. Widmo klasy z setkami różnych interfejsów, z których niektóre są posegregowane według klienta, a inne według wersji, jest dość przerażające.

Wniosek „Grube” klasy powoduję dziwaczne i szkodliwe sprzężenia pomiędzy klasami klienckimi. Gdy jeden z klientów wymusza zmiany w grubej klasie, zmiany te mają wpływ na wszystkie pozostałe klasy klienckie. Z tego względu klienty powinny zależeć tylko od tych metod, które faktycznie wywołują. Można to osiągnąć poprzez rozdzielenie interfejsu grubej klasy na wiele interfejsów specyficznych dla poszczególnych klientów. Każdy interfejs specyficzny dla klienta deklaruje tylko te funkcje, które wywołuje ten konkretny klient lub grupa klientów. W takiej sytuacji grube klasy mogą dziedziczyć i implementować wszystkie interfejsy specyficzne dla klientów. To eliminuje zależność klientów od metod, których one nie wywołują, i pozwala klientom zachować niezależność od siebie.

Bibliografia 1. Gamma, et al., Design Patterns, Reading, MA: Addison-Wesley, 19951.

1

Wydanie polskie: Wzorce projektowe. Elementy oprogramowania obiektowego wielokrotnego użytku, Wydawnictwa Naukowo-Techniczne, 2005 — przyp. tłum.

160

ROZDZIAŁ 12. ISP — ZASADA SEGREGACJI INTERFEJSÓW

CZĘŚĆ III Studium przypadku: system płacowy

Nadszedł czas na pierwsze poważne studium przypadku. Do tej pory analizowaliśmy praktyki i zasady. Omówiliśmy istotę projektowania. Pisaliśmy o testowaniu i planowaniu. Teraz nadszedł czas, aby wykonać jakąś konkretną pracę. W następnych kilku rozdziałach przeanalizujemy projekt i implementację systemu listy płac. W dalszej części książki zamieszczono szczątkowy opis tego systemu. W ramach tego projektu i implementacji skorzystamy z kilku różnych wzorców projektowych. Wśród nich są Polecenia (ang. Command), Metoda szablonowa (ang. Template method), Strategia (ang. Strategy), Singleton, Pusty obiekt (ang. Null object), Fabryka (ang. Factory) i Fasada (ang. Facade). Wzorce te będą tematem kilku kolejnych rozdziałów. Następnie w rozdziale 18. przeanalizujemy projekt i implementację problemu listy płac. Istnieje kilka sposobów czytania tego studium przypadku.  Zapoznanie się z kolejnymi rozdziałami w celu poznania wzorców projektowych, a następnie zaob-

serwowanie sposobów ich zastosowania do rozwiązania problemu listy płac.  Czytelnicy, którzy znają wzorce projektowe i nie są zainteresowani ich przeglądem, mogą przejść

bezpośrednio do rozdziału 18.  Przeczytanie najpierw rozdziału 18., a następnie powrót do wcześniejszych rozdziałów opisujących

wykorzystane wzorce projektowe.  Przeczytanie rozdziału 18. fragmentami. W przypadku napotkania wzorca, którego czytelnik nie zna,

można przeczytać rozdział, który opisuje ten wzorzec, a następnie powrócić do rozdziału 18.  W istocie nie istnieją sztywne reguły. Należy wybrać strategię, która wydaje się najbardziej odpo-

wiednia. Można również zastosować własną.

162

ROZDZIAŁ 13. WZORCE PROJEKTOWE POLECENIE I AKTYWNY OBIEKT

Szczątkowa specyfikacja systemu płacowego Poniżej zamieszczono kilka notatek, które zrobiliśmy podczas rozmów z klientem. System składa się z bazy danych pracowników firmy oraz związanych z nimi danych, takich jak karty czasu pracy. System powinien wypłacać wynagrodzenie wszystkim pracownikom. Pracownikom muszą być wypłacane wynagrodzenia w prawidłowej wysokości i na czas — zgodnie z określonymi metodami. Ponadto muszą być naliczane różne potrącenia od wynagrodzeń.  Niektórzy pracownicy pracują na godziny. Wypłaca się im wynagrodzenie według stawki godzino-

 







wej, która jest ustawiana w jednym z pól w rekordzie pracownika. Pracownicy dostarczają dzienne karty pracy, w których są zarejestrowane daty oraz liczba przepracowanych godzin. Jeśli pracują więcej niż 8 godzin dziennie, to za dodatkowe godziny są opłacani według stawki wynoszącej 1,5 raza więcej od ich normalnej stawki. Wynagrodzenia są im wypłacane w każdy piątek. Niektórzy pracownicy otrzymują „płaskie” wynagrodzenie. Wypłata następuje ostatniego roboczego dnia w miesiącu. Ich miesięczne wynagrodzenie jest zawarte w jednym z pól w rekordzie pracownika. Niektórzy pracownicy otrzymują prowizję na podstawie zrealizowanej przez nich sprzedaży. Dostarczają dokumenty potwierdzające sprzedaż i zawierające datę sprzedaży oraz kwotę. Stawka prowizji jest zapisana w jednym z pól rekordu pracownika. Wynagrodzenia są im wypłacane w każdy piątek. Pracownicy mają możliwość wyboru metody wypłaty. Mogą otrzymywać czeki, które są wysyłane pod wskazane adresy pocztowe. Mogą odebrać czeki osobiście od płatnika lub mogą zażądać przelania pieniędzy na wskazany rachunek bankowy. Niektórzy pracownicy należą do związku zawodowego. W rekordzie pracownika istnieje pole dotyczące wysokości należnych składek. Składki są potrącane z ich uposażenia. Ponadto związek zawodowy od czasu do czasu może pobierać dodatkowe opłaty od indywidualnych członków związku. Związek zawodowy dostarcza zleceń potrąceń co tydzień. Wskazane kwoty muszą być potrącone z kolejnej wypłaty wskazanego pracownika. Aplikacja płacowa jest uruchamiana tylko raz każdego dnia roboczego i dokonuje wypłat określonej grupie pracowników. System uzyska informacje dotyczące daty wypłaty. Na tej podstawie będzie mógł obliczyć wynagrodzenia od ostatniej wypłaty zrealizowanej dla pracownika do wskazanej daty.

Ćwiczenie Zanim przejdziemy dalej, zachęcam czytelników, aby teraz zaprojektowali opisany system płacowy samodzielnie. Można naszkicować kilka wstępnych diagramów UML. Jeszcze lepiej będzie, jeśli spróbujesz zaimplementować kilka pierwszych przypadków użycia, stosując technikę „najpierw test”. Należy stosować zasady i praktyki poznane do tej pory i dążyć do stworzenia zrównoważonego i „zdrowego” projektu. Jeśli masz zamiar to zrobić, powinieneś przyjrzeć się opisanym poniżej przypadkom użycia. W przeciwnym razie należy je pominąć. Będą zaprezentowane ponownie w rozdziale opisującym rozwiązanie systemu płacowego.

Przypadek użycia nr 1: dodawanie nowego pracownika Nowy pracownik jest dodawany w wyniku transakcji AddEmp. Transakcja zawiera nazwisko pracownika, adres oraz numer przypisany do pracownika. Transakcja może przyjąć jedną z następujących trzech form: AddEmp "" "" H AddEmp "" "" S AddEmp "" "" C

Następuje utworzenie rekordu pracownika i przypisanie wartości odpowiednich pól.

SZCZĄTKOWA SPECYFIKACJA SYSTEMU PŁACOWEGO

Alternatywa: Błąd w strukturze transakcji. Jeśli struktura transakcji jest nieodpowiednia, to jest wyświetlany komunikat o błędzie i nie są podejmowane żadne działania.

Przypadek użycia nr 2: usuwanie pracownika Pracownicy są usuwani w wyniku otrzymania transakcji DelEmp. Transakcja ta ma następujący format: DelEmp

Po otrzymaniu tej transakcji następuje usunięcie odpowiedniego rekordu pracownika. Alternatywa: Nieprawidłowy bądź nieznany identyfikator EmpID. Jeśli pole identyfikatora ma nieprawidłową strukturę lub jeśli nie odwołuje się do prawidłowego rekordu pracownika, to transakcja powoduje wyświetlenie komunikatu o błędzie i nie jest podejmowane żadne inne działanie.

Przypadek użycia nr 3: dostarczenie karty pracy Po otrzymaniu transakcji TimeCard system utworzy rekord karty czasu pracy i powiąże go z rekordem właściwego pracownika. TimeCard

Alternatywa 1: Wskazany pracownik nie pracuje według stawki godzinowej. System wyświetli odpowiedni komunikat o błędzie i nie podejmie żadnych innych działań. Alternatywa 2: Błąd w strukturze transakcji. System wyświetli odpowiedni komunikat o błędzie i nie podejmie żadnych innych działań.

Przypadek użycia nr 4: dostarczenie raportu sprzedaży Po otrzymaniu transakcji SalesReceipt system utworzy nowy rekord raportu sprzedaży i powiąże go z rekordem właściwego pracownika. SalesReceipt

Alternatywa 1: Wskazany pracownik nie jest uprawniony do prowizji od sprzedaży. System wyświetli odpowiedni komunikat o błędzie i nie podejmie żadnych innych działań. Alternatywa 2: Błąd w strukturze transakcji. System wyświetli odpowiedni komunikat o błędzie i nie podejmie żadnych innych działań.

163

164

ROZDZIAŁ 13. WZORCE PROJEKTOWE POLECENIE I AKTYWNY OBIEKT

Przypadek użycia nr 5: dostarczenie informacji o opłacie na rzecz związku zawodowego Po otrzymaniu transakcji ServiceCharge system utworzy rekord opłaty na rzecz związku zawodowego i powiąże go z rekordem właściwego członka związku zawodowego. ServiceCharge

Alternatywa: Nieprawidłowy format transakcji. Jeśli transakcja ma nieprawidłowy format lub jeśli identyfikator nie odnosi się do członka związku zawodowego, to następuje wyświetlenie odpowiedniego komunikatu o błędzie.

Przypadek użycia nr 6: zmiana danych pracownika Po otrzymaniu transakcji ChgEmp system zmodyfikuje szczegółowe dane w rekordzie wskazanego pracownika. Transakcja ma kilka możliwych odmian. ChgEmp Name ChgEmp Address ChgEmp Hourly ChgEmp Salaried ChgEmp Commissioned

ChgEmp Hold ChgEmp Direct ChgEmp Mail ChgEmp Member Dues ChgEmp NoMember

Zmiana nazwiska pracownika Zmiana adresu pracownika Zmiana sposobu wynagradzania przy stawce godzinowej Zmiana sposobu wynagradzania przy pensji miesięcznej Zmiana sposobu wynagradzania przy prowizji od sprzedaży Osobisty odbiór czeku Przelew na rachunek bankowy Przesłanie czeku pocztą Ustawia opcję członkostwa pracownika w związku zawodowym Usuwa opcję członkostwa pracownika w związku zawodowym

Alternatywa: Błędy transakcji. Jeśli struktura transakcji jest nieprawidłowa lub jeśli identyfikator nie odnosi się do rzeczywistego pracownika albo identyfikator odnosi się do już istniejącego członka związku zawodowego, to następuje wyświetlenie odpowiedniego komunikatu o błędzie i system nie podejmuje żadnych innych działań.

Przypadek użycia nr 7: wygenerowanie listy płac na dzień Po otrzymaniu transakcji Payday system wyszukuje wszystkich pracowników, dla których tego dnia powinna być zrealizowana wypłata. Następnie system określa, jaką kwotę powinien wypłacić każdemu z nich, i realizuje wypłatę zgodnie z wybranym sposobem wypłaty. Payday

SZCZĄTKOWA SPECYFIKACJA SYSTEMU PŁACOWEGO

165

R OZDZIAŁ 13

Wzorce projektowe Polecenie i Aktywny obiekt

Żaden człowiek nie otrzymał od natury prawa do wydawania poleceń innym ludziom — Denis Diderot (1713 – 1784)

Spośród wszystkich wzorców projektowych, które opisano przez ostatnie lata, wzorzec Polecenie (ang. cornmand) zrobił na mnie wrażenie jednego z najprostszych i najbardziej eleganckich. Jednak jak się wkrótce przekonamy, jego prostota jest pozorna. Zakres zastosowań wzorca Polecenie jest prawdopodobnie nieograniczony. Prostota wzorca projektowego Polecenie, jak pokazano na rysunku 13.1, jest niemal śmieszna. Na listingu 13.1 przedstawiono kod, który nie robi zbyt wiele. Istnienie wzorca projektowego składającego się z zaledwie jednego interfejsu z jedną metodą wydaje się absurdalne.

Rysunek 13.1. Wzorzec Polecenie Listing 13.1. Command.java public interface Command { public void do(); }

166

ROZDZIAŁ 13. WZORCE PROJEKTOWE POLECENIE I AKTYWNY OBIEKT

Jednak w rzeczywistości prezentowany wzorzec przekracza pewną granicę. To w przekroczeniu tej granicy istnieje interesująca złożoność wzorca Polecenie. Większość klas łączy zestaw metod z odpowiadającymi im zbiorami zmiennych. Wzorzec Polecenie nie realizuje tego schematu. W tym przypadku wzorzec obejmuje funkcję wolną od jakichkolwiek zmiennych. Według ścisłych reguł projektowania obiektowego to jest niedopuszczalne — takie rozwiązania są sprzeczne z przyjętą konwencją dekompozycji funkcjonalności. Wzorzec podnosi rolę funkcji do roli klasy. To istne bluźnierstwo! Z drugiej strony, na granicy dwóch paradygmatów można zaobserwować interesujące rzeczy.

Proste polecenia Kilka lat temu pracowałem jako konsultant dla dużej firmy produkującej fotokopiarki. Moim zadaniem była pomoc jednemu z zespołów projektowych przy projektowaniu i implementacji wbudowanego oprogramowania sterującego działaniem nowej kopiarki. Wpadliśmy na pomysł, aby zastosować wzorzec projektowy Polecenie w celu zarządzania urządzeniami. Stworzyliśmy hierarchię podobną do tej, którą przedstawiono na rysunku 13.2.

Rysunek 13.2. Proste polecenia dla oprogramowania kopiarki

Rola tych klas powinna być oczywista. Wywołanie metody do() dla polecenia RelayOnCommand powoduje włączenie określonego przekaźnika. Wywołanie metody do() dla polecenia MotorOffCommand powoduje wyłączenie określonego silnika. Adres silnika lub przekaźnika jest przekazywany do obiektu za pośrednictwem argumentu jego konstruktora. Dzięki takiej strukturze możemy przekazywać obiekty poleceń pomiędzy komponentami systemu i wykonywać na nich funkcje do () bez konieczności dokładnej znajomości rodzaju reprezentowanych poleceń. Takie rozwiązanie prowadzi do interesujących uproszczeń. System był sterowany zdarzeniami. Przekaźniki są otwierane i zamykane, silniki uruchamiane lub zatrzymywane, a sprzęgła załączane i rozłączane na podstawie określonych zdarzeń, które zachodzą w tym systemie. Wiele z tych zdarzeń było wykrywanych przez czujniki. Na przykład kiedy czujnik optyczny wykrył, że arkusz papieru dotarł do określonego punktu, trzeba było uaktywnić odpowiednie sprzęgło. Można zaimplementować ten mechanizm poprzez związanie odpowiedniego obiektu klasy ClutchOnCommand z obiektem kontrolującym określony czujnik optyczny (patrz rysunek 13.3).

Rysunek 13.3. Polecenie sterowane przez czujnik

TRANSAKCJE

167

Ta prosta struktura ma bardzo ważną zaletę: klasa Sensor nie musi „wiedzieć”, co robi. Za każdym razem, gdy wykrywa zdarzenie, wywołuje funkcję do() obiektu klasy Comnand, z którym jest związana. Oznacza to, że obiekty klasy Sensor nie muszą nic „wiedzieć” o poszczególnych sprzęgłach czy przekaźnikach. Nie muszą „znać” mechanicznej struktury toru arkuszy papieru. Ich funkcja staje się niezwykle prosta. Złożoność problemu określenia, które przekaźniki należy zamknąć w reakcji na zdarzenia wykrywane przez poszczególne czujniki, przeniesiono na poziom funkcji inicjującej. Na pewnym etapie procesu inicjalizacji systemu należy związać poszczególne obiekty klasy Sensor z odpowiednimi obiektami Command. W ten sposób całe okablowanie1 znajduje się w jednym miejscu i jest przeniesione poza główną treść systemu. Co więcej, można by nawet utworzyć prosty plik tekstowy opisujący, które obiekty Sensor są związane z którymi obiektami klasy Command. Program inicjujący mógłby odczytać zawartość tego pliku i odpowiednio skonfigurować system. W ten sposób okablowanie tego systemu może być określone całkowicie poza właściwym programem i może być modyfikowane bez konieczności ponownej kompilacji. Dzięki hermetyzacji pojęcia polecenia wzorzec ten umożliwił wyeliminowanie sprzężenia połączeń logicznych systemu z poszczególnymi urządzeniami. To olbrzymia korzyść.

Transakcje Innym powszechnym zastosowaniem wzorca Polecenie — tym, które przyda się do rozwiązania problemu systemu listy płac — jest tworzenie i realizacja transakcji. Wyobraźmy sobie na przykład, że piszemy program, który utrzymuje bazę danych pracowników (patrz rysunek 13.4). Istnieje szereg działań, które użytkownicy mogą wykonywać na tej bazie danych. Mogą dodawać nowych pracowników, usuwać pracowników istniejących albo zmieniać im atrybuty.

Rysunek 13.4. Baza danych pracowników

1

Połączenia logiczne pomiędzy czujnikami a poleceniami.

168

ROZDZIAŁ 13. WZORCE PROJEKTOWE POLECENIE I AKTYWNY OBIEKT

Gdy użytkownik zdecyduje się dodać nowego pracownika, musi podać wszystkie informacje potrzebne do pomyślnego stworzenia rekordu pracownika. Przed przetworzeniem tych informacji system musi zweryfikować, czy informacje te są poprawne pod względem składni i semantyki. Zastosowanie wzorca Polecenie może pomóc w wykonaniu tego zadania. Obiekt Command pełni rolę repozytorium niezweryfikowanych danych, implementuje metody sprawdzania poprawności oraz implementuje metody, które na koniec wykonują transakcję. Dla przykładu rozważmy projekt pokazany na rysunku 13.5. Klasa AddEmployeeTransaction zawiera te same pola danych co klasa Employee. Zawiera również wskaźnik do obiektu PayClassification. Te pola i obiekt są tworzone na podstawie danych, które użytkownik podaje podczas wydawania systemowi polecenia dodania nowego pracownika.

Rysunek 13.5. Transakcja AddEmployee

Metoda validate przegląda wszystkie dane i sprawdza, czy mają one sens. Sprawdza je pod kątem poprawności składniowej i semantycznej. Może nawet sprawdzić, czy dane w transakcji są spójne z istniejącym stanem bazy danych. Na przykład może sprawdzić, czy taki pracownik wcześniej nie został dodany do bazy danych. Metoda execute korzysta ze zweryfikowanych danych w celu zaktualizowania bazy danych. W tym prostym przykładzie utworzony zostanie nowy obiekt Employee, do którego zostaną załadowane pola z obiektu AddEmployeeTransaction. Obiekt PayClassification zostanie przeniesiony lub skopiowany do obiektu Employee.

Fizyczny i czasowy podział kodu Największą korzyścią wynikającą z tego projektu jest wyraźny podział kodu na część odpowiedzialną za pobieranie danych od użytkownika, część weryfikującą i operującą na tych danych oraz właściwe obiekty biznesowe. Na przykład można oczekiwać, że dane potrzebne do dodania nowego pracownika będą pochodziły z okna dialogowego w jakimś interfejsie GUI. Pomieszanie kodu GUI z algorytmami walidacji i wykonywania transakcji byłoby niekorzystne. Takie sprzężenie uniemożliwiłoby wykorzystanie kodu sprawdzającego poprawność i wykonującego transakcje w innych interfejsach. Dzięki wydzieleniu kodu wykonania transakcji i walidacji do klasy AddEmployeeTransaction udało się fizycznie oddzielić ten kod od interfejsu dostarczania danych. Co więcej, oddzieliliśmy kod, który „wie”, jak manipulować logistyką bazy danych, od obiektów biznesowych.

Czasowy podział kodu Kod weryfikujący poprawność danych i kod wykonawczy zostały rozdzielone także w inny sposób. Po dostarczeniu danych nie ma powodu, aby metody walidacji i przetwarzania danych były wykonywane natychmiast. Obiekty transakcji mogą być umieszczone na liście, a następnie walidowane i przetwarzane znacznie później.

AKTYWNY OBIEKT

169

Załóżmy, że mamy bazę danych, która w ciągu dnia nie może być zmieniana. Zmiany mogą być wprowadzane wyłącznie w godzinach pomiędzy północą a pierwszą w nocy. Byłoby niefortunne, gdyby trzeba było czekać do północy, a potem spieszyć się, aby wpisać wszystkie polecenia przed pierwszą. Wygodniej byłoby wpisać wszystkie polecenia, zwalidować je natychmiast, a następnie przetworzyć później po północy. Wzorzec Polecenie daje nam taką możliwość.

Metoda Undo Na rysunku 13.6 dodano metodę undo() do wzorca Polecenie. Wydaje się oczywiste, że jeśli można zaimplementować metodę do() pochodnej interfejsu Command w celu zapamiętania szczegółów operacji do wykonania, to można także zaimplementować metodę undo(), która cofnie tę operację i przywróci system do stanu pierwotnego.

Rysunek 13.6. Odmiana wzorca Polecenie z metodą Undo

Dla przykładu wyobraźmy sobie aplikację umożliwiającą użytkownikowi rysowanie na ekranie figur geometrycznych. Na pasku narzędzi są przyciski, które pozwalają użytkownikowi rysować okręgi, kwadraty, prostokąty itp. Załóżmy, że użytkownik klika przycisk rysowania okręgu. System tworzy obiekt DrawCircleCommand, a następnie wywołuje metodę do() tego obiektu. Obiekt DrawCircleCommand śledzi mysz użytkownika, czekając na kliknięcie w oknie rysowania. Po tym kliknięciu ustawia punkt kliknięcia jako środek okręgu i przechodzi do rysowania animowanego okręgu o środku w tym punkcie oraz promieniu wynikającym z bieżącej pozycji myszy. Kiedy użytkownik kliknie ponownie, obiekt DrawCircleCommand zatrzymuje animowanie okręgu i dodaje odpowiedni obiekt okręgu do listy figur aktualnie wyświetlanych na ekranie. Obiekt ten zapamiętuje również identyfikator nowego okręgu w pewnej prywatnej zmiennej. Następnie zwraca sterowanie z metody do(). Następnie system umieszcza wykonane polecenie DrawCirlceCommand na stosie zrealizowanych komend. Po jakimś czasie użytkownika klika przycisk Undo na pasku narzędzi. System ściąga ze stosu zrealizowane polecenie i wywołuje na uzyskanym w ten sposób obiekcie Command metodę undo(). Po otrzymaniu komunikatu undo() obiekt DrawCircleCommand usuwa okrąg odpowiadający zapisanemu identyfikatorowi z listy obiektów aktualnie wyświetlanych w obszarze rysowania. Dzięki zastosowaniu tej techniki można łatwo zaimplementować polecenie Cofnij w prawie każdej aplikacji. Kod, dzięki któremu możliwe jest cofnięcie polecenia, jest zawsze przydatny jako uzupełnienie kodu, dzięki któremu polecenie można wykonać.

Aktywny obiekt Jednym z moich ulubionych zastosowań wzorca projektowego Polecenie jest jego użycie we wzorcu Aktywny obiekt (ang. Active object)2. Jest to bardzo stara technika implementacji wielu wątków sterowania. Jest ona używana w takiej czy innej formie do zapewnienia prostego jądra wielozadaniowości w tysiącach instalacji przemysłowych.

2

[Lavender 96].

170

ROZDZIAŁ 13. WZORCE PROJEKTOWE POLECENIE I AKTYWNY OBIEKT

Idea jest bardzo prosta. Rozważmy listingi 13.2 i 13.3. Obiekt ActiveObjectEngine utrzymuje listę obiektów Command. Użytkownicy mogą dodawać nowe polecenia do silnika albo mogą wywołać polecenie run(). Działanie funkcji run() sprowadza się do przeglądania listy oraz uruchamiania i usuwania poleceń. Listing 13.2. ActiveObjectEngine.java import java.util.LinkedList; import java.util.Iterator; public class ActiveObjectEngine { LinkedList itsCommands = new LinkedList();

}

public void addCommand(Command c) { itsCommands.add(c); } public void run() { while (!itsCommands.isEmpty()) { Command c = (Command) itsCommands.getFirst(); itsCommands.removeFirst(); c.execute(); } }

Listing 13.3. Command.java public interface Command { public void execute() throws Exception; }

Powyższy kod być może nie wygląda zbyt imponująco. Wyobraźmy sobie jednak, co by się stało, gdyby jeden z obiektów Command na liście sklonował samego siebie, a następnie umieściłby tego klona z powrotem na liście. Lista nigdy by się nie opróżniła, a metoda run() nigdy nie zwróciłaby sterowania. Rozważmy przypadek testowy z listingu 13.4. Kod tworzy obiekt o nazwie SleepCommand. Kod między innymi przekazuje opóźnienie 1000 ms do konstruktora obiektu SleepCommand. Następnie umieszcza obiekt SleepCommand wewnątrz obiektu ActiveObjectEngine. Po wywołaniu run() oczekuje upływu określonej liczby milisekund. Listing 13.4. TestSleepCommand.java import junit.framework.*; import junit.swingui.TestRunner; public class TestSleepCommand extends TestCase { public static void main(String[] args) { TestRunner.main(new String[]{"TestSleepCommand"}); } public TestSleepCommand(String name) { super(name); } private boolean commandExecuted = false; public void testSleep() throws Exception {

AKTYWNY OBIEKT

}

}

171

Command wakeup = new Command() { public void execute() {commandExecuted = true;} }; ActiveObjectEngine e = new ActiveObjectEngine(); SleepCommand c = new SleepCommand(1000,e,wakeup); e.addCommand(c); long start = System.currentTimeMillis(); e.run(); long stop = System.currentTimeMillis(); long sleepTime = (stop-start); assert("Oczekiwano wartości SleepTime " + sleepTime + "> 1000", sleepTime > 1000); assert("Oczekiwano wartości SleepTime " + sleepTime + "< 1100", sleepTime < 1100); assert("Polecenie wykonano", commandExecuted);

Spróbujmy przyjrzeć się temu przypadkowi testowemu nieco bliżej. Konstruktor klasy SleepCommand zawiera trzy argumenty. Pierwszy oznacza czas opóźnienia wyrażony w milisekundach. Drugi to obiekt ActiveObjectEngine, w którym polecenie będzie uruchomione. Trzeci argument to kolejny obiekt Command o nazwie wakeup. Koncepcja jest taka, aby obiekt SleepCommand odczekał określoną liczbę milisekund, a następnie wywołał polecenie wakeup. Implementację polecenia SleepCommand zamieszczono na listingu 13.5. Po uruchomieniu obiekt SleepCommand sprawdza, czy nie został uruchomiony wcześniej. Jeśli nie, to rejestruje czas uruchomienia. Jeśli czas opóźnienia jeszcze nie upłynął, obiekt umieszcza siebie z powrotem na liście obiektu ActiveObjectEngine. Jeśli czas opóźnienia upłynął, umieszcza na liście obiektu ActiveObjectEngine obiekt wakeup. Listing 13.5. SleepCommand.java public class SleepCommand implements Command { private Command wakeupCommand = null; private ActiveObjectEngine engine = null; private long sleepTime = 0; private long startTime = 0; private boolean started = false; public SleepCommand(long milliseconds, ActiveObjectEngine e, Command wakeupCommand) { sleepTime = milliseconds; engine = e; this.wakeupCommand = wakeupCommand; } public void execute() throws Exception { long currentTime = System.currentTimeMillis(); if (!started) { started = true; startTime = currentTime; engine.addCommand(this); } else if ((currentTime - startTime) < sleepTime) { engine.addCommand(this); } else {

172

}

ROZDZIAŁ 13. WZORCE PROJEKTOWE POLECENIE I AKTYWNY OBIEKT

}

}

engine.addCommand(wakeupCommand);

Możemy znaleźć analogię pomiędzy tym programem a programem wielowątkowym, który czeka na zdarzenie. Kiedy wątek w programie wielowątkowym oczekuje na zdarzenie, zazwyczaj wywołuje jakieś polecenie systemu operacyjnego, które blokuje wątek do czasu wystąpienia zdarzenia. Program z listingu 13.5 nie blokuje się. Zamiast tego, jeśli zdarzenie, na które oczekuje ((currentTime - startTime) < sleepTime) jeszcze nie wystąpiło, po prostu umieszcza siebie z powrotem na liście obiektu ActiveObjectEngine. Budowanie systemów wielowątkowych z wykorzystaniem tej techniki było i nadal będzie bardzo powszechną praktyką. Wątki tego typu są określana jako zadania RTC (ang. run-to-completion — dosł. uruchom do zakończenia), ponieważ każdy egzemplarz obiektu Command jest wykonywany w całości przed uruchomieniem następnego egzemplarza klasy Command. Nazwa RTC sugeruje, że egzemplarze klasy Command nie blokują się. Fakt, że wszystkie egzemplarze Command działają do zakończenia, daje wątkom RTC interesującą korzyść polegającą na współdzieleniu tego samego stosu wykonywania. W przeciwieństwie do wątków w tradycyjnym systemie wielowątkowym nie jest konieczne definiowanie lub określanie osobnego stosu wykonywania dla każdego wątku RTC. Może to być potężnym atutem w systemach z ograniczoną pamięcią, w których jest uruchomionych wiele wątków. Wracając do naszego przykładu: na listingu 13.6 pokazano prosty program, który korzysta z klasy SleepCommand i działa wielowątkowo. Program nosi nazwę DelayedTyper. Listing 13.6. DelayedTyper.java public class DelayedTyper implements Command { private long itsDelay; private char itsChar; private static ActiveObjectEngine engine = new ActiveObjectEngine(); private static boolean stop = false; public static void main(String args[]) { engine.addCommand(new DelayedTyper(100,'1')); engine.addCommand(new DelayedTyper(300,'3')); engine.addCommand(new DelayedTyper(500,'5')); engine.addCommand(new DelayedTyper(700,'7')); Command stopCommand = new Command() { public void execute() {stop=true;} };

}

engine.addCommand( new SleepCommand(20000,engine,stopCommand)); engine.run();

public DelayedTyper(long delay, char c) { itsDelay = delay; itsChar = c; } public void execute() throws Exception { System.out.print(itsChar); if (!stop) delayAndRepeat();

BIBLIOGRAFIA

}

173

} private void delayAndRepeat() throws Exception { engine.addCommand(new SleepCommand(itsDelay,engine,this); }

Zwróćmy uwagę, że klasa DelayedTyper implementuje interfejs Command. Metoda execute wyświetla znak, który został przekazany do konstruktora, sprawdza flagę stopu, a jeśli nie została ona ustawiona, wywołuje metodę delayAndRepeat. Metoda delayAndRepeat tworzy obiekt SleepCommand z wykorzystaniem wartości opóźnienia przekazanej w momencie tworzenia obiektu. Następnie umieszcza obiekt SleepCommand wewnątrz obiektu ActiveObjectEngine. Działanie tego obiektu Command jest łatwe do przewidzenia. Działanie sprowadza się do „zawieszenia” w pętli, która na przemian wyświetla wprowadzony znak i czeka przez określony czas opóźnienia. Pętla kończy działanie, kiedy zostanie ustawiona flaga stop. Główny program tworzy kilka egzemplarzy klasy DelayedTyper i umieszcza je na liście obiektu ActiveObjectEngine, przy czym każdy egzemplarz ma ustawiony własny znak i własne opóźnienie. Następnie wywoływany jest obiekt SleepCommand, który po pewnym czasie ustawia flagę stop. Uruchomienie tego programu powoduje wyświetlenie ciągu znaków złożonego z jedynek, trójek, piątek i siódemek. Uruchomienie go ponownie powoduje wyświetlenie podobnego, ale innego ciągu znaków. Oto wyniki dwóch uruchomień: 135711311511371113151131715131113151731111351113711531111357... 135711131513171131511311713511131151731113151131711351113117...

Ciągi są różne, ponieważ zegar procesora i zegar czasu rzeczywistego nie są idealnie zsynchronizowane. Ten rodzaj niedeterministycznych zachowań jest cechą charakterystyczną systemów wielowątkowych. Zachowania niedeterministyczne są również źródłem wielu problemów, cierpienia i bólu. Każdy, kto pracował z wbudowanymi systemami czasu rzeczywistego, wie, jak trudne do debugowania są niedeterministyczne zachowania.

Wniosek Prostota wzorca projektowego Polecenie nie zaprzecza jego wszechstronności. Wzorzec ten może być stosowany w wielu obszarach — począwszy od transakcji w bazach danych, poprzez zarządzanie urządzeniami, aż do systemów wielowątkowych oraz zarządzania poleceniami i cofania poleceń w interfejsach GUI. Niektórzy uważają, że wzorzec Polecenie łamie paradygmat obiektowy, ponieważ koncentruje się bardziej na funkcjach niż na klasach. W pewnym stopniu to może być prawdą, ale w realnym świecie dewelopera wzorzec projektowy Polecenie może być bardzo przydatny.

Bibliografia 1. Gamma, et al., Design Patterns, Reading, MA: Addison-Wesley, 19953. 2. R.G. Lavender i D.C. Schmidt, Active Object: An Object Behavioral Pattern for Concurrent Programming, w Pattern Languages of Program Design (J.O. Copliena, J. Vlissidesa i N. Kertha). Reading, MA: Addison-Wesley, 1996.

3

Wydanie polskie: Wzorce projektowe. Elementy oprogramowania obiektowego wielokrotnego użytku, Wydawnictwa Naukowo-Techniczne, 2005 — przyp. tłum.

174

ROZDZIAŁ 13. WZORCE PROJEKTOWE POLECENIE I AKTYWNY OBIEKT

R OZDZIAŁ 14

Metoda szablonowa i Strategia: dziedziczenie a delegacja

Najlepszą strategią w życiu jest pracowitość — chińskie przysłowie

Na początku lat dziewięćdziesiątych, kiedy programowanie obiektowe dopiero zyskiwało popularność, wszyscy byliśmy pod wrażeniem pojęcia dziedziczenia. Znaczenie tej nowej własności było ogromne. Dzięki dziedziczeniu możliwe stało się programowanie według różnic! Oznacza to, że można było wziąć klasę, która realizowała jakąś przydatną funkcjonalność, a następnie stworzyć podklasę i zmienić tylko te fragmenty, które nam się nie podobały. Wielokrotne wykorzystywanie kodu sprowadzało się do dziedziczenia po nim! Można było ustalić całe taksonomie struktur programowych. Każdy poziom takiej taksonomii korzystał z kodu z poziomów wyższych. To był odważny, nowy świat. Podobnie jak jest w przypadku większości odważnych nowych światów, tak i ten okazał się nieco zbyt wyidealizowany. Już w połowie lat dziewięćdziesiątych okazało się, że z zastosowaniem dziedziczenia można było bardzo łatwo przesadzić, a nadużywanie tej techniki było bardzo kosztowne. Gamma, Helm, Johnson i Vlissides posunęli się nawet do sformułowania tezy kompozycja obiektów jest ważniejsza od dziedziczenia klas1. W związku z tym zaczęto wycofywać się ze stosowania dziedziczenia. Często zastępowano je kompozycją lub delegacją. W tym rozdziale opisano dwa wzorce, które uosabiają różnicę między dziedziczeniem a delegacją. Wzorce Metoda szablonowa (ang. Template method) i Strategia (ang. Strategy) rozwiązują podobne problemy i często mogą być stosowane zamiennie. Jednak wzorzec Metoda szablonowa wykorzystuje dziedziczenie, natomiast wzorzec Strategia używa delegacji. 1

[GOF 95], str. 20.

176

ROZDZIAŁ 14. METODA SZABLONOWA I STRATEGIA: DZIEDZICZENIE A DELEGACJA

Oba wzorce rozwiązują problem oddzielenia ogólnego algorytmu od szczegółowego kontekstu. W produkcji oprogramowania problem ten występuje bardzo często. Istnieje algorytm, który ma ogólne zastosowanie. Aby zapewnić zgodność z zasadą odwracania zależności (DIP), chcemy zadbać o to, by ogólny algorytm nie zależał od szczegółowej implementacji. Zamiast tego chcemy, aby zarówno ogólny algorytm, jak i szczegółowa implementacja zależały od abstrakcji.

Metoda szablonowa Rozważmy wszystkie programy, które dotychczas napisaliśmy. Większość z nich prawdopodobnie zawiera podstawową strukturę pętli głównej. Initialize(); while (!done()) // główna pętla { Idle(); // wykonuj przydatne działania. } Cleanup();

Najpierw inicjujemy aplikację. Następnie wchodzimy w główną pętlę. W głównej pętli robimy to, co program musi zrobić. Możemy przetwarzać zdarzenia GUI lub na przykład wykonywać działania na rekordach bazy danych. Na koniec, po zakończeniu operacji, wychodzimy z głównej pętli i „sprzątamy po sobie”. Ta struktura jest tak popularna, że można ją zaimplementować w klasie o nazwie Application. Następnie można korzystać z tej klasy w każdym nowym programie, który piszemy. Pomyślcie o tym. Nigdy więcej nie będziemy zmuszeni do napisania głównej pętli ponownie 2! Dla przykładu rozważmy program z listingu 14.1. Mamy tam elementy standardowego programu. Najpierw są inicjowane obiekty InputStreamReader i BufferedReader. Następnie jest główna pętla, która odczytuje temperaturę w stopniach Fahrenheita z obiektu BufferedReader, a następnie wyświetla wartość po konwersji na stopnie Celsjusza. Na koniec generowany jest końcowy komunikat. Listing 14.1. Program do konwersji stopni Fahrenheita na Celsjusza import java.io.*; public class ftocraw { public static void main(String[] args) throws Exception { InputStreamReader isr = new InputStreamReader(System.in); BufferedReader br = new BufferedReader(isr); boolean done = false; while (!done) { String fahrString = br.readLine(); if (fahrString == null || fahrString.length() == 0) done = true; else { double fahr = Double.parseDouble(fahrString); double celcius = 5.0/9.0*(fahr-32); System.out.println("F=" + fahr + ", C=" + celcius); } } System.out.println("Program ftoc zakończył pracę."); } }

2

Wydaje mi się, że nadawałbym się na sprzedawcę.

METODA SZABLONOWA

177

W tym programie są wszystkie elementy struktury głównej pętli. Krótka inicjalizacja, wykonanie pracy w pętli głównej, a następnie posprzątanie i zakończenie pracy. Tę podstawową strukturę programu ftoc można rozdzielić, stosując wzorzec projektowy Metoda szablonowa. Wzorzec ten pozwala na umieszczenie całego generycznego kodu w zaimplementowanej metodzie abstrakcyjnej klasy bazowej. Zaimplementowana metoda obejmuje ogólny algorytm, ale wszystkie szczegóły są realizowane przez metody abstrakcyjne klasy bazowej. Zatem można by umieścić strukturę głównej pętli w abstrakcyjnej klasie bazowej o nazwie Application (patrz listing 14.2). Listing 14.2. Application.java public abstract class Application { private boolean isDone = false; protected abstract void init(); protected abstract void idle(); protected abstract void cleanup(); protected void setDone() {isDone = true;} protected boolean done() {return isDone;}

}

public void run() { init(); while (!done()) idle(); cleanup(); }

Powyższa klasa opisuje generyczną aplikację z główną pętlą. Główna pętla została zaimplementowana w funkcji run. Można także zauważyć, że wszystkie operacje zostały przeniesione do abstrakcyjnych metod init, idle i cleanup. Metoda init jest odpowiedzialna za wszystkie operacje inicjalizacji. Metoda idle realizuje główną pracę programu. Będzie wywoływana wielokrotnie do czasu wywołania metody setDone. Metoda cleanup wykonuje działania, które należy wykonać przed zakończeniem działania programu. Klasę ftoc można przepisać w taki sposób, aby dziedziczyła po klasie Application i wypełniała metody abstrakcyjne. Klasę w tej postaci zaprezentowano na listingu 14.3. Listing 14.3. ftocTemplateMethod.java import java.io.*; public class ftocTemplateMethod extends Application { private InputStreamReader isr; private BufferedReader br;

}

public static void main(String[] args) throws Exception { (new ftocTemplateMethod()).run(); protected void init() { isr = new InputStreamReader(System.in); br = new BufferedReader(isr); }

178

ROZDZIAŁ 14. METODA SZABLONOWA I STRATEGIA: DZIEDZICZENIE A DELEGACJA

protected void idle() { String fahrString = readLineAndReturnNullIfError(); if (fahrString == null || fahrString.length() == 0) setDone(); else { double fahr = Double.parseDouble(fahrString); double celcius = 5.0/9.0*(fahr-32); System.out.println("F=" + fahr + ", C=" + celcius); } } protected void cleanup() { System.out.println("Program ftoc zakończył pracę!"); } private String readLineAndReturnNullIfError() { String s; try { s = br.readLine(); } catch(IOException e) { s = null; } return s; } }

Ze względu na obsługę wyjątków kod stał się nieco dłuższy, ale wyraźnie widać sposób zastosowania wzorca Metoda szablonowa do programu ftoc.

Nadużywanie wzorca W tej chwili niektórzy czytelnicy pewnie pomyśleli: Czy on mówi poważnie? Czy naprawdę oczekuje, że będę stosował taką klasę Application do wszystkich nowych aplikacji? Nie zyskuję w ten sposób niczego, a tylko problem nadmiernie się skomplikował. Wybrałem ten przykład, ponieważ był prosty i zapewniał dobrą platformę do zaprezentowania sposobu działania wzorca Metoda szablonowa. Z drugiej strony, w rzeczywistości nie polecam budowania aplikacji ftoc w ten sposób. To jest dobry przykład nadużywania wzorca. Zastosowanie wzorca Metoda szablonowa w tej konkretnej aplikacji jest śmieszne. To jedynie komplikuje problem i niepotrzebnie rozbudowuje program. Idea hermetyzacji głównej pętli wszystkich aplikacji na świecie brzmiała cudownie na początku, ale jej praktyczne zastosowanie w tym przypadku jest bezowocne. Wzorce projektowe to doskonałe narzędzia. Mogą pomóc w rozwiązaniu wielu problemów projektowych. Ale fakt, że one istnieją, nie oznacza, że powinny być stosowane zawsze. W tym przypadku, chociaż zastosowanie wzorca Metoda szablonowa do rozwiązania opisywanego problemu było możliwe, to jego użycie nie było wskazane. Koszt zastosowania wzorca okazał się wyższy niż korzyści, jakie za jego pomocą uzyskaliśmy. Rozważmy teraz nieco bardziej przydatny przykład (patrz listing 14.4).

METODA SZABLONOWA

179

Sortowanie bąbelkowe3 Listing 14.4. BubbleSorter.java public class BubbleSorter { static int operations = 0; public static int sort(int [] array) { operations = 0; if (array.length <= 1) return operations; for (int nextToLast = array.length-2; nextToLast >= 0; nextToLast--) for (int index = 0; index <= nextToLast; index++) compareAndSwap(array, index); return operations;

} private static void swap(int[] array, int index) { int temp = array[index]; array[index] = array[index+1]; array[index+1] = temp; }

}

private static void compareAndSwap(int[] array, int index) { if (array[index] > array[index+1]) swap(array, index); operations++; }

Klasa BubbleSorter „wie”, jak sortować tablicę liczb całkowitych za pomocą algorytmu sortowania bąbelkowego. Metoda sort klasy BubbleSorter zawiera algorytm, który „wie”, jak zrealizować sortowanie bąbelkowe. Dwie metody pomocnicze: swap i compareAndSwap obsługują szczegóły operacji na liczbach całkowitych i tablicach oraz obsługują mechanizmy niezbędne do działania algorytmu sortowania. Stosując wzorzec Metoda szablonowa, możemy wydzielić algorytm sortowania bąbelkowego do abstrakcyjnej klasy bazowej o nazwie BubbleSorter. Klasa BubbleSorter zawiera implementację funkcji sort, która wywołuje abstrakcyjną metodę o nazwie outOfOrder oraz inną o nazwie swap. Metoda outOfOrder porównuje dwa sąsiednie elementy w tablicy i zwraca true, jeśli elementy nie są ustawione we właściwej kolejności. Metoda swap przestawia dwie sąsiednie komórki w tablicy. Metoda sort nic „nie wie” o tablicy ani „nie obchodzi” jej, jakie obiekty są w niej zapisane. Po prostu wywołuje metodę outOfOrder dla różnych indeksów w tablicy i określa, czy te indeksy powinny być przestawione, czy nie (patrz listing 14.5). Listing 14.5. BubbleSorter.java public abstract class BubbleSorter { private int operations = 0; protected int length = 0; protected int doSort() { operations = 0;

3

Algorytm sortowania bąbelkowego  tak jak klasa Application  jest łatwy do zrozumienia, dlatego jest użyteczną pomocą naukową. Jednak nikt przy zdrowych zmysłach nigdy faktycznie nie skorzystałby z sortowania bąbelkowego do realizacji poważnych zadań sortowania. Istnieją znacznie lepsze algorytmy.

180

ROZDZIAŁ 14. METODA SZABLONOWA I STRATEGIA: DZIEDZICZENIE A DELEGACJA

if (length <= 1) return operations; for (int nextToLast = length-2; nextToLast >= 0; nextToLast--) for (int index = 0; index <= nextToLast; index++) { if (outOfOrder(index)) swap(index); operations++; } }

}

return operations;

protected abstract void swap(int index); protected abstract boolean outOfOrder(int index);

Na podstawie klasy BubbleSorter możemy stworzyć jej proste pochodne, za pomocą których można posortować dowolne rodzaje obiektów. Na przykład można stworzyć klasę IntBubbleSorter, która sortuje tablice liczb całkowitych, oraz DoubleBubbleSorter, która sortuje tablice liczb double (patrz rysunek 14.1, listing 14.6 oraz listing 14.7).

Rysunek 14.1. Struktura klasy BubbleSorter Listing 14.6. IntBubbleSorter.java public class IntBubbleSorter extends BubbleSorter { private int[] array = null; public int sort(int [] theArray) { array = theArray; length = array.length; return doSort(); } protected void swap(int index) { int temp = array[index]; array[index] = array[index+1]; array[index+1] = temp; }

}

protected boolean outOfOrder(int index) { return (array[index] > array[index+1]); }

STRATEGIA

181

Listing 14.7. DoubleBubbleSorter.java public class DoubleBubbleSorter extends BubbleSorter { private double[] array = null; public int sort(double [] theArray) { array = theArray; length = array.length; return doSort(); } protected void swap(int index) { double temp = array[index]; array[index] = array[index+1]; array[index+1] = temp; }

}

protected boolean outOfOrder(int index) { return (array[index] > array[index+1]); }

Wzorzec Metoda szablonowa prezentuje jedną z klasycznych form wielokrotnego wykorzystywania kodu w programowaniu obiektowym. Generyczne algorytmy są umieszczane w klasie bazowej i dziedziczone w różnych kontekstach szczegółowych. Jednak stosowanie tej techniki wiąże się z kosztami. Dziedziczenie jest bardzo silną relacją. Klasy pochodne są nierozerwalnie związane ze swoimi klasami bazowymi. Na przykład metody outOfOrder i swap interfejsu IntBubbleSorter to dokładnie to, czego potrzeba dla innych rodzajów algorytmów sortowania. Pomimo tego nie ma sposobu, aby skorzystać z metod outOfOrder i swap we wspomnianych innych algorytmach sortowania. Decydując się na dziedziczenie po klasie BubbleSorter, musimy liczyć się z tym, że klasa IntBubbleSorter będzie na stale związana z klasą BubbleSorter. Innym rozwiązaniem jest zastosowanie wzorca projektowego Strategia.

Strategia Wzorzec projektowy Strategia (ang. Strategy) rozwiązuje problem odwracania zależności uniwersalnego algorytmu i szczegółowej implementacji w zupełnie inny sposób. Rozważmy ponownie przykład nadużycia wzorca projektowego przez klasę Application. Zamiast umieszczać uniwersalny algorytm w abstrakcyjnej klasie bazowej, umieścimy go w konkretnej klasie o nazwie ApplicationRunner. W interfejsie o nazwie Application zdefiniowaliśmy metody abstrakcyjne, które musi wywołać uniwersalny algorytm. Następnie stworzyliśmy klasę ftocStrategy implementującą interfejs Application i przekazaliśmy ją do obiektu ApplicationRunner. Obiekt ApplicationRunner deleguje wywołania do interfejsu ftocStrategy (patrz rysunek 14.2 oraz listingi od 14.8 do 14.10).

Rysunek 14.2. Zastosowanie wzorca Strategia do algorytmu Application

182

ROZDZIAŁ 14. METODA SZABLONOWA I STRATEGIA: DZIEDZICZENIE A DELEGACJA

Listing 14.8. ApplicationRunner.java public class ApplicationRunner { private Application itsApplication = null;

}

public ApplicationRunner(Application app) { itsApplication = app; } public void run() { itsApplication.init(); while (!itsApplication.done()) itsApplication.idle(); itsApplication.cleanup(); }

Listing 14.9. Application.java public interface Application { public void init(); public void idle(); public void cleanup(); public boolean done(); }

Listing 14.10. ftocStrategy.java import java.io.*; public class ftocStrategy implements Application { private InputStreamReader isr; private BufferedReader br; private boolean isDone = false; public static void main(String[] args) throws Exception { (new ApplicationRunner(new ftocStrategy())).run(); } public void init() { isr = new InputStreamReader(System.in); br = new BufferedReader(isr); } public void idle() { String fahrString = readLineAndReturnNullIfError(); if (fahrString == null || fahrString.length() == 0) isDone = true; else { double fahr = Double.parseDouble(fahrString); double celcius = 5.0/9.0*(fahr-32); System.out.println("F=" + fahr + ", C=" + celcius); } } public void cleanup() { System.out.println("Program ftoc zakończył pracę!"); }

STRATEGIA

183

public boolean done() { return isDone; }

}

private String readLineAndReturnNullIfError() { String s; try { s = br.readLine(); } catch(IOException e) { s = null; } return s; }

Powyższa struktura w zestawieniu z wzorcem Metoda szablonowa ma zarówno zalety, jak i wady. Wzorzec Strategia wymaga więcej klas oraz pośrednich konstrukcji niż wzorzec Metoda szablonowa. Wskaźnik na delegację w obiekcie ApplicationRunner jest nieco bardziej kosztowny pod względem czasu działania i miejsca na dane w porównaniu z dziedziczeniem. Z drugiej strony, jeśli mieliśmy uruchomić wiele różnych aplikacji, moglibyśmy wielokrotnie wykorzystać egzemplarz obiektu ApplicationRunner, a tym samym zminimalizować sprzężenia pomiędzy uniwersalnym algorytmem a zarządzanymi przez niego szczegółami. Żadne z tych kosztów i korzyści nie mają znaczenia decydującego. W większości przypadków te korzyści lub wady są pomijalnie małe. W typowym przypadku najbardziej niepokojącą wadą jest potrzeba dodatkowej klasy w przypadku wzorca projektowego Strategia. Jest jednak więcej cech, które należy wziąć pod uwagę.

Sortowanie jeszcze raz Rozważmy implementację algorytmu sortowania bąbelkowego z wykorzystaniem wzorca projektowego Strategia (patrz listingi od 14.11 do 14.13). Listing 14.11. BubbleSorter.java public class BubbleSorter { private int operations = 0; private int length = 0; private SortHandle itsSortHandle = null; public BubbleSorter(SortHandle handle) { itsSortHandle = handle; } public int sort(Object array) { itsSortHandle.setArray(array); length = itsSortHandle.length(); operations = 0; if (length <= 1) return operations; for (int nextToLast = length-2; nextToLast >= 0; nextToLast--) for (int index = 0; index <= nextToLast; index++) {

184

ROZDZIAŁ 14. METODA SZABLONOWA I STRATEGIA: DZIEDZICZENIE A DELEGACJA

}

}

}

if (itsSortHandle.outOfOrder(index)) itsSortHandle.swap(index); operations++;

return operations;

Listing 14.12. SortHandle.java public interface SortHandle { public void swap(int index); public boolean outOfOrder(int index); public int length(); public void setArray(Object array); }

Listing 14.13. IntSortHandle.java public class IntSortHandle implements SortHandle { private int[] array = null; public void swap(int index) { int temp = array[index]; array[index] = array[index+1]; array[index+1] = temp; } public void setArray(Object array) { this.array = (int[])array; } public int length() { return array.length; }

}

public boolean outOfOrder(int index) { return (array[index] > array[index+1]); }

Zwróćmy uwagę, że klasa IntSortHandle nic „nie wie” o klasie BubbleSorter. W żaden sposób nie zależy od implementacji algorytmu sortowania bąbelkowego. Inaczej sprawa wygląda w przypadku wzorca projektowego Metoda szablonowa. Jeśli jeszcze raz spojrzymy na listing 14.6, zauważymy, że klasa IntBubbleSorter zależała bezpośrednio od klasy BubbleSorter — tej, która zawiera algorytm sortowania bąbelkowego. Sposób z wykorzystaniem wzorca Metoda szablonowa częściowo narusza zasadę odwracania zależności, ponieważ metody swap i outOfOrder zależą bezpośrednio od algorytmu sortowania bąbelkowego. Sposób bazujący na wzorcu Strategia nie jest obarczony taką zależnością. A zatem możemy skorzystać z interfejsu IntSortHandle z implementacją klasy Sorter inną niż BubbleSorter. Na przykład możemy stworzyć odmianę algorytmu sortowania bąbelkowego, która kończy działanie w przypadku, gdy okaże się, że kolejność elementów w przetwarzanej tablicy jest prawidłowa (patrz listing 14.14). Z interfejsu IntSortHandle może również skorzystać klasa QuickBubbleSorter oraz dowolna inna klasa pochodna klasy SortHandle.

BIBLIOGRAFIA

185

Listing 14.14. QuickBubbleSorter.java public class QuickBubbleSorter { private int operations = 0; private int length = 0; private SortHandle itsSortHandle = null; public QuickBubbleSorter(SortHandle handle) { itsSortHandle = handle; } public int sort(Object array) { itsSortHandle.setArray(array); length = itsSortHandle.length(); operations = 0; if (length <= 1) return operations; boolean thisPassInOrder = false; for (int nextToLast = length-2; nextToLast >= 0 && !thisPassInOrder; nextToLast--) { thisPassInOrder = true; //potencjalnie. for (int index = 0; index <= nextToLast; index++) { if (itsSortHandle.outOfOrder(index)) { itsSortHandle.swap(index); thisPassInOrder = false; } operations++; } }

}

}

return operations;

Tak więc wzorzec projektowy Strategia daje jedną dodatkową korzyść w porównaniu z wzorcem Metoda szablonowa. O ile wzorzec Metoda szablonowa pozwala na to, aby generyczny algorytm manipulował wieloma szczegółowymi implementacjami, o tyle wzorzec Strategia dzięki całkowitej zgodności z zasadą odwracania zależności pozwala na to, aby każda ze szczegółowych implementacji była zarządzana przez wiele różnych uniwersalnych algorytmów.

Wniosek Zarówno wzorzec projektowy Metoda szablonowa, jak i wzorzec Strategia umożliwiają rozdzielenie wysokopoziomowych algorytmów od niskopoziomowych detali. Oba pozwalają na używanie wysokopoziomowych algorytmów niezależnie od szczegółów. Kosztem nieco większej złożoności, ilości pamięci i czasu wykonania wzorzec projektowy Strategia pozwala także na wielokrotne wykorzystywanie szczegółowych implementacji od wysokopoziomowego algorytmu.

Bibliografia 1. Gamma, et al., Design Patterns, Reading, MA: Addison-Wesley, 19954. 2. Robert C. Martin, et al., Pattern Languages of Program Design 3, Reading, MA: Addison-Wesley, 1998. 4

Wydanie polskie: Wzorce projektowe. Elementy oprogramowania obiektowego wielokrotnego użytku, Wydawnictwa Naukowo-Techniczne, 2005 — przyp. tłum

186

ROZDZIAŁ 14. METODA SZABLONOWA I STRATEGIA: DZIEDZICZENIE A DELEGACJA

R OZDZIAŁ 15

Wzorce projektowe Fasada i Mediator

Symbole wznoszą fasadę szacunku, aby ukryć nieprzyzwoitość marzeń — Mason Cooley

Dwa wzorce omówione w tym rozdziale spełniają wspólny cel. Oba nakładają jakąś strategię na inną grupę obiektów. Wzorzec Fasada (ang. Facade) nakłada strategię od góry, natomiast wzorzec Mediator (ang. Mediator) nakłada strategię od dołu. Wykorzystanie wzorca Fasada jest widoczne i ogranicza zakres funkcji, natomiast użycie wzorca Mediator jest niewidoczne i nie ogranicza zbioru oferowanych działań.

Fasada Wzorzec projektowy Fasada jest wykorzystywany w przypadku, gdy chcemy zapewnić prosty i konkretny interfejs dla grupy obiektów, które mają złożony i ogólny interfejs. Dla przykładu rozważmy klasę DB.java z listingu 26.9. Klasa ta nakłada bardzo prosty interfejs, specyficzny dla klasy ProductData, na złożone i ogólne interfejsy klas w obrębie pakietu java.sql. Strukturę pokazano na rysunku 15.1. Zwróćmy uwagę, że klasa DB chroni klasę Application przed koniecznością znajomości wewnętrznych szczegółów pakietu java.sql. Ukrywa całą ogólność i złożoność pakietu java.sql za bardzo prostym i konkretnym interfejsem. Fasada podobna do klasy DB narzuca strategię wykorzystania pakietu java.sql. Klasa ta „wie”, w jaki sposób zainicjować i zamknąć połączenie z bazą danych. „Wie” również, w jaki sposób przetłumaczyć składowe klasy ProductData na pola bazy danych i z powrotem. „Wie”, jak zbudować odpowiednie zapytania i polecenia do operowania na bazie danych. Do tego ukrywa tę całą złożoność przed użytkownikami. Z punktu widzenia klasy Application pakiet java.sql nie istnieje. Jest ukryty za Fasadą.

188

ROZDZIAŁ 15. WZORCE PROJEKTOWE FASADA I MEDIATOR

Rysunek 15.1. Klasa fasady — DB

Zastosowanie wzorca projektowego Fasada oznacza, że programiści przyjęli zasadę, według której wszystkie wywołania do bazy danych przechodzą przez klasę DB. Wywołania kierowane do pakietu java.sql bez pośrednictwa Fasady w dowolnej części kodu aplikacji są naruszeniem konwencji. A zatem Fasada narzuca aplikacji swoją politykę. Według konwencji klasa DB stała się jedynym sprzedawcą usług pakietu java.sql.

Mediator Wzorzec projektowy Mediator także narzuca swoją politykę. Jednak o ile wzorzec Fasada nakłada swoją politykę w sposób widoczny i ograniczający funkcje, o tyle wzorzec Mediator robi to w sposób ukryty, bez ograniczania zbioru funkcji. Na przykład QuickEntryMediator z listingu 15.1 to klasa, która jest ukryta „za kulisami” i wiąże pole tekstowe z listą. Kiedy użytkownik wpisuje tekst w polu tekstowym, to pierwszy element, który odpowiada wpisanej wartości, jest podświetlany. Dzięki temu wystarczy wpisać skrót, aby wybrać z listy właściwą pozycję. Listing 15.1. QuickEntryMediator.java package utility; import javax.swing.*; import javax.swing.event.*;

/** QuickEntryMediator. Klasa otrzymuje na wejściu obiekty JTextField i JList. Zakłada, że użytkownik wpisuje do pola JTextField znaki, które są prefiksami elementów listy JList. Klasa automatycznie zaznacza na liście JList pierwszy element pasujący do bieżącego prefiksu w polu JTextField. Jeśli obiekt JTextField ma wartość null albo prefiks nie pasuje do żadnego elementu na liście JList, to zaznaczenie na liście JList jest zerowane. Ten obiekt nie pozwala na wywoływanie metod. Wystarczy stworzyć obiekt i można o nim zapomnieć. (Ale nie wolno dopuścić, by został zniszczony przez mechanizm „odśmiecania” ...)

MEDIATOR

189

Przykład: JTextField t = new JTextField(); JList l = new JList(); QuickEntryMediator qem = new QuickEntryMediator(t, l); // to by było na tyle. @author Robert C. Martin, Robert S. Koss @data 30 czerwca 1999 2113 (SLAC) */ public class QuickEntryMediator { public QuickEntryMediator(JTextField t, JList l) { itsTextField = t; itsList = l; itsTextField.getDocument().addDocumentListener( new DocumentListener() { public void changedUpdate(DocumentEvent e) { textFieldChanged(); } public void insertUpdate(DocumentEvent e) { textFieldChanged(); } public void removeUpdate(DocumentEvent e) { textFieldChanged(); }

} // new DocumentListener ); // addDocumentListener

} // QuickEntryMediator()

private void textFieldChanged() { String prefix = itsTextField.getText(); if (prefix.length() == 0) { itsList.clearSelection(); return; }

}

ListModel m = itsList.getModel(); boolean found = false; for (int i = 0; found == false && i < m.getSize(); i++) { Object o = m.getElementAt(i); String s = o.toString(); if (s.startsWith(prefix)) { itsList.setSelectedValue(o, true); found = true; }

if (!found) { itsList.clearSelection(); }

} // textFieldChanged private JTextField itsTextField; private JList itsList;

} // class QuickEntryMediator

Strukturę klasy QuickEntryMediator pokazano na rysunku 15.2. Stworzono egzemplarz klasy QuickEntryMediator z obiektami JList i JTextField. Obiekt QuickEntryMediator rejestruje dla obiektu JTextField anonimowy obiekt nasłuchujący DocumentListener. Ten obiekt wywołuje metodę textFieldChanged za każdym razem, gdy w tekście zostanie wprowadzona modyfikacja. Następnie metoda znajduje na liście JList element, którego prefiks jest zgodny z wpisanym tekstem, i go zaznacza.

190

ROZDZIAŁ 15. WZORCE PROJEKTOWE FASADA I MEDIATOR

Rysunek 15.2. Klasa QuickEntryMediator

Użytkownicy klas JList i JTextField nie mają pojęcia o istnieniu obiektu klasy Mediatora. Obiekt działa w ukryciu, nakładając swoją politykę na te obiekty bez ich zezwolenia i wiedzy.

Wniosek Nakładanie polityki, jeśli jest ona rozbudowana i ma być widoczna, można zrealizować od góry za pomocą wzorca Fasada. Z drugiej strony, jeśli wymagana jest dyskrecja i większa subtelność, to wybór wzorca projektowego Mediator może być bardziej odpowiedni. Fasady są zazwyczaj stosowane zgodnie z ustaloną konwencją. Wszyscy zgadzają się na używanie Fasady zamiast obiektów znajdujących się za nią. Z drugiej strony, wzorzec Mediator jest ukryty przed użytkownikami. Jego polityka jest raczej faktem dokonanym niż kwestią konwencji.

Bibliografia 1. Gamma, et al., Design Patterns, Reading, MA: Addison-Wesley, 19951.

1

Wydanie polskie: Wzorce projektowe. Elementy oprogramowania obiektowego wielokrotnego użytku. Wydawnictwa Naukowo-Techniczne, 2005 — przyp. tłum.

R OZDZIAŁ 16

Wzorce projektowe Singleton i Monostate

Nieskończone błogosławieństwo istnienia! Jest i nie ma nic oprócz Niego — Edwin A. Abbott, Flatland

Pomiędzy klasami a ich egzemplarzami zazwyczaj zachodzi relacja jeden do wielu. Większość klas pozwala na tworzenie wielu egzemplarzy. Egzemplarze są tworzone, kiedy są potrzebne, i niszczone, kiedy przestajemy ich potrzebować. Pojawiają się i znikają w strumieniu operacji rezerwowania i zwalniania pamięci. Istnieją jednak klasy, które powinny mieć tylko jeden egzemplarz. Ten egzemplarz powinien być powoływany do istnienia w momencie uruchomienia programu i powinien zostać zniszczony wraz z końcem działania aplikacji. Takie obiekty czasami stanowią rdzeń aplikacji. Za pośrednictwem tego rdzenia można uzyskać dostęp do wielu innych obiektów w systemie. Czasami są to fabryki używane do tworzenia innych obiektów w systemie. Czasami są to menedżery odpowiedzialne za zarządzanie innymi obiektami i ich funkcjonowanie. Niezależnie od tego, czym są takie obiekty, stworzenie ich w większej liczbie egzemplarzy niż jeden jest poważnym błędem logicznym. Jeśli utworzymy więcej niż jeden rdzeń aplikacji, to dostęp do obiektów w aplikacji może zależeć od wybranego rdzenia. Nie wiedząc o tym, że istnieje więcej niż jeden rdzeń, programiści mogą nieświadomie uzyskać dostęp tylko do podzbioru obiektów aplikacji. Jeśli istnieje więcej niż jedna fabryka, kontrola tworzonych obiektów może być utrudniona. Jeśli istnieje więcej niż jeden menedżer, to działania, które powinny następować po sobie kolejno, mogą być wykonywane równolegle. Może się wydawać, że tworzenie mechanizmów, które wymuszają istnienie takich obiektów w liczbie pojedynczej, jest nadużyciem. W końcu już po zainicjowaniu aplikacji można samodzielnie zadbać, aby utworzyć tylko jeden taki obiekt. W rzeczywistości takie rozwiązanie często jest najlepsze. Należy

192

ROZDZIAŁ 16. WZORCE PROJEKTOWE SINGLETON I MONOSTATE

unikać stosowania dodatkowych mechanizmów, jeśli nie są one potrzebne w danej chwili. Powinniśmy jednak dbać o to, aby kod komunikował nasze intencje. Jeśli mechanizm egzekwowania liczby pojedynczej jest prosty, korzyści komunikacyjne mogą przewyższyć koszty stworzenia tego mechanizmu. W tym rozdziale opisano dwa wzorce projektowe wymuszające występowanie obiektów w liczbie pojedynczej. Wzorce te różnią się pomiędzy sobą relacją kosztów do korzyści. W wielu sytuacjach ich koszt jest na tyle niski, że równoważy korzyści wynikające z większej ekspresji kodu.

Singleton1 Singleton to bardzo prosty wzorzec projektowy. Przypadek testowy z listingu 16.1 pokazuje, jak powinien on działać. Pierwsza funkcja testowa pokazuje, że do egzemplarza obiektu Singleton istnieje dostęp za pośrednictwem publicznej, statycznej metody Instance. Pokazuje również, że metoda Instance jest wywoływana wiele razy i za każdym razem zwraca referencję do dokładnie tego samego egzemplarza. Druga funkcja testowa pokazuje, że klasa Singleton nie ma publicznego konstruktora, zatem nikt nie może utworzyć egzemplarza obiektu Singleton bez użycia metody Instance. Listing 16.1. Przypadek testowy wzorca projektowego Singleton import junit.framework.*; import java.lang.reflect.Constructor; public class TestSimpleSingleton extends TestCase { public TestSimpleSingleton(String name) { super(name); } public void testCreateSingleton() { Singleton s = Singleton.Instance(); Singleton s2 = Singleton.Instance(); assertSame(s, s2); }

}

public void testNoPublicConstructors() throws Exception { Class singleton = Class.forName("Singleton"); Constructor[] constructors = singleton.getConstructors(); assertEquals("public constructors.", 0, constructors.length); }

Ten przypadek testowy jest specyfikacją dla wzorca projektowego Singleton. Zaprezentowany test prowadzi bezpośrednio do implementacji pokazanej na listingu 16.2. Z analizy tego kodu powinno być jasne, że nigdy nie może istnieć więcej niż jeden egzemplarz klasy Singleton wewnątrz zasięgu statycznej zmiennej Singleton.theInstance. Listing 16.2. Implementacja wzorca projektowego Singleton public class Singleton { private static Singleton theInstance = null; private Singleton() {} public static Singleton Instance()

1

[GOF 95], str. 127.

SINGLETON

{

}

}

193

if (theInstance == null) theInstance = new Singleton(); return theInstance;

Korzyści ze stosowania wzorca Singleton  Przenośność pomiędzy wieloma platformami. Dzięki zastosowaniu odpowiedniego oprogramo-

wania middleware (np. RMI) wzorzec projektowy Singleton może być rozszerzony do pracy na wielu maszynach wirtualnych Javy (JVM) i wielu komputerach.  Możliwość stosowania do dowolnej klasy. We wzorcu Singleton można przekształcić każdą klasę. Wystarczy zadeklarować konstruktory jako prywatne oraz dodać właściwe funkcje statyczne i zmienną.  Możliwość tworzenia przez dziedziczenie. Na podstawie określonej klasy można stworzyć podklasę, która będzie singletonem.  Leniwe konstruowanie. Jeśli Singleton nie zostanie użyty, nigdy nie będzie stworzony.

Koszty stosowania wzorca Singleton  Niezdefiniowana destrukcja. Nie istnieje dobry sposób niszczenia lub „zwalniania” Singletonu.

Jeśli dodamy metodę decommision, która przypisuje wartość null do egzemplarza theInstance, to inne moduły w systemie nadal mogą zachować referencje do egzemplarza Singletonu. Kolejne wywołania metody Instance spowodują stworzenie innego egzemplarza. W efekcie równolegle będą istniały dwa egzemplarze. Problem ten jest szczególnie dotkliwy w C++, gdzie egzemplarz może być zniszczony. To prowadzi do ewentualnego odwoływania się do zniszczonego obiektu.  Brak możliwości dziedziczenia. Klasa odziedziczona z Singletonu nie jest singletonem. Jeśli powinna być Singletonem, należy dodać do niej statyczną funkcję i zmienną.  Wydajność. Każde wywołanie metody Instance wiąże się z wywołaniem instrukcji if. W przypadku większości tych wywołań instrukcja if jest bezużyteczna.  Nieprzezroczystość. Użytkownicy Singletonu wiedzą, że używają go, ponieważ muszą wywoływać metodę Instance.

Wzorzec projektowy Singleton w praktyce Załóżmy, że mamy system webowy, który pozwala użytkownikom na logowanie się w zabezpieczonych obszarach serwera WWW. Taki system zawiera bazę danych z nazwami użytkowników, hasłami i innymi atrybutami użytkownika. Załóżmy dodatkowo, że dostęp do bazy danych jest realizowany za pomocą zewnętrznego API. Moglibyśmy uzyskać dostęp do bazy danych bezpośrednio w każdym module, który potrzebuje zapisywania i odczytu danych użytkownika. To jednak spowodowałoby rozproszenie wywołań zewnętrznego API po całym kodzie i nie pozwoliłoby na egzekwowanie konwencji dotyczących dostępu lub struktury. Lepszym rozwiązaniem jest zastosowanie wzorca projektowego Fasada i utworzenie klasy UserDatabase dostarczającej metod czytania i zapisywania obiektów User. Te metody uzyskują dostęp do zewnętrznego API bazy danych i tłumaczą obiekty User na tabele i wiersze bazy danych. W obrębie klasy UserDatabase możemy egzekwować konwencje dotyczące struktury i dostępu. Na przykład możemy zagwarantować, że żaden obiekt User nie zostanie zapisany, jeśli jego pole username będzie puste. Możemy także zapewnić sekwencyjny dostęp do rekordu User. W ten sposób można uzyskać pewność, że dwa moduły nie będą mogły jednocześnie czytać i zapisywać rekordu. Rozwiązanie z wykorzystaniem wzorca Singleton pokazano w kodzie na listingach 16.3 i 16.4. Klasa Singletonu nosi nazwę UserDatabaseSource. Klasa implementuje interfejs UserDatabase. Zwróćmy uwagę, że statyczna metoda instance() nie zawiera tradycyjnej instrukcji if, która zabezpieczałaby przed tworzeniem wielu egzemplarzy. Zamiast tego wykorzystano mechanizm inicjalizacji Javy.

194

ROZDZIAŁ 16. WZORCE PROJEKTOWE SINGLETON I MONOSTATE

Listing 16.3. Interfejs UserDatabase public interface UserDatabase { User readUser(String userName); void writeUser(User user); }

Listing 16.4. Singleton — klasa UserDatabaseSource public class UserDatabaseSource implements UserDatabase { private static UserDatabase theInstance = new UserDatabaseSource(); public static UserDatabase instance() { return theInstance; } private UserDatabaseSource() { } public User readUser(String userName) {

// Jakaś implementacja.

}

return null; // aby kod się skompilował.

public void writeUser(User user) { }

}

// Jakaś implementacja.

Pokazany przykład prezentuje bardzo popularne zastosowanie wzorca projektowego Singleton. Daje ono pewność, że dostęp do bazy danych będzie realizowany za pomocą pojedynczego egzemplarza klasy UserDatabaseSource. Dzięki temu można łatwo wprowadzić testy, liczniki i blokady w klasie UserData baseSource, które będą egzekwowały wspomniane wcześniej konwencje dotyczące dostępu i struktury.

Monostate2 Wzorzec projektowy Monostate to kolejny sposób na zapewnienie występowania obiektu w liczbie pojedynczej. Wzorzec ten działa z wykorzystaniem całkowicie innego mechanizmu. Ze sposobem działania tego mechanizmu można się zapoznać, studiując przypadek testowy wzorca Monostate zamieszczony na listingu 16.5. Listing 16.5. Przypadek testowy wzorca projektowego Monostate import junit.framework.*; public class TestMonostate extends TestCase { public TestMonostate(String name) { super(name); } public void testInstance() 2

[BALL 2000].

MONOSTATE

{

}

195

Monostate m = new Monostate(); for (int x = 0; x<10; x++) { m.setX(x); assertEquals(x, m.getX()); }

public void testInstancesBehaveAsOne() { Monostate m1 = new Monostate(); Monostate m2 = new Monostate();

}

}

for (int x = 0; x<10; x++) { m1.setX(x); assertEquals(x, m2.getX()); }

Pierwsza funkcja testowa opisuje obiekt, którego zmienną x można ustawić i odczytać. Natomiast drugi przypadek testowy pokazuje, że dwa egzemplarze tej samej klasy zachowują się tak, jakby to była jedna klasa. Jeśli ustawimy zmienną x w jednym egzemplarzu na określoną wartość, możemy odczytać tę wartość poprzez pobranie zmiennej x innego egzemplarza. Działa to tak, jakby dwa egzemplarze były w rzeczywistości różnymi nazwami tego samego obiektu. Gdybyśmy podłączyli klasę Singleton do tego przypadku testowego i zastąpili wszystkie instrukcje new Monostate wywołaniami metody Singleton.Instance, to ten test nadal powinien przechodzić. Zatem pokazany test opisuje zachowanie klasy Singleton bez narzucania ograniczenia pojedynczego egzemplarza! Jak to jest możliwe, aby dwa egzemplarze zachowywały się tak, jakby był to pojedynczy obiekt? To proste — oznacza to, że te dwa obiekty współdzielą te same zmienne. Można to łatwo osiągnąć poprzez zadeklarowanie wszystkich zmiennych jako statycznych. Na listingu 16.6 pokazano implementację wzorca projektowego Monostate, która przechodzi zamieszczony powyżej przypadek testowy. Zwróćmy uwagę, że zmienna itsX tego obiektu jest statyczna. Zwróćmy także uwagę na to, że żadna z metod nie jest statyczna. To bardzo ważne, o czym przekonasz się później. Listing 16.6. Implementacja wzorca Monostate public class Monostate { private static int itsX = 0; public Monostate() {} public void setX(int x) { itsX = x; }

}

public int getX() { return itsX; }

Uważam ten wzorzec za „uroczo zakręcony”. Niezależnie od tego, ile stworzymy egzemplarzy klasy Monostate, wszystkie one zachowują się tak, jakby był to jeden obiekt. Można nawet zniszczyć wszystkie aktualne egzemplarze klasy Monostate bez obawy o utratę danych.

Zwróćmy uwagę na fakt, że różnica pomiędzy dwoma pokazanymi wzorcami polega na tym, że jeden dotyczy zachowania, natomiast drugi — struktury. Wzorzec projektowy Singleton wymusza stosowanie struktury, która zapewnia występowanie obiektu w liczbie pojedynczej. Wzorzec nie dopuszcza

196

ROZDZIAŁ 16. WZORCE PROJEKTOWE SINGLETON I MONOSTATE

możliwości tworzenia więcej niż jednego egzemplarza obiektu. Z kolei wzorzec projektowy Monostate egzekwuje zachowanie bez nakładania strukturalnych ograniczeń. O wymienionych różnicach świadczy to, że klasa testowa Singleton przechodzi przypadek testowy dla wzorca projektowego Monostate, ale klasa Monostate nie przechodzi przypadku testowego dla wzorca Singleton.

Korzyści ze stosowania wzorca Monostate  Przezroczystość. Klasy klienckie wzorca Monostate nie zachowują się inaczej niż klasy klienckie

standardowych obiektów. Nie muszą wiedzieć, że obiekt implementuje wzorzec Monostate.  Możliwość dziedziczenia. Klasy pochodne klas implementujących wzorzec Monostate same także

implementują ten wzorzec. W istocie wszystkie pochodne klasy implementującej wzorzec Monostate są częścią tej samej konstrukcji. Wszystkie one korzystają z tych samych zmiennych statycznych.  Polimorfizm. Ponieważ metody klas implementujących wzorzec Monostate nie są statyczne, mogą być przesłonięte w klasach pochodnych. W związku z tym różne pochodne mogą oferować różne zachowanie, wykorzystując ten sam zbiór zmiennych statycznych.  Dobrze zdefiniowane operacje tworzenia i destrukcji. Zmienne klas implementujących wzorzec Monostate są statyczne, zatem czas tworzenia i destrukcji jest dla nich ściśle określony.

Koszty stosowania wzorca Monostate  Brak możliwości konwersji. Nie można przekształcić zwykłej klasy na klasę zgodną ze wzorcem

projektowym Monostate poprzez dziedziczenie.  Wydajność. Obiekt klasy zgodnej ze wzorcem Monostate może być wielokrotnie tworzony i nisz-

czony, ponieważ jest to zwykły obiekt. Tego rodzaju operacje zwykle są kosztowne.  Zajmowana przestrzeń. Zmienne klas implementujących wzorzec Monostate zajmują miejsce nawet

wtedy, gdy obiekty tej klasy nigdy nie są wykorzystywane.  Brak przenośności. Jeden obiekt klasy implementującej wzorzec Monostate nie może działać na

wielu egzemplarzach maszyny JVM lub na przestrzeni wielu platform.

Wzorzec projektowy Monostate w praktyce Rozważmy implementację prostej, skończonej maszyny stanów dla kołowrotu przy wejściu do metra. Projekt tej aplikacji zaprezentowano na rysunku 16.1. Początkowo kołowrót jest w stanie Locked. Po wrzuceniu monety następuje przejście do stanu Unlocked, odblokowanie bramki, wyzerowanie wszystkich ewentualnych stanów alarmowych i przekazanie monety do pojemnika. Jeśli w tym momencie użytkownik przejdzie przez bramkę, kołowrót przechodzi z powrotem do stanu Locked i blokuje bramkę.

Rysunek 16.1. Skończona maszyna stanów kołowrotu przy wejściu do metra

Istnieją dwie nadzwyczajne sytuacje. Jeżeli użytkownik wrzuci dwie lub więcej monet przed przejściem przez bramkę, monety zostaną zwrócone, a bramka pozostanie odblokowana. Jeżeli użytkownik przejdzie przez bramkę bez zapłaty, spowoduje to zainicjowanie alarmu dźwiękowego, a bramka pozostanie zablokowana.

MONOSTATE

197

Program testowy, który opisuje takie działanie, pokazano na listingu 16.7. Zwróćmy uwagę, że w metodach testowych założono, że klasa Turnstile implementuje wzorzec Monostate. Klasa oczekuje możliwości generowania zdarzeń i odpowiadania na zapytania od różnych egzemplarzy. To ma sens w przypadku, gdy nigdy nie będzie istniał więcej niż jeden egzemplarz klasy Turnstile. Listing 16.7. TestTurnstile import junit.framework.*; public class TestTurnstile extends TestCase { public TestTurnstile(String name) { super(name); } public void setUp() { Turnstile t = new Turnstile(); t.reset(); } public void testInit() { Turnstile t = new Turnstile(); assert(t.locked()); assert(!t.alarm()); } public void testCoin() { Turnstile t = new Turnstile(); t.coin(); Turnstile t1 = new Turnstile(); assert(!t1.locked()); assert(!t1.alarm()); assertEquals(1, t1.coins()); } public void testCoinAndPass() { Turnstile t = new Turnstile(); t.coin(); t.pass(); Turnstile t1 = new Turnstile(); assert(t1.locked()); assert(!t1.alarm()); assertEquals("coins", 1, t1.coins());

} public void testTwoCoins() { Turnstile t = new Turnstile(); t.coin(); t.coin();

}

Turnstile t1 = new Turnstile(); assert("unlocked", !t1.locked()); assertEquals("coins",1, t1.coins()); assertEquals("refunds", 1, t1.refunds()); assert(!t1.alarm());

public void testPass() { Turnstile t = new Turnstile(); t.pass();

198

ROZDZIAŁ 16. WZORCE PROJEKTOWE SINGLETON I MONOSTATE

}

Turnstile t1 = new Turnstile(); assert("alarm", t1.alarm()); assert("locked", t1.locked());

public void testCancelAlarm() { Turnstile t = new Turnstile(); t.pass(); t.coin(); Turnstile t1 = new Turnstile(); assert("alarm", !t1.alarm()); assert("locked", !t1.locked()); assertEquals("coin", 1, t1.coins()); assertEquals("refund", 0, t1.refunds()); }

}

public void testTwoOperations() { Turnstile t = new Turnstile(); t.coin(); t.pass(); t.coin(); assert("unlocked", !t.locked()); assertEquals("coins", 2, t.coins()); t.pass(); assert("locked", t.locked()); }

Implementację klasy Turnstile implementującej wzorzec Monostate pokazano na listingu 16.8. Klasa bazowa Turnstile deleguje dwie funkcje zdarzeń (coin i pass) do dwóch pochodnych klasy Turnstile (Locked i Unlocked) reprezentujących stany skończonej maszyny stanów. Listing 16.8. Turnstile public class Turnstile { private static boolean isLocked = true; private static boolean isAlarming = false; private static int itsCoins = 0; private static int itsRefunds = 0; protected final static Turnstile LOCKED = new Locked(); protected final static Turnstile UNLOCKED = new Unlocked(); protected static Turnstile itsState = LOCKED; public void reset() { lock(true); alarm(false); itsCoins = 0; itsRefunds = 0; itsState = LOCKED; } public boolean locked() { return isLocked; } public boolean alarm() { return isAlarming; } {

public void coin()

MONOSTATE

}

itsState.coin();

public void pass() { itsState.pass(); } protected void lock(boolean shouldLock) { isLocked = shouldLock; } protected void alarm(boolean shouldAlarm) { isAlarming = shouldAlarm; } { }

public int coins() return itsCoins;

public int refunds() { return itsRefunds; } public void deposit() { itsCoins++; }

}

public void refund() { itsRefunds++; }

class Locked extends Turnstile { public void coin() { itsState = UNLOCKED; lock(false); alarm(false); deposit(); } public void pass() { alarm(true); }

} class Unlocked extends Turnstile { public void coin() { refund(); }

}

public void pass() { lock(true); itsState = LOCKED; }

199

200

ROZDZIAŁ 16. WZORCE PROJEKTOWE SINGLETON I MONOSTATE

Ten przykład pokazuje kilka przydatnych własności wzorca projektowego Monostate. Wykorzystuje możliwości stosowania polimorfizmu w klasach pochodnych klasy implementującej wzorzec Monostate oraz fakt, że pochodne klasy zgodnej ze wzorcem Monostate same również są zgodne z tym wzorcem. Ten przykład pokazuje również, jak trudne może być czasami przekształcenie klasy zgodnej ze wzorcem Monostate w zwykłą klasę. Struktura tego rozwiązania w dużym stopniu zależy od charakteru Monostate klasy Turnstile. Gdyby trzeba było zarządzać więcej niż jednym kołowrotem za pomocą tej skończonej maszyny stanów, w kodzie trzeba by było przeprowadzić znaczącą refaktoryzację. Być może zastanawiasz się nad niekonwencjonalnym wykorzystaniem dziedziczenia w tym przykładzie. To, że klasy Unlocked i Locked są pochodnymi klasy Turnstile, wydaje się być naruszeniem standardowych zasad projektowania obiektowego. Ponieważ jednak klasa Turnstile jest zgodna ze wzorcem Monostate, nie istnieją jej odrębne egzemplarze. Tak więc Unlocked i Locked nie są w rzeczywistości osobnymi obiektami. Zamiast tego są one częścią abstrakcji Turnstile. Obiekty Unlocked i Locked mają dostęp do tych samych zmiennych i metod, do których ma dostęp obiekt Turnstile.

Wniosek Często konieczne jest wyegzekwowanie ograniczenia, zgodnie z którym określony obiekt ma tylko jeden egzemplarz. W niniejszym rozdziale zaprezentowano dwie różne techniki pozwalające na spełnienie tego warunku. Wzorzec projektowy Singleton wykorzystuje prywatne konstruktory, zmienne statyczne i funkcję statyczną do kontroli i ograniczania tworzenia egzemplarzy. Wzorzec Monostate sprawia, że wszystkie zmienne obiektu są statyczne. Wzorzec Singleton najlepiej stosuje się w przypadku, gdy mamy klasę, którą chcemy ograniczyć poprzez dziedziczenie, a nie mamy nic przeciwko temu, że każdy, aby uzyskać dostęp, będzie zmuszony do wywołania metody instance(). Wzorzec projektowy Monostate najlepiej stosować w przypadku, gdy chcemy, aby fakt występowania obiektu w liczbie pojedynczej był dla użytkowników przezroczysty, lub gdy chcemy zastosować polimorficzne pochodne jednego obiektu.

Bibliografia 1. Gamma, et al., Design Patterns, Reading, MA: Addison-Wesley, 19953. 2. Robert C. Martin, et al., Pattern Languages of Program Design 3, Reading, MA: Addison-Wesley, 1998. 3. Steve Ball i John Crawford, Monostate Classes: The Power of One. Opublikowano w magazynie „More C++ Gems”, zredagowane przez Roberta C. Martina. Cambridge, Wielka Brytania: Cambridge University Press, 2000, str. 223.

3

Wydanie polskie: Wzorce projektowe. Elementy oprogramowania obiektowego wielokrotnego użytku, Wydawnictwa Naukowo-Techniczne, 2005 — przyp. tłum.

R OZDZIAŁ 17

Wzorzec projektowy Obiekt Null

Błędnie bezbłędny, lodowato regularny, wspaniale pusty, śmiertelnie perfekcyjny, nic więcej — Alfred Tennyson (1809 – 1892)

Przeanalizujmy następujący kod: Employee e = DB.getEmployee("Bogdan"); if (e != null && e.isTimeToPay(today)) e.pay();

Zadajemy do bazy danych pytanie o obiekt Employee odpowiadający pracownikowi o imieniu Bogdan. Obiekt klasy DB zwraca null, jeśli taki obiekt nie istnieje. W przeciwnym razie zwraca żądany egzemplarz klasy Employee. Jeśli pracownik istnieje i jest czas wypłaty dla tego pracownika, to wywołujemy metodę pay. Podobny kod wszyscy pisaliśmy już wcześniej. Idiom jest popularny, ponieważ w językach programowania wywodzących się z języka C pierwszy operand operatora && jest przetwarzany w pierwszej kolejności, natomiast drugi jest przetwarzany tylko wtedy, gdy pierwszy ma wartość true. Większość programistów zapomina również o sprawdzaniu, czy operand ma wartość null. Chociaż ten idiom jest popularny, jest nieelegancki i prowokuje do popełniania błędów.

202

ROZDZIAŁ 17. WZORZEC PROJEKTOWY OBIEKT NULL

Aby złagodzić podatność na błędy, można zaimplementować metodę DB.getEmployee w taki sposób, aby zgłaszała wyjątek, zamiast zwracać wartość null. Jednak stosowanie bloków try-catch jest jeszcze mniej eleganckie od testów sprawdzających wartość null. Co więcej, zastosowanie wyjątków zmusza do deklarowania ich w klauzulach throws. To sprawia, że trudno dostosować wyjątki do istniejącej aplikacji. Opisane problemy można rozwiązać, stosując wzorzec projektowy Obiekt null (ang. Null object)1. Zastosowanie tego wzorca często eliminuje potrzebę sprawdzania wartości null, a tym samym pomaga uprościć kod. Strukturę wzorca pokazano na rysunku 17.1. Employee jest interfejsem, który ma dwie implementacje. Klasa EmployeeImplementation to standardowa implementacja tego interfejsu. Zawiera wszystkie metody i zmienne, których istnienia oczekujemy od obiektu Employee. Kiedy metoda DB.getEmployee znajdzie pracownika w bazie danych, zwróci egzemplarz obiektu EmployeeImplementation. Obiekt klasy NullEmployee zostanie zwrócony tylko wówczas, kiedy metoda DB.getEmployee nie może znaleźć pracownika.

Rysunek 17.1. Wzorzec projektowy Obiekt null

Klasa NullEmployee implementuje wszystkie metody interfejsu Employee jako brak jakichkolwiek działań. Ten „brak działań” zależy od indywidualnych metod. Na przykład można by oczekiwać, że metoda isTimeToPay będzie zawsze zwracać false, ponieważ dla obiektu NullEmployee nigdy nie ma dnia wypłaty. Stosując wzorzec Obiekt null, można zastąpić pierwotny kod kodem o następującej postaci: Employee e = DB.getEmployee("Bogdan"); if (e.isTimeToPay(today)) e.pay();

Taki kod nie jest ani podatny na błędy, ani nieelegancki. Jest bardzo spójny. Metoda DB.getEmployee zawsze zwróci egzemplarz obiektu Employee. Ten egzemplarz będzie zachowywał się właściwie niezależnie od tego, czy pracownik został znaleziony, czy nie. Oczywiście można sobie wyobrazić wiele sytuacji, w których chcielibyśmy wiedzieć, że metodzie DB.getEmployee nie udało się znaleźć pracownika. W tym celu można utworzyć w interfejsie Employee zmienną z modyfikatorem static final, która będzie przechowywała jeden egzemplarz klasy Null Employee. Na listingu 17.1 pokazano przypadek testowy dla klasy NullEmployee. W tym przypadku „Bogdan” nie istnieje w bazie danych. Zwróćmy uwagę, że w przypadku testowym oczekujemy, aby metoda isTimeToPay zwróciła false. Zwróćmy także uwagę na to, że test oczekuje, aby metoda DB.getEmployee zwracała obiekt Employee.NULL.

1

[PLOPD3], str. 5. Ten wspaniały artykuł Bobby’ego Woolfa jest pełen dowcipu, ironii i praktycznych porad.

WNIOSEK

203

Listing 17.1. TestEmployee.java (fragment) public void testNull() throws Exception { Employee e = DB.getEmployee("Bogdan"); if (e.isTimeToPay(new Date())) fail(); assertEquals(Employee.NULL, e); }

Klasę DB pokazano na listingu 17.2. Zwróćmy uwagę, że dla celów testu metoda getEmployee po prostu zwraca Employee.NULL. Listing 17.2. DB.java public class DB { public static Employee getEmployee(String name) { return Employee.NULL; } }

Interfejs Employee pokazano na listingu 17.3. Zwróćmy uwagę, że zadeklarowano w nim zmienną statyczną o nazwie NULL, która zawiera anonimową implementację interfejsu Employee. Ta anonimowa implementacja jest jedynym egzemplarzem pracownika null. Implementacja metody isTimeToPay zawsze zwraca false, natomiast metoda pay nie wykonuje żadnych działań. Listing 17.3. Employee.java import java.util.Date; public interface Employee { public boolean isTimeToPay(Date payDate); public void pay(); public static final Employee NULL = new Employee() { public boolean isTimeToPay(Date payDate) { return false; }

}

};

public void pay() { }

Dzięki zaimplementowaniu pracownika null jako anonimowej, wewnętrznej klasy zyskaliśmy pewność istnienia tylko jednego egzemplarza takiego obiektu. Klasa NullEmployee samodzielnie nie istnieje. Nikt inny nie może stworzyć egzemplarza pracownika null. To korzystne rozwiązanie, ponieważ chcemy mieć możliwość posługiwania się wyrażeniem: if (e == Employee.NULL)

Takie wyrażenie byłoby niewiarygodne, gdyby było możliwe tworzenie wielu egzemplarzy pracownika null.

204

ROZDZIAŁ 17. WZORZEC PROJEKTOWY OBIEKT NULL

Wniosek Czytelnicy korzystający z języków programowania bazujących na języku C są przyzwyczajeni do funkcji, które zwracają null bądź 0 w przypadku wystąpienia różnych błędów. Zakładamy, że w takich przypadkach należy sprawdzać wartość zwracaną przez takie funkcje. Stosowanie wzorca projektowego Obiekt null zwalnia nas z tego obowiązku. Korzystając z tego wzorca, możemy zapewnić, że funkcje zawsze zwrócą prawidłowe obiekty, nawet wtedy, gdy zakończą się niepowodzeniem. Obiekty reprezentujące to niepowodzenie nie wykonują „żadnych działań”.

Bibliografia 1. Robert Martin, Dirk Riehle i Frank Buschmann, Pattern Languages of Program Design 3, Reading, MA: Addison-Wesley, 1998.

R OZDZIAŁ 18

Studium przypadku: system płacowy. Pierwsza iteracja

Wszystko, co jest w jakikolwiek sposób piękne, jest piękne samo w sobie, i przemija samo w sobie, nie osiągając chwały — Marek Aureliusz, około 170 r. n.e.

Wprowadzenie W tym rozdziale zamieszczono studium przypadku opisujące pierwszą iterację prostego systemu płacowego. Historyjki użytkownika w tym studium przypadku są uproszczone. Na przykład całkowicie zignorowano problem naliczania podatków. To typowe podejście dla wczesnych iteracji. Ich celem jest dostarczenie systemu, który realizuje tylko niewielki podzbiór potrzeb biznesowych klienta. W tym rozdziale przeprowadzimy szybkie sesje analizy i projektowania, które często wykonuje się na początku normalnej iteracji. Klient wybrał historyjki dla iteracji, a teraz trzeba ustalić, w jaki sposób zostaną one zaimplementowane. Takie sesje projektowe są krótkie i pobieżne — tak jak niniejszy rozdział. Diagramy UML, które zamieścimy w tym rozdziale, nie są niczym więcej niż pospiesznymi szkicami na tablicy. Prawdziwą pracę projektową przeprowadzimy w następnym rozdziale, gdy będziemy pracować nad testami jednostkowymi i implementacją.

206

ROZDZIAŁ 18. STUDIUM PRZYPADKU: SYSTEM PŁACOWY. PIERWSZA ITERACJA

Specyfikacja Poniżej zamieszczono kilka notatek, które zrobiliśmy podczas rozmów z klientem dotyczących historyjek wybranych do realizacji w pierwszej iteracji.  Niektórzy pracownicy pracują na godziny. Wypłaca się im wynagrodzenie według stawki godzino-

 







wej, która jest ustawiana w jednym z pól w rekordzie pracownika. Pracownicy dostarczają dzienne karty pracy, w których są zarejestrowane daty oraz liczba przepracowanych godzin. Jeśli pracują więcej niż 8 godzin dziennie, za te dodatkowe godziny są opłacani według stawki wynoszącej 1,5 raza więcej od ich normalnej stawki. Wynagrodzenia są im wypłacane w każdy piątek. Niektórzy pracownicy otrzymują „płaskie” wynagrodzenie. Wypłata następuje ostatniego roboczego dnia w miesiącu. Ich miesięczne wynagrodzenie jest jednym z pól w rekordzie pracownika. Niektórzy pracownicy otrzymują prowizję na podstawie zrealizowanej przez nich sprzedaży. Dostarczają dokumenty potwierdzające sprzedaż, zawierające datę sprzedaży oraz kwotę. Stawka prowizji jest zapisana w jednym z pól rekordu pracownika. Wynagrodzenia są im wypłacane w każdy piątek. Pracownicy mają możliwość wyboru metody wypłaty. Mogą otrzymywać czeki, które są wysyłane na wskazane adresy pocztowe. Mogą odebrać czeki osobiście od płatnika lub mogą zażądać przelania pieniędzy na wskazany rachunek bankowy. Niektórzy pracownicy należą do związku zawodowego. W rekordzie pracownika istnieje pole dotyczące wysokości należnych składek. Składki są potrącane z ich uposażenia. Ponadto związek zawodowy od czasu do czasu może pobierać dodatkowe opłaty od indywidualnych członków związku. Związek zawodowy dostarcza zleceń potrąceń co tydzień. Wskazane kwoty muszą być potrącone z kolejnej wypłaty wskazanego pracownika. Aplikacja płacowa jest uruchamiana tylko raz każdego dnia roboczego i dokonuje wypłat określonej grupie pracowników. System uzyska informacje dotyczące daty wypłaty. Na tej podstawie będzie mógł obliczyć wynagrodzenia od ostatniej wypłaty zrealizowanej dla pracownika do wskazanej daty.

Pracę moglibyśmy rozpocząć od wygenerowania schematu bazy danych. Wyraźnie widać, że do rozwiązania problemu może być potrzebny jakiś rodzaj relacyjnej bazy danych, a sformułowane wymagania dają nam dobre wyobrażenie, jakie tabele i pola powinny się znaleźć w takiej bazie danych. Z łatwością można by zaprojektować schemat, a następnie rozpocząć budowę potrzebnych kwerend. Jednak takie podejście prowadziłoby do wygenerowania aplikacji, w której centralnym punktem byłaby baza danych. Bazy danych są szczegółami implementacji! Wybór bazy danych powinien być odłożony w czasie tak długo, jak to możliwe. Zbyt wiele aplikacji jest nierozerwalnie związanych ze swoimi bazami danych tylko dlatego, że od początku zaprojektowano je z myślą o bazie danych. Pamiętajmy, jaka jest definicja abstrakcji: nacisk na rzeczy zasadnicze i eliminowanie rzeczy nieistotnych. Baza danych nie ma znaczenia na tym etapie projektu. Jest to jedynie technika wykorzystywana do przechowywania i dostępu do danych — nic więcej.

Analiza według przypadków użycia Zamiast zaczynać od danych występujących w systemie, spróbujmy zacząć od przeanalizowania zachowań systemu. Ostatecznie to za implementację tych zachowań otrzymamy zapłatę. Jednym ze sposobów uchwycenia i analizy zachowań systemu jest stworzenie przypadków użycia. Przypadki użycia, po raz pierwszy opisane przez Jacobsona, są bardzo podobne do pojęcia historyjek użytkowników w programowaniu EP. Przypadek użycia jest jak historyjka użytkownika, która została sformułowana trochę bardziej szczegółowo. Takie opracowanie jest właściwe wtedy, gdy historyjka użytkownika została wybrana do zaimplementowania w bieżącej iteracji.

ANALIZA WEDŁUG PRZYPADKÓW UŻYCIA

207

Podczas wykonywania analizy przypadków użycia zaglądamy do historyjek użytkowników i testów akceptacyjnych, aby zapoznać się z bodźcami, które generują użytkownicy tego systemu. Następnie staramy się ustalić, w jaki sposób system reaguje na te bodźce. Oto przykładowy zbiór historyjek użytkownika wybranych przez klienta do wykonania w kolejnej iteracji: 1. 2. 3. 4. 5. 6. 7.

Dodawanie nowego pracownika. Usuwanie pracownika. Dostarczenie karty pracy. Dostarczenie raportu sprzedaży. Dostarczenie informacji o opłacie na rzecz związku zawodowego. Zmiana szczegółowych danych pracownika (np. stawka godzinowa, należne składki). Wygenerowanie listy płac na dzień.

Spróbujmy przekształcić każdą z wymienionych historyjek użytkowników na bardziej rozbudowany przypadek użycia. Nie trzeba wchodzić w szczegóły. Opis powinien jedynie obejmować te elementy, które ułatwią nam projektowanie kodu implementującego wybraną historyjkę.

Dodawanie pracowników Przypadek użycia nr 1: Dodawanie nowego pracownika Nowy pracownik jest dodawany w wyniku transakcji AddEmp. Transakcja zawiera nazwisko pracownika, adres oraz numer przypisany do pracownika. Transakcja może przyjąć jedną z trzech form: AddEmp "" "" H AddEmp "" "" S AddEmp "" "" C

Następuje utworzenie rekordu pracownika i przypisanie wartości odpowiednich pól. Alternatywa 1: Błąd w strukturze transakcji. Jeśli struktura transakcji jest nieodpowiednia, to jest wyświetlany komunikat o błędzie i nie są podejmowane żadne działania. Przypadek użycia nr 1 sugeruje użycie pewnej abstrakcji. Istnieją trzy formy transakcji AddEmp, ale we wszystkich trzech formach występują pola , i . Możemy skorzystać ze wzorca projektowego Polecenie do stworzenia abstrakcyjnej klasy bazowej AddEmployeeTransaction. Klasa ta będzie miała trzy pochodne. AddHourlyEmployeeTransaction, AddSalariedEmployeeTransaction oraz AddCommissionedEmployeeTransaction (patrz rysunek 18.1). Ta struktura spełnia zasadę pojedynczej odpowiedzialności (SRP) — dla każdego zadania wyznaczono oddzielną klasę. Alternatywą byłoby umieszczenie wszystkich tych zadań w jednym module. Chociaż to mogłoby zmniejszyć liczbę klas w systemie, a tym samym uprościć go, to spowodowałoby skoncentrowanie całego kodu przetwarzania transakcji w jednym miejscu. W efekcie powstałby duży moduł, potencjalnie podatny na błędy.

208

ROZDZIAŁ 18. STUDIUM PRZYPADKU: SYSTEM PŁACOWY. PIERWSZA ITERACJA

Rysunek 18.1. Hierarchia klas AddEmployeeTransaction

Przypadek użycia nr 1 jawnie mówi o rekordzie pracownika, co wskazuje na zastosowanie jakiejś bazy danych. Nasza skłonność do baz danych może skusić nas do myślenia o układach rekordów lub strukturze pól w tabeli relacyjnej bazy danych, ale musimy oprzeć się tej pokusie. Prawdziwym sednem tego przypadku użycia jest stworzenie pracownika. Jaki jest model obiektowy pracownika? Lepiej postawione pytanie powinno brzmieć: „co powinny tworzyć wymienione trzy transakcje?”. W mojej ocenie tworzą one trzy różne rodzaje obiektów pracownika odzwierciedlające trzy formy transakcji AddEmp. Możliwą strukturę pokazano na rysunku 18.2.

Rysunek 18.2. Możliwa hierarchia klas Employee

Usuwanie pracowników Przypadek użycia nr 2: Usuwanie pracownika Pracownicy są usuwani w wyniku transakcji DelEmp. Transakcja ta ma następujący format: DelEmp

Po otrzymaniu tej transakcji następuje usunięcie odpowiedniego rekordu pracownika. Alternatywa 1: Nieprawidłowy bądź nieznany identyfikator EmpID. Jeśli pole identyfikatora ma nieprawidłową strukturę lub jeśli nie odwołuje się do prawidłowego rekordu pracownika, to transakcja powoduje wyświetlenie komunikatu o błędzie i nie jest podejmowane żadne inne działanie. Ten przypadek użycia nie daje mi żadnych spostrzeżeń projektowych w tym momencie. W związku z tym przyjrzyjmy się następnemu.

ANALIZA WEDŁUG PRZYPADKÓW UŻYCIA

209

Dostarczenie karty pracy Przypadek użycia nr 3: Dostarczenie karty pracy Po otrzymaniu transakcji TimeCard system utworzy rekord karty czasu pracy i powiąże go z rekordem właściwego pracownika. TimeCard

Alternatywa 1: Wskazany pracownik nie pracuje według stawki godzinowej. System wyświetli odpowiedni komunikat o błędzie i nie podejmie żadnych innych działań. Alternatywa 2: Błąd w strukturze transakcji. System wyświetli odpowiedni komunikat o błędzie i nie podejmie żadnych innych działań. Ten przypadek użycia wskazuje, że niektóre transakcje dotyczą tylko określonych rodzajów pracowników. To wzmacnia przekonanie o tym, że różne rodzaje pracowników powinny być reprezentowane przez różne klasy. W tym przypadku istnieje również domniemanie istnienia relacji pomiędzy kartami czasu pracy a pracownikami pracującymi w systemie godzinowym. Możliwy statyczny model takiej relacji pokazano na rysunku 18.3.

Rysunek 18.3. Relacja pomiędzy obiektami HourlyEmployee i TimeCard

Dostarczenie raportów sprzedaży Przypadek użycia nr 4: Dostarczenie raportu sprzedaży Po otrzymaniu transakcji SalesReceipt system utworzy nowy rekord raportu sprzedaży i powiąże go z rekordem właściwego pracownika. SalesReceipt

Alternatywa 1: Wskazany pracownik nie jest uprawniony do prowizji od sprzedaży. System wyświetli odpowiedni komunikat o błędzie i nie podejmie żadnych innych działań. Alternatywa 2: Błąd w strukturze transakcji. System wyświetli odpowiedni komunikat o błędzie i nie podejmie żadnych innych działań. Ten przypadek użycia jest bardzo podobny do przypadku użycia nr 3. Sugeruje strukturę pokazaną na rysunku 18.4.

210

ROZDZIAŁ 18. STUDIUM PRZYPADKU: SYSTEM PŁACOWY. PIERWSZA ITERACJA

Rysunek 18.4. Relacja pomiędzy pracownikami wynagradzanymi według prowizji a raportami sprzedaży

Dostarczenie informacji o opłacie na rzecz związku zawodowego Przypadek użycia nr 5: Dostarczenie informacji o opłacie na rzecz związku zawodowego Po otrzymaniu transakcji ServiceCharge system utworzy rekord opłaty na rzecz związku zawodowego i powiąże go z rekordem właściwego członka związku zawodowego. ServiceCharge

Alternatywa 1: Nieprawidłowy format transakcji. Jeśli transakcja ma nieprawidłowy format lub jeśli identyfikator nie odnosi się do członka związku zawodowego, to następuje wyświetlenie odpowiedniego komunikatu o błędzie. Ten przypadek użycia pokazuje, że dostępu do danych członków związków zawodowych nie uzyskujemy za pomocą identyfikatorów pracowników. Związek zawodowy utrzymuje własny system numerów identyfikacyjnych dla związkowców. Z tego powodu system musi zapewniać możliwość wiązania członków związku zawodowego z pracownikami. Istnieje wiele różnych sposobów zapewnienia tego rodzaju relacji. Zatem aby uniknąć przypadkowości, lepiej będzie odłożyć tę decyzję na później. Być może ograniczenia z innych części systemu zmuszą nas do podjęcia konkretnej decyzji. Jedno jest pewne. Istnieje bezpośrednia relacja pomiędzy członkami związku zawodowego a opłacanymi przez nich składkami. Możliwy statyczny model takiej relacji pokazano na rysunku 18.5.

Rysunek 18.5. Członkowie związku zawodowego i opłacane składki

Zmiana danych pracownika Przypadek użycia nr 6: Zmiana danych pracownika Po otrzymaniu transakcji ChgEmp system zmodyfikuje szczegółowe dane w rekordzie wskazanego pracownika. Transakcja ma kilka możliwych odmian. ChgEmp Name ChgEmp Address ChgEmp Hourly ChgEmp Pensja

Zmiana nazwiska pracownika Zmiana adresu pracownika Zmiana wynagrodzenia przy stawce godzinowej Zmiana sposobu wynagradzania przy pensji miesięcznej

ANALIZA WEDŁUG PRZYPADKÓW UŻYCIA

ChgEmp Commissioned

ChgEmp Hold ChgEmp Direct ChgEmp Mail ChgEmp Member Dues ChgEmp NoMember

211

Zmiana sposobu wynagradzania przy prowizji od sprzedaży Osobisty odbiór czeku Przelew na rachunek bankowy Przesłanie czeku pocztą Ustawia opcję członkostwa pracownika w związku zawodowym Usuwa opcję członkostwa pracownika w związku zawodowym

Alternatywa 1: Błędy transakcji. Jeśli struktura transakcji jest nieprawidłowa lub jeśli identyfikator nie odnosi się do rzeczywistego pracownika albo identyfikator odnosi się do członka związku zawodowego, to następuje wyświetlenie odpowiedniego komunikatu o błędzie i system nie podejmuje żadnych innych działań. Ten przypadek użycia daje dużo informacji o projektowanym systemie. Informuje o wszystkich aspektach dotyczących pracownika, dla których musi istnieć możliwość modyfikacji. Fakt, że można zmienić sposób wynagradzania pracownika z systemu godzinowego na pensję, oznacza, że diagram przedstawiony na rysunku 18.2 jest nieprawidłowy. Zamiast takiego schematu do obliczenia płacy lepiej byłoby zastosować wzorzec Strategia. Klasa Employee mogłaby zawierać klasę strategii PaymentClassification podobną do tej, której diagram pokazano na rysunku 18.6. Takie rozwiązanie jest korzystne, ponieważ można zmodyfikować obiekt PaymentClassification bez konieczności modyfikowania którejkolwiek części obiektu Employee. Zmiana sposobu wynagradzania pracownika z godzinowego na ze stałą pensją miesięczną wymagałaby zastąpienia obiektu HourlyClassification odpowiedniego obiektu Employee obiektem SalariedClassification. Obiekt PaymentClassification ma trzy odmiany. Obiekt HourlyClassification zawiera stawkę godzinową oraz listę obiektów TimeCard. Obiekt SalariedClassification przechowuje informacje o wysokości miesięcznej pensji. Obiekt CommissionedClassification zawiera informacje o miesięcznej pensji, stawce prowizji oraz listę obiektów SalesReceipt. W tych przypadkach zastosowałem relacje kompozycji, ponieważ uważam, że obiekty TimeCard i SalesReceipt powinny być usuwane wraz z usuwaniem pracownika. System musi zapewniać również możliwość modyfikacji sposobu wypłaty. Na rysunku 18.6 zaimplementowano tę koncepcję poprzez zastosowanie wzorca Strategia i trzech różnych klas pochodnych klasy PaymentMethod. Jeśli obiekt Employee zawiera obiekt MailMethod, to pracownikowi reprezentującemu ten obiekt czeki będą wysyłane pocztą. W obiekcie MailMethod jest zarejestrowany adres, pod który będą wysyłane czeki. Jeśli obiekt Employee zawiera obiekt DirectMethod, to wynagrodzenie pracownika będzie bezpośrednio przelewane na rachunek bankowy zapisany w obiekcie DirectMethod. Jeśli obiekt Employee zawiera obiekt HoldMethod, to czeki wypłat będą przesyłane do płatnika, od którego pracownik reprezentujący ten obiekt będzie je mógł odebrać osobiście. Na koniec na rysunku 18.6 warto zwrócić uwagę na zastosowanie wzorca projektowego Obiekt null w celu określenia przynależności do związku zawodowego. Każdy obiekt Employee zawiera obiekt Affiliation, który występuje w dwóch postaciach. Jeśli obiekt Employee zawiera obiekt NoAffiliation, to jego wynagrodzenie nie jest modyfikowane przez żadną inną instytucję poza pracodawcą. Jeśli jednak obiekt Employee zawiera obiekt UnionAffiliation, to ten pracownik musi płacić składki i opłaty zarejestrowane w obiekcie UnionAffiliation.

212

ROZDZIAŁ 18. STUDIUM PRZYPADKU: SYSTEM PŁACOWY. PIERWSZA ITERACJA

Rysunek 18.6. Poprawiony diagram klas systemu płacowego — model podstawowy

Dzięki zastosowaniu tych wzorców system dobrze spełnia zasadę otwarte-zamknięte (OCP). Klasa Employee jest zamknięta na zmiany w sposobie płatności, klasyfikacji płatności i przynależności do związ-

ków zawodowych. Do systemu można dodać nowe metody, klasyfikacje i przynależności do organizacji bez wpływu na obiekt Employee. Diagram z rysunku 18.6 staje się modelem podstawowym, czyli architekturą systemu. Znajduje się on w centralnym punkcie wszystkiego, co robi system płacowy. W aplikacji płacowej będzie wiele innych klas i projektów, ale będą one miały wtórne znaczenie dla tej podstawowej struktury. Oczywiście ta konstrukcja nie jest „wyrzeźbiona w skale”: będzie podlegać zmianom tak jak wszystko inne.

Wypłaty Przypadek użycia nr 7: Wygenerowanie listy płac na dzień Po otrzymaniu transakcji Payday system wyszukuje wszystkich pracowników, dla których tego dnia powinna być zrealizowana wypłata. Następnie system określa, jaką kwotę powinien wypłacić każdemu z nich, i realizuje wypłatę zgodnie z wybranym sposobem wypłaty. Payday

Chociaż przeznaczenie intencji tego przypadku użycia jest zrozumiałe, to nie jest proste określenie wpływu, jaki będzie on miał na statyczną strukturę z rysunku 18.6. Trzeba sobie odpowiedzieć na kilka pytań. Po pierwsze, skąd obiekt Employee „wie”, jak obliczyć wypłatę. Jest oczywiste, że jeśli pracownik jest wynagradzany według stawki godzinowej, to system musi zliczyć czas na podstawie kart pracy, a następnie pomnożyć go przez stawkę godzinową. Jeśli pracownik jest wynagradzany w systemie prowizji,

ANALIZA WEDŁUG PRZYPADKÓW UŻYCIA

213

to system musi zliczyć jego raporty sprzedaży, pomnożyć uzyskaną wartość przez stawkę prowizji i dodać zasadnicze uposażenie. Ale gdzie te obliczenia są wykonywane? Idealnym miejscem wydają się pochodne klasy PaymentClassification. Obiekty te utrzymują informacje niezbędne do obliczenia wynagrodzenia, więc powinny zawierać metody potrzebne do obliczenia wynagrodzenia. Na rysunku 18.7 przedstawiono diagram, który opisuje, jak to mogłoby działać.

Rysunek 18.7. Obliczanie wynagrodzenia pracownika

Kiedy skierujemy żądanie obliczenia wynagrodzenia do obiektu Employee, obiekt skieruje to żądanie do obiektu PaymentClassification. Właściwy algorytm, który będzie zastosowany, zależy do typu obiektu PaymentClassification zapisanego wewnątrz obiektu Employee. Trzy możliwe scenariusze przedstawiono na rysunkach od 18.8 do 18.10.

Rysunek 18.8. Obliczanie wynagrodzenia pracownika wynagradzanego według stawki godzinowej

Rysunek 18.9. Obliczanie wynagrodzenia pracownika otrzymującego prowizję

214

ROZDZIAŁ 18. STUDIUM PRZYPADKU: SYSTEM PŁACOWY. PIERWSZA ITERACJA

Rysunek 18.10. Obliczanie wynagrodzenia pracownika otrzymującego stałą pensję

Refleksja: czego się nauczyliśmy? Dowiedzieliśmy się, że prosta analiza przypadku użycia może dostarczyć mnóstwo informacji na temat projektu systemu. Rysunki od 18.6 do 18.10 są efektem analizy przypadków użycia — tzn. myślenia o zachowaniu systemu.

Wyszukiwanie potrzebnych abstrakcji Aby skutecznie stosować zasadę OCP, trzeba poszukać abstrakcji i znaleźć te, które tworzą podstawy aplikacji. Często te abstrakcje nie są podane, a nawet wspomniane w wymaganiach aplikacji, a nawet przypadkach użycia. Wymagania i przypadki użycia mogą być zbyt przesiąknięte szczegółami, aby wyrażać uogólnienia w postaci bazowych abstrakcji. Jakie są bazowe abstrakcje aplikacji płacowej? Przyjrzyjmy się ponownie wymaganiom. Widzimy w nich takie zdania jak: „niektórzy pracownicy pracują według stawki godzinowej”, „niektórym pracownikom jest wypłacana stała pensja” oraz „niektórzy pracownicy otrzymują prowizję”. Można na tej podstawie sformułować następujące uogólnienie: „Wszyscy pracownicy otrzymują wynagrodzenie, ale jest ono wypłacane według różnych zasad”. Abstrakcją w tym przypadku jest sformułowanie „Wszyscy pracownicy otrzymują wynagrodzenie”. Tę abstrakcję dobrze wyraża model klasy Payment Classification pokazany na rysunkach od 18.7 do 18.10. Tak więc tę abstrakcję już znaleźliśmy wśród naszych historyjek użytkowników, wykonując bardzo prostą analizę przypadków użycia.

Abstrakcja harmonogramu Poszukując innych abstrakcji, znajdujemy: „Wypłaty są realizowane w każdy piątek”, „Wypłata następuje w ostatnim dniu roboczym miesiąca” oraz „Wypłata następuje co drugi piątek”. To prowadzi do innego uogólnienia: „Wszyscy pracownicy otrzymują wynagrodzenie zgodnie z określonym harmonogramem”. Abstrakcją w tym przypadku jest pojęcie harmonogramu. Powinna istnieć możliwość zapytania obiektu Employee o to, czy określony dzień jest datą wypłaty. W przypadkach użycia jest o tym zaledwie wzmianka. Wymagania zawierają powiązanie harmonogramu pracownika z jego klasyfikacją wynagrodzenia. Zatem pracownicy wynagradzani według stawki godzinowej otrzymują wynagrodzenie co tydzień, pracownicy ze stałą pensją otrzymują wypłatę co miesiąc, natomiast pracownicy otrzymujący prowizję otrzymują wypłatę co drugi tydzień. Jednak czy takie powiązanie jest istotne? Czy polityka nie może się zmienić pewnego dnia w taki sposób, aby pracownicy mogli wybrać konkretny harmonogram, albo żeby pracownicy należący do różnych działów lub filii mogli mieć różne harmonogramy? Czy harmonogramy nie mogą się zmieniać niezależnie od sposobu wynagradzania? To na pewno wydaje się prawdopodobne. Gdybyśmy zgodnie z wymaganiami oddelegowali problem tworzenia harmonogramu do klasy PaymentClassification, to nasza klasa nie byłaby zamknięta na problemy zmian w harmonogramie. Gdybyśmy zmienili sposób wynagradzania, musielibyśmy także testować harmonogram. Gdybyśmy

WYSZUKIWANIE POTRZEBNYCH ABSTRAKCJI

215

zmienili harmonogramy, musielibyśmy także testować strategię wynagradzania. Naruszylibyśmy zarówno zasady OCP, jak i SRP. Powiązanie pomiędzy harmonogramem a sposobem wynagradzania mogłoby doprowadzić do błędów, w wyniku których zmiana w konkretnym sposobie płatności mogłaby powodować generowanie nieprawidłowego harmonogramu dla niektórych pracowników. Takie błędy mogą wydawać się sensowne dla programistów, ale mogą też zasiać strach w sercach menedżerów i użytkowników. Obawiają się oni, i słusznie, że jeśli harmonogramy mogą ulec uszkodzeniu w wyniku zmian w sposobie wynagradzania, to wszelkie zmiany dokonane w dowolnym miejscu mogą powodować problemy w dowolnej innej niezwiązanej części systemu. Obawiają się, że nie będą mogli przewidzieć skutków wprowadzonych zmian. Kiedy nie można przewidzieć efektów, tracimy zaufanie do programu, a aplikacja w oczach menedżerów i użytkowników uzyskuje status „niebezpiecznej i niestabilnej”. Pomimo istotnego charakteru abstrakcji harmonogramu nasza analiza przypadków użycia nie dała nam żadnych bezpośrednich wskazówek na temat jej istnienia. Aby dostrzec tę abstrakcję, należy dokładnie przeanalizować wymagania i zastanowić się nad oczekiwaniami społeczności użytkowników. Nadmierne poleganie na narzędziach i procedurach oraz niedocenianie wiedzy i doświadczenia to przepis na katastrofę. Na rysunkach 18.11 i 18.12 pokazano statyczne i dynamiczne modele abstrakcji harmonogramu. Jak można zauważyć, ponownie zastosowaliśmy wzorzec Strategia. Klasa Employee zawiera abstrakcyjną klasę PaymentSchedule. Istnieją trzy odmiany klasy PaymentSchedule odpowiadające trzem harmonogramom, według których pracownicy są wynagradzani.

Rysunek 18.11. Statyczny model abstrakcji Schedule

Rysunek 18.12. Dynamiczny model abstrakcji Schedule

Sposoby wypłaty Innym uogólnieniem, które możemy wywnioskować na podstawie wymagań, jest sformułowanie: „wszyscy pracownicy otrzymują wynagrodzenie określonym sposobem”. Abstrakcją jest klasa PaymentMethod. Co ciekawe, ta abstrakcja została wyrażona wcześniej na rysunku 18.6.

216

ROZDZIAŁ 18. STUDIUM PRZYPADKU: SYSTEM PŁACOWY. PIERWSZA ITERACJA

Przynależność do związków zawodowych Z wymagań wynika, że pracownicy mogą należeć do związków zawodowych. Trzeba jednak pamiętać, że związek zawodowy może nie być jedyną instytucją, która może zgłaszać roszczenia do części wynagrodzenia pracownika. Pracownicy mogą życzyć sobie realizowania automatycznych wpłat na rzecz wskazanych organizacji charytatywnych lub opłacania składek do stowarzyszeń zawodowych. Wynika stąd następujące uogólnienie: „Pracownik może należeć do wielu organizacji. Składki na rzecz tych organizacji powinny być automatycznie opłacane z wynagrodzenia pracownika”. Odpowiednią abstrakcją jest w tym przypadku klasa Affiliation, której diagram pokazano na rysunku 18.6. Na tym rysunku nie pokazano jednak obiektu Employee, który zawiera więcej niż jeden obiekt Affiliation. Zaprezentowano też istnienie klasy NoAffiliation. Ten projekt nie całkiem pasuje do abstrakcji, której — jak się wydaje — teraz potrzebujemy. Na rysunkach 18.13 i 18.14 pokazano statyczne i dynamiczne modele reprezentujące abstrakcję Affilliation.

Rysunek 18.13. Statyczna struktura abstrakcji Affiliation

Rysunek 18.14. Dynamiczna struktura abstrakcji Affiliation

Lista obiektów Affiliation pozwoliła na wyeliminowanie potrzeby korzystania ze wzorca projektowego Obiekt null dla pracowników niezrzeszonych w związku zawodowym. Jeśli pracownik nie jest zrzeszony w żadnej organizacji, to teraz jego lista obiektów Affiliation po prostu będzie pusta.

Wniosek Na początku iteracji często się zdarza, że zespół gromadzi się przy „białej tablicy”. Członkowie zespołu wspólnie omawiają historyjki użytkownika, które zostały wybrane do tej iteracji. Taka szybka sesja projektowa zwykle trwa mniej niż godzinę. Powstałe diagramy UML mogą pozostać na tablicy bądź też mogą być z niej zmazane. Zwykle nie są utrwalane w formie papierowej. Celem sesji jest rozpoczęcie procesu myślowego i zaprezentowanie deweloperom wspólnego modelu mentalnego, na podstawie którego będą realizowane prace. Celem nie jest stworzenie kompletnego projektu. Niniejszy rozdział jest opisowym odpowiednikiem takiej szybkiej sesji projektowej.

Bibliografia 1. Ivar Jacobson, Object-Oriented Software Engineering, A Use-Case-Driven Approach, Wokingham, Wielka Brytania: Addison-Wesley, 1992.

R OZDZIAŁ 19

Studium przypadku: system płacowy. Implementacja

Minęło sporo czasu od momentu, gdy zaczęliśmy pisać kod obsługujący i weryfikujący projekty, nad którymi pracujemy. Zamierzam tworzyć ten kod w bardzo małych, przyrostowych etapach, ale będę prezentował go czytelnikom tylko w dogodnych punktach w tekście. To, że czytelnikom są prezentowane w pełni sformatowane fragmenty kodu, nie oznacza, że napisałem go w takiej formie. W rzeczywistości pomiędzy każdą partią kodu, którą zaprezentowałem, były dziesiątki edycji, kompilacji i sprawdzania testów — każda taka operacja dotyczyła niewielkiej, ewolucyjnej zmiany w kodzie. Zaprezentujemy również sporo diagramów UML. Te diagramy UML należy traktować tak jak szkice na tablicy, których używałem, by przekazać czytelnikowi — mojemu partnerowi — to, co mam na myśli. Diagramy UML są dogodnym medium komunikacji pomiędzy deweloperami. Na rysunku 19.1 pokazano, że transakcje zaprezentowaliśmy w formie abstrakcyjnej klasy bazowej o nazwie Transaction z metodą o nazwie Execute(). To jest oczywiście wzorzec projektowy Polecenie. Implementację klasy Transaction zamieszczono na listingu 19.1.

Rysunek 19.1. Interfejs Transaction

218

ROZDZIAŁ 19. STUDIUM PRZYPADKU: SYSTEM PŁACOWY. IMPLEMENTACJA

Listing 19.1. Transaction.h #ifndef TRANSACTION_H #define TRANSACTION_H class Transaction { public: virtual ~Transaction(); virtual void Execute() = 0; }; #endif

Dodawanie pracowników Na rysunku 19.2 pokazano możliwą strukturę transakcji służącej do dodawania pracowników. Należy pamiętać, że w ramach tych transakcji jest wiązany harmonogram wypłat pracowników z formą wypłaty. Jest to właściwe, ponieważ transakcje są raczej sposobem realizacji, a nie częścią podstawowego modelu. Tak więc podstawowy model „nie wie” o tym powiązaniu. Jest ono tylko częścią jednej z implementacji i może ulec zmianie w dowolnym czasie. Na przykład z łatwością moglibyśmy dodać transakcję, która pozwala zmienić harmonogram wypłat pracownika.

Rysunek 19.2. Statyczny model transakcji AddEmployeeTransaction

DODAWANIE PRACOWNIKÓW

219

Zwróćmy także uwagę na to, że domyślną metodą płatności jest odbieranie czeku od płatnika. Jeśli pracownik chce wybrać inną metodę realizacji wypłaty, zmiany muszą być wykonane za pomocą odpowiedniej transakcji ChgEmp. Tak jak zwykle kod zaczynamy pisać od napisania testu. Na listingu 19.2 pokazano przypadek testowy, który pokazuje, że transakcja AddSalariedTransaction działa prawidłowo. Kod, który zamieszczono poniżej, spowoduje, że zaprezentowany przypadek testowy przejdzie. Listing 19.2. PayrollTest::TestAddSalariedEmployee void PayrollTest::TestAddSalariedEmployee() { int empId = 1; AddSalariedEmployee t(empId, "Bogdan", "Dom", 2500.00); t.Execute(); Employee* e = GpayrollDatabase.GetEmployee(empId); assert("Bob" == e->GetName()); PaymentClassification* pc = e->GetClassification(); SalariedClassification* sc = dynamic_cast(pc); assert(sc);

}

assertEquals(2500.00, sc->GetSalary(), .001); PaymentSchedule* ps = e->GetSchedule(); MonthlySchedule* ms = dynamic_cast(ps); assert(ms); PaymentMethod* pm = e->GetMethod(); HoldMethod* hm = dynamic_cast(pm); assert(hm);

Baza danych systemu płacowego Klasa AddEmployeeTransaction korzysta z klasy o nazwie PayrollDatabase. Klasa ta przechowuje wszystkie istniejące obiekty Employee w obiekcie Dictionary, w której kluczem jest identyfikator empID. Klasa zawiera także obiekt Dictionary zawierający odwzorowanie identyfikatorów memberIDs członków związków zawodowych na identyfikatory empID. Strukturę tej klasy pokazano na rysunku 19.3. PayrollDatabase jest przykładem zastosowania wzorca projektowego Fasada (rozdział 15.).

Rysunek 19.3. Statyczna struktura klasy PayrollDatabase

Uproszczoną implementację klasy PayrollDatabase zamieszczono na listingach 19.3 i 19.4. Pokazana implementacja ma ułatwić nam zrealizowanie początkowych przypadków testowych. Nie zawiera jeszcze słownika, który odwzorowuje identyfikatory członków związków zawodowych na egzemplarze obiektów Employee.

220

ROZDZIAŁ 19. STUDIUM PRZYPADKU: SYSTEM PŁACOWY. IMPLEMENTACJA

Listing 19.3. PayrollDatabase.h #ifndef PAYROLLDATABASE_H #define PAYROLLDATABASE_H #include class Employee; class PayrollDatabase { public: virtual ~PayrollDatabase(); Employee* GetEmployee(int empId); void AddEmployee(int empid, Employee*); void clear() {itsEmployees.clear();} private: map itsEmployees; }; #endif

Listing 19.4. PayrollDatabase.cpp #include "PayrollDatabase.h" #include "Employee.h" PayrollDatabase GpayrollDatabase; PayrollDatabase::~PayrollDatabase() { } Employee* PayrollDatabase::GetEmployee(int empid) { return itsEmployees[empid]; } void PayrollDatabase::AddEmployee(int empid, Employee* e) { itsEmployees[empid] = e; }

Ogólnie rzecz biorąc, implementację bazy danych uważam za szczegóły. Wybór tych szczegółów powinien być odłożony w czasie tak długo, jak to możliwe. To, czy ta konkretna baza danych będzie zaimplementowana w formie systemu RDBMS, zwykłych plików, czy też systemu OODBMS, w tym momencie jest bez znaczenia. W tej chwili ważne jest stworzenie API, które będzie świadczyć usługi bazy danych dla reszty aplikacji. Właściwą implementacją potrzebnej bazy danych zajmiemy się później. Odkładanie implementacji szczegółów dotyczących bazy danych jest rzadką praktyką, ale bardzo korzystną. Decyzje dotyczące bazy danych zazwyczaj mogą czekać do chwili, gdy zdobędziemy większą wiedzę na temat oprogramowania i jego potrzeb. Dzięki oczekiwaniu unikamy problemu zbytniej rozbudowy infrastruktury bazy danych. Zamiast tego implementujemy tylko te mechanizmy bazy danych, które są niezbędne z punktu widzenia realizacji potrzeb aplikacji.

Zastosowanie wzorca Metoda szablonowa do dodawania pracowników Na rysunku 19.4 pokazano dynamiczny model dodawania pracownika. Zwróćmy uwagę, że obiekt AddEmployeeTransaction wysyła komunikaty sam do siebie w celu uzyskania odpowiednich obiektów PaymentClassification i PaymentSchedule. Komunikaty te są zaimplementowane w pochodnych klasy AddEmployeeTransaction. To jest implementacja wzorca projektowego Metoda szablonowa.

DODAWANIE PRACOWNIKÓW

221

Rysunek 19.4. Dynamiczny model dodawania pracownika

Na listingach 19.5 i 19.6 zamieszczono implementację wzorca Metoda szablonowa w klasie AddEm ployeeTransaction. Klasa implementuje metodę Execute() w celu wywołania dwóch czysto wirtualnych funkcji zaimplementowanych w klasach pochodnych. Te funkcje, GetSchedule() i GetClassification(), zwracają obiekty PaymentSchedule i PaymentClassification wymagane przez nowo stworzony obiekt Employee. Następnie metoda Execute() wiąże te obiekty z obiektem Employee i zapisuje obiekt Employee do bazy PayrollDatabase. Listing 19.5. AddEmployeeTransaction.h #ifndef ADDEMPLOYEETRANSACTION_H #define ADDEMPLOYEETRANSACTION_H #include "Transaction.h" #include class PaymentClassification; class PaymentSchedule; class AddEmployeeTransaction : public Transaction { public: virtual ~AddEmployeeTransaction(); AddEmployeeTransaction(int empid, string name, string address); virtual PaymentClassification* GetClassification() const = 0; virtual PaymentSchedule* GetSchedule() const = 0; virtual void Execute(); private: int itsEmpid; string itsName; string itsAddress;

}; #endif

222

ROZDZIAŁ 19. STUDIUM PRZYPADKU: SYSTEM PŁACOWY. IMPLEMENTACJA

Listing 19.6. AddEmployeeTransaction.cpp #include #include #include #include

"AddEmployeeTransaction.h" "HoldMethod.h" "Employee.h" "PayrollDatabase.h"

class PaymentMethod; class PaymentSchedule; class PaymentClassification; extern PayrollDatabase GpayrollDatabase; AddEmployeeTransaction::~AddEmployeeTransaction() { } AddEmployeeTransaction:: AddEmployeeTransaction(int empid, string name, string address) : itsEmpid(empid) , itsName(name) , itsAddress(address) { } void AddEmployeeTransaction::Execute() { PaymentClassification* pc = GetClassification(); PaymentSchedule* ps = GetSchedule(); PaymentMethod* pm = new HoldMethod(); Employee* e = new Employee(itsEmpid, itsName, itsAddress); e->SetClassification(pc); e->SetSchedule(ps); e->SetMethod(pm); GpayrollDatabase.AddEmployee(itsEmpid, e); }

Na listingach 19.7 i 19.8 pokazano implementację klasy AddSalariedEmployee. Ta klasa dziedziczy po klasie AddEmployeeTransaction. Implementuje metody GetSchedule() i GetClassification() w celu przekazania właściwych obiektów do metody AddEmployeeTransaction::Execute(). Listing 19.7. AddSalariedEmployee.h #ifndef ADDSALARIEDEMPLOYEE_H #define ADDSALARIEDEMPLOYEE_H #include "AddEmployeeTransaction.h" class AddSalariedEmployee : public AddEmployeeTransaction { public: virtual ~AddSalariedEmployee(); AddSalariedEmployee(int empid, string name, string address, double salary); PaymentClassification* GetClassification() const; PaymentSchedule* GetSchedule() const; private: double itsSalary;

}; #endif

USUWANIE PRACOWNIKÓW

223

Listing 19.8. AddSalariedEmployee.cpp #include "AddSalariedEmployee.h" #include "SalariedClassification.h" #include "MonthlySchedule.h" AddSalariedEmployee::~AddSalariedEmployee() { } AddSalariedEmployee:: AddSalariedEmployee(int empid, string name, string address, double salary) : AddEmployeeTransaction(empid, name, address) , itsSalary(salary) { } PaymentClassification* AddSalariedEmployee::GetClassification() const { return new SalariedClassification(itsSalary); } PaymentSchedule* AddSalariedEmployee::GetSchedule() const { return new MonthlySchedule(); }

Implementację klas AddHourlyEmployee i AddCommissionedEmployee pozostawiam Ci jako ćwiczenie do samodzielnego wykonania. Pamiętaj, aby najpierw napisać przypadki testowe.

Usuwanie pracowników Na rysunkach 19.5 i 19.6 pokazano statyczne i dynamiczne modele transakcji używanych do usuwania pracowników.

Rysunek 19.5. Statyczny model transakcji DeleteEmployee

Rysunek 19.6. Dynamiczny model transakcji DeleteEmployee

224

ROZDZIAŁ 19. STUDIUM PRZYPADKU: SYSTEM PŁACOWY. IMPLEMENTACJA

Na listingu 19.9 pokazano przypadek testowy dla transakcji usuwania pracownika. Na listingach 19.10 i 19.11 zamieszczono implementację klasy DeleteEmployeeTransaction. To jest bardzo typowa implementacja wzorca projektowego Polecenie. W konstruktorze są zapisywane dane, na których metoda Execute() wykonuje działania. Listing 19.9. PayrollTest::TestDeleteEmployee() void PayrollTest::TestDeleteEmployee() { cerr << "TestDeleteEmployee" << endl; int empId = 3; AddCommissionedEmployee t(empId, "Lidia", "Dom", 2500, 3.2); t.Execute(); { Employee* e = GpayrollDatabase.GetEmployee(empId); assert(e); } DeleteEmployeeTransaction dt(empId); dt.Execute(); { Employee* e = GpayrollDatabase.GetEmployee(empId); assert(e == 0); } }

Listing 19.10. DeleteEmployeeTransaction.h #ifndef DELETEEMPLOYEETRANSACTION_H #define DELETEEMPLOYEETRANSACTION_H #include "Transaction.h" class DeleteEmployeeTransaction : public Transaction { public: virtual ~DeleteEmployeeTransaction(); DeleteEmployeeTransaction(int empid); virtual void Execute(); private: int itsEmpid; }; #endif

Listing 19.11. DeleteEmployeeTransaction.cpp #include "DeleteEmployeeTransaction.h" #include "PayrollDatabase.h" extern PayrollDatabase GpayrollDatabase; DeleteEmployeeTransaction::~DeleteEmployeeTransaction() { } DeleteEmployeeTransaction::DeleteEmployeeTransaction(int empid) : itsEmpid(empid) { } void DeleteEmployeeTransaction::Execute() { GpayrollDatabase.DeleteEmployee(itsEmpid); }

KARTY PRACY, RAPORTY SPRZEDAŻY I SKŁADKI

225

Zmienne globalne Dotychczas posłużyliśmy się zmienną globalną GpayrollDatabase. Przez dziesięciolecia w podręcznikach i na wykładach nie bez powodu zniechęcano do korzystania ze zmiennych globalnych. Zmienne globalne nie są jednak wewnętrznie złe czy też szkodliwe. Ta konkretna sytuacja idealnie nadaje się do zastosowania zmiennej globalnej. Będzie tylko jeden egzemplarz klasy PayrollDatabase i musi on być znany bardzo dużej grupie klas klienckich. Można by sądzić, że lepiej byłoby zrealizować ten cel poprzez zastosowanie wzorców projektowych Singleton bądź Monostate. Prawdą jest, że zastosowanie tych wzorców spełniłoby swoją rolę. Jednak wzorce te same wykorzystują zmienne globalne. Klasy implementujące wzorce Singleton lub Monostate są z definicji encjami globalnymi. W tym przypadku uznałem, że zastosowanie wzorca Singleton lub Monostate spowodowałoby, że projekt zacząłby wydawać woń niepotrzebnej złożoności. Łatwiej jest przechowywać egzemplarz bazy danych w zmiennej globalnej.

Karty pracy, raporty sprzedaży i składki Na rysunku 19.7 pokazano statyczną strukturę transakcji służącej do dostarczania kart czasu pracy pracowników. Na rysunku 19.8 pokazano model dynamiczny. Podstawowe działanie polega na pobraniu obiektu Employee z bazy danych PayrollDatabase, zażądaniu od obiektu Employee powiązanego z nim obiektu PaymentClassification, a następnie stworzeniu i dodaniu obiektu TimeCard do tego obiektu PaymentClassification.

Rysunek 19.7. Statyczna struktura klasy TimeCardTransaction

Zwróćmy uwagę, że nie można dodać obiektów TimeCard do ogólnych obiektów PaymentClassification. Można je dodawać tylko do obiektów HourlyClassification. Wynika stąd konieczność zrzutowania obiektu PaymentClassification otrzymanego z obiektu Employee na obiekt HourlyClassification. Do tego celu świetnie nadaje się operator języka C++ dynamic_cast. Zobaczymy to później na listingu 19.15.

226

ROZDZIAŁ 19. STUDIUM PRZYPADKU: SYSTEM PŁACOWY. IMPLEMENTACJA

Rysunek 19.8. Dynamiczny model dostarczania karty czasu pracy

Na listingu 19.12 pokazano jeden z przypadków testowych, który weryfikuje, czy można dodać karty czasu pracy do pracowników wynagradzanych w systemie godzinowym. Kod testu po prostu tworzy rekord pracownika godzinowego i dodaje go do bazy danych. Następnie tworzy transakcję TimeCardTransaction, wywołuje metodę Execute() i sprawdza, czy obiekt HourlyClassification zawiera właściwy obiekt TimeCard. Listing 19.12. PayrollTest::TestTimeCardTransaction() void PayrollTest::TestTimeCardTransaction() { cerr << "TestTimeCardTransaction" << endl; int empId = 2; AddHourlyEmployee t(empId, "Bartosz", "Dom", 15.25); t.Execute(); TimeCardTransaction tct(20011031, 8.0, empId); tct.Execute(); Employee* e = GpayrollDatabase.GetEmployee(empId); assert(e); PaymentClassification* pc = e->GetClassification(); HourlyClassification* hc = dynamic_cast(pc); assert(hc); TimeCard* tc = hc->GetTimeCard(20011031); assert(tc); assertEquals(8.0, tc->GetHours()); }

Implementację klasy TimeCard zamieszczono na listingu 19.13. Nie ma w tej klasie niczego specjalnego. Jest to tylko klasa do przechowywania danych. Zwróćmy uwagę, że do reprezentowania dat użyłem typu long integer. Zrobiłem to, ponieważ nie miałem odpowiedniej klasy Date. Prawdopodobnie wkrótce będę jej potrzebował, ale na razie nie jest konieczna. Nie chcę się rozpraszać przy wykonywaniu bieżącego zadania, które polega na doprowadzeniu do tego, by opracowany przypadek testowy zaczął przechodzić. Ostatecznie napiszę przypadek testowy, który będzie wymagał prawdziwej klasy Date. Kiedy to się stanie, wrócę do tego kodu i zastosuję go w klasie TimeCard. Listing 19.13. TimeCard.h #ifndef TIMECARD_H #define TIMECARD_H class TimeCard { public:

KARTY PRACY, RAPORTY SPRZEDAŻY I SKŁADKI

227

virtual ~TimeCard(); TimeCard(long date, double hours); long GetDate() {return itsDate;} double GetHours() {return itsHours;} private: long itsDate; double itsHours;

}; #endif

Na listingach 19.14 i 19.15 pokazano implementację klasy TimeCardTransaction. Zwróćmy uwagę na wykorzystanie prostych wyjątków tekstowych. Na dłuższą metę nie jest to dobra praktyka, ale wystarcza w tej wczesnej fazie projektu. Kiedy przekonamy się, jak powinny wyglądać wyjątki, będziemy mogli wrócić do tego kodu i stworzyć sensowne klasy opisu wyjątków. Zwróćmy również uwagę na to, że egzemplarz klasy TimeCard jest tworzony tylko wtedy, gdy jesteśmy pewni, że nie będziemy zgłaszać wyjątku. Dzięki temu operacja zgłaszania wyjątku nie może powodować wycieków pamięci. Bardzo łatwo można stworzyć kod, w którym podczas zgłaszania wyjątków wycieka pamięć lub inne zasoby, dlatego należy zachować ostrożność1. Listing 19.14. TimeCardTransaction.h #ifndef TIMECARDTRANSACTION_H #define TIMECARDTRANSACTION_H #include "Transaction.h" class TimeCardTransaction : public Transaction { public: virtual ~TimeCardTransaction(); TimeCardTransaction(long date, double hours, int empid); virtual void Execute(); private: int itsEmpid; long itsDate; double itsHours;

}; #endif

Listing 19.15. TimeCardTransaction.cpp #include #include #include #include #include

"TimeCardTransaction.h" "Employee.h" "PayrollDatabase.h" "HourlyClassification.h" "TimeCard.h"

extern PayrollDatabase GpayrollDatabase; TimeCardTransaction::~TimeCardTransaction() { } TimeCardTransaction::TimeCardTransaction(long date, double hours, int empid) : itsDate(date) , itsHours(hours)

1

Radzę jak najszybciej zaopatrzyć się w książki Herba Suttera Exceptional C++ i More Exceptional C++. Te dwie książki pozwolą Ci zaoszczędzić wiele bólu, płaczu i zgrzytania zębami przy obsłudze wyjątków w C++.

228

{ }

ROZDZIAŁ 19. STUDIUM PRZYPADKU: SYSTEM PŁACOWY. IMPLEMENTACJA

, itsEmpid(empid)

void TimeCardTransaction::Execute() { Employee* e = GpayrollDatabase.GetEmployee(itsEmpid); if (e){ PaymentClassification* pc = e->GetClassification(); if (HourlyClassification* hc = dynamic_cast(pc)) { hc->AddTimeCard(new TimeCard(itsDate, itsHours)); } else throw("Próba dodania karty czasu pracy do pracownika, który nie pracuje w systemie godzinowym"); } else throw("Nie ma takiego pracownika."); }

Na rysunkach 19.9 i 19.10 pokazano podobny projekt dla transakcji dostarczania raportów sprzedaży do pracownika wynagradzanego w systemie prowizyjnym. Implementację tych klas pozostawiam czytelnikom jako ćwiczenie do samodzielnego wykonania.

Rysunek 19.9. Statyczny model transakcji SalesReceiptTransaction

Rysunek 19.10. Dynamiczny model transakcji SalesReceiptTransaction

KARTY PRACY, RAPORTY SPRZEDAŻY I SKŁADKI

229

Na rysunkach 19.11 i 19.12 pokazano projekt transakcji przypisywania składek członkom związków zawodowych.

Rysunek 19.11. Statyczny model transakcji ServiceChargeTransaction

Rysunek 19.12. Dynamiczny model transakcji ServiceChargeTransaction

Te projekty pokazują rozbieżność pomiędzy modelem transakcji i podstawowym modelem, który stworzyliśmy. Podstawowy obiekt Employee może być powiązany z wieloma organizacjami, ale model transakcji zakłada, że każde powiązanie oznacza przynależność do związku zawodowego. Tak więc model transakcji nie zapewnia sposobu identyfikacji określonego rodzaju przynależności. Zamiast tego po prostu zakłada, że jeśli dodajemy opłatę składki, to pracownik należy do związku zawodowego. Problem ten rozwiązano w modelu dynamicznym, gdzie następuje przeszukiwanie zbioru obiektów Affiliation zapisanych w obiekcie Employee i sprawdzenie, czy ten zbiór zawiera obiekt UnionAffiliation. W przypadku powodzenia w wyszukiwaniu obiekt ServiceCharge jest przypisywany do odnalezionego obiektu UnionAffiliation. Na listingu 19.16 pokazano przypadek testowy dla transakcji ServiceChargeTransaction. Kod testu po prostu tworzy rekord pracownika godzinowego i dodaje do niego obiekt UnionAffiliation. Sprawdza również, czy pracownik o podanym identyfikatorze członka związku został zarejestrowany w bazie danych PayrollDatabase. Następnie tworzy transakcję ServiceChargeTransaction i wykonuje ją. Na koniec sprawdza, czy właściwy obiekt ServiceCharge rzeczywiście został dodany do obiektu UnionAffiliation powiązanego z obiektem Employee.

230

ROZDZIAŁ 19. STUDIUM PRZYPADKU: SYSTEM PŁACOWY. IMPLEMENTACJA

Listing 19.16. PayrollTest::TestAddServiceCharge() void PayrollTest::TestAddServiceCharge() { cerr << "TestAddServiceCharge" << endl; int empId = 2; AddHourlyEmployee t(empId, "Bartosz", "Dom", 15.25); t.Execute(); Employee* e = GpayrollDatabase.GetEmployee(empId); assert(e); UnionAffiliation* af = new UnionAffiliation(12.5); e->SetAffiliation(af); int memberId = 86; // Maxwell Smart GpayrollDatabase.AddUnionMember(memberId, e); ServiceChargeTransaction sct(memberId, 20011101, 12.95); sct.Execute(); ServiceCharge* sc = af->GetServiceCharge(20011101); assert(sc); assertEquals(12.95, sc->GetAmount(), .001); }

Kod a diagramy UML. Kiedy rysowałem diagram UML zamieszczony na rysunku 19.12, sądziłem, że zastąpienie obiektu NoAffiliation listą przynależności do organizacji jest lepszym rozwiązaniem. Uważałem takie rozwiązanie za bardziej elastyczne i mniej złożone. W końcu mogłem dodać informacje o przynależności w każdej chwili i nie musiałem tworzyć klasy NoAffiliation. Jednak podczas pisania przypadku testowego z listingu 19.16 zdałem sobie sprawę, że wywołanie metody SetAffiliation na obiekcie Employee jest lepsze niż wywołanie metody AddAffiliation. W końcu w wymaganiach nie ma żadnej wzmianki o tym, że z pracownikiem może być związany więcej niż jeden obiekt Affiliation, zatem nie ma potrzeby stosowania operatora dynamic_cast w celu wyboru spośród potencjalnie wielu rodzajów. Taka próba wiązałaby się z nadmierną złożonością. Przykład ten pokazuje, dlaczego rysowanie zbyt wielu diagramów UML bez sprawdzania ich w kodzie może być niebezpieczne. Kod może dać nam takie informacje na temat projektu, których nie da się uzyskać za pomocą UML. W tym przypadku umieściłem na diagramach UML struktury, które nie były potrzebne. Być może kiedyś takie struktury się przydadzą, ale na razie nie warto ponosić kosztów ich utrzymywania do nieznanej pory w przyszłości. Wspomniane koszty mogą przewyższać potencjalne korzyści. W tym przypadku mimo że koszty utrzymania wywołania dynamic_cast są stosunkowo niskie, nie mam zamiaru ich ponosić. Znacznie prościej jest zaimplementować klasę bez listy obiektów Affiliation. W związku z tym postanowiłem zastosować wzorzec projektowy Obiekt null zamiast klasy NoAffiliation. Implementację klasy ServiceChargeTransaction pokazano na listingach 19.17 i 19.18. Rzeczywiście jest ona znacznie prostsza bez pętli wyszukującej obiekty UnionAffiliation. Transakcja pobiera obiekt Employee z bazy danych, rzutuje związany z nim obiekt Affillation do obiektu UnionAffilliation, a następnie dodaje do niego obiekt ServiceCharge. Listing 19.17. ServiceChargeTransaction.h #ifndef SERVICECHARGETRANSACTION_H #define SERVICECHARGETRANSACTION_H #include "Transaction.h" class ServiceChargeTransaction : public Transaction { public: virtual ~ServiceChargeTransaction(); ServiceChargeTransaction(int memberId, long date, double charge); virtual void Execute(); private: int itsMemberId;

ZMIANA DANYCH PRACOWNIKÓW

}; #endif

231

long itsDate; double itsCharge;

Listing 19.18. ServiceChargeTransaction.cpp #include #include #include #include #include

"ServiceChargeTransaction.h" "Employee.h" "ServiceCharge.h" "PayrollDatabase.h" "UnionAffiliation.h"

extern PayrollDatabase GpayrollDatabase; ServiceChargeTransaction::~ServiceChargeTransaction() { } ServiceChargeTransaction:: ServiceChargeTransaction(int memberId, long date, double charge) :itsMemberId(memberId) , itsDate(date) , itsCharge(charge) { } void ServiceChargeTransaction::Execute() { Employee* e = GpayrollDatabase.GetUnionMember(itsMemberId); Affiliation* af = e->GetAffiliation(); if (UnionAffiliation* uaf = dynamic_cast(af)) { uaf->AddServiceCharge(itsDate, itsCharge); } }

Zmiana danych pracowników Na rysunkach 19.13 i 19.14 pokazano statyczną strukturę transakcji zmieniających atrybuty pracownika. Tę strukturę łatwo wywnioskować z przypadku użycia nr 6. Wszystkie transakcje pobierają argument EmpID, dzięki czemu możemy utworzyć klasę bazową o nazwie ChangeEmployeeTransaction. Poniżej tej klasy bazowej są klasy zmieniające pojedyncze atrybuty. Są to między innymi klasy ChangeNameTransaction oraz ChangeAddressTransaction. Transakcje, które zmieniają klasyfikacje, mają wspólny cel w tym sensie, że wszystkie modyfikują to samo pole obiektu Employee. Dzięki temu można je pogrupować za pomocą abstrakcyjnej klasy bazowej ChangeClassificationTransaction. To samo dotyczy transakcji zmieniających sposób wypłaty oraz przynależność związkową. Można to zaobserwować na podstawie struktury transakcji ChangeMethodTransaction i ChangeAffiliationTransaction.

232

ROZDZIAŁ 19. STUDIUM PRZYPADKU: SYSTEM PŁACOWY. IMPLEMENTACJA

Rysunek 19.13. Statyczny model transakcji ChangeEmployeeTransaction

Rysunek 19.14. Statyczny model transakcji ChangeEmployeeTransaction (kontynuacja)

ZMIANA DANYCH PRACOWNIKÓW

233

Na rysunku 19.15 pokazano dynamiczny model wszystkich transakcji modyfikujących dane pracownika. Ponownie można tu zobaczyć zastosowanie wzorca projektowego Metoda szablonowa. W każdym przypadku z bazy danych PayrollDatabase należy pobrać obiekt Employee odpowiadający wartości EmpID. Z tego powodu metoda Execute klasy ChangeEmployeeTransaction implementuje to zachowanie, a następnie wysyła do własnego obiektu komunikat Change. Metoda ta będzie zadeklarowana jako wirtualna i zaimplementowana w klasach pochodnych, jak pokazano na rysunkach 19.16 i 19.17.

Rysunek 19.15. Dynamiczny model transakcji ChangeEmployeeTransaction

Rysunek 19.16. Dynamiczny model transakcji ChangeNameTransaction

Rysunek 19.17. Dynamiczny model transakcji ChangeAddressTransaction

Na listingu 19.19 pokazano przypadek testowy dla transakcji ChangeNameTransaction. Ten przypadek testowy jest bardzo prosty. Wykorzystuje transakcję AddHourlyEmployee w celu stworzenia pracownika o imieniu Bartosz wynagradzanego w systemie godzinowym. Następnie tworzy i wykonuje transakcję ChangeNameTransaction, która powinna zmienić imię tego pracownika na Bogdan. Na koniec pobiera egzemplarz klasy Employee z bazy danych PayrollDatabase i sprawdza, czy imię się zmieniło. Listing 19.19. PayrollTest::TestChangeNameTransaction() void PayrollTest::TestChangeNameTransaction() { cerr << "TestChangeNameTransaction" << endl; int empId = 2; AddHourlyEmployee t(empId, "Bartosz", "Dom", 15.25); t.Execute(); ChangeNameTransaction cnt(empId, "Bogdan"); cnt.Execute(); Employee* e = GpayrollDatabase.GetEmployee(empId); assert(e); assert("Bogdan" == e->GetName()); }

234

ROZDZIAŁ 19. STUDIUM PRZYPADKU: SYSTEM PŁACOWY. IMPLEMENTACJA

Na listingach 19.20 i 19.21 pokazano implementację abstrakcyjnej klasy bazowej ChangeEmployee Transaction. Wyraźnie można zauważyć strukturę wzorca projektowego Metoda szablonowa. Metoda Execute() czyta odpowiedni egzemplarz klasy Employee z bazy PayrollDatabase, a jeśli się to powiedzie, wywołuje czysto wirtualną metodę Change(). Listing 19.20. ChangeEmployeeTransaction.h #ifndef CHANGEEMPLOYEETRANSACTION_H #define CHANGEEMPLOYEETRANSACTION_H #include "Transaction.h" #include "Employee.h" class ChangeEmployeeTransaction : public Transaction { public: ChangeEmployeeTransaction(int empid); virtual ~ChangeEmployeeTransaction(); virtual void Execute(); virtual void Change(Employee&) = 0;

};

private: int itsEmpId;

#endif

Listing 19.21. ChangeEmployeeTransaction.cpp #include "ChangeEmployeeTransaction.h" #include "Employee.h" #include "PayrollDatabase.h" extern PayrollDatabase GpayrollDatabase; ChangeEmployeeTransaction::~ChangeEmployeeTransaction() { } ChangeEmployeeTransaction::ChangeEmployeeTransaction(int empid) : itsEmpId(empid) { } void ChangeEmployeeTransaction::Execute() { Employee* e = GpayrollDatabase.GetEmployee(itsEmpId); if (e != 0) Change(*e); }

Na listingach 19.22 i 19.23 zamieszczono implementację transakcji ChangeNameTransaction. Z łatwością można zauważyć drugą część wzorca projektowego Metoda szablonowa. Metodę Change() zaimplementowano w celu zmiany imienia pracownika reprezentowanego przez argument — obiekt klasy Employee. Struktura klasy ChangeAddressTransaction jest bardzo podobna. Jej implementację pozostawiam czytelnikom jako ćwiczenie do samodzielnego wykonania. Listing 19.22. ChangeEmployeeTransaction.h #ifndef CHANGENAMETRANSACTION_H #define CHANGENAMETRANSACTION_H #include "ChangeEmployeeTransaction.h" #include class ChangeNameTransaction : public ChangeEmployeeTransaction

ZMIANA DANYCH PRACOWNIKÓW

{

235

public: virtual ~ChangeNameTransaction(); ChangeNameTransaction(int empid, string name); virtual void Change(Employee&); private: string itsName;

}; #endif

Listing 19.23. ChangeNameTransaction.cpp #include "ChangeNameTransaction.h" ChangeNameTransaction::~ChangeNameTransaction() { } ChangeNameTransaction::ChangeNameTransaction(int empid, string name) : ChangeEmployeeTransaction(empid) , itsName(name) { } void ChangeNameTransaction::Change(Employee& e) { e.SetName(itsName); }

Zmiana klasyfikacji Na rysunku 19.18 pokazano wizję dynamicznego zachowania transakcji ChangeClassificationTransaction. Ponownie użyto wzorca projektowego Metoda szablonowa. Transakcje muszą stworzyć nowy obiekt PaymentClassification, a następnie przekazać go do obiektu Employee. Można to uzyskać poprzez wysłanie komunikatu GetClassification do obiektu transakcji. Ta abstrakcyjna metoda jest zaimplementowana we wszystkich klasach pochodnych od klasy ChangeClassificationTransaction, jak pokazano na rysunkach od 19.19 do 19.21.

Rysunek 19.18. Dynamiczny model transakcji ChangeClassificationTransaction

236

ROZDZIAŁ 19. STUDIUM PRZYPADKU: SYSTEM PŁACOWY. IMPLEMENTACJA

Rysunek 19.19. Dynamiczny model transakcji ChangeHourlyTransaction

Rysunek 19.20. Dynamiczny model transakcji SalariedTransaction

Rysunek 19.21. Dynamiczny model transakcji ChangeCommissionedTransaction

Na listingu 19.24 pokazano przypadek testowy dla transakcji ChangeHourlyTransaction. W przypadku testowym wykorzystano transakcję AddCommissionedEmployee w celu stworzenia pracownika wynagradzanego w systemie prowizyjnym. Następnie stworzono transakcję ServiceChargeTransaction i ją wykonano. Transakcja pobiera pracownika, sprawdza, czy powiązany z nim obiekt PaymentClassification to obiekt HourlyClassification zawierający właściwą stawkę godzinową oraz czy jego obiekt Payment Schedule to WeeklySchedule. Listing 19.24. PayrollTest::TestChangeHourlyTransaction() void PayrollTest::TestChangeHourlyTransaction() { cerr << "TestChangeHourlyTransaction" << endl; int empId = 3; AddCommissionedEmployee t(empId, "Lance", "Home", 2500, 3.2);

ZMIANA DANYCH PRACOWNIKÓW

}

237

t.Execute(); ChangeHourlyTransaction cht(empId, 27.52); cht.Execute(); Employee* e = GpayrollDatabase.GetEmployee(empId); assert(e); PaymentClassification* pc = e->GetClassification(); assert(pc); HourlyClassification* hc = dynamic_cast(pc); assert(hc); assertEquals(27.52, hc->GetRate(), .001); PaymentSchedule* ps = e->GetSchedule(); WeeklySchedule* ws = dynamic_cast(ps); assert(ws);

Na listingach 19.25 i 19.26 pokazano implementację abstrakcyjnej klasy bazowej ChangeClassifica tionTransaction. Ponownie użyto wzorca projektowego Metoda szablonowa. Metoda Change() wywołuje dwie czysto wirtualne funkcje: GetClassification i GetSchedule. Wykorzystuje wartości zwracane przez te funkcje w celu ustawienia sposobu wynagradzania oraz harmonogramu wypłat pracownika identyfikowanego przez obiekt Employee. Listing 19.25. ChangeClassificationTransaction.h #ifndef CHANGECLASSIFICATIONTRANSACTION_H #define CHANGECLASSIFICATIONTRANSACTION_H #include "ChangeEmployeeTransaction.h" class PaymentClassification; class PaymentSchedule; class ChangeClassificationTransaction : public ChangeEmployeeTransaction { public: virtual ~ChangeClassificationTransaction(); ChangeClassificationTransaction(int empid); virtual void Change(Employee&); virtual PaymentClassification* GetClassification() const = 0; virtual PaymentSchedule* GetSchedule() const = 0; }; #endif

Listing 19.26. ChangeClassificationTransaction.cpp #include "ChangeClassificationTransaction.h" ChangeClassificationTransaction::~ChangeClassificationTransaction() { } ChangeClassificationTransaction::ChangeClassificationTransaction(int empid) : ChangeEmployeeTransaction(empid) { } void ChangeClassificationTransaction::Change(Employee& e) { e.SetClassification(GetClassification()); e.SetSchedule(GetSchedule()); }

238

ROZDZIAŁ 19. STUDIUM PRZYPADKU: SYSTEM PŁACOWY. IMPLEMENTACJA

Na listingach 19.27 i 19.28 pokazano implementację klasy ChangeHourlyTransaction. Ta klasa uzupełnia wzorzec projektowy Metoda szablonowa poprzez zaimplementowanie metod GetClassification() i GetSchedule() odziedziczonych z klasy ChangeClassificationTransaction. Implementuje metodę GetClassification(), która zwraca nowo utworzony obiekt HourlyClassification. Implementuje metodę GetSchedule(), która zwraca nowo utworzony obiekt WeeklySchedule. Listing 19.27. ChangeHourlyTransaction.h #ifndef CHANGEHOURLYTRANSACTION_H #define CHANGEHOURLYTRANSACTION_H #include "ChangeClassificationTransaction.h" class ChangeHourlyTransaction : public ChangeClassificationTransaction { public: virtual ~ChangeHourlyTransaction(); ChangeHourlyTransaction(int empid, double hourlyRate); virtual PaymentSchedule* GetSchedule() const; virtual PaymentClassification* GetClassification() const; private: double itsHourlyRate;

}; #endif

Listing 19.28. ChangeHourlyTransaction.cpp #include "ChangeHourlyTransaction.h" #include "WeeklySchedule.h" #include "HourlyClassification.h" ChangeHourlyTransaction::~ChangeHourlyTransaction() { } ChangeHourlyTransaction::ChangeHourlyTransaction(int empid, double hourlyRate) : ChangeClassificationTransaction(empid) , itsHourlyRate(hourlyRate) { } PaymentSchedule* ChangeHourlyTransaction::GetSchedule() const { return new WeeklySchedule(); } PaymentClassification* ChangeHourlyTransaction::GetClassification() const { return new HourlyClassification(itsHourlyRate); }

Zgodnie z tradycją implementację klas ChangeSalariedTransaction oraz ChangeCommissionedTransaction pozostawiam czytelnikom jako ćwiczenie do samodzielnego wykonania. Podobny mechanizm zastosowano w celu implementacji transakcji ChangeMethodTransaction. Wykorzystano abstrakcyjną metodę GetMethod w celu wybrania właściwej pochodnej klasy PaymentMethod. Tę pochodną przekazano następnie do obiektu Employee (patrz rysunki od 19.22 do 19.25).

ZMIANA DANYCH PRACOWNIKÓW

239

Rysunek 19.22. Dynamiczny model transakcji ChangeMethodTransaction

Rysunek 19.23. Dynamiczny model transakcji ChangeDirectTransaction

Rysunek 19.24. Dynamiczny model transakcji ChangeMailTransaction

Rysunek 19.25. Dynamiczny model transakcji ChangeHoldTransaction

Implementacja tych klas okazała się prosta. Zaimplementowanie ich również pozostawiam czytelnikom jako ćwiczenie do samodzielnego wykonania. Na rysunku 19.26 pokazano sposób implementacji transakcji ChangeAffiliationTransaction. Tak jak wcześniej zastosowano wzorzec projektowy Metoda szablonowa w celu wybrania pochodnej klasy Affiliation, którą należy przekazać do obiektu Employee (patrz rysunki od 19.27 do 19.29).

240

ROZDZIAŁ 19. STUDIUM PRZYPADKU: SYSTEM PŁACOWY. IMPLEMENTACJA

Rysunek 19.26. Dynamiczny model transakcji ChangeAffiliationTransaction

Rysunek 19.27. Dynamiczny model transakcji ChangeMemberTransaction

Rysunek 19.28. Dynamiczny model transakcji ChangeUnaffiliatedTransaction

Co ja paliłem? Byłem bardzo zaskoczony, kiedy przystąpiłem do implementacji tego projektu. Przyjrzyjmy się bliżej dynamicznym modelom transakcji dotyczących przynależności do organizacji. Można zaobserwować tu pewien problem. Implementację rozpocząłem od napisania przypadku testowego ChangeMemberTransaction. Ten przypadek testowy zamieszczono na listingu 19.29. Przypadek testowy zaczyna się dość prosto. Tworzy pracownika „Bartosz” wynagradzanego w systemie godzinowym, a następnie wykonuje transakcję ChangeMemberTransaction w celu oznaczenia przynależności tego pracownika do związku zawodowego. Następnie sprawdza, czy istnieje obiekt UnionAffiliation związany z pracownikiem Bartosz oraz czy w obiekcie UnionAffiliation ustawiono prawidłowe wartości składek. Listing 19.29. PayrollTest::TestChangeMemberTransaction() void PayrollTest::TestChangeMemberTransaction() { cerr << "TestChangeMemberTransaction" << endl; int empId = 2; int memberId = 7734; AddHourlyEmployee t(empId, "Bartosz", "Dom", 15.25); t.Execute();

ZMIANA DANYCH PRACOWNIKÓW

}

241

ChangeMemberTransaction cmt(empId, memberId, 99.42); cmt.Execute(); Employee* e = GpayrollDatabase.GetEmployee(empId); assert(e); Affiliation* af = e->GetAffiliation(); assert(af); UnionAffiliation* uf = dynamic_cast(af); assert(uf); assertEquals(99.42, uf->GetDues(), .001); Employee* member = GpayrollDatabase.GetUnionMember(memberId); assert(member); assert(e == member);

Niespodzianka kryje się w kilku ostatnich linijkach tego przypadku testowego. Ten kod zawiera sprawdzenie, czy w bazie PayrollDatabase zarejestrowano przynależność Bartosza do związku zawodowego. W diagramach UML nie ma żadnego elementu, który pozwalałby na uzyskanie takiego potwierdzenia. Diagramy koncentrują się tylko na tym, czy z obiektem Employee powiązano odpowiednią pochodną klasy Affiliation. W ogóle nie zauważyłem na nich żadnego braku. A czy czytelnicy coś zauważyli? Początkowo kodowałem transakcje ściśle według diagramów, a następnie zauważyłem, że test jednostkowy nie przechodzi. Kiedy wystąpił błąd, stało się oczywiste, co zaniedbałem. Czy jednak rozwiązanie tego problemu nie było oczywiste? W jaki sposób doprowadzić do sytuacji, w której przynależność do organizacji rejestruje transakcja ChangeMemberTransaction, natomiast usuwa ją transakcja ChangeUnaffiliatedTransaction? Rozwiązanie polega na dodaniu kolejnej, czysto wirtualnej funkcji do klasy ChangeAffiliationTrans action, o nazwie RecordMembership(Employee*). Funkcję tę zaimplementowano w klasie ChangeMember Transaction w celu powiązania identyfikatora memberId z egzemplarzem klasy Employee. W klasie ChangeUnaffiliatedTransaction metodę tę zaimplementowano w celu usunięcia rekordu opisującego przynależność do związku. Uzyskaną implementację abstrakcyjnej klasy bazowej ChangeClassificationTransaction pokazano na listingach 19.30 i 19.31. Tak jak poprzednio można wyraźnie zauważyć zastosowanie wzorca projektowego Metoda szablonowa. Listing 19.30. ChangeAffiliationTransaction.h #ifndef CHANGEAFFILIATIONTRANSACTION_H #define CHANGEAFFILIATIONTRANSACTION_H #include "ChangeEmployeeTransaction.h" class ChangeAffiliationTransaction: public ChangeEmployeeTransaction { public: virtual ~ChangeAffiliationTransaction(); ChangeAffiliationTransaction(int empid); virtual Affiliation* GetAffiliation() const = 0; virtual void RecordMembership(Employee*) = 0; virtual void Change(Employee&); }; #endif

Listing 19.31. ChangeAffiliationTransaction.cpp #include "ChangeAffiliationTransaction.h" ChangeAffiliationTransaction::~ChangeAffiliationTransaction() { } ChangeAffiliationTransaction::ChangeAffiliationTransaction(int empid)

242

ROZDZIAŁ 19. STUDIUM PRZYPADKU: SYSTEM PŁACOWY. IMPLEMENTACJA

: ChangeEmployeeTransaction(empid) { } void ChangeAffiliationTransaction::Change(Employee& e) { RecordMembership(&e); e.SetAffiliation(GetAffiliation()); }

Na listingach 19.32 i 19.33 zamieszczono implementację klasy ChangeMemberTransaction. Ta implementacja nie jest ani szczególnie skomplikowana, ani interesująca. Z drugiej strony, implementacja klasy ChangeUnaffiliatedTransaction zamieszczona na listingach 19.34 i 19.35 jest odrobinę bardziej znacząca. Funkcja RecordMembership musi zdecydować, czy bieżący pracownik jest członkiem związku zawodowego. Jeśli tak jest, to pobiera wartość identyfikatora memberId z obiektu UnionAffiliation i usuwa rekord opisujący przynależność do związku. Listing 19.32. ChangeMemberTransaction.h #ifndef CHANGEMEMBERTRANSACTION_H #define CHANGEMEMBERTRANSACTION_H #include "ChangeAffiliationTransaction.h" class ChangeMemberTransaction : public ChangeAffiliationTransaction { public: virtual ~ChangeMemberTransaction(); ChangeMemberTransaction(int empid, int memberid, double dues); virtual Affiliation* GetAffiliation() const; virtual void RecordMembership(Employee*); private: int itsMemberId; double itsDues; }; #endif

Listing 19.33. ChangeMemberTransaction.cpp #include "ChangeMemberTransaction.h" #include "UnionAffiliation.h" #include "PayrollDatabase.h" extern PayrollDatabase GpayrollDatabase; ChangeMemberTransaction::~ChangeMemberTransaction() { } ChangeMemberTransaction:: ChangeMemberTransaction(int empid, int memberid, double dues) : ChangeAffiliationTransaction(empid) , itsMemberId(memberid) , itsDues(dues) { } Affiliation* ChangeMemberTransaction::GetAffiliation() const { return new UnionAffiliation(itsMemberId, itsDues); } void ChangeMemberTransaction::RecordMembership(Employee* e) { GpayrollDatabase.AddUnionMember(itsMemberId, e); }

ZMIANA DANYCH PRACOWNIKÓW

243

Listing 19.34. ChangeUnaffiliatedTransaction.h #ifndef CHANGEUNAFFILIATEDTRANSACTION_H #define CHANGEUNAFFILIATEDTRANSACTION_H #include "ChangeAffiliationTransaction.h" class ChangeUnaffiliatedTransaction : public ChangeAffiliationTransaction { public: virtual ~ChangeUnaffiliatedTransaction(); ChangeUnaffiliatedTransaction(int empId); virtual Affiliation* GetAffiliation() const; virtual void RecordMembership(Employee*); }; #endif

Listing 19.35. ChangeUnaffiliatedTransaction.cpp #include #include #include #include

"ChangeUnaffiliatedTransaction.h" "NoAffiliation.h" "UnionAffiliation.h" "PayrollDatabase.h"

extern PayrollDatabase GpayrollDatabase; ChangeUnaffiliatedTransaction::~ChangeUnaffiliatedTransaction() { } ChangeUnaffiliatedTransaction::ChangeUnaffiliatedTransaction(int empId) : ChangeAffiliationTransaction(empId) { } Affiliation* ChangeUnaffiliatedTransaction::GetAffiliation() const { return new NoAffiliation(); } void ChangeUnaffiliatedTransaction::RecordMembership(Employee* e) { Affiliation* af = e->GetAffiliation(); if (UnionAffiliation* uf = dynamic_cast(af)) { int memberId = uf->GetMemberId(); GpayrollDatabase.RemoveUnionMember(memberId); } }

Nie mogę powiedzieć, że jestem bardzo zadowolony z tego projektu. Martwi mnie to, że obiekt ChangeUnaffiliatedTransaction zależy od obiektu UnionAffiliation. Mógłbym rozwiązać ten problem, definiując abstrakcyjne metody RecordMembership i EraseMembership w klasie Affiliation. To jednak wymusiłoby zależność klas UnionAffiliation i NoAffiliation od klasy PayrollDatabase. Takie

rozwiązanie także mnie nie satysfakcjonuje2. Pomimo tych wad implementacja w zaprezentowanej formie jest dość prosta i tylko nieznacznie narusza zasadę OCP. Pozytywnym objawem jest to, że bardzo niewiele modułów w systemie zależy od klasy ChangeUnaffiliatedTransaction, zatem jej dodatkowe zależności nie sprawiają zbyt wielkiego problemu.

2

Do rozwiązania tego problemu mógłbym użyć wzorca projektowego Wizytator (rozdział 28.), ale to byłoby zbyt skomplikowane rozwiązanie.

244

ROZDZIAŁ 19. STUDIUM PRZYPADKU: SYSTEM PŁACOWY. IMPLEMENTACJA

Realizacja wypłat Na koniec nadszedł czas, aby przeanalizować transakcje dotyczące podstawowej funkcjonalności tej aplikacji: transakcji, która instruuje system o realizacji wypłaty dla określonych pracowników. Na rysunku 19.29 zamieszczono statyczną strukturę klasy PaydayTransaction. Rysunki od 19.30 do 19.33 opisują dynamiczne zachowanie.

Rysunek 19.29. Statyczny model transakcji PaydayTransaction

Rysunek 19.30. Dynamiczny model transakcji PaydayTransaction

REALIZACJA WYPŁAT

245

Rysunek 19.31. Dynamiczny model scenariusza „dziś nie ma wypłaty”

Rysunek 19.32. Dynamiczny model scenariusza „dziś jest wypłata”

Rysunek 19.33. Dynamiczny model scenariusza „księgowanie wypłaty”

Te dynamiczne modele wyrażają wiele zachowań polimorficznych. Algorytm wykorzystywany przez komunikat CalculatePay zależy od rodzaju obiektu PaymentClassification powiązanego z obiektem Employee. Algorytm wykorzystywany do określenia tego, czy dzień jest dniem wypłaty, zależy od rodzaju obiektu PaymentSchedule powiązanego z obiektem Employee. Algorytm wykorzystany w celu wysłania wypłaty do obiektu Employee zależy od typu obiektu PaymentMethod. Taki wysoki stopień abstrakcji pozwala na zamknięcie algorytmów dla operacji dodawania nowych rodzajów zatrudnienia, harmonogramów, przynależności do organizacji lub sposobów wypłaty. Algorytmy przedstawione na rysunkach 19.32 i 19.33 wprowadzają pojęcie księgowania wypłaty. Po obliczeniu odpowiedniej kwoty wypłaty i przesłaniu jej do obiektu Employee następuje księgowanie wypłaty — tzn. aktualizacja rekordów reprezentujących wypłaty. Możemy zatem zdefiniować metodę CalculatePay jako mechanizm obliczania wypłaty od ostatniego księgowania do wskazanej daty.

246

ROZDZIAŁ 19. STUDIUM PRZYPADKU: SYSTEM PŁACOWY. IMPLEMENTACJA

Czy chcemy, aby deweloperzy podejmowali decyzje biznesowe? Skąd wzięło się pojęcie księgowania? Z pewnością nie wspominano o nim w historyjkach użytkowników lub przypadkach użycia. Pojęcie to wprowadziłem jako sposób na rozwiązanie problemu, który wcześniej spostrzegłem. Obawiałem się, że metoda Payday może być wywołana wiele razy z tą samą datą albo z datą w tym samym okresie rozliczeniowym. W związku z tym chciałem uzyskać pewność, że żaden pracownik nie otrzyma wynagrodzenia więcej niż raz. Zrobiłem to z własnej inicjatywy, nie pytając o zdanie mojego klienta. To po prostu wydawało się słuszne. W efekcie podjąłem decyzję biznesową. Zdecydowałem, że w wyniku wielu uruchomień programu płacowego powinniśmy uzyskać różne wyniki. Powinienem zapytać mojego klienta lub menedżera projektu o zdanie na ten temat, ponieważ mogli oni mieć bardzo różne pomysły. Z konsultacji z klientem wynika, że pomysł księgowania wypłat nie jest zgodny z jego intencją3. Klient chciałby uruchamiać system płacowy wielokrotnie i weryfikować generowane płace. Jeśli któraś z nich będzie naliczona niepoprawnie, klient chce poprawić odpowiednie informacje i ponownie uruchomić program płacowy. Klient udzielił mi wskazówki, abym nigdy nie uwzględniał kart czasu pracy lub raportów sprzedaży dotyczących dat spoza bieżącego okresu rozliczeniowego. Tak więc pomysł księgowania musi być odrzucony. W pewnym momencie wydawało się, że będzie to dobry pomysł, ale to nie jest to, czego klient oczekuje.

Realizacja wypłat dla pracowników ze stałą pensją Na listingu 19.36 zamieszczono dwa przypadki testowe. Służą one do sprawdzenia, czy pracownik otrzymuje wynagrodzenie we właściwy sposób. Pierwszy przypadek testowy sprawdza, czy pracownik otrzymuje wypłatę ostatniego dnia miesiąca. Drugi test sprawdza, czy pracownik nie otrzymuje wypłaty w innym dniu niż ostatni dzień miesiąca. Listing 19.36. PayrollTest::TestPaySingleSalariedEmployee void PayrollTest::TestPaySingleSalariedEmployee() { cerr << "TestPaySingleSalariedEmployee" << endl; int empId = 1; AddSalariedEmployee t(empId, "Bogdan", "Dom", 1000.00); t.Execute(); Date payDate(11,30,2001); PaydayTransaction pt(payDate); pt.Execute(); Paycheck* pc = pt.GetPaycheck(empId); assert(pc); assert(pc->GetPayDate() == payDate); assertEquals(1000.00, pc->GetGrossPay(), .001); assert("Hold" == pc->GetField("Disposition")); assertEquals(0.0, pc->GetDeductions(), .001); assertEquals(1000.00, pc->GetNetPay(), .001); } void PayrollTest::TestPaySingleSalariedEmployeeOnWrongDate() { cerr << "TestPaySingleSalariedEmployeeWrongDate" << endl; int empId = 1; AddSalariedEmployee t(empId, "Bogdan", "Dom", 1000.00); t.Execute(); Date payDate(11,29,2001); PaydayTransaction pt(payDate); pt.Execute(); Paycheck* pc = pt.GetPaycheck(empId); assert(pc == 0); } 3

Właściwie to ja jestem klientem.

REALIZACJA WYPŁAT

247

Przypomnijmy sobie listing 19.13, na którym zaimplementowałem klasę TimeCard. Użyłem wtedy wartości typu long integer do reprezentowania daty. Teraz pojawiła się realna potrzeba zaimplementowania klasy Date. Pokazane powyżej dwa przypadki testowe nie przejdą, jeśli nie będzie można stwierdzić, czy data wypłaty przypada ostatniego dnia miesiąca. Przypomniałem sobie, że klasę Date zaimplementowałem 10 lat wcześniej na potrzeby kursu C++, na którym wykładałem. W związku z tym przekopałem swoje archiwa i odnalazłem ją na starej maszynie SPARC, która stała gdzieś w kącie4. Przeniosłem ją do mojego środowiska programistycznego i w ciągu kilku minut udało mi się ją skompilować. Wydało mi się to zaskakujące, ponieważ napisałem klasę do pracy w systemie Linux, a teraz użyłem jej w systemie Windows 2000. Było kilka niewielkich błędów do naprawienia i musiałem zastąpić napisaną przeze mnie klasę obsługi łańcuchów znaków klasą String z biblioteki STL, ale to były drobiazgi. Na listingu 19.37 pokazano funkcję Execute() klasy PaydayTransaction. Metoda iteruje po wszystkich obiektach Employee w bazie danych. Dla każdego pracownika jest zadawane pytanie, czy data transakcji jest zgodna z datą wypłaty. Jeśli tak, to tworzony jest nowy czek dla pracownika i wysyłana jest informacja o konieczności wypełnienia właściwych pól. Listing 19.37. PaydayTransaction::Execute() void PaydayTransaction::Execute() { list empIds; GpayrollDatabase.GetAllEmployeeIds(empIds);

}

list::iterator i = empIds.begin(); for (; i != empIds.end(); i++) { int empId = *i; if (Employee* e = GpayrollDatabase.GetEmployee(empId)) { if (e->IsPayDate(itsPayDate)) { Paycheck* pc = new Paycheck(itsPayDate); itsPaychecks[empId] = pc; e->Payday(*pc); } } }

Na listingu 19.38 pokazano fragment klasy MonthlySchedule.cpp. Zwróćmy uwagę, że metodę IsPayDate zaimplementowano tak, żeby zwracała true tylko wtedy, kiedy argument date przypada ostatniego dnia miesiąca. Ten algorytm wyraźnie pokazuje, dlaczego potrzebowałem klasy Date. Wykonanie tego rodzaju prostych obliczeń na datach jest bardzo trudne bez dobrej klasy Date. Listing 19.38. MonthlySchedule.cpp (fragment) namespace { bool IsLastDayOfMonth(const Date& date) { int m1 = date.GetMonth(); int m2 = (date+1).GetMonth(); return (m1 != m2); } } bool MonthlySchedule::IsPayDate(const Date& payDate) const { return IsLastDayOfMonth(payDate); } 4

Oryginalny oma.com. To była stacja SPARC kupiona przeze mnie za 6000 dolarów od firmy, która nabyła ją do realizacji projektu, a następnie z niego zrezygnowała. W 1994 roku to był naprawdę dobry interes. Fakt, że maszyna nadal sobie cicho pracuje w sieci firmy Object Mentor, jest świadectwem tego, jak dobry to sprzęt.

248

ROZDZIAŁ 19. STUDIUM PRZYPADKU: SYSTEM PŁACOWY. IMPLEMENTACJA

Na listingu 19.39 zamieszczono implementację metody Employee::PayDay(). Funkcja ta zawiera implementację ogólnego algorytmu obliczania wynagrodzeń dla wszystkich pracowników. Zwróć uwagę na szczególny sposób wykorzystania wzorca projektowego Strategia. Wszystkie szczegółowe obliczenia przeniesiono do klas strategii: itsClassification, itsAffiliation oraz itsPaymentMethod. Listing 19.39. Employee::PayDay() void Employee::Payday(Paycheck& pc) { double grossPay = itsClassification->CalculatePay(pc); double deductions = itsAffiliation->CalculateDeductions(pc); double netPay = grossPay - deductions; pc.SetGrossPay(grossPay); pc.SetDeductions(deductions); pc.SetNetPay(netPay); itsPaymentMethod->Pay(pc); }

Realizacja wypłat dla pracowników zatrudnionych w systemie godzinowym Realizacja wypłat dla pracowników zatrudnionych w systemie godzinowym jest dobrym przykładem przyrostowego charakteru projektowania zgodnego z metodologią „najpierw test”. Zaczynamy od bardzo prostych przypadków testowych, a następnie przechodzimy do bardziej złożonych. Poniżej zaprezentuję przypadki testowe, a następnie pokażę kod produkcyjny, który powstał na ich podstawie. Najprostszy przypadek testowy znajduje się na listingu 19.40. Dodajemy pracownika wynagradzanego w systemie godzinowym, a następnie realizujemy dla niego wypłatę. Ponieważ nie zarejestrowano żadnych kart czasu pracy, oczekujemy, że na czeku będzie zerowa wartość. Funkcja narzędziowa ValidateHourlyPaycheck reprezentuje kod po przeprowadzonej później refaktoryzacji. Początkowo ten kod był umieszczony wewnątrz funkcji testowej. Ten przypadek testowy przechodzi bez wprowadzania żadnych zmian w pozostałej części kodu. Listing 19.40. TestPaySingleHourlyEmployeeNoTimeCards void PayrollTest::TestPaySingleHourlyEmployeeNoTimeCards() { cerr << "TestPaySingleHourlyEmployeeNoTimeCards" << endl; int empId = 2; AddHourlyEmployee t(empId, "Barosz", "Dom", 15.25); t.Execute(); Date payDate(11,9,2001); // Piątek PaydayTransaction pt(payDate); pt.Execute(); ValidateHourlyPaycheck(pt, empId, payDate, 0.0); } void PayrollTest::ValidateHourlyPaycheck(PaydayTransaction& pt, int empid, const Date& payDate, double pay) { Paycheck* pc = pt.GetPaycheck(empid); assert(pc); assert(pc->GetPayDate() == payDate); assertEquals(pay, pc->GetGrossPay(), .001); assert("Hold" == pc->GetField("Disposition")); assertEquals(0.0, pc->GetDeductions(), .001); assertEquals(pay, pc->GetNetPay(), .001); }

Na listingu 19.41 pokazano dwa przypadki testowe. Pierwszy test pokazuje, czy można zapłacić pracownikowi po dodaniu jednej karty czasu pracy. Drugi test sprawdza, czy można zapłacić za nadgodziny w przypadku karty, na której zarejestrowano więcej niż 8 godzin. Oczywiście nie napisałem tych dwóch przypadków testowych w tym samym czasie. Napisałem pierwszy i doprowadziłem do tego, że zaczął przechodzić, a potem napisałem drugi.

REALIZACJA WYPŁAT

249

Listing 19.41. TestPaySingleHourlyEmployeeOneTimeCard void PayrollTest::TestPaySingleHourlyEmployeeOneTimeCard() { cerr << "TestPaySingleHourlyEmployeeOneTimeCard" << endl; int empId = 2; AddHourlyEmployee t(empId, "Bartosz", "Dom", 15.25); t.Execute(); Date payDate(11,9,2001); // Piątek

}

TimeCardTransaction tc(payDate, 2.0, empId); tc.Execute(); PaydayTransaction pt(payDate); pt.Execute(); ValidateHourlyPaycheck(pt, empId, payDate, 30.5);

void PayrollTest::TestPaySingleHourlyEmployeeOvertimeOneTimeCard() { cerr << "TestPaySingleHourlyEmployeeOvertimeOneTimeCard" << endl; int empId = 2; AddHourlyEmployee t(empId, "Bartosz", "Dom", 15.25); t.Execute(); Date payDate(11,9,2001); // Piątek

}

TimeCardTransaction tc(payDate, 9.0, empId); tc.Execute(); PaydayTransaction pt(payDate); pt.Execute(); ValidateHourlyPaycheck(pt, empId, payDate, (8 + 1.5) * 15.25);

Doprowadzenie kodu do zgodności z pierwszym przypadkiem testowym sprowadzało się do modyfikacji metody HourlyClassification::CalculatePay w taki sposób, aby przeglądała w pętli karty czasowe pracownika, dodawała godziny, a następnie mnożyła przez stawkę godzinową. Aby kod był zgodny z drugim przypadkiem testowym, musiałem zrefaktoryzować funkcję w taki sposób, żeby obliczała wynagrodzenie za godziny z normalnego czasu pracy oraz godziny nadliczbowe. Przypadek testowy z listingu 19.42 pokazuje, że pracownikom wynagradzanym w systemie godzinowym nie realizujemy wypłaty, jeśli obiekt klasy PaydayTransaction nie został stworzony z datą reprezentującą piątek. Listing 19.42. TestPaySingleHourlyEmployeeOnWrongDate void PayrollTest::TestPaySingleHourlyEmployeeOnWrongDate() { cerr << "TestPaySingleHourlyEmployeeOnWrongDate" << endl; int empId = 2; AddHourlyEmployee t(empId, "Bartosz", "Dom", 15.25); t.Execute(); Date payDate(11,8,2001); // Czwartek TimeCardTransaction tc(payDate, 9.0, empId); tc.Execute(); PaydayTransaction pt(payDate); pt.Execute();

}

Paycheck* pc = pt.GetPaycheck(empId); assert(pc == 0);

Na listingu 19.43 pokazano przypadek testowy, który sprawdza, czy możemy obliczyć wynagrodzenie dla pracownika, dla którego zarejestrowano więcej niż jedną kartę czasu pracy.

250

ROZDZIAŁ 19. STUDIUM PRZYPADKU: SYSTEM PŁACOWY. IMPLEMENTACJA

Listing 19.43. TestPaySingleHourlyEmployeeTwoTimeCards void PayrollTest::TestPaySingleHourlyEmployeeTwoTimeCards() { cerr << "TestPaySingleHourlyEmployeeTwoTimeCards" << endl; int empId = 2; AddHourlyEmployee t(empId, "Bartosz", "Dom", 15.25); t.Execute(); Date payDate(11,9,2001); // Piątek

}

TimeCardTransaction tc(payDate, 2.0, empId); tc.Execute(); TimeCardTransaction tc2(Date(11,8,2001), 5.0, empId); tc2.Execute(); PaydayTransaction pt(payDate); pt.Execute(); ValidateHourlyPaycheck(pt, empId, payDate, 7*15.25);

Na koniec przypadek testowy z listingu 19.44 dowodzi, że wypłatę realizujemy tylko dla kart czasu pracy z bieżącego okresu rozliczeniowego. Karty czasu pracy z pozostałych okresów są ignorowane. Listing 19.44. TestPaySingleHourlyEmployeeWithTimeCardsSpanningTwoPayPeriods void PayrollTest:: TestPaySingleHourlyEmployeeWithTimeCardsSpanningTwoPayPeriods() { cerr << "TestPaySingleHourlyEmployeeWithTimeCards" "SpanningTwoPayPeriods" << endl; int empId = 2; AddHourlyEmployee t(empId, "Bartosz", "Dom", 15.25); t.Execute(); Date payDate(11,9,2001); // Piątek Date dateInPreviousPayPeriod(11,2,2001);

}

TimeCardTransaction tc(payDate, 2.0, empId); tc.Execute(); TimeCardTransaction tc2(dateInPreviousPayPeriod, 5.0, empId); tc2.Execute(); PaydayTransaction pt(payDate); pt.Execute(); ValidateHourlyPaycheck(pt, empId, payDate, 2*15.25);

Kod, który spełnił te wszystkie testy, był tworzony przyrostowo — po jednym przypadku testowym. Struktura widoczna w kodzie ewoluowała od testu do testu. Na listingu 19.45 pokazano właściwe fragmenty klasy HourlyClassification.cpp. W istocie kod przetwarza w pętli karty czasu pracy. Dla każdej karty czasu pracy sprawdzamy, czy przypada okres wypłaty. Jeśli tak, to obliczamy uposażenie, które wynika z danej karty. Listing 19.45. HourlyClassification.cpp (fragment) double HourlyClassification::CalculatePay(Paycheck& pc) const { double totalPay = 0; Date payPeriod = pc.GetPayDate(); map::const_iterator i; for (i=itsTimeCards.begin(); i != itsTimeCards.end(); i++) { TimeCard * tc = (*i).second; if (IsInPayPeriod(tc, payPeriod)) totalPay += CalculatePayForTimeCard(tc); } return totalPay; } bool HourlyClassification::IsInPayPeriod(TimeCard* tc, const Date& payPeriod) const

REALIZACJA WYPŁAT

{

251

Date payPeriodEndDate = payPeriod; Date payPeriodStartDate = payPeriod - 5; Date timeCardDate = tc->GetDate(); return (timeCardDate >= payPeriodStartDate) && (timeCardDate <= payPeriodEndDate);

} double HourlyClassification:: CalculatePayForTimeCard(TimeCard* tc) const { double hours = tc->GetHours(); double overtime = max(0.0, hours - 8.0); double straightTime = hours - overtime; return straightTime * itsRate + overtime * itsRate * 1.5; }

Na listingu 19.46 widać, że klasa WeeklySchedule realizuje wypłaty tylko w piątki. Listing 19.46. WeeklySchedule::IsPayDate bool WeeklySchedule::IsPayDate(const Date& theDate) const { return theDate.GetDayOfWeek() == Date::friday; }

Implementację mechanizmu obliczania wynagrodzeń dla pracowników otrzymujących prowizję pozostawiłem czytelnikom do samodzielnego wykonania. Nie powinna ona sprawić większych trudności. Nieco ciekawszym ćwiczeniem mogłoby być opracowanie kodu, który dopuszcza dostarczanie kart czasu pracy w weekendy. W takim przypadku należy odpowiednio wyliczyć nadgodziny.

Okresy rozliczeniowe: problem projektowy Nadszedł właściwy czas na zaimplementowanie mechanizmu obliczania składek w związku z przynależnością do związków zawodowych i innych organizacji. Wymyśliłem przypadek testowy, który dodaje pracownika wynagradzanego w systemie godzinowym, przekształca go na członka związku zawodowego, a następnie sprawdza, czy z uposażenia pracownika zostały potrącone składki. Ten przypadek testowy zapisałem na listingu 19.47. Listing 19.47. PayrollTest::TestSalariedUnionMemberDues void PayrollTest::TestSalariedUnionMemberDues() { cerr << "TestSalariedUnionMemberDues" << endl; int empId = 1; AddSalariedEmployee t(empId, "Bogdan", "Dom", 1000.00); t.Execute(); int memberId = 7734; ChangeMemberTransaction cmt(empId, memberId, 9.42); cmt.Execute(); Date payDate(11,30,2001); PaydayTransaction pt(payDate); pt.Execute(); ValidatePaycheck(pt, empId, payDate, 1000.0 - ??? ); }

Zwróćmy uwagę na trzy znaki zapytania (???) w ostatniej linijce przypadku testowego. Co tam powinno się znaleźć? Z historyjek użytkowników wynika, że składki na związki zawodowe są naliczane co tydzień, natomiast pracownicy wynagradzani w systemie godzinowym otrzymują uposażenie co miesiąc. Ile tygodni mamy w każdym miesiącu? Czy powinienem po prostu pomnożyć wysokość składki przez cztery? To nie jest zbyt dokładne. Chyba należałoby zapytać klienta5. 5

Bob ponownie rozmawia sam ze sobą. Warto odwiedzić stronę www.google.com/groups i poszukać frazy Schizophrenic Robert Martin .

252

ROZDZIAŁ 19. STUDIUM PRZYPADKU: SYSTEM PŁACOWY. IMPLEMENTACJA

Klient poinformował mnie, że składki na związki zawodowe powinny być naliczane co piątek. Trzeba zatem zliczyć piątki w okresie rozliczeniowym, a następnie pomnożyć przez wysokość składki tygodniowej. W listopadzie 2001 roku, miesiącu, dla którego napisano przypadek testowy, jest pięć piątków. Z tego powodu mogę odpowiednio zmodyfikować przypadek testowy. Ze względu na konieczność zliczania piątków w okresie rozliczeniowym potrzebuję początkowej i końcowej daty tego okresu. Te obliczenia wykonywałem wcześniej w funkcji IsInPayPeriod na listingu 19.45 (prawdopodobnie wykonałeś podobną pracę na potrzeby klasy CommissionedClassification). Ta funkcja została użyta w metodzie CalculatePay obiektu HourlyClassification, aby w obliczaniu uposażenia uwzględniać tylko te karty czasu pracy, które należą do okresu rozliczeniowego. Wydaje się, że obiekt UnionAffiliation także będzie musiał wywoływać tę funkcję. Zastanówmy się jednak chwilę. Co ta funkcja robi w klasie HourlyClassification? Ustaliliśmy już, że związek pomiędzy harmonogramem wypłat a klasyfikacją płatności jest przypadkowy. Funkcja, która wyznacza okres rozliczeniowy, powinna należeć do klasy PaymentSchedule , a nie do klasy PaymentClassification . Interesujące, że diagramy UML nie pomogły nam w wykryciu tego problemu. Problem uwidocznił się dopiero wtedy, gdy zacząłem opracowywać przypadki testowe dla klasy UnionAffiliation. To kolejny przykład sytuacji, w której kod źródłowy dostarcza niezbędnych informacji do projektu. Diagramy UML mogą się przydać, ale poleganie na nich bez weryfikowania z kodem źródłowym może być ryzykowne. A zatem jak wyznaczyć okresy rozliczeniowe z hierarchii PaymentSchedule, aby skorzystać z nich w hierarchiach PaymentClassification i Affiliation? Te hierarchie nic o sobie wzajemnie nie wiedzą. Moglibyśmy umieścić daty okresów rozliczeniowych w obiekcie Paycheck. Na razie w obiekcie Paycheck jest zapisana tylko data końcowa okresu rozliczeniowego. Powinniśmy umieścić tam także datę początkową. Na listingu 19.48 pokazano zmianę wprowadzoną w metodzie PaydayTransaction::Execute(). Zwróćmy uwagę, że w momencie tworzenia obiektu Paycheck przekazujemy do niego zarówno datę początkową, jak i datę końcową okresu rozliczeniowego. Jeśli przejdziemy do listingu 19.55, zauważymy, że za obliczenie obu dat odpowiada klasa PaymentSchedule. Zmiany w klasie Paycheck są dość oczywiste. Listing 19.48. PaydayTransaction::Execute() void PaydayTransaction::Execute() { list empIds; GpayrollDatabase.GetAllEmployeeIds(empIds);

}

list::iterator i = empIds.begin(); for (; i != empIds.end(); i++) { int empId = *i; if (Employee* e = GpayrollDatabase.GetEmployee(empId)) { if (e->IsPayDate(itsPayDate)) { Paycheck* pc = new Paycheck(e->GetPayPeriodStartDate(itsPayDate), itsPayDate); itsPaychecks[empId] = pc; e->Payday(*pc); } } }

Dwie funkcje w klasach HourlyClassification i CommissionedClassification odpowiedzialne za sprawdzenie, czy obiekty TimeCard i SalesReceipt mieszczą się w okresie obliczeniowym, zostały scalone i przeniesione do klasy bazowej PaymentClassification (patrz listing 19.49).

REALIZACJA WYPŁAT

253

Listing 19.49. PaymentClassification::IsInPayPeriod(...) bool PaymentClassification:: IsInPayPeriod(const Date& theDate, const Paycheck& pc) const { Date payPeriodEndDate = pc.GetPayPeriodEndDate(); Date payPeriodStartDate = pc.GetPayPeriodStartDate(); return (theDate >= payPeriodStartDate) && (theDate <= payPeriodEndDate); }

Teraz jesteśmy gotowi do obliczenia składek na rzecz związków zawodowych w metodzie Union Affilliation::CalculateDeductions. Sposób wykonania tego obliczenia zaprezentowano na listingu 19.50. Dwie daty definiujące okres rozliczeniowy zostały wyodrębnione z obiektu Paycheck i przekazane do funkcji narzędziowej obliczającej liczbę piątków pomiędzy dwiema datami. W celu obliczenia należnych składek za okres rozliczeniowy liczba piątków została pomnożona przez kwotę należnej składki. Listing 19.50. UnionAffiliation::CalculateDeductions() namespace { int NumberOfFridaysInPayPeriod(const Date& payPeriodStart, const Date& payPeriodEnd) { int fridays = 0; for (Date day = payPeriodStart; day <= payPeriodEnd; day++) { if (day.GetDayOfWeek() == Date::friday) fridays++; } return fridays; } } double UnionAffiliation:: CalculateDeductions(Paycheck& pc) const { double totalDues = 0;

}

int fridays = NumberOfFridaysInPayPeriod(pc.GetPayPeriodStartDate(), pc.GetPayPeriodEndDate()); totalDues = itsDues * fridays; return totalDues;

Ostatnie dwa przypadki testowe dotyczą potrąceń opłat związkowych. Pierwszy przypadek testowy zamieszczono na listingu 19.51. Ten kod sprawdza, czy właściwie potrącono opłaty związkowe. Listing 19.51. PayrollTest::TestHourlyUnionMemberServiceCharge void PayrollTest::TestHourlyUnionMemberServiceCharge() { cerr << "TestHourlyUnionMemberServiceCharge" << endl; int empId = 1; AddHourlyEmployee t(empId, "Bartosz", "Dom", 15.24); t.Execute(); int memberId = 7734; ChangeMemberTransaction cmt(empId, memberId, 9.42); cmt.Execute(); Date payDate(11,9,2001); ServiceChargeTransaction sct(memberId, payDate, 19.42); sct.Execute(); TimeCardTransaction tct(payDate, 8.0, empId); tct.Execute();

254

}

ROZDZIAŁ 19. STUDIUM PRZYPADKU: SYSTEM PŁACOWY. IMPLEMENTACJA

PaydayTransaction pt(payDate); pt.Execute(); Paycheck* pc = pt.GetPaycheck(empId); assert(pc); assert(pc->GetPayPeriodEndDate() == payDate); assertEquals(8*15.24, pc->GetGrossPay(), .001); assert("Hold" == pc->GetField("Disposition")); assertEquals(9.42 + 19.42, pc->GetDeductions(), .001); assertEquals((8*15.24)-(9.42 + 19.42), pc->GetNetPay(), .001);

Drugi przypadek testowy sprawił mi pewien problem. Można go zobaczyć na listingu 19.52. Ten przypadek testowy sprawdza, czy nie są potrącane opłaty związkowe z datą spoza okresu rozliczeniowego. Listing 19.52. PayrollTest::TestServiceChargesSpanningMultiplePayPeriods void PayrollTest:: TestServiceChargesSpanningMultiplePayPeriods() { cerr << "TestServiceChargesSpanningMultiplePayPeriods" << endl; int empId = 1; AddHourlyEmployee t(empId, "Bartosz", "Dom", 15.24); t.Execute(); int memberId = 7734; ChangeMemberTransaction cmt(empId, memberId, 9.42); cmt.Execute(); Date earlyDate(11,2,2001); // poprzedni piątek Date payDate(11,9,2001); Date lateDate(11,16,2001); // następny piątek ServiceChargeTransaction sct(memberId, payDate, 19.42); sct.Execute(); ServiceChargeTransaction sctEarly(memberId, earlyDate, 100.00); sctEarly.Execute(); ServiceChargeTransaction sctLate(memberId, lateDate, 200.00); sctLate.Execute(); TimeCardTransaction tct(payDate, 8.0, empId); tct.Execute(); PaydayTransaction pt(payDate); pt.Execute(); Paycheck* pc = pt.GetPaycheck(empId); assert(pc); assert(pc->GetPayPeriodEndDate() == payDate); assertEquals(8*15.24, pc->GetGrossPay(), .001); assert("Hold" == pc->GetField("Disposition")); assertEquals(9.42 + 19.42, pc->GetDeductions(), .001); assertEquals((8*15.24)-(9.42 + 19.42), pc->GetNetPay(), .001); }

W celu zaimplementowania kodu, który spełnia powyższy przypadek testowy, chciałem, aby metoda UnionAffiliation::CalculateDeductions wywoływała metodę IsInPayPeriod. Niestety, metoda IsInPayPeriod została umieszczona w klasie PaymentClassification (patrz listing 19.49). Umieszczenie jej w tym miejscu było wygodne, ponieważ była ona wykorzystywana przez pochodne klasy Payment Classification. Teraz jednak potrzebują jej także inne klasy. W związku z tym przeniosłem tę funkcję do klasy Date. W końcu ta funkcja po prostu ustala, czy określona data znajduje się pomiędzy dwiema innymi datami (patrz listing 19.53). Listing 19.53. Date::IsBetween static bool IsBetween(const Date& const Date& const Date& { return (theDate >= startDate) }

theDate, startDate, endDate) && (theDate <= endDate);

REALIZACJA WYPŁAT

255

Teraz możemy dokończyć funkcję UnionAffiliation::CalculateDeductions. To zadanie pozostawiam czytelnikom jako ćwiczenie do samodzielnego wykonania. Na listingach 19.54 i 19.55 pokazano implementację klasy Employee. Listing 19.54. Employee.h #ifndef EMPLOYEE_H #define EMPLOYEE_H #include class class class class class class

PaymentSchedule; PaymentClassification; PaymentMethod; Affiliation; Paycheck; Date;

class Employee { public: virtual ~Employee(); Employee(int empid, string name, string address); void SetName(string name); void SetAddress(string address); void SetClassification(PaymentClassification*); void SetMethod(PaymentMethod*); void SetSchedule(PaymentSchedule*); void SetAffiliation(Affiliation*); int GetEmpid() const {return itsEmpid;} string GetName() const {return itsName;} string GetAddress() const {return itsAddress;} PaymentMethod* GetMethod() {return itsPaymentMethod;} PaymentClassification* GetClassification() {return itsClassification;} PaymentSchedule* GetSchedule() {return itsSchedule;} Affiliation* GetAffiliation() {return itsAffiliation;} void Payday(Paycheck&); bool IsPayDate(const Date& payDate) const; Date GetPayPeriodStartDate(const Date& payPeriodEndDate) const; private: int itsEmpid; string itsName; string itsAddress; PaymentClassification* itsClassification; PaymentSchedule* itsSchedule; PaymentMethod* itsPaymentMethod; Affiliation* itsAffiliation;

}; #endif

Listing 19.55. Employee.cpp #include #include #include #include #include #include

"Employee.h" "NoAffiliation.h" "PaymentClassification.h" "PaymentSchedule.h" "PaymentMethod.h" "Paycheck.h"

Employee::~Employee() { delete itsClassification; delete itsSchedule; delete itsPaymentMethod;

256

ROZDZIAŁ 19. STUDIUM PRZYPADKU: SYSTEM PŁACOWY. IMPLEMENTACJA

} Employee::Employee(int empid, string name, string address) : itsEmpid(empid) , itsName(name) , itsAddress(address) , itsAffiliation(new NoAffiliation()) , itsClassification(0) , itsSchedule(0) , itsPaymentMethod(0) { } void Employee::SetName(string name) { itsName = name; } void Employee::SetAddress(string address) { itsAddress = address; } void Employee::SetClassification(PaymentClassification* pc) { delete itsClassification; itsClassification = pc; } void Employee::SetSchedule(PaymentSchedule* ps) { delete itsSchedule; itsSchedule = ps; } void Employee::SetMethod(PaymentMethod* pm) { delete itsPaymentMethod; itsPaymentMethod = pm; } void Employee::SetAffiliation(Affiliation* af) { delete itsAffiliation; itsAffiliation = af; } bool Employee::IsPayDate(const Date& payDate) const { return itsSchedule->IsPayDate(payDate); } Date Employee::GetPayPeriodStartDate(const Date& payPeriodEndDate) const { return itsSchedule->GetPayPeriodStartDate(payPeriodEndDate); } void Employee::Payday(Paycheck& pc) { Date payDate = pc.GetPayPeriodEndDate(); double grossPay = itsClassification->CalculatePay(pc); double deductions = itsAffiliation->CalculateDeductions(pc); double netPay = grossPay - deductions; pc.SetGrossPay(grossPay); pc.SetDeductions(deductions); pc.SetNetPay(netPay); itsPaymentMethod->Pay(pc); }

BAZA DANYCH

257

Program główny Program główny systemu płacowego możemy teraz wyrazić w postaci pętli, która analizuje transakcje pochodzące z określonego źródła, a następnie je wykonuje. Statyczny i dynamiczny model programu głównego pokazano na rysunkach 19.34 i 19.35. Idea jest prosta. Klasa PayrollApplication przetwarza zadania w pętli — naprzemiennie żąda transakcji z obiektu TransactionSource oraz żąda od uzyskanych obiektów Transaction wykonania metody Execute. Zwróćmy uwagę na różnice w porównaniu z diagramem z rysunku 19.1. Różnice te prezentują zmianę naszego podejścia w kierunku bardziej abstrakcyjnego mechanizmu.

Rysunek 19.34. Statyczny model programu głównego

Rysunek 19.35. Dynamiczny model programu głównego TransactionSource jest klasą abstrakcyjną, którą można zaimplementować na kilka sposobów. Na statycznym diagramie można zobaczyć klasę pochodną o nazwie TextParserTransactionSource. Jej zadanie polega na odczytaniu wejściowego strumienia tekstowego i analizowaniu transakcji tak, jak opisano w przypadkach użycia. Ten obiekt następnie tworzy właściwe obiekty Transaction i przesyła je do obiektu PayrollApplication. Dzięki oddzieleniu interfejsu od implementacji w klasie TransactionSource źródło transakcji mogło pozostać abstrakcyjne. Na przykład z łatwością można wykorzystać interfejs, aby aplikacja PayrollAppli cation mogła pracować z klasami GUITransactionSource lub RemoteTransactionSource.

Baza danych Teraz gdy dokonaliśmy analizy aplikacji, zaprojektowaliśmy i (w większości) zaimplementowaliśmy wszystkie zadania zaplanowane do zrealizowania w tej iteracji, możemy rozważyć rolę bazy danych. Klasa PayrollDatabase z pewnością hermetyzuje pewien rodzaj utrwalania danych. Obiekty zawarte w obiekcie PayrollDatabase muszą istnieć dłużej, niż trwa konkretne wykonanie aplikacji. W jaki sposób można to zaimplementować? Z pewnością tymczasowy mechanizm stosowany w przypadkach użycia nie jest wystarczający dla rzeczywistego systemu. Mamy do dyspozycji kilka możliwości.

258

ROZDZIAŁ 19. STUDIUM PRZYPADKU: SYSTEM PŁACOWY. IMPLEMENTACJA

Możemy zaimplementować klasę PayrollDatabase z wykorzystaniem obiektowego systemu zarządzania bazą danych (OODBMS). Takie rozwiązanie pozwoliłoby na rezydowanie rzeczywistych obiektów w trwałej pamięci bazy danych. Dla projektantów takie rozwiązanie wiązałoby się z niewielką ilością dodatkowej pracy, ponieważ zastosowanie systemu OODBMS nie wprowadziłoby zbyt wielu nowych elementów do projektu. Jedną z największych zalet systemów OODBMS jest to, że mają one niewielki wpływ na model obiektowy aplikacji lub wcale nie wywierają wpływu na ten model. Z punktu widzenia projektu baza danych właściwie nie istnieje6. Alternatywnym rozwiązaniem mogłoby być skorzystanie z prostego pliku tekstowego do rejestrowania danych. Po zainicjowaniu obiekt PayrollDatabase mógłby odczytać zawartość tego pliku i stworzyć właściwe obiekty w pamięci. Na koniec działania programu obiekt PayrollDatabase mógłby zapisać nową wersję pliku tekstowego. Oczywiście ta opcja nie byłaby wystarczająca dla firmy zatrudniającej setki tysięcy pracowników lub dla takiej, która chciałaby mieć współbieżny dostęp w czasie rzeczywistym do swojej bazy danych płacowych. Jednak takie rozwiązanie mogłoby wystarczyć w przypadku mniejszej firmy i z całą pewnością mogłoby być zastosowane jako mechanizm testowania pozostałych klas aplikacji bez inwestowania w wielki system bazy danych. Jeszcze inną opcją mogłoby być wykorzystanie do implementacji obiektu PayrollDatabase relacyjnego systemu zarządzania bazą danych (RDBMS). W implementacji obiektu PayrollDatabase można by wtedy wykonać odpowiednie zapytania do systemu RDMBS w celu tymczasowego stworzenia potrzebnych obiektów w pamięci. Chodzi o to, że z punktu widzenia aplikacji bazy danych są po prostu mechanizmem zarządzania pamięcią trwałą. Zazwyczaj nie powinny być one rozpatrywane jako główny czynnik projektu i implementacji. Jak pokazaliśmy w tym przykładzie, decyzję o zastosowaniu konkretnego systemu bazy danych można zostawić na koniec i potraktować jako szczegół implementacji7. W ten sposób możemy odłożyć podjęcie decyzji o zastosowaniu konkretnej implementacji mechanizmów utrwalania. Nie musimy też od razu decydować się na stosowanie konkretnych mechanizmów do testowania pozostałej części aplikacji. Nie wiążemy się również z żadną konkretną technologią czy produktem bazodanowym. Mamy swobodę wyboru potrzebnej bazy danych na podstawie pozostałej części projektu oraz w razie potrzeby zachowujemy swobodę zmiany lub zastąpienia określonego produktu bazy danych w przyszłości.

Podsumowanie projektu systemu płacowego Za pomocą około 50 diagramów i 3300 wierszy kodu pokazaliśmy projekt i implementację jednej iteracji aplikacji płacowej. W projekcie wykorzystywaliśmy wiele abstrakcji i często stosowaliśmy polimorfizm. W efekcie duża część tego projektu jest zamknięta dla zmian w polityce wypłacania uposażeń. Na przykład aplikację można zmodyfikować tak, by obsługiwała pracowników otrzymujących wynagrodzenie co kwartał. Wystarczyłoby wykorzystać mechanizmy wynagrodzeń dla pracowników otrzymujących pensję i dodać nowy harmonogram. Taka zmiana wymagałaby dodania pewnych elementów do projektu, ale niewielka część istniejącego projektu i kodu uległaby zmianom.

6

To podejście jest dość optymistyczne. W prostej aplikacji, takiej jak przykładowy system płacowy, zastosowanie systemu OODBMS miałoby bardzo niewielki wpływ na projekt programu. W miarę jak aplikacja staje się coraz bardziej skomplikowana, wpływ zastosowania systemu OODBMS na projekt programu wzrasta. Pomimo wszystko wpływ systemu OODBMS na projekt programu jest znacznie mniejszy niż wpływ zastosowania systemu RDBMS.

7

Czasami charakter bazy danych jest jednym z wymagań stawianych aplikacji. Systemy RDBMS umożliwiają tworzenie złożonych zapytań i raportów, które mogą być wymienione jako wymagania aplikacji. Jednak nawet wtedy, gdy takie wymagania są formułowane jawnie, projektanci powinni oddzielić projekt aplikacji od projektu baz danych. Projekt aplikacji nie powinien zależeć od żadnego konkretnego rodzaju bazy danych.

BIBLIOGRAFIA

259

Podczas tego procesu rzadko zastanawialiśmy się nad tym, czy przeprowadzamy analizę, wykonujemy projekt, czy implementację. Zamiast tego koncentrowaliśmy się na kwestiach przejrzystości i kompletności. W miarę możliwości staraliśmy się wyszukiwać potrzebne abstrakcje. W efekcie udało się opracować dobry wyjściowy projekt aplikacji płacowej oraz rdzeń klas, które mogą być użyte do rozwiązywania podobnych problemów.

Historia Diagramy zamieszczone w tym rozdziale zostały stworzone na podstawie diagramów Boocha z odpowiedniego rozdziału książki z 1995 roku zatytułowanej Designing Object-Oriented C++ Applications using the Booch Method. Diagramy te stworzyłem w 1994 roku. Podczas ich tworzenia napisałem też część kodu, który je implementuje, aby uzyskać pewność, że diagramy mają sens. Jednak wtedy nie napisałem tyle kodu co teraz. Oznacza to, że tamte diagramy nie były weryfikowane za pomocą kodu i testów. Ten brak weryfikacji był bardzo widoczny. Kod prezentowany w niniejszym rozdziale pisałem w takiej kolejności, w jakiej został zaprezentowany. Za każdym razem przypadki testowe były pisane przed kodem produkcyjnym. W wielu sytuacjach testy były tworzone przyrostowo — ewoluowały w miarę ewolucji kodu produkcyjnego. Kod produkcyjny był pisany w zgodzie ze stworzonymi diagramami, o ile miało to sens. W kilku przypadkach nie miało to sensu, dlatego zmieniłem projekt kodu. Jednym z pierwszych miejsc, gdzie tak się stało, była sytuacja opisana w podrozdziale „Karty pracy, raporty sprzedaży i składki”, kiedy postanowiłem zrezygnować z wielu egzemplarzy obiektów Affiliation wewnątrz obiektu Employee. Inna zmiana nastąpiła w podrozdziale „Zmiana klasyfikacji”, kiedy zdałem sobie sprawę, że nie uwzględniłem rejestrowania przynależności pracownika do związku zawodowego w transakcji ChangeMemberTransaction. Takie zmiany są normalne. Kiedy projektujemy aplikację bez weryfikacji w kodzie źródłowym i testach często popełniamy błędy. Błędy te wykryliśmy w czasie prac nad przypadkami testowymi i kodem źródłowym.

Zasoby Finalną wersję kodu prezentowanego w tym rozdziale można znaleźć na stronie internetowej wydawnictwa Prentice Hall albo pod adresem www.objectmentor.com/PPP.

Bibliografia 1. Ivar Jacobson, Object-Oriented Software Engineering, A Use-Case-Driven Approach, Wokingham, Wielka Brytania: Addison-Wesley, 1992.

260

ROZDZIAŁ 19. STUDIUM PRZYPADKU: SYSTEM PŁACOWY. IMPLEMENTACJA

CZĘŚĆ IV Podział systemu płacowego na pakiety

W tej części omówimy zasady projektowania, które pomogą nam podzielić duży system oprogramowania na pakiety. W pierwszym rozdziale tej części omówiono te zasady, w drugim opisano wzorzec, którego będziemy używać, aby poprawić strukturę pakietów, natomiast w trzecim pokażemy sposób zastosowania zasad i wzorca do systemu płacowego.

262

ROZDZIAŁ 20. ZASADY PROJEKTOWANIA PAKIETÓW

PROJEKTOWANIE Z WYKORZYSTANIEM PAKIETÓW?

263

R OZDZIAŁ 20

Zasady projektowania pakietów

Fajny pakiet — Anthony

W miarę wzrostu rozmiarów i złożoności aplikacji potrzebne są mechanizmy wysokopoziomowej organizacji. Chociaż klasy są bardzo wygodną jednostką organizacji niewielkich aplikacji, są one zbyt szczegółowe do tego, aby były stosowane jako jedyna jednostka organizacyjna dla dużych aplikacji. Czasami do zorganizowania większych aplikacji potrzebne są „większe” jednostki od klas. Te większe jednostki nazywane są pakietami. W niniejszym rozdziale zaprezentowano sześć zasad. Pierwsze trzy dotyczą spójności pakietu. Pozwalają one przydzielić klasy do pakietów. Kolejne trzy dotyczą sprzężeń pomiędzy pakietami. Pozwalają one określić sposób wzajemnych zależności pomiędzy pakietami. Ostatnie dwie zasady opisują zbiór metryk zarządzania zależnościami (ang. Dependency Management — DM), które pozwala programistom mierzyć i charakteryzować strukturę zależność swoich projektów.

Projektowanie z wykorzystaniem pakietów? W notacji UML pakiety mogą być wykorzystane jako kontenery dla grup klas. Dzięki pogrupowaniu klas w pakiety możemy wyrazić projekt na wyższym poziomie abstrakcji. Pakiety możemy również wykorzystać do zarządzania rozwojem i dystrybucją oprogramowania. Celem jest podzielenie klas w aplikacji na części według pewnych kryteriów, a następnie przydzielenie klas w ramach tych części do pakietów.

264

ROZDZIAŁ 20. ZASADY PROJEKTOWANIA PAKIETÓW

Ale klasy często zależą od innych klas, a te zależności bardzo często wykraczają poza granice pakietu. W związku z tym pakiety będą wchodziły w relacje zależności pomiędzy sobą. Relacje pomiędzy pakietami wyrażają wysokopoziomową organizację aplikacji i muszą być zarządzane. W związku z tym nasuwa się wiele pytań: 1. Jakie zasady rządzą przydziałem klas do pakietów? 2. Jakie zasady projektowe dotyczą relacji pomiędzy pakietami? 3. Czy pakiety należy projektować przed klasami (według reguły góra-dół)? Czy raczej to klasy należy projektować przed pakietami (według reguły dół-góra)? 4. W jaki sposób są fizycznie reprezentowane pakiety? W języku C++? W Javie? W środowisku programistycznym? 5. Jaki cel spełniają pakiety po utworzeniu? W niniejszym rozdziale przedstawiono sześć zasad projektowych, które regulują tworzenie, wzajemne relacje oraz wykorzystanie pakietów. Pierwsze trzy zasady dotyczą podziału klas na pakiety. Ostatnie trzy opisują wzajemne relacje pomiędzy pakietami.

Ziarnistość: zasady spójności pakietów Trzy zasady spójności pakietów ułatwiają deweloperom podjęcie decyzji dotyczącej sposobu podziału klas na pakiety. Zależą one od wykrycia co najmniej niektórych klas oraz wzajemnych relacji, które je łączą. W związku z tym te zasady opisują podział klas typu „dół-góra”.

Zasada równoważności wielokrotnego wykorzystania kodu i dystrybucji (REP) Ziarnistość wielokrotnego wykorzystywania kodu jest równoważna ziarnistości wydań wersji dystrybucyjnych. Czego oczekujemy od autora biblioteki klas, które planujemy wykorzystać wielokrotnie? Oczywiście chcielibyśmy dobrej dokumentacji, działającego kodu, dobrze określonych interfejsów itp. Istnieją jednak inne rzeczy, których oczekujemy. Po pierwsze: aby warto było poświęcić czas na skorzystanie z kodu napisanego przez inną osobę, chcielibyśmy, aby autor zagwarantował utrzymanie kodu. W końcu jeśli sami mielibyśmy utrzymywać kod, musielibyśmy zainwestować w to ogromną ilość czasu. Ten czas lepiej poświęcić na samodzielne zaprojektowanie mniejszych i lepszych pakietów. Po drugie: chcielibyśmy, aby autor kodu powiadomił nas z wyprzedzeniem o wszelkich planowanych zmianach w interfejsie i funkcjonalności kodu. Ale samo poinformowanie nie wystarcza. Autor musi dać nam możliwość zrezygnowania z używania nowych wersji. Może się przecież zdarzyć, że nowa wersja zostanie wprowadzona w czasie, gdy mamy bardzo napięty harmonogram. Wprowadzone zmiany mogą również być niezgodne z naszym kodem. W obu przypadkach należy podjąć decyzję o odrzuceniu nowej wersji. W takiej sytuacji autor powinien zagwarantować wsparcie dla korzystania ze starej wersji. Równie dobrze może to być czas trzech miesięcy, jak i roku. Powinno to być przedmiotem negocjacji pomiędzy nami a autorem biblioteki. Ale nie może się zdarzyć, aby autor po prostu odmówił nam wsparcia. Jeśli autor nie zgodzi się na wsparcie dla korzystania ze starszych wersji biblioteki, to powinniśmy poważnie zastanowić się nad sensem dalszego korzystania z jego kodu i polegania na jego kaprysach. Problem jest kwestią przyjętej polityki. Ma związek ze wsparciem menedżerskim, które powinno być udzielone, jeśli inne osoby chcą korzystać z naszego kodu. Ale te kwestie polityczne i menedżerskie mają głęboki wpływ na strukturę pakietów tworzonego oprogramowania. W celu zagwarantowania spełnienia wymagań użytkowników korzystających z kodu autorzy muszą zorganizować swoje oprogramowanie w pakiety wielokrotnego użytku, a następnie śledzić numery wersji dystrybucyjnych tych pakietów.

ZIARNISTOŚĆ: ZASADY SPÓJNOŚCI PAKIETÓW

265

Zasada REP mówi, że ziarnistość wielokrotnego wykorzystywania kodu (tzn. pakiet) nie może być mniejsza od ziarnistości wydań wersji dystrybucyjnych. Każde oprogramowanie, które jest wykorzystywane wielokrotnie, musi być również wydawane, a wersjom dystrybucyjnym powinny być nadawane odrębne numery. Wymaganie, aby deweloper napisał klasę, a następnie stwierdził, że spełnia ona warunki komponentu wielokrotnego użytku, jest po prostu nierealistyczne. Możliwość wielokrotnego wykorzystywania powstaje tylko wówczas, gdy istnieje system kontroli wersji, który gwarantuje informowanie, bezpieczeństwo i wsparcie potrzebne potencjalnym użytkownikom kodu. Zasada REP daje nam pierwszą wskazówkę dotyczącą sposobu podziału projektu na pakiety. Ponieważ zdolność wielokrotnego wykorzystywania kodu musi bazować na pakietach, pakiety wielokrotnego użytku muszą składać się z klas wielokrotnego użytku. Zatem przynajmniej niektóre pakiety powinny zawierać zestawy klas wielokrotnego użytku. Wpływ czynników politycznych na sposób podziału oprogramowania może wydawać się niepokojący, ale oprogramowanie nie jest matematycznie czystą jednostką, która może być zorganizowana według czysto matematycznych zasad. Oprogramowanie jest produktem człowieka, który powinien wspierać wysiłki podejmowane przez ludzi. Programy są tworzone i wykorzystywane przez ludzi. Jeśli oprogramowanie ma być wykorzystywane wielokrotnie, to musi być podzielone w sposób, który zagwarantuje użytkownikom wygodę przy realizacji ich zadań. Co to znaczy dla wewnętrznej struktury pakietu? Wewnętrzną zawartość pakietu należy rozpatrywać z punktu widzenia potencjalnych użytkowników kodu. Jeśli pakiet zawiera oprogramowanie, które powinno być wykorzystywane wielokrotnie, to nie powinien jednocześnie zawierać oprogramowania, które nie jest przeznaczone do ponownego użycia. Albo wszystkie klasy w pakiecie są wielokrotnego użytku, albo żadna. Możliwość wielokrotnego wykorzystywania kodu nie jest jedynym kryterium — trzeba także wziąć pod uwagę, kim są użytkownicy kodu. Oczywiście możliwość wielokrotnego wykorzystywania powinna oferować zarówno biblioteka klas kontenerów, jak i framework finansowy. Nie chcemy jednak, aby należały one do tego samego pakietu. Jest wiele osób, które chciałyby skorzystać z klasy kontenerów, a które w ogóle nie są zainteresowane frameworkiem finansowym. W związku z tym chcemy, aby wszystkie klasy w pakiecie były przeznaczone do ponownego wykorzystania przez tę samą grupę odbiorców. Nie chcemy, aby użytkownicy komponentu znaleźli w pakiecie zarówno kilka klas, które są im potrzebne, jak i takie, które zupełnie im się nie przydadzą.

Zasada zbiorowego wielokrotnego użytku (CRP) Klasy należące do pakietu są wykorzystywane wielokrotnie razem. Jeśli korzystamy z jednej klasy z pakietu, to korzystamy ze wszystkich klas należących do tego pakietu. Ta zasada pomaga nam zdecydować o tym, które klasy powinny być umieszczone w pakiecie. Mówi ona, że klasy, które mają być wspólnie wielokrotnie wykorzystywane, powinny należeć do tego samego pakietu. Klasy rzadko są używane wielokrotnie w izolacji. Zazwyczaj klasy wielokrotnego użytku współpracują z innymi klasami, które są częścią abstrakcji wielokrotnego użytku. Zasada CRP mówi, że takie klasy należą do tego samego pakietu. W takim pakiecie klasy mają ze sobą wiele zależności. Prostym przykładem może być klasa kontenerów oraz powiązane z nią iteratory. Klasy te są wykorzystywane wielokrotnie łącznie, ponieważ są ściśle sprzężone ze sobą. Z tego powodu powinny one znaleźć się w tym samym pakiecie. Ale zasada CRP mówi nam nie tylko o tym, które klasy umieścić razem w pakiecie. Mówi również o tym, których klas nie należy umieszczać w pakiecie. Gdy jeden pakiet korzysta z innego, pomiędzy takimi pakietami powstaje zależność. Może się zdarzyć, że pakiet korzystający używa tylko jednej klasy z pakietu. Ten fakt w żaden sposób nie osłabia jednak zależności pomiędzy klasami. Pakiet korzystający w dalszym ciągu zależy od pakietu wykorzystywanego. Za każdym razem, gdy następuje dystrybucja wykorzystywanego pakietu, pakiet korzystający musi być przetestowany i ponownie wydany. Dotyczy

266

ROZDZIAŁ 20. ZASADY PROJEKTOWANIA PAKIETÓW

to również sytuacji, w której używany pakiet został wydany z powodu zmian w klasie, której pakiet wykorzystujący nie używa. Co więcej, zazwyczaj pakiety mają fizyczne reprezentacje w postaci współdzielonych bibliotek, bibliotek DLL czy też archiwów JAR. Jeśli wykorzystywany pakiet jest wydawany w postaci archiwum JAR, to kod korzystający zależy od całego archiwum JAR. Wszelkie zmiany w tym archiwum JAR — nawet zmiany wprowadzane w klasie, której kod korzystający nie używa — będą powodowały konieczność wydania nowej wersji archiwum JAR. Nowy JAR będzie musiał być ponownie wydany, a kod korzystający będzie musiał być przetestowany na nowo. Z tego względu należy pamiętać o tym, że kiedy kod zależy od pakietu, to zależy od wszystkich klas, które należą do tego pakietu. Mówiąc inaczej, należy zadbać o to, aby klasy umieszczone w określonym pakiecie były nierozłączne — tzn. aby nie była możliwa sytuacja, w której kod zależy od jednej klasy, a nie zależy od innych klas. W przeciwnym razie będziemy zmuszeni do przeprowadzania testów i dystrybucji częściej, niż jest to konieczne, co oznacza marnotrawstwo czasu i wysiłków. Z tego powodu zasada CRP mówi nam więcej o tym, kiedy klas nie należy łączyć ze sobą w pakiet, niż o tym, kiedy należy je łączyć. Zasada CRP mówi, że klasy, które nie są ze sobą ściśle związane, nie powinny znaleźć się w tym samym pakiecie.

Zasada zbiorowego zamykania (CCP) Klasy należące do pakietu powinny być wspólnie zamknięte dla tego samego rodzaju zmian. Zmiana, która dotyczy określonego pakietu, dotyczy wszystkich klas w tym pakiecie i nie ma wpływu na żadne inne klasy. Zasada CCP (ang. Common-Closure Principle) jest odpowiednikiem zasady pojedynczej odpowiedzialności w odniesieniu do pakietów. Podobnie jak zasada SRP mówi, że klasa nie powinna być zmieniana z wielu powodów, tak zasada CCP mówi, że pakiet nie powinien być zmieniany z wielu powodów. W większości aplikacji możliwości utrzymania aplikacji są ważniejsze od możliwości wielokrotnego wykorzystywania. Jeśli kod w aplikacji musi się zmienić, to wolelibyśmy, aby zmiany dotyczyły jednego pakietu, a nie wielu. Jeśli zmiany są skoncentrowane w jednym pakiecie, to występuje potrzeba dystrybucji tylko jednego pakietu — tego, który został zmodyfikowany. Tych pakietów, które nie zależą od zmodyfikowanego pakietu, nie trzeba ponownie testować ani wydawać. Zasada CCP mówi nam, aby umieszczać w jednym pakiecie wszystkie klasy, które mogą się zmieniać z tych samych powodów. Jeśli dwie klasy są ze sobą tak ściśle sprzężone — fizycznie lub pojęciowo — że zawsze zmieniają się razem, to powinny one należeć do tego samego pakietu. To minimalizuje nakłady pracy związane z wydawaniem, testowaniem i dystrybucją oprogramowania. Zasada CCP ściśle wiąże się z zasadą otwarte-zamknięte (OCP). Zasada CCP dotyczy „zamykania” w sensie zasady OCP. Zgodnie z zasadą otwarte-zamknięte klasy powinny być zamknięte dla modyfikacji, ale otwarte dla rozszerzeń. Jednak jak się przekonaliśmy, stuprocentowe domknięcie jest nieosiągalne. Domknięcia muszą być wynikiem strategicznych decyzji. Systemy projektujemy w taki sposób, aby były zamknięte na większość rodzajów zmian, których doświadczyliśmy. Zasada CCP wzmacnia ten schemat poprzez pogrupowanie w jednym pakiecie klas, które są otwarte na specyficzne rodzaje zmian. Kiedy wystąpi potrzeba wprowadzenia zmian, to dzięki zastosowaniu takiego podejścia będzie szansa, że zakres tych zmian będzie ograniczony do minimalnej liczby pakietów.

Podsumowanie tematyki spójności pakietów W przeszłości sposób postrzegania spójności był znacznie prostszy w porównaniu z tym, który wynika z ostatnich trzech zasad. Wcześniej uważano, że spójność jest po prostu cechą modułu pozwalającą na wykonywanie jednej i tylko jednej funkcji. Jednak przedstawione trzy zasady spójności pakietów opisują bogatszy rodzaj spójności. Wybierając klasy, które mają być pogrupowane w pakiety, należy wziąć pod uwagę przeciwstawne siły dotyczące możliwości wielokrotnego wykorzystywania i rozwoju oprogramowania.

STABILNOŚĆ: ZASADY SPRZĘGANIA PAKIETÓW

267

Zrównoważenie tych sił z potrzebami aplikacji nie jest trywialne. Co więcej, ta równowaga prawie zawsze jest dynamiczna. Oznacza to, że podział, który jest właściwy jednego dnia, nie musi być właściwy za rok. Tak więc kompozycja pakietów prawdopodobnie będzie z czasem ewoluowała w miarę zmian w projekcie — od możliwości rozwoju do możliwości wielokrotnego wykorzystywania.

Stabilność: zasady sprzęgania pakietów Kolejne trzy zasady dotyczą związków zachodzących pomiędzy pakietami. Tutaj ponownie należy rozważyć sprzeczne punkty widzenia w kwestii możliwości rozwoju i logicznej budowy projektu. Siły, które wpływają na architekturę struktury pakietów, mają charaktery techniczny, polityczny i ulotny.

Zasada acyklicznych zależności (ADP) Graf zależności pomiędzy pakietami nie może zawierać cykli. Czy kiedykolwiek zdarzyło Ci się pracować cały dzień nad czymś, co na koniec dnia zaczęło działać, a gdy następnego dnia przyszedłeś do pracy, to okazało się, że już nie działa? Dlaczego przestało działać? Ponieważ ktoś został w pracy dłużej i wprowadził zmiany w kodzie, od którego zależało oprogramowanie! Taką sytuację nazywam „syndromem następnego poranka”. Syndrom następnego poranka występuje w środowiskach projektowych, w których wielu deweloperów modyfikuje te same pliki źródłowe. W stosunkowo niewielkich projektach, w których bierze udział zaledwie kilku deweloperów, nie stanowi to zbyt dużego problemu. Jednak w miarę rozrastania się projektu oraz zwiększania się liczby członków zespołu projektowego syndrom następnego poranka może stać się koszmarem. W niezdyscyplinowanych zespołach nie należy do rzadkości sytuacja, w której przez całe tygodnie nie można zbudować stabilnej wersji projektu. Każdy z członków zespołu projektowego próbuje zmieniać swój kod, starając się doprowadzić do tego, by działał z wersją kodu zmienionego przez kogoś innego. W kilku ostatnich dziesięcioleciach wyewoluowały dwa rozwiązania tego problemu. Oba rozwiązania mają swoje korzenie w branży telekomunikacyjnej. Pierwsze to „cotygodniowe kompilacje”, natomiast drugie to zasada acyklicznych zależności (Acyclic Dependencies Principle — ADP).

Cotygodniowe kompilacje Zasadę cotygodniowych kompilacji stosuje się w projektach średniej wielkości. Ten mechanizm działa następująco: Wszyscy deweloperzy ignorują zmiany wprowadzane przez innych deweloperów przez pierwsze cztery dni tygodnia. Wszyscy pracują na swoich prywatnych kopiach kodu i nie przejmują się integrowaniem wprowadzanych zmian. Następnie w piątek integrują wszystkie wprowadzone zmiany i kompilują system. Ma to tę wspaniałą zaletę, że pozwala programistom na działanie w odizolowanym świecie przez cztery z pięciu dni tygodnia. Wadą są oczywiście wysokie koszty integracji, które są ponoszone w piątek. Niestety, w miarę rozwoju projektu realizacja prac związanych z integracją i kompilacją kodu w każdy piątek staje się coraz mniej realna. Koszty integracji stale rosną, aż w końcu niektóre prace muszą być wykonywane w sobotę. Kilka takich sobót wystarcza do tego, aby przekonać deweloperów, że integracja w rzeczywistości powinna rozpocząć się w czwartek. W ten sposób początek zadań integracji powoli przesuwa się w kierunku środka tygodnia.

268

ROZDZIAŁ 20. ZASADY PROJEKTOWANIA PAKIETÓW

W miarę obniżania się wartości współczynnika czasu poświęcanego na prace rozwojowe w stosunku do zadań integracji maleje efektywność zespołu. W końcu staje się to tak frustrujące, że deweloperzy lub kierownicy projektu dochodzą do wniosku, że kompilacje powinny być wykonywane co dwa tygodnie. To na jakiś czas wystarcza, ale wraz z rozwojem projektu czas integracji nadal się wydłuża. Ostatecznie taka sytuacja prowadzi do kryzysu. Utrzymanie właściwej efektywności wymaga stałego wydłużania cyklu kompilacji. Trzeba jednak pamiętać, że wydłużony cykl kompilacji zwiększa ryzyko związane z projektem. Integracja i testowanie są coraz trudniejsze do wykonania, a zespół traci możliwość szybkiej weryfikacji kodu z działającym systemem.

Eliminowanie cykli zależności Rozwiązaniem tego problemu jest podzielenie środowiska wytwarzania oprogramowania na pakiety, które można publikować niezależnie. Pakiety stają się odrębnymi jednostkami pracy, które mogą być pobierane przez indywidualnych deweloperów bądź zespoły. Kiedy deweloperzy uznają pakiet za gotowy, wydają jego wersję dystrybucyjną, która może być wykorzystywana przez innych programistów. Pakiet otrzymuje numer wersji dystrybucyjnej i jest umieszczany w katalogu, z którego może być pobrany przez inne zespoły. Następnie prace są kontynuowane w prywatnych obszarach. Wszyscy pozostali korzystają z wersji, która została opublikowana. W miarę opracowywania nowych wersji dystrybucyjnych pakietu inne zespoły mogą zdecydować, czy chcą natychmiast przyjąć nową wersję, czy pozostać przy starej. Jeżeli zdecydują się nie zmieniać wersji, to po prostu w dalszym ciągu korzystają z wersji poprzedniej. Kiedy uznają, że są do tego gotowi, to po prostu przełączają się na nową wersję. A zatem żaden z zespołów nie jest skazany na łaskę bądź niełaskę innego zespołu. Zmiany wykonywane w jednym pakiecie nie muszą mieć natychmiastowego wpływu na inne zespoły. Każdy zespół może sam zdecydować, kiedy dostosować swoje pakiety do nowych wersji dystrybucyjnych wykorzystywanych pakietów. Co więcej, integracja jest przeprowadzana małymi krokami. Nie istnieje jeden punkt w czasie, kiedy wszyscy deweloperzy muszą się spotkać i zintegrować cały swój kod. Jest to bardzo prosty i racjonalny proces, który jest szeroko stosowany. Jednak aby można go było zastosować, trzeba zadbać o zarządzanie strukturą zależności pakietów. W grafie zależności nie może być cykli. Jeśli w strukturze zależności są cykle, to nie można uniknąć syndromu następnego poranka. Rozważmy diagram pakietów z rysunku 20.1. Można na nim zaobserwować typową strukturę pakietów zastosowaną w aplikacji. Funkcja, jaką spełnia ta aplikacja, nie ma znaczenia z punktu widzenia prezentowanego przykładu. Ważna jest struktura zależności pakietów. Zwróćmy uwagę, że ta struktura jest grafem skierowanym. Pakiety są reprezentowane przez węzły, natomiast relacje zależności są krawędziami skierowanymi.

Rysunek 20.1. Struktury pakietów są skierowanym grafem acyklicznym

STABILNOŚĆ: ZASADY SPRZĘGANIA PAKIETÓW

269

Zwróćmy uwagę na jeszcze jeden element. Niezależnie od pakietu, od którego zaczniemy, nie można podążać ścieżką relacji zależności w taki sposób, aby znaleźć się z powrotem w tym samym pakiecie. Te struktury nie mają cykli. Mamy tu do czynienia z acyklicznym grafem skierowanym (ang. Directed Acyclic Graph — DAG). Kiedy zespół odpowiedzialny za pakiet MyDialogs opublikuje nową wersję dystrybucyjną swojego pakietu, można z łatwością znaleźć pakiety, których to dotyczy — wystarczy spojrzeć na strzałki zależności i sprawdzić, jakie pakiety znajdują się po przeciwnej stronie do kierunku tych strzałek. W tym przypadku zmiany wpłyną na pakiety MyTasks oraz MyApplication. Deweloperzy, którzy w tym momencie pracują nad tymi pakietami, będą musieli zadecydować o tym, kiedy powinni zintegrować swój kod z nową wersją dystrybucyjną pakietu MyDialogs. Zwróćmy także uwagę, że opublikowanie wersji dystrybucyjnej pakietu MyDialogs nie wywiera żadnego wpływu na wiele innych pakietów w systemie. Pakiety te nic „nie wiedzą” o pakiecie MyDialogs, a w związku z tym wprowadzenie zmian w pakiecie MyDialogs nie wywiera na nie żadnego wpływu. To bardzo korzystne. Oznacza to, że wpływ wydania nowej wersji dystrybucyjnej pakietu MyDialogs na inne pakiety jest stosunkowo niewielki. Kiedy deweloperzy pracujący nad pakietem MyDialogs zdecydują się na przeprowadzenie testów tego pakietu, to wystarczy, że skompilują ten pakiet i skonsolidują go z wersją pakietu Windows, z której aktualnie korzystają. Nie będzie to miało wpływu na żadne inne pakiety w systemie. To bardzo korzystna sytuacja. Oznacza ona, że deweloperzy pracujący nad pakietem MyDialogs będą mieli stosunkowo niewiele pracy ze skonfigurowaniem testu oraz że będą musieli uwzględnić stosunkowo niewiele zmiennych. Kiedy nadejdzie czas wydania wersji dystrybucyjnej całego systemu, będzie można to zrobić metodą dół-góra. Najpierw zostanie skompilowany, przetestowany i wydany pakiet Windows. Następne będą pakiety MessageWindow i MyDialogs. W dalszej kolejności pakiet Task oraz pakiety TaskWindow i Database. Później należy skompilować pakiet MyTasks i na koniec pakiet MyApplication. Jest to bardzo czytelny proces i łatwy do przeprowadzenia. Wiadomo, jak zbudować system, ponieważ znane są zależności pomiędzy jego częściami.

Skutki istnienia cykli w grafie zależności między pakietami Powiedzmy, że nowe wymaganie zmusza nas do zmiany jednej z klas z pakietu MyDialogs w taki sposób, że musi ona skorzystać z klasy należącej do pakietu MyApplication. Powoduje to powstanie cyklu zależności, jak pokazano na rysunku 20.2.

Rysunek 20.2. Diagram pakietów zawierający cykl

270

ROZDZIAŁ 20. ZASADY PROJEKTOWANIA PAKIETÓW

Występowanie takiego cyklu prowadzi do pewnych bezpośrednich problemów. Na przykład deweloperzy pracujący nad pakietem MyTasks wiedzą, że opracowanie wersji dystrybucyjnej wymaga zapewnienia zgodności z pakietami Task, MyDialogs, Database i Windows. Jeśli jednak występuje cykl, musi być również zapewniona zgodność z pakietami MyApplication, TaskWindow i MessageWindow. Tak więc pakiet MyTasks zależy teraz od wszystkich innych pakietów w systemie. To sprawia, że opublikowanie wersji dystrybucyjnej pakietu MyTasks staje się bardzo trudne. Ten sam problem dotyczy pakietu MyDialogs. Występowanie cyklu sprawia, że pakiety MyApplication, MyTasks i MyDialogs zawsze muszą być publikowane w tym samym czasie. W istocie stają się one jednym dużym pakietem. Z tego powodu wszyscy programiści, którzy pracują nad jednym z tych pakietów, po raz kolejny będą doświadczali syndromu następnego poranka. Ciągle będą oni od siebie zależni, ponieważ każdy z tych zespołów jest zmuszony do korzystania z dokładnie tej samej wersji dystrybucyjnej swoich pakietów. Ale to tylko część problemów. Zastanówmy się, co się stanie, jeśli będziemy chcieli przetestować pakiet MyDialogs. Okazuje się, że musimy skonsolidować wszystkie inne pakiety systemu, łącznie z pakietem Database. Oznacza to, że tylko po to, aby przetestować pakiet MyDialogs, musimy wykonać kompletną kompilację całego systemu. Takie rozwiązanie jest nie do przyjęcia. Jeśli kiedykolwiek zastanawialiście się, dlaczego musicie konsolidować tak wiele różnych bibliotek i tyle zewnętrznego kodu tylko po to, aby uruchomić prosty test jednostkowy jednej ze swoich klas, to prawdopodobnie przyczyną było to, że istnieją cykle w grafie zależności. Występowanie takich cykli sprawia, że wyizolowanie modułów staje się bardzo trudne. Wykonywanie testów jednostkowych i publikowanie wersji dystrybucyjnych jest uciążliwe i stwarza wiele okazji do popełnienia błędów. A w języku C++ czas kompilacji rośnie geometrycznie wraz ze wzrostem liczby modułów. Co więcej, gdy istnieją cykle w grafie zależności, znalezienie właściwej kolejności kompilacji modułów może być bardzo trudne. Czasami prawidłowa kolejność może w ogóle nie istnieć. Może to prowadzić do dużych problemów w językach takich jak Java, które odczytują swoje deklaracje ze skompilowanych plików binarnych.

Przerywanie cykli Zawsze możliwe jest przerwanie cyklu zależności pomiędzy pakietami i odtworzenie grafu zależności do postaci acyklicznego grafu skierowanego. Dostępne są dwa główne mechanizmy wykonywania tej operacji. 1. Zastosowanie zasady odwracania zależności (DIP). W przypadku z rysunku 20.3 moglibyśmy utworzyć abstrakcyjną klasę bazową z interfejsem, którego oczekuje pakiet MyDialogs. Następnie można by umieścić tę abstrakcyjną klasę bazową w pakiecie MyDialogs, a w komponencie MyApplication stworzyć odpowiednią klasę potomną. To powoduje odwrócenie zależności pomiędzy pakietami MyDialogs i MyApplication, a tym samym przerwanie cyklu (patrz rysunek 20.3). Zwróćmy uwagę, że nazwa interfejsu została stworzona na podstawie nazwy klienta, a nie nazwy serwera. To kolejny przykład zastosowania reguły, zgodnie z którą interfejsy należą do klientów. 2. Utworzenie nowego pakietu, od którego zależą zarówno pakiet MyDialogs, jak i MyApplication. Klasę (klasy), od której zależą oba pakiety, należy przenieść do nowego pakietu (patrz rysunek 20.4).

Odchylenia Drugie rozwiązanie pokazuje, że struktura pakietów jest lotna w obliczu zmieniających się wymagań. W rzeczywistości w miarę rozwoju aplikacji struktura zależności pakietów zmienia się i rozrasta. Z tego powodu należy stale monitorować graf zależności pomiędzy pakietami pod kątem obecności cykli. Kiedy takie cykle zostaną znalezione, należy je przerwać. Czasami oznacza to konieczność tworzenia nowych pakietów, a tym samym rozrastanie się struktury zależności.

PROJEKT GÓRA-DÓŁ

271

Rysunek 20.3. Przerywanie cyklu poprzez zastosowanie zasady odwracania zależności

Rysunek 20.4. Przerywanie cyklu poprzez stworzenie nowego pakietu

Projekt góra-dół Problemy, które omówiliśmy do tej pory, prowadzą do oczywistego wniosku. Struktury pakietów nie da się zaprojektować od góry do dołu. Oznacza to, że struktura pakietów nie jest jednym z pierwszych elementów systemu, które powinniśmy zaprojektować. Struktura ta ewoluuje, w miarę jak system rozwija się i zmienia. Może się wydawać, że jest to sprzeczne z intuicją. Można by oczekiwać, że tak wysokopoziomowa dekompozycja jak podział na pakiety powinna również reprezentować dekompozycję funkcjonalną. Kiedy widzimy podział na tak duże grupy, czujemy, że pakiety powinny w pewien sposób reprezentować funkcje systemu. Wydaje się jednak, że diagramy zależności pomiędzy pakietami nie mają takiej cechy. W rzeczywistości diagramy zależności pomiędzy pakietami mają bardzo niewiele wspólnego z opisem funkcji aplikacji. Nie opisują one funkcji, ale raczej odzwierciedlają możliwości kompilacji aplikacji. Dlatego właśnie nie tworzy się ich na początku projektu. Nie ma potrzeby wykonywania kompilacji, a tym samym nie ma powodu, aby tworzyć mapę kompilacji. Jednak w miarę powstawania coraz większej liczby klas na początkowych etapach implementacji i projektowania powstaje coraz większe zapotrzebowanie na zarządzanie zależnościami, tak aby prace nad projektem mogły odbywać się bez syndromu następnego poranka. Co więcej, chcemy, aby zmiany miały charakter lokalny, dlatego zaczynamy zwracać uwagę na spełnienie zasad SRP i CCP oraz grupujemy klasy, które mogą się zmieniać razem.

272

ROZDZIAŁ 20. ZASADY PROJEKTOWANIA PAKIETÓW

Wraz z dalszym rozwojem aplikacji zaczynamy zwracać uwagę na tworzenie komponentów wielokrotnego użytku. Z tego powodu kompozycję pakietów zaczyna dyktować zasada CRP. Na koniec, wraz z pojawieniem się cykli, zaczynamy stosować zasadę acyklicznych zależności (ADP), a graf zależności pomiędzy pakietami zaczyna się zmieniać i rozrastać. Próba zaprojektowania struktury zależności pomiędzy pakietami przed zaprojektowaniem klas prawdopodobnie skończyłaby się niepowodzeniem. W takim przypadku nie wiedzielibyśmy zbyt wiele o wspólnych domknięciach, nie potrafilibyśmy wskazać komponentów wielokrotnego użytku i prawie na pewno stworzylibyśmy pakiety, których graf zależności zawierałby cykle. Z tych powodów struktura zależności pomiędzy pakietami rozwija się i ewoluuje wraz z rozwojem logicznego projektu systemu.

Zasada stabilnych zależności (SDP) Zależności powinny być zgodne z kierunkiem stabilności. Projekty nie mogą być całkowicie statyczne. Aby projekt mógł być właściwie utrzymywany, pewna ulotność jest konieczna. Aby ją osiągnąć, należy zapewnić zgodność z zasadą zbiorowego zamykania (ang. Common-Closure Principle — CCP). Korzystając z tej zasady, tworzymy pakiety, które są wrażliwe na niektóre rodzaje zmian. Te pakiety są projektowane z myślą o ulotności. Oczekujemy od nich, że będą się zmieniały. Żaden pakiet, który zgodnie z oczekiwaniami ma być ulotny, nie powinien zależeć od jakiegokolwiek pakietu, który jest trudny do zmiany! W przeciwnym przypadku ten ulotny pakiet również będzie trudny do zmiany. Przewrotnością branży oprogramowania jest to, że moduł, który zostały zaprojektowany z myślą o łatwym wprowadzaniu zmian, trudno się zmienia dlatego, że ktoś uzależnił swój kod od tego modułu. Pomimo tego, że żadna linijka kodu w module nie będzie wymagała zmiany, to moduł nagle stanie się trudny do zmiany. Dzięki zastosowaniu zasady SDP możemy zapewnić, że moduły, które są przeznaczone do łatwych modyfikacji, nie będą zależne od modułów, które są trudniejsze do zmiany.

Stabilność Spróbujmy postawić monetę jednogroszową na krawędzi. Czy w tej pozycji jest ona stabilna? Prawdopodobnie większość czytelników odpowiedziała, że nie. Jednak jeśli nic się nie wydarzy, moneta pozostanie w tej pozycji przez bardzo długi czas. A zatem stabilność nie ma bezpośredniego związku z częstością zmian. Moneta groszowa nie zmienia się, ale trudno myśleć o niej, że jest stabilna. Według słownika Webstera coś jest stabilne, jeśli „nie można tego łatwo przemieścić1”. Stabilność jest związana z ilością pracy wymaganej do wprowadzenia zmiany. Moneta groszowa nie jest stabilna, ponieważ aby ją przewrócić, potrzeba niewiele wysiłku. Z kolei stół jest bardzo stabilny, ponieważ aby go przewrócić, trzeba sporo wysiłku. Jak można to odnieść do oprogramowania? Jest wiele czynników, które sprawiają, że pakiet oprogramowania staje się trudny do zmiany: jego rozmiar, złożoność, czytelność itp. Na razie zignorujemy wszystkie te czynniki i skoncentrujemy się na czymś innym. Jednym z pewnych sposobów na to, aby pakiet oprogramowania stał się trudny do zmiany, jest uzależnienie od niego wielu innych pakietów oprogramowania. Pakiet z dużą liczbą przychodzących zależności jest bardzo stabilny, ponieważ dostosowanie wszystkich pakietów zależnych wymaga dużo pracy. Na rysunku 20.5 zaprezentowano przykład stabilnego pakietu X. Od tego pakietu zależą trzy inne pakiety, dlatego istnieją trzy istotne powody, aby go nie zmieniać. Mówimy, że pakiet X jest odpowiedzialny za te trzy pakiety. Z kolei pakiet X nie zależy od żadnego pakietu, zatem zmiany wprowadzane na zewnątrz nie mają na niego wpływu. Mówimy, że taki pakiet jest niezależny. 1

Webster’s Third New International Dictionary.

ZASADA STABILNYCH ZALEŻNOŚCI (SDP)

273

Rysunek 20.5. Stabilny pakiet X

Na rysunku 20.6 pokazano przykład bardzo niestabilnego pakietu. Żaden inny pakiet od niego nie zależy. Mówimy o takim pakiecie, że nie jest odpowiedzialny za inne pakiety. Sam pakiet Y zależy od trzech pakietów, zatem mogą na niego wpływać zmiany z trzech źródeł zewnętrznych. Mówimy, że pakiet Y jest od nich zależny.

Rysunek 20.6. Niestabilny pakiet Y

Metryki stabilności W jaki sposób można zmierzyć stabilność pakietu? Jednym ze sposobów jest policzenie zależności przychodzących i wychodzących z tego pakietu. Te wartości umożliwiają obliczenie pozycyjnej stabilności pakietu.  Ca (zależności przychodzące — ang. afferent couplings) — liczba klas na zewnątrz pakietu, które

zależą od klas wewnątrz pakietu.  Ce (zależności wychodzące — ang. efferent couplings) — liczba klas wewnątrz pakietu, które zależą

od klas na zewnątrz pakietu.  I (niestabilność — ang. instability):

I

Ce Ca  Ce

Opisana metryka przyjmuje wartości z przedziału [0,1]. Wartość I = 0 oznacza maksymalnie stabilny pakiet. Wartość I = 1 oznacza maksymalnie niestabilny pakiet. Wartości Ca i Ce wyznacza się poprzez zliczanie klas na zewnątrz pakietu, które są zależne od klas wewnątrz danego pakietu. Rozważmy przykład z rysunku 20.7.

Rysunek 20.7. Przykład struktury zależności

274

ROZDZIAŁ 20. ZASADY PROJEKTOWANIA PAKIETÓW

Linie przerywane pomiędzy pakietami reprezentują zależności. Relacje pomiędzy klasami należącymi do tych pakietów pokazują, jak te zależności są zaimplementowane. Występuje tu dziedziczenie oraz relacje asocjacji. Załóżmy, że chcemy obliczyć stabilność pakietu Pc. Jak można zauważyć, istnieją trzy klasy na zewnątrz pakietu Pc, które zależą od klas należących do pakietu Pc. A zatem Ca = 3. Ponadto istnieje jedna klasa na zewnątrz pakietu Pc, od której zależą klasy należące do Pc. Wynika stąd, że Ce = 1, natomiast I = 1/4. W języku C++ takie zależności zazwyczaj są reprezentowane przez instrukcje #include. Metrykę I najłatwiej obliczyć w przypadku, gdy kod źródłowy zorganizowano w taki sposób, że w każdym pliku jest jedna klasa. W Javie metrykę I można obliczyć poprzez zliczanie instrukcji import i kwalifikowanych nazw. Kiedy metryka I wynosi 1, to znaczy, że żaden inny pakiet nie zależy od tego pakietu (Ca = 0) oraz że ten pakiet zależy od innych pakietów (Ce > 0). Jest to najbardziej niestabilny pakiet, jaki może istnieć — nie jest odpowiedzialny i jest zależny. Brak pakietów, które zależą od naszego pakietu, eliminuje powód unikania zmian, a pakiety, od których zależy nasz pakiet, mogą generować wiele powodów do zmian. Z drugiej strony, jeśli metryka I ma wartość 0, to znaczy, że od naszego pakietu zależą inne pakiety (Ca > 0), ale ten pakiet sam nie zależy od innych pakietów (Ce = 0). Pakiet jest odpowiedzialny i niezależny. Taki pakiet jest maksymalnie stabilny. Ze względu na istnienie pakietów zależnych wprowadzanie w nim zmian jest trudne oraz nie istnieją zależności, które mogłyby wymusić wprowadzanie w nim zmian. Zasada SDP mówi, że metryka I pakietu powinna być większa niż metryki I pakietów, od których on zależy (tzn. metryki I powinny maleć w kierunku zależności).Nie wszystkie pakiety muszą

być stabilne Gdyby wszystkie pakiety w systemie były w maksymalnym stopniu stabilne, to takiego systemu nie można by było zmieniać. Nie jest to sytuacja pożądana. W praktyce chcemy projektować strukturę pakietów w taki sposób, aby niektóre pakiety były stabilne, a inne nie. Na rysunku 20.8 pokazano idealną konfigurację dla systemu składającego się z trzech pakietów.

Rysunek 20.8. Idealna konfiguracja pakietów

Pakiety, które można zmieniać, znajdują się w górnej części diagramu i zależą od pakietu stabilnego zamieszczonego na dole. Umieszczenie pakietów niestabilnych na górze diagramu jest użyteczną konwencją, ponieważ wszystkie strzałki wskazujące w górę naruszają zasadę SDP. Na rysunku 20.9 pokazano, jak można naruszyć zasadę SDP. Chcemy, aby pakiet Elastyczny można było łatwo zmieniać. A zatem chcemy, żeby pakiet Elastyczny był niestabilny. Jednak pewien programista pracujący nad pakietem o nazwie Stabilny wprowadził zależność od pakietu Elastyczny. Ta sytuacja narusza zasadę SDP, ponieważ metryka I dla pakietu Stabilny ma znacznie niższą wartość od metryki I pakietu Elastyczny. W rezultacie wprowadzanie zmian w pakiecie Elastyczny już nie będzie łatwe. Wprowadzenie zmian w pakiecie Elastyczny wymusi modyfikowanie pakietu Stabilny oraz wszystkich pakietów, które od niego zależą. Aby rozwiązać ten problem, trzeba w jakiś sposób przerwać zależność pomiędzy pakietami Stabilny i Elastyczny. Po co istnieje ta zależność? Załóżmy, że wewnątrz pakietu Elastyczny istnieje klasa C, z której musi skorzystać inna klasa U wewnątrz pakietu Stabilny (patrz rysunek 20.10).

ZASADA STABILNYCH ZALEŻNOŚCI (SDP)

275

Rysunek 20.9. Naruszenie zasady SDP

Rysunek 20.10. Przyczyna niewłaściwej zależności

Problem ten można rozwiązać, stosując zasadę DIP. Utworzymy interfejs o nazwie IU i umieścimy go w pakiecie o nazwie UInterface. Zadbamy o to, aby ten interfejs deklarował wszystkie metody, z których musi skorzystać klasa U. Następnie modyfikujemy klasę C w taki sposób, aby dziedziczyła po tym interfejsie (patrz rysunek 20.11). To powoduje przerwanie zależności pomiędzy pakietami Stabilny i Elastyczny i wymusza zależność obu pakietów od pakietu UInterface. Pakiet UInterface jest bardzo stabilny (I = 0), natomiast pakiet Elastyczny zachowuje pożądaną niestabilność (I = 1). Kierunek wszystkich zależności odpowiada teraz malejącej wartości metryki I.

Rysunek 20.11. Rozwiązanie problemu naruszenia stabilności z wykorzystaniem zasady DIP

276

ROZDZIAŁ 20. ZASADY PROJEKTOWANIA PAKIETÓW

Gdzie powinna się znaleźć implementacja projektu wysokiego poziomu? Pewna część oprogramowania w systemie nie powinna się często zmieniać. Takie oprogramowanie reprezentuje wysokopoziomową architekturę i decyzje projektowe. Nie chcemy, aby te decyzje były ulotne. Z tego powodu oprogramowanie, które implementuje projekt wysokiego poziomu, powinno być umieszczone w stabilnych pakietach (I = 0). Pakiety niestabilne (I = 1) powinny zawierać tylko takie oprogramowanie, które może się zmieniać. Jeśli jednak wysokopoziomowy projekt zostanie umieszczony w stabilnych pakietach, to kod źródłowy reprezentujący ten projekt będzie trudny do zmiany. To może sprawiać, że projekt stanie się nieelastyczny. W jaki sposób można doprowadzić do sytuacji, w której maksymalnie stabilne pakiety (I = 0) będą na tyle elastyczne, aby wprowadzanie zmian było możliwe? Rozwiązaniem tego problemu jest stosowanie zasady OCP. Zasada ta mówi, że jest możliwe i korzystne tworzenie takich klas, które są wystarczająco elastyczne, by można było je rozszerzać bez konieczności modyfikacji. Jakie klasy są zgodne z tą zasadą? Klasy abstrakcyjne.

Zasada stabilnych abstrakcji (SAP) Pakiet powinien być abstrakcyjny w stopniu odpowiadającym jego stabilności. Powyższa zasada określa związek pomiędzy stabilnością a abstrakcyjnością. Mówi ona, że stabilny pakiet powinien być jednocześnie abstrakcyjny, tak aby jego stabilność nie powodowała trudności z rozszerzaniem. Z drugiej strony, mówi, że pakiet niestabilny powinien być konkretny, ponieważ jego niestabilność pozwala na łatwe wprowadzanie zmian w konkretnym kodzie. A zatem jeśli pakiet ma być stabilny, to powinien zawierać także klasy abstrakcyjne, tak by mógł być rozszerzany. Stabilne pakiety, które są rozszerzalne, są elastyczne i nie wprowadzają niepotrzebnych ograniczeń na projekt. Połączenie zasad SAP i SDP jest odpowiednikiem zasady DIP w odniesieniu do pakietów. To prawda, ponieważ zasada SDP mówi, że kierunek zależności powinien być zgodny z malejącą stabilnością, natomiast zasada SAP mówi, że stabilność systemu implikuje jego abstrakcyjność. A zatem kierunek zależności powinien być zgodny z kierunkiem abstrakcji. Jednak DIP jest zasadą, która dotyczy klas. W przypadku klas nie istnieją odcienie szarości. Klasa jest abstrakcyjna albo nie. Połączenie zasad SDP i SAP dotyczy pakietów i pozwala na to, aby pakiet był częściowo abstrakcyjny i częściowo stabilny.

Mierzenie abstrakcji Metryka A jest miarą abstrakcyjności pakietu. Jej wartość oznacza stosunek klas abstrakcyjnych w pakiecie do całkowitej liczby klas w pakiecie. Nc — liczba klas w pakiecie. Na — liczba klas abstrakcyjnych w pakiecie. Należy pamiętać, że klasa jest abstrakcyjna, jeśli zawiera co najmniej jeden czysty interfejs. Nie można stworzyć egzemplarza klasy abstrakcyjnej. A — abstrakcyjność.

A

Na Nc

Metryka A może przyjmować wartości z przedziału od 0 do 1. Zero oznacza, że pakiet nie zawiera żadnych klas abstrakcyjnych. Wartość 1 oznacza, że w pakiecie znajdują się wyłącznie klasy abstrakcyjne.

ZASADA STABILNYCH ABSTRAKCJI (SAP)

277

Ciąg główny Spróbujmy zdefiniować relację pomiędzy stabilnością (I) a abstrakcyjnością (A). Możemy stworzyć wykres, w którym wartości A będą oznaczane na osi pionowej, natomiast wartości I na osi poziomej. Gdybyśmy zaznaczyli dwa „dobre” rodzaje pakietów na tym wykresie, zobaczymy, że pakiety, które są w maksymalnym stopniu stabilne i abstrakcyjne, znajdują się w górnym lewym punkcie wykresu (0,1). Z kolei pakiety, które są maksymalnie niestabilne i konkretne, znajdują się w dolnym prawym punkcie wykresu (1,0) (patrz rysunek 20.12).

Rysunek 20.12. Wykres A–I

Nie wszystkie pakiety można przypisać do jednej z tych dwóch pozycji. Pakiety charakteryzują się poziomami abstrakcji i stabilności. Na przykład bardzo często jedna klasa abstrakcyjna dziedziczy po innej klasie abstrakcyjnej. Klasa pochodna jest w tym przypadku abstrakcją, która jest zależna od innej abstrakcji. Zatem choć jest ona w maksymalnym stopniu abstrakcyjna, to nie jest maksymalnie stabilna. Jej zależności obniżają jej stabilność. Ponieważ nie można wymusić, aby wszystkie pakiety były umieszczone albo w punkcie (0,1), albo (1,0), musimy założyć, że istnieje zbiór punktów na wykresie A/I, który określa rozsądne pozycje dla pakietów. Ten zbiór możemy wywnioskować poprzez wyszukanie obszarów, w których pakiety nie powinny się znaleźć (czyli stref wykluczenia) (patrz rysunek 20.13).

Rysunek 20.13. Strefy wykluczenia

Rozważmy pakiet w obszarze (0,0). Jest to konkretny pakiet o wysokiej stabilności. Taki pakiet nie jest pożądany, ponieważ jest sztywny. Nie można go rozszerzyć, ponieważ nie jest abstrakcyjny. A ze względu na jego stabilność wprowadzanie w nim zmian jest bardzo trudne. Z tych powodów nie należy oczekiwać, aby dobrze zaprojektowane pakiety znalazły się w pobliżu punktu (0,0). Obszar wokół punktu (0,0) to strefa wykluczenia, zwana strefą problemów (ang. zone of pain).

278

ROZDZIAŁ 20. ZASADY PROJEKTOWANIA PAKIETÓW

Należy zwrócić uwagę, że istnieją przypadki, kiedy pakiety trafiają do strefy problemów. Przykładem może być schemat bazy danych. Schematy bazy danych są notorycznie niestabilne, bardzo konkretne i wiele pakietów od nich zależy. Jest to jeden z powodów, dla których interfejs między aplikacjami obiektowymi a bazami danych jest tak trudny do określenia, a aktualizacje schematu są zazwyczaj bolesne. Innym przykładem pakietu, który znajduje się blisko punktu (0,0), jest pakiet zawierający konkretną implementację biblioteki narzędziowej. Chociaż taki pakiet ma metrykę I o wartości 1, w rzeczywistości może być niezmienny. Rozważmy przykład pakietu zawierającego implementację operacji na łańcuchach znaków. Chociaż wszystkie klasy należące do tego pakietu są konkretne, pakiet jest niezmienny. Obecność takich pakietów w strefie (0,0) jest nieszkodliwa, ponieważ prawdopodobieństwo ich zmiany jest małe. Być może należałoby rozważyć dodanie do wykresu trzeciej osi reprezentującej ulotność. W takim przypadku rysunek 20.13 reprezentowałby płaszczyznę dla współczynnika ulotności równego 1. Rozważmy teraz pakiet w strefie w pobliżu punktu (1,1). Taka lokalizacja także jest niepożądana, ponieważ dotyczy pakietów, które są maksymalnie abstrakcyjne, ale nie mają pakietów zależnych. Takie pakiety są bezużyteczne. Stąd też nazwa — strefa bezużyteczności (ang. zone of uselessness). Wydaje się oczywiste, że pakiety ulotne powinny znajdować się jak najdalej od obu stref wykluczenia. Położenie punktów maksymalnie odległych od obu tych obszarów wyznacza prostą łączącą punkty (1,0) i (0,1). Ta linia jest określana jako ciąg główny (ang. main sequence)2. Pakiety rozmieszczone w punktach należących do ciągu głównego nie są ani „zbyt abstrakcyjne” jak na swoją stabilność, ani „zbyt niestabilne” jak na swoją abstrakcyjność. Nie są ani bezużyteczne, ani też nie stwarzają poważnych problemów. Zależą od innych pakietów w granicach swojej abstrakcyjności, a inne pakiety zależą od nich w granicach ich konkretności. Bez wątpienia najbardziej pożądanymi pozycjami dla pakietów są oba końce ciągu głównego. Z mojego doświadczenia wynika jednak, że mniej niż połowa pakietów w projekcie charakteryzuje się takimi idealnymi właściwościami. Pozostałe pakiety mają najlepsze właściwości wtedy, gdy znajdują się na linii ciągu głównego lub jak najbliżej tej linii.

Odległość od ciągu głównego W ten sposób doszliśmy do ostatniej z metryk. Jeśli oczekujemy, aby pakiety były reprezentowane przez punkty leżące na ciągu głównym lub w jego pobliżu, to możemy opracować metrykę opisującą odległość pakietu od ideału: D — odległość.

D

A  I 1 2

Opisana metryka przyjmuje wartości z przedziału [0,~0,707]. D' — odległość znormalizowana:

D '  A  I 1 Ta metryka jest znacznie wygodniejsza od metryki D, ponieważ może przyjmować wartości z przedziału [0;1]. Wartość zero oznacza, że pakiet należy do ciągu głównego. Wartość równa 1 oznacza, że określony pakiet jest maksymalnie oddalony od tego ciągu. Dysponując tą metryką, można przeanalizować projekt pod kątem ogólnej zgodności z ciągiem głównym. Dla każdego pakietu można wyznaczyć wartość metryki D: każdy pakiet, dla którego wartość D nie jest bliska 0, można ponownie przeanalizować i przebudować. Z doświadczenia wiem, że tego rodzaju 2

Nazwę „ciąg główny” przyjąłem ze względu na moje zainteresowania astronomią oraz diagramami HR.

ZASADA STABILNYCH ABSTRAKCJI (SAP)

279

analizy bardzo pomagały mi w definiowaniu komponentów, które są łatwiejsze w utrzymaniu i w mniejszym stopniu podatne na zmiany. Możliwe jest również przeprowadzanie analizy statystycznej projektu. Można obliczyć średnią i wariancję wartości metryki D dla wszystkich pakietów należących do projektu. Od dobrego projektu można oczekiwać niskich wartości zarówno średniej, jak i wariancji. Wariancja może służyć do ustanawiania „progów kontrolnych” pozwalających na identyfikację pakietów, które są „wyjątkowe” w porównaniu z pozostałymi (patrz rysunek 20.14).

Rysunek 20.14. Wykres punktowy wartości metryki D

Na wykresie punktowym przedstawionym na rysunku3 widać, że większość punktów reprezentujących pakiety leży w pobliżu ciągu głównego, ale niektóre pakiety znajdują się w odległości przekraczającej odchylenie standardowe (Z = 1). Warto zwrócić uwagę na te specyficzne pakiety. Prawdopodobnie są to pakiety albo bardzo abstrakcyjne z małą liczbą pakietów zależnych, albo bardzo konkretne z dużą liczbą pakietów zależnych. Innym sposobem wykorzystywania opisywanych metryk jest wykreślenie wartości metryki D' dla każdego pakietu na osi czasu. Przykład takiego wykresu zamieszczono na rysunku 20.15. Jak można zauważyć, w ciągu ostatnich kilku publikacji do pakietu Payroll przedostały się dość dziwne zależności. Na wykresie zaznaczono próg kontrolny dla wartości D' = 0,1. Ten próg został przekroczony dla publikacji R2.1. W związku z tym warto sprawdzić, dlaczego interesujący nas pakiet tak bardzo oddalił się od ciągu głównego.

Rysunek 20.15. Wykres czasowy wartości metryki D' pojedynczego pakietu

3

Wykres sporządzono na podstawie fikcyjnych danych.

280

ROZDZIAŁ 20. ZASADY PROJEKTOWANIA PAKIETÓW

Wniosek Metryki zarządzania zależnościami opisane w tym rozdziale pozwalają na ocenę zgodności projektu ze wzorcem zależności i abstrakcji uważanym za „dobry”. Z doświadczenia wynika, że niektóre zależności są dobre, natomiast inne złe. Zaprezentowany wzorzec jest wynikiem takich doświadczeń. Trzeba jednak pamiętać, że metryka sama w sobie nie może być „dobra” lub „zła” — ma jedynie określać ocenę względem jakiegoś standardu. Jest całkowicie możliwe, że standard wybrany w tym rozdziale jest odpowiedni tylko dla pewnych aplikacji, natomiast dla innych jest niewłaściwy. Istnieje także możliwość, że istnieją znacznie lepsze metryki opisujące jakość projektu.

R OZDZIAŁ 21

Wzorzec projektowy Fabryka

Człowiek, który buduje fabrykę, buduje świątynię... — Calvin Coolidge (1872 – 1933)

Zasada odwracania zależności (DIP1) mówi, że powinniśmy preferować zależności od klas abstrakcyjnych oraz unikać zależności od klas konkretnych, szczególnie jeśli te klasy często się zmieniają. Zatem poniższy fragment kodu narusza tę regułę: Circle c = new Circle(origin, 1);

Circle jest klasą konkretną. Z tego powodu moduły tworzące egzemplarze klasy Circle muszą naruszać zasadę DIP. W istocie każda linijka kodu, w której użyto słowa kluczowego new, narusza regułę DIP. W niektórych przypadkach naruszanie reguły DIP jest niemal nieszkodliwe2. Im wyższe prawdopodobieństwo zmian w konkretnej klasie, tym bardziej trzeba się liczyć z problemami uzależniania od tej klasy zewnętrznego kodu. Jeśli jednak konkretna klasa nie zmienia się często, to zależność od niej nie jest szkodliwa. Na przykład tworzenie egzemplarzy klasy String nie jest niczym złym. Zależność od klasy String jest bardzo bezpieczna, ponieważ nie istnieje duże prawdopodobieństwo częstych zmian w tej klasie. Z drugiej strony, jeśli aktywnie rozwijamy aplikację, musimy liczyć się z możliwością występowania wielu konkretnych klas, które często się zmieniają. Uzależnianie kodu od tych klas może być przyczyną problemów. Lepszym rozwiązaniem jest uzależnianie kodu od abstrakcyjnych interfejsów, które pozwalają na skuteczną ochronę przed większością zmian. 1

DIP — zasada odwracania zależności — rozdział 11.

2

To dość dobra wymówka.

282

ROZDZIAŁ 21. WZORZEC PROJEKTOWY FABRYKA

Wzorzec projektowy Fabryka (ang. Factory) umożliwia tworzenie egzemplarzy konkretnych klas oraz uzależnianie kodu wyłącznie od abstrakcyjnych interfejsów. Z tego powodu jest on dużym udogodnieniem w procesie aktywnego rozwoju oprogramowania w przypadku, gdy klasy konkretne często się zmieniają. Przykład scenariusza sprawiającego problemy pokazano na rysunku 21.1. Przedstawiono na nim klasę SomeApp, która zależy od interfejsu Shape. Klasa SomeApp korzysta z egzemplarzy klasy Shape wyłącznie za pośrednictwem interfejsu Shape. Nie wywołuje żadnych szczegółowych metod klas Square ani Circle. Niestety, klasa SomeApp tworzy egzemplarze klas Square i Circle i dlatego zależy od tych konkretnych klas.

Rysunek 21.1. Aplikacja narusza zasadę DIP ze względu na tworzenie egzemplarzy konkretnych klas

Problem można rozwiązać, stosując dla klasy SomeApp wzorzec projektowy Fabryka, tak jak pokazano na rysunku 21.2. W tym przypadku zastosowano interfejs ShapeFactory. Ten interfejs zawiera dwie metody: makeSquare oraz makeCircle. Metoda makeSquare zwraca egzemplarz klasy Square, natomiast metoda makeCircle zwraca egzemplarz klasy Circle. Jednak obie te metody zwracają obiekt implementujący interfejs Shape.

Rysunek 21.2. Zastosowanie wzorca projektowego Fabryka

Kod interfejsu ShapeFactory zamieszczono na listingu 21.1. Implementację tego interfejsu zamieszczono na listingu 21.2.

CYKL ZALEŻNOŚCI

283

Listing 21.1. ShapeFactory.java public interface ShapeFactory { public Shape makeCircle(); public Shape makeSquare(); }

Listing 21.2. ShapeFactoryImplementation.java public class ShapeFactoryImplementation implements ShapeFactory { public Shape makeCircle() { return new Circle(); }

}

public Shape makeSquare() { return new Square(); }

Warto zwrócić uwagę, że zastosowanie wzorca projektowego Fabryka całkowicie rozwiązuje problem zależności od konkretnych klas. Kod aplikacji nie zależy już od klas Circle ani Square, pomimo że egzemplarze tych klas są tworzone. Operacje na tych egzemplarzach są wykonywane za pośrednictwem interfejsu Shape. Aplikacja nigdy nie wywołuje metod, które są specyficzne dla klas Square bądź Circle. Problem zależności od konkretnej klasy przeniesiono na inny poziom. Ktoś musi teraz utworzyć obiekt ShapeFactoryImplementation, ale nikt więcej nie będzie musiał tworzyć egzemplarzy obiektów Square bądź Circle. Obiekt ShapeFactoryImplementation najprawdopodobniej zostanie stworzony wewnątrz funkcji main lub w funkcji inicjalizacyjnej dołączonej do funkcji main.

Cykl zależności Uważni czytelnicy z pewnością zauważyli problem z zastosowaniem wzorca projektowego Fabryka w tej formie. Klasa ShapeFactory zawiera metodę dla każdej pochodnej klasy Shape. W efekcie powstaje cykl zależności, który utrudnia dodawanie nowych pochodnych klasy Shape. Za każdym razem po utworzeniu nowej pochodnej klasy Shape trzeba będzie dodać metodę do interfejsu ShapeFactory(). W większości przypadków oznacza to konieczność ponownej kompilacji i instalacji wszystkich aplikacji klienckich korzystających z interfejsu ShapeFactory3. Aby pozbyć się tego cyklu zależności, trzeba w pewnym stopniu zrezygnować z bezpieczeństwa typów. Zamiast definiować w interfejsie ShapeFactory po jednej metodzie dla każdej pochodnej klasy Shape, możemy zdefiniować w nim jedną funkcję make, która pobiera argument typu String. Dla przykładu przeanalizujmy kod z listingu 21.3. Pokazana technika wymaga zastosowania wewnątrz klasy ShapeFactoryImplementation ciągu instrukcji if else sprawdzających wartość argumentu wejściowego po to, aby wybrać właściwą pochodną klasy Shape, której egzemplarz ma być stworzony. Odpowiedni kod zamieszczono na listingach 21.4 i 21.5. Listing 21.3. Fragment kodu tworzący obiekt Circle public void testCreateCircle() throws Exception { Shape s = factory.make("Circle"); assert(s instanceof Circle); } 3

W Javie nie istnieje taki przymus. Można poradzić sobie bez ponownej kompilacji i instalacji aplikacji klienckich o zmienionym interfejsem, ale jest to ryzykowne.

284

ROZDZIAŁ 21. WZORZEC PROJEKTOWY FABRYKA

Listing 21.4. ShapeFactory.java public interface ShapeFactory { public Shape make(String shapeName) throws Exception; }

Listing 21.5. ShapeFactoryImplementation.java public class ShapeFactoryImplementation implements ShapeFactory { public Shape make(String shapeName) throws Exception { if (shapeName.equals("Circle")) return new Circle(); else if (shapeName.equals("Square")) return new Square(); else throw new Exception( "Klasa ShapeFactory nie może utworzyć " + shapeName); } }

Można by polemizować, że takie podejście jest zbyt niebezpieczne, ponieważ jeśli programista popełni literówkę w nazwie figury, to niedopatrzenie to ujawni się dopiero w czasie wykonywania programu, a nie jako błąd kompilacji. To prawda. Jeśli jednak napiszemy odpowiednie testy jednostkowe i będziemy stosować techniki projektowania „najpierw test”, to błędy te zostaną wychwycone na długo, zanim staną się prawdziwymi problemami.

Fabryki wymienne Jedną z zalet wzorca projektowego Fabryka jest możliwość zastępowania jednej implementacji fabryki inną. W ten sposób można wymieniać w aplikacji całe rodziny obiektów. Dla przykładu wyobraźmy sobie aplikację, która musi mieć możliwość korzystania z wielu różnych implementacji bazy danych. Dla potrzeb przykładu załóżmy, że użytkownicy mogą korzystać ze zwykłych plików bądź z adapterów bazy danych Oracle. Można by skorzystać ze wzorca projektowego Pełnomocnik (ang. Proxy)4 w celu odseparowania aplikacji od implementacji bazy danych. Do stworzenia egzemplarzy klas-pełnomocników również można zastosować fabryki. Właściwą strukturę pokazano na rysunku 21.3. Zwróćmy uwagę, że mamy tam dwie implementacje interfejsu EmployeeFactory. Jedna tworzy klasy-pełnomocników, które działają z płaskimi plikami, natomiast druga tworzy odpowiednie klasy działające z bazą danych Oracle™. Zwróćmy również uwagę, że aplikacja „nie wie”, która z tych implementacji jest używana.

Wykorzystanie wzorca Fabryka do tworzenia zestawów testowych Podczas pisania testów jednostkowych często chcemy przetestować zachowanie modułu w oderwaniu od modułów, z których ten moduł korzysta. Dla przykładu rozważmy aplikację Payroll, która korzysta z bazy danych (patrz rysunek 21.4). Możemy przetestować działanie modułu Payroll całkowicie bez korzystania z bazy danych.

4

Wzorzec projektowy Pełnomocnik zostanie omówiony w dalszej części tej książki, w rozdziale 26. Teraz wystarczy, jeśli zapamiętamy, że klasa pełnomocnika „wie”, w jaki sposób należy czytać poszczególne obiekty z poszczególnych rodzajów baz danych.

WYKORZYSTANIE WZORCA FABRYKA DO TWORZENIA ZESTAWÓW TESTOWYCH

285

Rysunek 21.3. Fabryki wymienne

Rysunek 21.4. Klasa Payroll korzysta z klasy Database

Aby to osiągnąć, możemy skorzystać z abstrakcyjnego interfejsu dla bazy danych. Jedna z implementacji tego abstrakcyjnego interfejsu korzysta z prawdziwej bazy danych. Drugą implementacją jest kod testowy napisany w celu zasymulowania zachowania bazy danych oraz do sprawdzenia, czy odwołania do bazy danych są wykonywane prawidłowo. Właściwą strukturę pokazano na rysunku 21.5. Moduł PayrollTest testuje klasę PayrollModule poprzez kierowanie do niego wywołań. Ponadto implementuje interfejs Database tak, aby móc przechwytywać wywołania, które klasa Payroll kieruje do bazy danych. Dzięki temu obiekt klasy PayrollTest może sprawdzić, czy klasa Payroll zachowuje się prawidłowo. Pozwala również klasie PayrollTest symulować wiele rodzajów błędów bazy danych oraz problemów, które w innym przypadku byłyby trudne do zasymulowania. Taka technika czasami jest określana jako imitowanie (ang. spoofing).

Rysunek 21.5. Klasa PayrollTest imituje klasę Database

286

ROZDZIAŁ 21. WZORZEC PROJEKTOWY FABRYKA

Zastanówmy się, jak klasa Payroll uzyskuje egzemplarz klasy PayrollTest, który jest następnie wykorzystywany zamiast obiektu Database. Oczywiście obiekt klasy Payroll nie tworzy egzemplarza klasy PayrollTest. Pomimo to obiekt Payroll musi jakoś uzyskać referencję do implementacji obiektu Database, z którego będzie korzystał. W niektórych przypadkach całkowicie naturalnym podejściem jest przekazanie przez obiekt PayrollTest do obiektu Payroll referencji do obiektu Database. W innych przypadkach obiekt PayrollTest musi skorzystać ze zmiennej globalnej w celu odwołania się do obiektu Database. W jeszcze innych przypadkach egzemplarz obiektu Database może tworzyć obiekt Payroll. W tym ostatnim przypadku możemy skorzystać ze wzorca projektowego Fabryka, aby „oszukać” obiekt Payroll, tak by stworzył testową wersję obiektu Database. W tym celu wystarczy przekazać do obiektu Payroll alternatywną wersję fabryki. Możliwą strukturę pokazano na rysunku 21.6. Moduł Payroll uzyskuje dostęp do fabryki za pośrednictwem zmiennej globalnej (lub statycznej zmiennej w globalnej klasie) o nazwie GdatabaseFactory. Moduł PayrollTest implementuje interfejs DatabaseFactory i przypisuje referencję do samego siebie do zmiennej GdatabaseFactory. Kiedy obiekt Payroll korzysta z fabryki w celu stworzenia obiektu Database, moduł PayrollTest przechwytuje to wywołanie i przekazuje referencję do samego siebie. Z tego powodu obiekt Payroll jest „przekonany”, że stworzył obiekt PayrollDatabase. Dzięki temu moduł PayrollTest może „oszukać” moduł Payroll i przechwycić wszystkie wywołania do bazy danych.

Rysunek 21.6. Imitowanie fabryki

Znaczenie korzystania z fabryk W przypadku ścisłego przestrzegania zasady DIP fabryki należałoby stosować dla wszystkich zmieniających się klas w systemie. Poza tym możliwości wzorca projektowego Fabryka są bardzo kuszące. Te dwa czynniki czasami powodują, że programiści wpadają w pułapkę nadużywania tego wzorca. Jest to podejście ekstremalne, którego nie polecam. Osobiście początkowo nie korzystam z fabryk. Stosuję je w systemie tylko wtedy, gdy powstaną ku temu ważne powody. Na przykład kiedy zachodzi konieczność użycia wzorca Pełnomocnik, to najprawdopodobniej trzeba skorzystać z fabryki do stworzenia obiektów trwałych. Podobnie jeśli podczas tworzenia testów jednostkowych napotkam sytuacje, w których muszę podszyć się pod twórcę obiektu, to najczęściej korzystam z fabryki. Nie zakładam jednak, że stosowanie fabryk jest koniecznością. Fabryki wprowadzają dodatkową złożoność, której można uniknąć, zwłaszcza we wczesnych fazach rozwijającego się projektu. Domyślne stosowanie fabryk znacznie utrudnia rozbudowę projektu. Utworzenie nowej klasy może wymagać utworzenia nawet czterech nowych klas: dwóch interfejsów reprezentujących nową klasę oraz jej fabrykę oraz dwóch konkretnych klas implementujących te interfejsy.

BIBLIOGRAFIA

287

Wniosek Wzorzec projektowy Fabryka daje duże możliwości. Jest istotnym narzędziem zapewniania zgodności z zasadą odwracania zależności (DIP). Pozwala modułom, które implementują wysokopoziomową strategię, tworzyć egzemplarze klas bez wprowadzania zależności od konkretnych implementacji. Pozwala również zastępować grupy klas całkowicie odmiennymi rodzinami implementacji. Trzeba równocześnie pamiętać, że fabryki wprowadzają dodatkową złożoność, której często można uniknąć. Nadużywanie ich rzadko jest właściwym sposobem postępowania.

Bibliografia 1. Gamma, et al., Design Patterns, Reading, MA: Addison-Wesley, 1995.

288

ROZDZIAŁ 21. WZORZEC PROJEKTOWY FABRYKA

R OZDZIAŁ 22

Studium przypadku: system płacowy (część 2.)

Dobra rada: Jeśli sądzisz, że coś jest inteligentne i wyszukane, uważaj — to prawdopodobnie samouwielbienie — Donald A. Norman, The Design of Everyday Things, 1990

Dotychczas mnóstwo czasu poświęciliśmy na analizę, projektowanie i implementację systemu płacowego. Jednak w dalszym ciągu musimy podjąć wiele decyzji projektowych. Do tej pory nad problemem pracował tylko jeden programista — byłem nim ja. Bieżąca struktura środowiska wytwarzania oprogramowania jest spójna z tym stanem rzeczy. Wszystkie pliki programów są umieszczone w jednym katalogu. W ogóle nie istnieje struktura wyższego poziomu. Nie ma pakietów, podsystemów, oddzielnie publikowanych modułów innych niż cała aplikacja. Takie rozwiązanie w przyszłości się nie sprawdzi. Musimy założyć, że w miarę rozwoju tego programu będzie rosła również liczba osób, które nad nim pracują. Aby projekt stał się wygodny dla wielu deweloperów, trzeba będzie podzielić kod źródłowy na pakiety, które można wygodnie pobierać, modyfikować i testować. Aplikacja płacowa obecnie składa się z 3280 linii kodu, podzielonych na około 50 różnych klas i 100 różnych plików źródłowych. Chociaż nie jest to ogromna liczba, to obsługa tylu jednostek stanowi pewne obciążenie organizacyjne. Jak należy zarządzać plikami źródłowymi? Jak należy podzielić zadania implementacji, aby proces wytwarzania oprogramowania przebiegał sprawnie, a programiści nie wchodzili sobie w drogę? Chcielibyśmy podzielić klasy na grupy, które będą pozwalały indywidualnym programistom lub zespołom na wygodne pobieranie i utrzymywanie.

290

ROZDZIAŁ 22. STUDIUM PRZYPADKU: SYSTEM PŁACOWY (CZĘŚĆ 2.)

Struktura pakietów i notacja Diagram z rysunku 22.1 przedstawia możliwą strukturę pakietów dla aplikacji płacowej. Oceną, czy ta struktura jest właściwa, zajmiemy się później. Na razie ograniczymy się do tego, w jaki sposób taka struktura jest udokumentowana i wykorzystywana.

Rysunek 22.1. Możliwy diagram pakietów aplikacji płacowej

Na stronie 487 zamieszczono opis notacji UML w odniesieniu do pakietów. Zgodnie z konwencją diagramy pakietów są rysowane z zależnościami skierowanymi do dołu. Pakiety na górze zależą od pakietów narysowanych niżej. Zgodnie z rysunkiem 22.1 aplikację płacową podzielono na osiem pakietów. Pakiet PayrollApplication zawiera klasy PayrollApplication oraz klasy TransactionSource i TextParserTransactionSource. Pakiet Transactions zawiera kompletną hierarchię klasy Transaction. Jeśli uważnie przyjrzymy się diagramowi, nie powinniśmy mieć trudności z interpretacją składników innych pakietów. Zależności również powinny być czytelne. Pakiet PayrollApplication zależy od pakietu Transactions, ponieważ klasa PayrollApplication wywołuje metodę Transaction::Execute. Pakiet Transactions zależy od pakietu PayrollDatabase, ponieważ każda z wielu klas pochodnych klasy Transaction bezpośrednio komunikuje się z klasą PayrollDatabase. Pozostałe zależności mogą być uzasadnione w taki sam sposób. Jakie kryteria zostały użyte w celu pogrupowania tych klas w pakiety? Po prostu do tego samego pakietu przyporządkowałem klasy, które sprawiały wrażenie, że wykonują podobne funkcjonalności. Jak dowiedzieliśmy się w rozdziale 20., takie postępowanie nie jest najlepszym pomysłem. Zastanówmy się, co się stanie, jeśli wprowadzimy zmianę do pakietu Classifications. Wymusi to ponowną kompilację i testowanie pakietu EmployeeDatabase, co zresztą wydaje się słuszne. Ale zmiana wymusi także ponowną kompilację i testowanie pakietu Transactions. Z całą pewnością klasa ChangeClassificationTransaction oraz jej trzy klasy potomne z rysunku 19.3 powinny być ponownie skompilowane i przetestowane, ale dlaczego zmiana spowodowała również konieczność ponownej kompilacji i testowania innych modułów?

ZASTOSOWANIE ZASADY ZBIOROWEGO DOMYKANIA (CCP)

291

Z technicznego punktu widzenia te inne transakcje nie wymagają ponownej kompilacji i testowania. Jeśli jednak są one częścią pakietu Transactions oraz jeśli pakiet ma być ponownie opublikowany, aby uwzględnić zmiany wprowadzone w pakiecie Classifications, to rezygnacja z ponownej kompilacji i testowania pakietu jako całości może się wydawać nieodpowiedzialna. Nawet jeśli nie wszystkie transakcje są ponownie skompilowane i przetestowane, sam pakiet musi być ponownie opublikowany i wdrożony, a wtedy wszystkie jego aplikacje klienckie będą wymagały co najmniej weryfikacji, a prawdopodobnie również ponownej kompilacji. Klasy należące do pakietu Transactions nie mają wspólnego domknięcia. Każda z nich jest wrażliwa na własne, konkretne zmiany. Klasa ServiceChargeTransaction jest otwarta na zmiany w klasie ServiceCharge, natomiast klasa TimeCardTransaction jest otwarta na zmiany w klasie TimeCard. W rzeczywistości, jak widać na rysunku 22.1, pewna część pakietu Transactions zależy od prawie wszystkich pozostałych części oprogramowania. Zatem ten pakiet będzie musiał być bardzo często publikowany. Za każdym razem, gdy zmieni się coś w niższych warstwach, trzeba będzie zweryfikować pakiet Transactions i go ponownie opublikować. Pakiet PayrollApplication jest jeszcze bardziej wrażliwy na zmiany: każda zmiana w dowolnej części systemu będzie miała wpływ na ten pakiet, dlatego częstość jego publikowania może być ogromna. Można by pomyśleć, że jest to nieuniknione. Im wyżej pakiet znajduje się w hierarchii, tym większa częstotliwość jego publikowania. Na szczęście nie jest to prawdą, a unikanie tej własności jest jednym z głównych celów programowania obiektowego.

Zastosowanie zasady zbiorowego domykania (CCP) Rozważmy diagram z rysunku 22.2. Pogrupowano na nim klasy aplikacji płacowej zgodnie z ich domknięciami. Na przykład pakiet PayrollApplication zawiera klasy PayrollApplication i TransactionSource. Obie te klasy zależą od abstrakcyjnej klasy Transaction, która należy do pakietu PayrollDomain. Zwróćmy uwagę, że klasa TextParserTransactionSource to inny pakiet, który zależy od abstrakcyjnej klasy PayrollApplication. W ten sposób powstaje odwrócona struktura, w której klasy szczegółowe zależą od klas ogólnych, natomiast klasy ogólne są niezależne. Taka struktura jest zgodna z zasadą DIP. Najbardziej oczywistym przykładem ogólności i niezależności jest pakiet PayrollDomain. Ten pakiet zawiera esencję całego systemu, a pomimo to nie zależy od żadnego innego pakietu! Spróbujmy dokładnie przeanalizować ten pakiet. Zawiera on klasy Employee, PaymentClassification, PaymentMethod, PaymentSchedule, Affiliation oraz Transaction. Ten pakiet zawiera wszystkie najważniejsze abstrakcje w naszym modelu, a mimo to nie ma zależności! Dlaczego? Ponieważ prawie wszystkie klasy, które on zawiera, są abstrakcyjne. Rozważmy pakiet Classifications zawierający trzy klasy potomne klasy PaymentClassification. Zawiera on także klasę ChangeClassificationTransaction wraz z jej trzema klasami potomnymi oraz klasami TimeCard i SalesReceipt. Zwróćmy uwagę, że dowolna zmiana wprowadzona w tych dziewięciu klasach jest odizolowana. Nie ma wpływu na żadne pakiety oprócz pakietu TextParser! Taka izolacja dotyczy także pakietu Methods, pakietu Schedules oraz Affiliations. To dość duży poziom izolacji. Zwróćmy uwagę, że większa część kodu wykonywalnego tych pakietów ma zaledwie kilka zależności lub nie ma ich wcale. Ponieważ żadne inne pakiety nie zależą od tych pakietów, nazywamy je nieodpowiedzialnymi (ang. irresponsible). Kod należący do tych pakietów jest niezwykle elastyczny. Można go zmieniać bez wpływu na wiele innych części projektu. Zauważmy także, że najbardziej ogólne pakiety tego systemu zawierają najmniejszą ilość kodu wykonywalnego. Te pakiety są w dużym stopniu zależne, ale nie zależą od niczego. Ponieważ wiele pakietów od nich zależy, nazywamy je odpowiedzialnymi (ang. responsible), a ponieważ nie zależą od niczego, nazywamy je niezależnymi (ang. independent). Zatem ilość odpowiedzialnego kodu (czyli takiego kodu, w którym zmiany będą miały wpływ na wiele innego kodu) jest bardzo mała. Ponadto ta niewielka część kodu odpowiedzialnego jest jednocześnie niezależna, co oznacza, że zmiany wprowadzone w innych modułach nie będą powodowały konieczności ich zmiany. Ta odwrócona struktura, w której wysoce niezależne i odpowiedzialne klasy ogólne znajdują się na dole, natomiast bardzo nieodpowiedzialne i zależne klasy szczegółowe na górze, jest charakterystyczną cechą projektowania obiektowego.

292

ROZDZIAŁ 22. STUDIUM PRZYPADKU: SYSTEM PŁACOWY (CZĘŚĆ 2.)

Rysunek 22.2. Zamknięta hierarchia pakietów dla aplikacji płacowej

Spróbujmy porównać rysunek 22.1 z rysunkiem 22.2. Zwróćmy uwagę, że klasy szczegółowe zaprezentowane w dolnej części rysunku 22.1 są niezależne i w wysokim stopniu odpowiedzialne. To nie jest właściwe miejsce na szczegóły! Szczegóły powinny zależeć od ważnych decyzji architektonicznych systemu i nie powinny być uzależnione od innych części systemu. Zauważmy również, że pakiety ogólne, które definiują architekturę systemu, są nieodpowiedzialne i w wysokim stopniu zależne. Zatem pakiety określające decyzje architektoniczne zależą od pakietów, które zawierają szczegóły implementacji. To jawne naruszenie zasady SAP. Byłoby lepiej, gdyby to architektura wprowadzała ograniczenia dla szczegółów!

Zastosowanie zasady równoważności wielokrotnego wykorzystania kodu i dystrybucji (REP) Jakie części aplikacji płacowej mogą być wykorzystane wielokrotnie? Gdyby pracownicy innego działu naszej firmy chcieli skorzystać z naszego systemu płacowego, ale używali zupełnie innego zestawu strategii, nie mogliby ponownie użyć pakietów Classifications, Methods, Schedules czy Affiliations. Mogliby jednak skorzystać z pakietów PayrollDomain, PayrollApplication, Application, PayrollDatabase oraz ewentualnie PDImplementation. Z drugiej strony, gdyby pracownicy innego działu chcieli napisać oprogramowanie, które analizuje bieżącą bazę danych pracowników, mogliby użyć pakietów PayrollDomain, Classifications, Methods, Schedules, Affiliations, PayrollDatabase oraz PDImplementation. W każdym przypadku jednostką wielokrotnego użytku jest pakiet.

ZASTOSOWANIE ZASADY RÓWNOWAŻNOŚCI WIELOKROTNEGO WYKORZYSTANIA KODU I DYSTRYBUCJI (REP) 293

Bardzo rzadko, o ile w ogóle, może być wykorzystana wielokrotnie pojedyncza klasa z pakietu. Powód jest prosty: klasy należące do pakietu powinny być ze sobą spójne. Oznacza to, że zależą wzajemnie od siebie i nie mogą być w łatwy i sensowny sposób rozdzielone. Na przykład nie miałoby sensu używanie klasy Employee bez używania klasy PaymentMethod. Aby to zrobić, trzeba by zmodyfikować klasę Employee w taki sposób, aby nie była zależna od klasy PaymentMethod. Z pewnością nie chcemy wspierać takiego rodzaju ponownego użycia, które zmusza nas do modyfikowania wielokrotnie wykorzystywanych komponentów. Z tego powodu jednostką wielokrotnego użytku jest pakiet. Wynika stąd kolejne kryterium spójności, które należy stosować podczas grupowania klas w pakiety: klasy nie tylko powinny mieć wspólne domknięcie, powinny również pozwalać na wielokrotne wykorzystywanie w zgodzie z zasadą REP. Rozważmy jeszcze raz wyjściowy diagram pakietów z rysunku 22.1. Pakiety, które mogłyby być wielokrotnie użyte, takie jak Transactions czy PayrollDatabase, nie mogą być łatwo wykorzystane, ponieważ pociągają za sobą sporo dodatkowego bagażu. Pakiet PayrollApplication jest bardzo mocno uzależniony (zależy od wszystkich części systemu). Gdybyśmy chcieli stworzyć nową aplikację płacową, która używa innego zbioru harmonogramów, metod, przynależności do związków zawodowych i form zatrudnienia, nie moglibyśmy skorzystać z tego pakietu jako całości. Musielibyśmy pobrać pojedyncze klasy z pakietów PayrollApplication, Transactions, Methods, Schedules, Classifications i Affiliations. Podzielenie pakietów w taki sposób niszczy ich strukturę dystrybucji. Nie można powiedzieć, że dystrybucja 3.2 aplikacji PayrollApplication nadaje się do wielokrotnego użycia. Struktura przedstawiona na rysunku 22.1 narusza zasadę CRP. Gdyby więc użytkownik zaakceptował do wielokrotnego użytku fragmenty różnych naszych pakietów, musiałby zmierzyć się z trudnym problemem zarządzania: nie byłby w stanie utrzymać zależności od naszej struktury dystrybucji. Nowa publikacja pakietu Methods miałaby na niego wpływ ze względu na wykorzystanie klasy PaymentMethod. W większości przypadków zmiany będą wprowadzane w klasach, które nie są ponownie wykorzystywane. Pomimo to trzeba śledzić nowe numery wersji dystrybucyjnych pakietu oraz prawdopodobnie ponownie skompilować i przetestować kod. To może być tak trudne do zorganizowania, że użytkownik może się zdecydować na wykonanie kopii komponentów wielokrotnego użytku i rozwijanie tej kopii oddzielnie od naszej. Takie postępowanie nie ma wiele wspólnego z wielokrotnym używaniem. Te dwa fragmenty kodu wkrótce będą różne i będą wymagały utrzymywania niezależnie od siebie, co w efekcie podwoi potrzebne nakłady pracy. Takich problemów nie ma w przypadku zastosowania struktury pokazanej na rysunku 22.2. Pakiety należące do tej struktury są łatwiejsze do ponownego wykorzystania. Pakiet PayrollDomain nie jest obciążony tak dużym bagażem zależności. Może on być wykorzystywany niezależnie od pochodnych klas PaymentMethod, PaymentClassification, PaymentSchedule itd. Spostrzegawczy czytelnicy z pewnością zauważyli, że schemat pakietów z rysunku 22.2 nie do końca spełnia zasadę CRP. Można zauważyć, że klasy należące do pakietu PayrollDomain nie tworzą najmniejszej jednostki wielokrotnego użytku. Klasa Transaction nie musi być ponownie wykorzystywana razem z pozostałą częścią pakietu. Można by zaprojektować wiele aplikacji, które wykorzystują obiekty klasy Employee i jej pola, ale nigdy nie korzystają z obiektu Transaction. To wskazuje na konieczność wprowadzenia zmian w schemacie pakietu, tak jak pokazano na rysunku 22.3. W ten sposób oddzielamy transakcje od elementów, którymi one manipulują. Na przykład klasy należące do pakietu MethodTransactions wykonują operacje na klasach z pakietu Methods. Klasę Transaction przenieśliśmy do nowego pakietu pod nazwą TransactionApplication. Pakiet ten zawiera również klasę TransactionSource oraz klasę TransactionApplication. Te trzy klasy tworzą jednostkę wielokrotnego użytku. Klasa PayrollApplication stała się teraz jednostką scalającą. Zawiera główny program oraz pochodną klasy TransactionApplication o nazwie PayrollApplication, która łączy klasę TextParserTransactionSource z klasą TransactionApplication. Wykonanie tych manipulacji spowodowało dodanie kolejnej warstwy abstrakcji do projektu. Pakiet TransactionApplication może być teraz wykorzystywany przez dowolną aplikację, która pobiera obiekty klasy Transaction za pośrednictwem klasy TransactionSource, a następnie wykonuje na nich metodę Execute. Pakiet PayrollApplication nie może być już wielokrotnie wykorzystywany, ponieważ jest bardzo

294

ROZDZIAŁ 22. STUDIUM PRZYPADKU: SYSTEM PŁACOWY (CZĘŚĆ 2.)

mocno uzależniony od innych pakietów. Jednak zastąpił go pakiet TransactionApplication, który jest bardziej ogólny. Możemy teraz wykorzystywać pakiet PayrollDomain bez żadnych obiektów klasy Transaction. To z pewnością zwiększa możliwość wielokrotnego użycia i łatwość konserwacji projektu, ale kosztem pięciu dodatkowych pakietów i bardziej złożonej architektury zależności. Cena tego kompromisu zależy od oczekiwanego modelu wielokrotnego używania pakietów oraz tempa zmian aplikacji. Jeśli aplikacja jest bardzo stabilna i niewielu klientów z niej korzysta, to wprowadzenie tego rodzaju zmiany jest przesadą. Z drugiej strony, jeżeli wiele aplikacji będzie korzystało z tej struktury lub jeśli oczekujemy wielu zmian w aplikacji, to nowa struktura jest lepsza. Wszystko zależy od właściwej oceny sytuacji, która powinna opierać się na dokładnych danych, a nie na spekulacjach. Najlepszym rozwiązaniem jest rozpoczęcie od prostej struktury i rozwijanie jej w miarę potrzeb. Strukturę pakietów zawsze można rozwinąć, jeśli zajdzie taka konieczność.

Sprzężenia i hermetyzacja Podobnie jak sprzężenia pomiędzy klasami są zarządzane przez granice hermetyzacji w Javie i C++, tak sprzężenia pomiędzy pakietami mogą być zarządzane przez oznaczenia eksportu — tzw. ozdobniki (ang. adornments) — w notacji UML.

Rysunek 22.3. Zaktualizowany diagram pakietów aplikacji płacowej

SPRZĘŻENIA I HERMETYZACJA

295

Jeśli klasa należąca do określonego pakietu ma być wykorzystana w innym pakiecie, ta klasa musi być wyeksportowana. W notacji UML klasy są eksportowane domyślnie. Można jednak wprowadzić dodatkowe oznaczenia, które pokazują, że określone klasy pakietu nie mają być eksportowane. Z opisu pakietu Classifications na rysunku 22.4 widać, że trzy pochodne klasy PaymentClassification są eksportowane, ale klasy TimeCard i SalesReceipt nie należą do tej grupy. To oznacza, że inne pakiety nie będą w stanie korzystać z pakietów TimeCard i SalesReceipt. Te klasy są prywatne dla pakietu Classifications.

Rysunek 22.4. Klasy prywatne w pakiecie Classifications

Czasami może być korzystne ukrycie niektórych klas w obrębie pakietu, aby zapobiec niepotrzebnym sprzężeniom. Pakiet Classifications jest bardzo szczegółowy — zawiera implementacje kilku sposobów wynagrodzeń. W celu utrzymania tego pakietu w ciągu głównym chcemy ograniczyć jego sprzężenia przychodzące. Z tego powodu ukrywamy klasy, o których inne pakiety nie muszą „wiedzieć”. Dobrym przykładem klas prywatnych są klasy TimeCard i SalesReceipt. Te klasy zawierają szczegóły implementacji mechanizmów obliczania wynagrodzenia pracowników. Chcemy pozostawić swobodę zmian tych szczegółów, dlatego musimy zadbać o to, aby inne pakiety nie zależały od ich struktury. Wystarczy spojrzeć na rysunki od 19.7 do 19.10 oraz kod z listingu 19.15, aby zauważyć, że klasy TimeCardTransaction i SalesReceiptTransaction już zależą od klas TimeCard i SalesReceipt. Problem ten można łatwo rozwiązać, jak pokazano na rysunkach 22.5 i 22.6.

Rysunek 22.5. Modyfikacja klasy TimeCardTransaction w celu ochrony prywatności klasy TimeCard

Rysunek 22.6. Modyfikacja klasy SalesReceiptTransaction w celu ochrony prywatności klasy SalesReceipt

296

ROZDZIAŁ 22. STUDIUM PRZYPADKU: SYSTEM PŁACOWY (CZĘŚĆ 2.)

Metryki Jak pokazano w rozdziale 20., możemy obliczyć atrybuty spójności, sprzężeń, stabilności, ogólności i zgodności z ciągiem głównym za pomocą kilku prostych wskaźników. Zastanówmy się jednak, dlaczego to robimy? Parafrazując powiedzenie Toma DeMarco: nie można zarządzać tym, czego nie można kontrolować, a nie da się kontrolować tego, czego nie można zmierzyć1. Skuteczny inżynier oprogramowania bądź menedżer oprogramowania musi być w stanie kontrolować praktyki wytwarzania oprogramowania. Jeśli jednak nie będziemy w stanie ich mierzyć, nigdy nie będziemy potrafili ich kontrolować. Dzięki zastosowaniu heurystyki opisanej poniżej oraz obliczeniu kilku podstawowych wskaźników projektów obiektowych możemy zacząć korelować te wskaźniki z mierzoną wydajnością oprogramowania, a także wydajnością zespołów, które rozwijają to oprogramowanie. Im więcej metryk zdołamy zebrać, tym większą ilością informacji będziemy dysponowali, a co za tym idzie — będziemy mieć większą kontrolę nad oprogramowaniem. Wskaźniki opisane poniżej zostały z powodzeniem zastosowane w wielu projektach prowadzonych od 1994 roku. Istnieje kilka automatycznych narzędzi, które pozwalają je obliczać, ale wykonanie obliczeń ręcznie także nie jest trudne. Można również napisać prosty skrypt powłoki albo program w Pythonie lub Ruby, który przegląda pliki źródłowe i oblicza potrzebne wskaźniki2.  H (spójność relacyjna). Jeden z aspektów spójności pakietu może być wyrażony za pomocą średniej

liczby wewnętrznych relacji na klasę. Niech R oznacza liczbę relacji klas wewnątrz pakietu (tzn. takich, które nie łączą klas na zewnątrz pakietu). Przyjmijmy ponadto, że N oznacza liczbę klas wewnątrz pakietu). Dodanie liczby 1 we wzorze zabezpiecza przed przyjęciem wartości H = 0 w przypadku, gdy N = 1. Wartość ta reprezentuje relację łączącą pakiet ze wszystkimi jego klasami.

H 





Ca (sprzężenia przychodzące) można zaprezentować jako liczbę klas z innych pakietów, które zależą od klas wchodzących w skład badanego pakietu. Te zależności oznaczają takie relacje łączące klasy jak dziedziczenie i asocjacje. Ce (sprzężenia wychodzące) można reprezentować za pomocą liczby klas należących do innych pakietów, od których są uzależnione klasy wchodzące w skład badanego pakietu. Tak jak poprzednio te zależności oznaczają związki pomiędzy klasami. A (abstrakcyjność lub ogólność) można obliczyć jako iloraz liczby klas abstrakcyjnych (lub interfejsów) w pakiecie do całkowitej liczby grup (i) interfejsów wchodzących w skład tego pakietu3. Opisany wskaźnik przyjmuje wartości z przedziału od 0 do 1. A



R 1 N

Klasy abstrakcyjne Wszystkie klasy

I (niestabilność) można obliczyć jako stosunek liczby sprzężeń wychodzących do całkowitej liczby sprzężeń. Ten wskaźnik także przyjmuje wartości z przedziału od 0 do 1.

1

[DeMarco82], str. 3.

2

Przykładowy skrypt powłoki — depend.sh — można pobrać z sekcji freeware witryny www.objectmentor.com. Można również przyjrzeć się skryptowi JDepend w witrynie www.clarkware.com.

3

Można by sądzić, że lepszy wzór na wskaźnik A powinien mieć postać stosunku liczby funkcji czysto wirtualnych do wszystkich funkcji składowych w ramach pakietu. Jednak w mojej opinii ten wzór za bardzo osłabia wskaźnik abstrakcyjności. Należy pamiętać, że nawet jedna czysto wirtualna funkcja powoduje, że cała klasa jest abstrakcyjna. Fakt abstrakcyjności klasy jest bardziej znaczący od faktu, że klasa zawiera dziesiątki konkretnych funkcji — zwłaszcza jeśli programiści przestrzegają reguły DIP.

ZASTOSOWANIE WSKAŹNIKÓW DO APLIKACJI PŁACOWEJ

I 

Ce Ce  Ca

D (odległość od ciągu głównego). Ciąg główny jest reprezentowany przez prostą o równaniu A + I = 1. Wzór na wskaźnik D umożliwia obliczenie odległości określonego pakietu od ciągu głównego. Wskaźnik ma wartość z przedziału od 0 do około 0,74. Im bliżej do 0, tym lepiej.

D 

297

A  I 1 2

D' (znormalizowana odległość od ciągu głównego). Ten wskaźnik reprezentuje wskaźnik D znormalizowany do wartości z przedziału od 0 do 1. Ten wskaźnik jest nieco wygodniejszy w obliczeniach i interpretacji. Wartość zero oznacza, że pakiet należy do ciągu głównego. Wartość jeden oznacza pakiet, który jest w maksymalnym stopniu oddalony od ciągu głównego.

D '  A  I 1

Zastosowanie wskaźników do aplikacji płacowej W tabeli 22.1 pokazano, jak przypisano do pakietów klasy należące do modelu aplikacji płacowej. Na rysunku 22.7 pokazano diagram pakietów dla aplikacji płacowej z obliczonymi wszystkimi wskaźnikami. Z kolei w tabeli 22.2 zamieszczono wszystkie wskaźniki obliczone dla każdego pakietu. Każdej zależności pakietu przedstawionej na rysunku 22.7 towarzyszą dwie liczby. Liczba znajdująca się najbliżej pakietu uzależnionego reprezentuje liczbę klas w tym pakiecie, które zależą od pakietu zewnętrznego. Liczba znajdująca się najbliżej pakietu, od którego pakiet zależy, reprezentuje liczbę klas w tym pakiecie, od których zależą klasy pakietu zewnętrznego. Każdemu pakietowi z rysunku 22.7 towarzyszy skojarzona z nim metryka. Wiele z tych metryk wygląda zachęcająco. Na przykład metryki PayrollApplication, PayrollDomain i PayrollDatabase mają wysoką spójność relacyjną i albo znajdują się w ciągu głównym, albo w jego pobliżu. Z kolei pakiety Classifications, Methods i Schedules, ogólnie rzecz biorąc, wykazują słabą spójność relacyjną i są prawie maksymalnie oddalone od ciągu głównego. Liczby te informują nas o tym, że przyjęty przydział klas do pakietów nie jest najlepszy. Jeśli nie znajdziemy sposobu na poprawienie tych wskaźników, nasze środowisko projektowania będzie wrażliwe na zmiany, co z kolei może się wiązać z koniecznością niepotrzebnego publikowania wersji dystrybucyjnych i testowania pakietów. W szczególności mamy do czynienia z pakietami o niskiej wartości wskaźnika abstrakcyjności, na przykład ClassificationTransactions, które zależą od innych pakietów o niskiej abstrakcyjności, jak Classifications. Klasy o niskiej abstrakcyjności zawierają większość szczegółowego kodu, dlatego są podatne na zmiany. To wymusza konieczność publikowania wersji dystrybucyjnych pakietów, które od nich zależą. Oznacza to, że pakiet ClassificationTransactions będzie miał bardzo wysoką wartość częstotliwości publikacji, ponieważ mają na niego wpływ częste zmiany wprowadzane w nim samym, jak i w pakiecie Classifications. Na tyle, na ile to możliwe, chcielibyśmy ograniczyć wrażliwość środowiska wytwarzania oprogramowania na zmiany.

4

Wykreślenie punktu na wykresie wskaźników od A do I poza kwadratem o długości 1 jest niemożliwe. To dlatego, że ani wskaźnik A, ani I nie mogą przekroczyć wartości 1. Ciąg główny jest reprezentowany przez odcinek od punktu (0,1) do punktu (1,0). Punkty wewnątrz kwadratu, które znajdują się najdalej od ciągu głównego, to dwa przeciwległe narożniki obszaru — punkty (0,0) i (1,1). Ich odległość od ciągu głównego można obliczyć za pomocą wzoru: 2  0,70710678... 2

298

ROZDZIAŁ 22. STUDIUM PRZYPADKU: SYSTEM PŁACOWY (CZĘŚĆ 2.)

Tabela 22.1. Przydział klas do pakietów w aplikacji płacowej Pakiet

Klasy w pakiecie

Affiliations

ServiceCharge

UnionAffiliation

Affiliation Transactions

ChangeAffiliation Transaction

ChangeUnaffiliated-Transaction

ChangeMember-Transaction

SalariedClassification

ServiceChargeTransaction Application

Application

Classifications

Commissioned Classification

HourlyClassification

SalesReceipt

Timecard

ChangeClassification-Transaction

ChangeCommissioned-Transaction

ChangeHourly-Transaction

ChangeSalariedTransaction

SalesReceiptTransaction

TimecardTransaction

AddCommissionedEmployee

AddEmployeeTransaction

AddHourlyEmployee

AddSalariedEmployee

ChangeAddressTransaction

ChangeEmployee-Transaction

ChangeNameTransaction

DeleteEmployeeTransaction

PaydayTransaction

Methods

DirectMethod

HoldMethod

MailMethod

MethodTransactions

ChangeDirectTransaction

ChangeHoldTransaction

ChangeMailTransaction

PaymentClassification

Classification Transaction

GeneralTransactions

ChangeMethodTransaction PayrollApplication

PayrollApplication

PayrollDatabase

PayrollDatabase

PayrollDatabase-Implementation

PayrollDatabase-Implementation

PayrollDomain

Affiliation

Employee

PaymentMethod

PaymentSchedule

Schedules

BiweeklySchedule

MonthlySchedule

WeeklySchedule

TextParser Transaction-Source

TextParserTransaction Source

TransactionApplication

TransactionApplication

Transaction

TransactionSource

Jeśli zespół projektowy składa się z dwóch lub trzech programistów, to są oni w stanie efektywnie zarządzać środowiskiem wytwarzania oprogramowania, a potrzeba utrzymywania pakietów na linii ciągu głównego lub blisko niej będzie stosunkowo niska. Jednak im więcej programistów zaangażowanych w projekt, tym trudniej zachować właściwą strukturę środowiska wytwarzania aplikacji. Ponadto nakłady pracy wymagane do uzyskiwania właściwych wartości mierników będą minimalne w porównaniu z nakładami związanymi z ponownym testowaniem i instalacją nawet jednego pakietu5. Warto się więc zastanowić, czy praca poświęcona na wyznaczenie wartości tych metryk jest krótkoterminową stratą, czy zyskiem.

5

W przypadku aplikacji płacowej ręczne wyliczanie statystyk i metryk zajęło mi około dwóch godzin. Gdybym skorzystał z jednego z powszechnie dostępnych narzędzi, potrzebne nakłady pracy na wyznaczenie odpowiednich wskaźników byłyby jeszcze niższe.

ZASTOSOWANIE WSKAŹNIKÓW DO APLIKACJI PŁACOWEJ

299

Rysunek 22.7. Diagram pakietów z metrykami Tabela 22.2. Wskaźniki przypisane do pakietów Nazwa pakietu

N

A

Ca

Ce

R

H

I

Affiliations

2

0

2

1

AffiliationTransactions

4

1

1

7

Application

1

1

1

0

0

Classifications

5

0

8

3

2

ClassificationTransaction

6

1

1

14

5

GeneralTransactions

9

2

4

12

5

Methods

3

0

4

1

0

MethodTransactions

4

1

1

6

PayrollApplication

1

0

0

2

PayrollDatabase

1

1

11

1

PayrollDatabaseImplementation

1

0

0

1

PayrollDomain

5

4

26

0

Schedules

3

0

6

TextParserTransactionSource

1

0

1

TransactionApplication

3

3

9

1

A

D

D•

1

1

0,33

0

0,47

0,67

2

0,75

0,88

0,25

0,09

0,12

1

0

1

0

0

0,06

0,27

0

0,51

0,73

1

0,93

0,17

0,07

0,10

0,67

0,75

0,22

0,02

0,03

0,33

0,20

0

0,57

0,80

3

1

0,86

0,25

0,08

0,11

0

1

1

0

0

0

0

1

0,08

1

0,06

0,08

0

1

1

0

0

0

4

1

0

0,80

0,14

0,20

1

0

0,33

0,14

0

0,61

0,86

20

0

1

0,95

0

0,03

0,05

2

1

0,1

1

0,07

0,10

300

ROZDZIAŁ 22. STUDIUM PRZYPADKU: SYSTEM PŁACOWY (CZĘŚĆ 2.)

Fabryki obiektów Od pakietów Classifications i ClassificationTransactions zależy tak wiele klas, ponieważ wewnątrz nich trzeba tworzyć egzemplarze klas. Na przykład klasa TextParserTransactionSource musi mieć możliwość tworzenia obiektów klasy AddHourlyEmployeeTransaction. Z tego powodu istnieje sprzężenie wychodzące skierowane od pakietu TextParserTransactionSource do pakietu ClassificationTransactions. Podobnie klasa ChangeHourlyTransaction musi mieć możliwość tworzenia obiektów klasy HourlyClassification, zatem istnieje sprzężenie wychodzące od pakietu ClassificationTransactions do pakietu Classifications. Niemal co drugie odwołanie do obiektów wewnątrz wymienionych pakietów odbywa się za pośrednictwem ich abstrakcyjnych interfejsów. Gdyby nie istniała potrzeba tworzenia tych konkretnych obiektów, opisane sprzężenia wychodzące z tymi pakietami również by nie istniały. Na przykład gdyby klasa TextParserTransactionSource nie musiała tworzyć obiektów różnych transakcji, nie zależałaby od czterech pakietów zawierających implementacje transakcji. Problem ten można znacząco złagodzić, stosując wzorzec projektowy Fabryka. Każdy pakiet powinien definiować fabrykę obiektów odpowiedzialną za tworzenie wszystkich publicznych obiektów wchodzących w skład wskazanego pakietu.

Fabryka obiektów dla pakietu TransactionImplementation Na rysunku 22.8 przedstawiono propozycję struktury fabryki obiektów dla pakietu TransactionImplemen tation. Pakiet TransactionFactory zawiera abstrakcyjną klasę bazową, która definiuje czysto wirtualne funkcje reprezentujące konstruktory konkretnych obiektów transakcji. Pakiet TransactionImplementation zawiera konkretną klasę potomną interfejsu TransactionFactory i wykorzystuje konkretne transakcje do tworzenia potrzebnych obiektów.

Rysunek 22.8. Fabryka obiektów dla transakcji

ZASTOSOWANIE WSKAŹNIKÓW DO APLIKACJI PŁACOWEJ

301

Interfejs TransactionFactory zawiera statyczną składową zadeklarowaną jako wskaźnik do egzemplarza tego interfejsu. Ta składowa musi zostać zainicjowana w programie głównym, aby wskazywała na egzemplarz konkretnej klasy TransactionFactoryImplementation.

Inicjowanie fabryk Aby możliwe było tworzenie obiektów za pomocą tych fabryk, statyczne składowe abstrakcyjnych fabryk obiektów będą musiały być zainicjowane w taki sposób, aby wskazywały na właściwe fabryki konkretne. Tę inicjalizację należy przeprowadzić, zanim jakikolwiek użytkownik spróbuje użyć określonej fabryki. Zazwyczaj najlepszym miejscem dla takich operacji jest program główny. Oznacza to, że jest on zależny od wszystkich fabryk oraz wszystkich konkretnych pakietów. W związku z tym każdy konkretny pakiet jest związany przynajmniej jedną relacją przychodzącą z programem głównym. To powoduje nieznaczne oddalenie konkretnych pakietów od ciągu głównego, ale nie można temu zaradzić6. Oznacza to, że program główny trzeba będzie ponownie opublikować za każdym razem, gdy zmienimy którykolwiek z konkretnych pakietów. Oczywiście konieczność ponownej publikacji programu głównego dla każdej zmiany istniałaby niezależnie od opisywanych warunków, ponieważ po wprowadzeniu zmian zawsze trzeba przeprowadzić odpowiednie testy. Na rysunkach 22.9 i 22.10 pokazano statyczną i dynamiczną strukturę programu głównego wraz z relacją z fabrykami obiektów.

Rysunek 22.9. Statyczna struktura programu głównego i fabryk obiektów

Rysunek 22.10. Dynamiczna struktura programu głównego i fabryk obiektów

Przebudowa granic spójności Początkowo odizolowaliśmy pakiety Classifications, Methods, Schedules i Affiliations (patrz rysunek 22.1). Wtedy taki podział wydawał nam się rozsądny. Zakładaliśmy, że inni użytkownicy będą chcieli skorzystać z klas harmonogramów bez używania klas reprezentujących przynależność do związków zawodowych. Opisywany podział został utrzymany także po wyodrębnieniu transakcji do osobnych pakietów. W ten sposób powstała hierarchia dualna. Być może to było zbyt dużo. Diagram przedstawiony na rysunku 22.7 jest bardzo zagmatwany.

6

Zazwyczaj ignoruję sprzężenia wychodzące z programu głównego.

302

ROZDZIAŁ 22. STUDIUM PRZYPADKU: SYSTEM PŁACOWY (CZĘŚĆ 2.)

Skomplikowane powiązania na diagramie pakietów sprawiają, że zarządzanie publikacjami wersji dystrybucyjnych staje się dużo trudniejsze (zakładając, że robimy to ręcznie). Mimo że istnieją narzędzia do automatycznego planowania projektów, które doskonale radzą sobie ze skomplikowanymi diagramami pakietów, większość z nas nie może liczyć na taki luksus. W związku z tym trzeba zadbać o maksymalną prostotę i praktyczność tworzonych diagramów pakietów. Osobiście uważam, że podział według transakcji jest ważniejszy od podziału według funkcjonalności. Dlatego postaramy się połączyć transakcje w ramach jednego pakietu TransactionImplementation (patrz rysunek 22.11). Scalimy też pakiety Classifications, Schedules, Methods i Affiliations w ramach jednego pakietu PayrolImplementation.

Ostateczna struktura pakietów W tabeli 22.3 pokazano ostateczny przydział klas do pakietów. Tabela 22.4 zawiera również arkusz metryk. Na rysunku 22.11 pokazano ostateczną strukturę pakietów wraz z fabrykami obiektów, które przybliżają konkretne pakiety do ciągu głównego.

Rysunek 22.11. Ostateczna postać struktury pakietów aplikacji płacowej

OSTATECZNA STRUKTURA PAKIETÓW

303

Tabela 22.3. Ostateczny przydział klas do pakietów w aplikacji płacowej Pakiety

Klasy w pakietach

AbstractTransactions

AddEmployeeTransaction

ChangeAffiliationTransac tion

ChangeClassificationTransaction

ChangeMethodTransaction

Application

Application

PayrollApplication

PayrollApplication

PayrollDatabase

PayrollDatabase

PayrollDatabaseImplemen tation

PayrollDatabaseImplementation

PayrollDomain

Affiliation

Employee

PaymentMethod

PaymentSchedule

ChangeEmployeeTransaction

PaymentClassification

PayrollFactory

PayrollFactory

PayrollImplementation

BiweeklySchedule

CommissionedClassificati on

DirectMethod

HoldMethod

HourlyClassification

MailMethod

MonthlySchedule

PayrollFactoryImplementation

SalariedClassification

SalesReceipt

ServiceCharge

Timecard

UnionAffiliation

WeeklySchedule

TextParser-TransactionSource

TextParserTransactionSou rce

Transaction-Application

Transaction

TransactionFactory

TransactionFactory

Transaction-Implementation

TransactionApplication

TransactionSource

AddCommissionedEmployee

AddHourlyEmployee

AddSalariedEmployee

ChangeAddressTransaction

ChangeCommissionedTransaction

ChangeDirectTransaction

ChangeHoldTransaction

ChangeHourlyTransaction

ChangeMailTransaction

ChangeMemberTransaction

ChangeNameTransaction

ChangeSalariedTransactio n

ChangeUnaffiliatedTransa ction

DeleteEmployee

PaydayTransaction

SalesReceiptTransaction

ServiceChargeTransaction

TimecardTransaction

TransactionFactoryImplementation

Wartości metryk na tym wykresie są zadowalające. Prezentowana struktura charakteryzuje się bardzo wysoką spójnością relacyjną (częściowo dzięki relacjom łączącym konkretne fabryki z tworzonymi przez nie obiektami). Nie ma również znaczących odchyleń od ciągu głównego. Oznacza to, że sprzężenia pomiędzy pakietami są odpowiednie dla dobrze zaprojektowanego środowiska. Pakiety abstrakcyjne są zamknięte, zapewniają możliwość wielokrotnego wykorzystywania i wchodzą w wiele związków zależności, ale same nie są zależne od innych pakietów. Pakiety konkretne podzielono z myślą o zapewnieniu możliwości ponownego wykorzystania, są silnie zależne od pakietów abstrakcyjnych, ale mają niewiele zależności przychodzących.

304

ROZDZIAŁ 22. STUDIUM PRZYPADKU: SYSTEM PŁACOWY (CZĘŚĆ 2.)

Tabela 22.4. Wartości wskaźników dla pakietów w aplikacji płacowej Nazwa pakietu

N

A

Ca

Ce

R

H

I

A

D

D•

AbstractTransactions

5

5

13

1

0

0,20

0,07

1

0,05

0,07

Application

1

1

1

0

0

1

0

1

0

0

PayrollApplication

1

0

0

5

0

1

1

0

0

0

PayrollDatabase

1

1

19

5

0

1

0,21

1

0,15

0,21

PayrollDatabaseImplementation

1

0

0

1

0

1

1

0

0

0

PayrollDomain

5

4

30

0

4

1

0

0,80

0,14

0,20

PayrollFactory

1

1

12

4

0

1

0,25

1

0,18

0,25

PayrollImplementation

14

0

1

5

3

0,29

0,83

0

0,12

0,17

TextParserTransactionSource

1

0

1

3

0

1

0,75

0

0,18

0,25

TransactionApplication

3

3

14

1

3

1,33

0,07

1

0,05

0,07

TransactionFactory TransactionImplementation

1

1

3

1

0

1

0,25

1

0,18

0,25

19

0

1

14

0

0,05

0,93

0

0,05

0,07

Wniosek Konieczność zarządzania strukturami komponentów powstaje zwłaszcza w dużych projektach tworzonych przez liczne zespoły programistów. Jednak nawet niewielkie zespoły muszą dzielić kod źródłowy, aby programiści nie wchodzili sobie w drogę. Duże programy, w których nie zastosowano właściwego podziału na pakiety, z czasem przyjmują formę nieczytelnej masy złożonej z wielu plików źródłowych.

Bibliografia 1. Benjamin Cummings, Object-Oriented Analysis and Design with Applications, wydanie drugie, 1994. 2. Tom DeMarco, Controlling Software Projects, Yourdon Press, 1982.

CZĘŚĆ V Studium przypadku: stacja pogodowa Kolejne rozdziały zawierają szczegółowe studium przypadku prostego systemu monitorowania pogody. Chociaż jest ono fikcyjne, zostało wykonane z wysokim stopniem realizmu. Napotkamy problemy związane z presją czasu, starszym kodem, ubogimi i zmieniającymi się specyfikacjami, nowymi, niesprawdzonymi technologiami itp. Naszym celem jest pokazanie zastosowania poznanych zasad, wzorców i praktyk w rzeczywistym świecie inżynierii oprogramowania. Tak jak poprzednio podczas prac nad stacją pogodową spotkamy kilka przydatnych wzorców projektowych. W pierwszych rozdziałach, zanim przejdziemy do sedna tego studium przypadku, zajmiemy się opisem tych wzorców.

306

ROZDZIAŁ 23. WZORZEC PROJEKTOWY KOMPOZYT

PRZYKŁAD: POLECENIA KOMPOZYTOWE

307

R OZDZIAŁ 23

Wzorzec projektowy Kompozyt

Wzorzec projektowy Kompozyt (ang. Composite) jest bardzo prosty, ale wywiera znaczący wpływ na projekt. Podstawową strukturę wzorca Kompozyt zaprezentowano na rysunku 23.1. Pokazano na nim diagram hierarchii figur geometrycznych. Klasa bazowa Shape ma dwie klasy potomne o nazwach Circle i Square. Trzecia klasa potomna reprezentuje wzorzec Kompozyt. Klasa CompositeShape zawiera listę wielu egzemplarzy klasy Shape. W przypadku wywołania metody draw() obiektu CompositeShape ta metoda jest delegowana do wszystkich egzemplarzy klasy Shape na liście.

Rysunek 23.1. Wzorzec Kompozyt

308

ROZDZIAŁ 23. WZORZEC PROJEKTOWY KOMPOZYT

Tak więc egzemplarz klasy CompositeShape z punktu widzenia systemu wygląda tak, jakby był pojedynczym obiektem Shape. Można go przekazać do dowolnej funkcji lub obiektu, które pobierają argument Shape. Obiekt ten zachowuje się tak jak zwyczajny obiekt Shape. W rzeczywistości jednak jest on pośrednikiem1 dla grupy egzemplarzy klasy Shape. Na listingach 23.1 i 23.2 zamieszczono przykład implementacji klasy CompositeShape. Listing 23.1. Shape.java public interface Shape { public void draw(); }

Listing 23.2. CompositeShape.java import java.util.Vector; public class CompositeShape implements Shape { private Vector itsShapes = new Vector(); public void add(Shape s) { itsShapes.add(s); }

}

public void draw() { for (int i = 0; i < itsShapes.size(); i++) { Shape shape = (Shape) itsShapes.elementAt(i); shape.draw(); } }

Przykład: polecenia kompozytowe Powróćmy do analizy obiektów Sensors i Command, którą przeprowadziliśmy w rozdziale 13., w podrozdziale „Proste polecenia”. Na rysunku 13.3 pokazano klasę Sensor, która korzysta z klasy Command. Kiedy obiekt klasy Sensor wykryje bodziec, wywołuje metodę do() na obiekcie Command. W tamtym przykładzie nie wspomniałem jednak, że często występują przypadki, kiedy obiekt Sensor musi wykonać więcej niż jedno polecenie. Na przykład kiedy arkusz papieru dotrze do określonego punktu, trzeba uaktywnić odpowiedni sensor optyczny. Ten sensor zatrzymuje silnik, uruchamia inny silnik i włącza właściwe sprzęgło. Początkowo założyliśmy, że każdy obiekt klasy Sensor będzie utrzymywał listę obiektów Command (patrz rysunek 23.2). Szybko jednak zdaliśmy sobie sprawę z tego, że gdy obiekt Sensor musiał uruchomić więcej niż jedno polecenie, zawsze traktował te obiekty Command identycznie. Po prostu iterował po liście obiektów Command i na każdym z nich wykonywał metodę do(). Ta sytuacja idealnie nadaje się do zastosowania wzorca projektowego Kompozyt.

Rysunek 23.2. Obiekt klasy Sensor zawierający wiele obiektów klasy Command

1

Warto zwrócić uwagę na podobieństwo struktury tego wzorca do wzorca Pełnomocnik.

WIELOKROTNOŚĆ CZY BRAK WIELOKROTNOŚCI

309

W tym przypadku pozostawimy klasę Sensor i stworzymy klasę CompositeCommand, jak pokazano na rysunku 23.3.

Rysunek 23.3. Klasa CompositeCommand

To oznacza, że nie musimy modyfikować ani klasy Sensor, ani klasy Command. Udało się obsłużyć mnogość obiektów Command przez obiekt klasy Sensor bez modyfikowania żadnej z tych klas. Jest to przykład zastosowania zasady OCP.

Wielokrotność czy brak wielokrotności Powyższy przykład prowadzi do interesującego wniosku. Udało się doprowadzić do sytuacji, w której obiekty Sensor zachowują się tak, jakby zawierały wiele obiektów Command, bez konieczności modyfikowania klasy Sensor. W praktyce wytwarzania oprogramowania takie sytuacje występują stosunkowo często. Zdarza się, że można skorzystać ze wzorca projektowego Kompozyt, zamiast budować listę wektorów bądź obiektów. Spróbujmy przedstawić to w inny sposób. Związek pomiędzy obiektami Sensor i Command to relacja jeden do jednego. Najpierw ulegliśmy pokusie, aby przekształcić ten związek do postaci jeden do wielu. Jednak zamiast tej zmiany udało się nam uzyskać zachowanie typowe dla relacji jeden do wielu bez faktycznego tworzenia tej relacji. Relacja jeden do jednego jest znacznie bardziej zrozumiała, łatwiejsza do kodowania i utrzymania w porównaniu z relacją jeden do wielu, zatem przyjęty kompromis projektowy bez wątpienia się opłacał. Zastanówmy się, jak wiele relacji jeden do wielu w projektach moglibyśmy zastąpić relacją jeden do jednego, gdybyśmy zastosowali wzorzec projektowy Kompozyt. Oczywiście nie wszystkie relacje jeden do wielu można przekształcić na relacje jeden do jednego za pomocą wzorca Kompozyt. Kandydatami do takiego przekształcenia są tylko takie relacje, w których każdy obiekt z listy jest traktowany identycznie. Na przykład gdybyśmy mieli listę pracowników i przeszukiwali tę listę po to, by znaleźć pracowników, którzy mają dziś wypłatę, prawdopodobnie nie powinniśmy używać wzorca Kompozyt, ponieważ pracownicy nie są traktowani jednakowo. Istnieje jednak pewna grupa relacji jeden do wielu, które kwalifikują się do konwersji na wzorzec projektowy Kompozyt. Korzyści wynikające z zastosowania tego wzorca są znaczące. Zamiast powielać kod związany z utrzymywaniem listy i iterowaniem po niej w każdym kliencie, ten kod można umieścić we wspólnej klasie kompozytowej.

310

ROZDZIAŁ 23. WZORZEC PROJEKTOWY KOMPOZYT

R OZDZIAŁ 24

Obserwator — ewolucja kodu do wzorca

Niniejszy rozdział ma specjalny cel. Omówimy w nim wzorzec projektowy Obserwator (ang. Observer)1, ale to cel drugorzędny. Głównym celem tego rozdziału jest zademonstrowanie sposobu przekształcenia projektu i kodu w celu zastosowania wzorca. W poprzednich rozdziałach skorzystaliśmy z wielu wzorców. Często prezentowaliśmy ich zastosowanie jako „fakt dokonany” bez pokazywania zmian w kodzie potrzebnych do tego, by można było użyć wzorca. Można było stąd wysnuć wniosek, że wzorce są gotowymi konstrukcjami, które wystarczy wstawić do kodu i projektu. Nie zalecam takiego postępowania. Osobiście preferuję przekształcanie kodu, nad którym pracuję, w odpowiednim kierunku. Podczas refaktoryzacji mającej na celu pozbycie się sprzężeń, uproszczenie kodu i poprawienie jego czytelności czasami odkrywam, że kod przyjął postać zbliżoną do określonego wzorca. Kiedy tak się dzieje, zmieniam nazwy używanych klas i zmiennych tak, aby pasowały do wzorca, a następnie zmieniam strukturę kodu tak, by można było skorzystać ze wzorca w bardziej regularnej formie. A zatem kod ewoluuje do wzorca. W niniejszym rozdziale określono prosty problem, a następnie pokazano sposób przekształcenia projektu i kodu w celu rozwiązania tego problemu. Efektem tej ewolucji będzie wzorzec projektowy Obserwator. Na każdym etapie ewolucji opiszę problemy, które staram się rozwiązać, a następnie pokażę kroki, które umożliwiają ich rozwiązanie.

Zegar cyfrowy Załóżmy, że mam obiekt reprezentujący zegar. Ten obiekt przechwytuje z systemu operacyjnego milisekundowe przerwania (znane jako tyknięcia — ang. tics) i zamienia je na aktualną godzinę. Obiekt „wie”, jak obliczyć sekundy z milisekund, minuty z sekund, godziny z minut, dni z godziny itd. „Wie” także, ile jest dni w miesiącu oraz ile jest miesięcy w roku. Potrafi obsługiwać lata przestępne oraz stosować specjalne zasady, które ich dotyczą. Obiekt zegara obsługuje wszystkie operacje związane z czasem (patrz rysunek 24.1). 1

[GOF 95], str. 293.

312

ROZDZIAŁ 24. OBSERWATOR — EWOLUCJA KODU DO WZORCA

Rysunek 24.1. Klasa Clock

Chcielibyśmy stworzyć zegar cyfrowy, który wyświetla się na pulpicie i przez cały czas pokazuje aktualną godzinę. Jaki jest najprostszy sposób realizacji tego zadania? Moglibyśmy napisać następujący kod: public void DisplayTime { while(1) { int sec = clock.getSeconds(); int min = clock.getMinutes(); int hour = clock.getHours(); showTime(hour,min,sec); } }

Powyższe rozwiązanie nie jest jednak optymalne. Taki program zużywa wszystkie dostępne cykle procesora w celu ciągłego wyświetlania godziny. W większości przypadków oznacza to marnotrawstwo, ponieważ wyświetlana godzina będzie taka sama. Takie rozwiązanie mogłoby być odpowiednie w zegarku cyfrowym lub zegarze ściennym, ponieważ oszczędzanie cykli procesora w tego rodzaju systemach nie ma znaczenia. Nie chcemy jednak, aby zegar obciążający procesor w takim stopniu działał na naszym pulpicie. Podstawowy problem polega na opracowaniu sposobu wydajnego przekazywania danych z obiektu klasy Clock do obiektu klasy DigitalClock. Zakładam, że zarówno obiekt Clock, jak i DigitalClock już istnieją. Interesuje mnie sposób ich połączenia. Połączenie to mogę przetestować, sprawdzając, czy dane otrzymane z obiektu Clock są tymi samymi danymi, które przesłałem do obiektu DigitalClock. Prostym sposobem na napisanie takiego testu jest utworzenie jednego interfejsu, który imituje zachowanie obiektu Clock, oraz drugiego, który udaje obiekt DigitalClock. Następnie można napisać specjalne obiekty testowe, które implementują te interfejsy, i sprawdzić, czy połączenie pomiędzy nimi działa zgodnie z oczekiwaniami (patrz rysunek 24.2).

Rysunek 24.2. Testowanie obiektu DigitalClock

ZEGAR CYFROWY

313

Obiekt ClockDriverTest połączy obiekt ClockDriver z dwoma obiektami-makietami za pośrednictwem interfejsów TimeSource oraz TimeSink. Następnie sprawdzi każdy z tych obiektów-makiet w celu zweryfikowania, czy obiekt ClockDriver przesłał informację o czasie od źródła do ujścia. Gdyby zachodziła taka konieczność, obiekt ClockDriverTest mógłby również sprawdzać wydajność połączenia. Sądzę, że na uwagę zasługuje fakt dodania do projektu interfejsów tylko po to, aby można było wykonać test. Aby można było przetestować moduł, musi istnieć sposób odizolowania go od innych modułów w systemie dokładnie tak, jak odizolowaliśmy obiekt ClockDriver od obiektów Clock i DigitalClock. Zastosowanie techniki „najpierw test” umożliwia zminimalizowanie ilości sprzężeń w projektach. W jaki sposób działa obiekt ClockDriver? Jest oczywiste, że aby obiekt ClockDriver działał wydajnie, musi potrafić wykryć zmianę czasu w obiekcie TimeSource. Tylko wtedy, kiedy nastąpi taka zmiana, obiekt powinien przesłać informację o czasie do obiektu TimeSink. Skąd obiekt ClockDriver dowie się, że czas się zmienił? W tym celu mógłby odpytywać obiekt TimeSource, ale to tylko odtworzyłoby problem obciążenia procesora. Najprościej by było, aby obiekt ClockDriver uzyskał informację o zmianie czasu od samego obiektu Clock. Można przekazać obiekt ClockDriver do obiektu Clock za pośrednictwem interfejsu TimeSource, a następnie, kiedy zmieni się czas, obiekt Clock może zaktualizować obiekt ClockDriver. Z kolei obiekt ClockDriver może wtedy ustawić czas w obiekcie ClockSink (patrz rysunek 24.3).

Rysunek 24.3. Wykorzystanie obiektu TimeSource w celu aktualizacji obiektu ClockDriver

Zwróćmy uwagę na zależność pomiędzy obiektami TimeSource a ClockDriver. Występuje ona, ponieważ argumentem metody setDriver jest obiekt ClockDriver. Nie jestem zadowolony z tego rozwiązania, ponieważ oznacza ono, że obiekty TimeSource za każdym razem muszą korzystać z obiektów ClockDriver. Na razie jednak odłożę rozwiązanie problemu zależności do czasu, aż program zacznie działać. Na listingu 24.1 pokazano przypadek testowy dla klasy ClockDriver. Warto zwrócić uwagę, że utworzono w nim obiekt ClockDriver i powiązano z nim obiekty MockTimeSource oraz MockTimeSink. Następnie został ustawiony czas źródła. Po ustawieniu tego czasu oczekujemy, że magicznie znajdzie się w ujściu. Pozostałą część kodu zamieszczono na listingach od 24.2 do 24.6. Listing 24.1. ClockDriverTest.java import junit.framework.*; public class ClockDriverTest extends TestCase { public ClockDriverTest(String name) {

314

ROZDZIAŁ 24. OBSERWATOR — EWOLUCJA KODU DO WZORCA

super(name); } public void testTimeChange() { MockTimeSource source = new MockTimeSource(); MockTimeSink sink = new MockTimeSink(); ClockDriver driver = new ClockDriver(source,sink); source.setTime(3,4,5); assertEquals(3, sink.getHours()); assertEquals(4, sink.getMinutes()); assertEquals(5, sink.getSeconds());

}

}

source.setTime(7,8,9); assertEquals(7, sink.getHours()); assertEquals(8, sink.getMinutes()); assertEquals(9, sink.getSeconds());

Listing 24.2. TimeSource.java public interface TimeSource { public void setDriver(ClockDriver driver); }

Listing 24.3. TimeSink.java public interface TimeSink { public void setTime(int hours, int minutes, int seconds); }

Listing 24.4. ClockDriver.java public class ClockDriver { private TimeSink itsSink; public ClockDriver(TimeSource source, TimeSink sink) { source.setDriver(this); itsSink = sink; }

}

public void update(int hours, int minutes, int seconds) { itsSink.setTime(hours, minutes, seconds); }

Listing 24.5. MockTimeSource.java public class MockTimeSource implements TimeSource { private ClockDriver itsDriver; public void setTime(int hours, int minutes, int seconds) { itsDriver.update(hours, minutes, seconds); }

}

public void setDriver(ClockDriver driver) { itsDriver = driver; }

ZEGAR CYFROWY

315

Listing 24.6. MockTimeSink.java public class MockTimeSink implements TimeSink { private int itsHours; private int itsMinutes; private int itsSeconds; public int getSeconds() { return itsSeconds; } public int getMinutes() { return itsMinutes; } public int getHours() { return itsHours; }

}

public void setTime(int hours, int minutes, int seconds) { itsHours = hours; itsMinutes = minutes; itsSeconds = seconds; }

Teraz kiedy wszystko działa, można pomyśleć o uporządkowaniu kodu. Nie podoba mi się zależność pomiędzy klasami TimeSource i ClockDriver, ponieważ chciałbym, aby z interfejsu klasy TimeSource mogły skorzystać dowolne klienty, a nie tylko obiekty klasy ClockDriver. Aby rozwiązać ten problem, można stworzyć interfejs, który klasa TimeSource wykorzystuje, natomiast klasa ClockDriver implementuje. Temu interfejsowi nadamy nazwę ClockObserver. Spójrzmy na listingi od 24.7 do 24.10. Kod, który się zmienił, oznaczono pogrubieniem.

Rysunek 24.4. Przerwanie zależności klasy TimeSource od klasy ClockDriver

316

ROZDZIAŁ 24. OBSERWATOR — EWOLUCJA KODU DO WZORCA

Listing 24.7. ClockObserver.java public interface ClockObserver { public void update(int hours, int minutes, int seconds); }

Listing 24.8. ClockDriver.java public class ClockDriver implements ClockObserver { private TimeSink itsSink; public ClockDriver(TimeSource source, TimeSink sink) { source.setObserver(this); itsSink = sink; }

}

public void update(int hours, int minutes, int seconds) { itsSink.setTime(hours, minutes, seconds); }

Listing 24.9. TimeSource.java public interface TimeSource { public void setObserver(ClockObserver observer); }

Listing 24.10. MockTimeSource.java public class MockTimeSource implements TimeSource { private ClockObserver itsObserver; public void setTime(int hours, int minutes, int seconds) { itsObserver.update(hours, minutes, seconds); }

}

public void setObserver(ClockObserver observer) { itsObserver=observer; }

To rozwiązanie jest lepsze. Teraz z klasy TimeSource może skorzystać dowolna klasa. Wystarczy, że implementuje interfejs ClockObserver oraz wywołuje metodę SetObserver, przekazując siebie jako argument. Chciałbym, aby informacje o czasie mogły być przekazane do więcej niż jednego obiektu TimeSink. Jedna aplikacja kliencka może implementować zegar cyfrowy. Inna może być wykorzystana w celu dostarczenia informacji o czasie do usługi przypominającej. Jeszcze inna może inicjować wykonywanie kopii zapasowej o ustalonej godzinie. Krótko mówiąc, chciałbym, aby jeden obiekt TimeSource mógł dostarczać informacje o czasie do wielu obiektów TimeSink. W związku z tym zmodyfikuję konstruktor klasy ClockDriver w taki sposób, żeby pobierał sam obiekt TimeSource, a następnie dodam metodę addTimeSink, która pozwala dodawać egzemplarze obiektów TimeSink w dowolnym czasie.

ZEGAR CYFROWY

317

Największą wadą przedstawionego rozwiązania jest korzystanie z podwójnego pośrednictwa. Trzeba poinformować obiekt klasy TimeSource, „kim” jest obiekt klasy ClockObserver, poprzez wywołanie metody setObserver. Trzeba także poinformować obiekt klasy ClockDriver, „kim” są egzemplarze klasy TimeSink. Czy to podwójne pośrednictwo jest naprawdę niezbędne? Jeśli przyjrzymy się klasom ClockObserver i TimeSink, możemy zauważyć, że obie zawierają metodę setTime. Wygląda na to, że klasa TimeSink mogłaby implementować interfejs ClockObserver. Gdyby tak było, to w moim programie testowym można by stworzyć obiekt klasy MockTimeSink, a następnie wywołać metodę setObserver obiektu TimeSource. Dzięki temu można by się pozbyć klasy ClockDriver (oraz interfejsu TimeSink). Zmiany wprowadzone w klasie ClockDriverTest zaprezentowano na listingu 24.11. Listing 24.11. ClockDriverTest.java import junit.framework.*; public class ClockDriverTest extends TestCase { public ClockDriverTest(String name) { super(name); } public void testTimeChange() { MockTimeSource source = new MockTimeSource(); MockTimeSink sink = new MockTimeSink(); source.setObserver(sink); source.setTime(3,4,5); assertEquals(3, sink.getHours()); assertEquals(4, sink.getMinutes()); assertEquals(5, sink.getSeconds());

}

}

source.setTime(7,8,9); assertEquals(7, sink.getHours()); assertEquals(8, sink.getMinutes()); assertEquals(9, sink.getSeconds());

Wynika stąd, że klasa MockTimeSink powinna implementować interfejs ClockObserver zamiast interfejsu TimeSink (patrz listing 24.12). Wprowadzone zmiany dobrze się sprawdziły. Zastanawiam się, dlaczego w ogóle potrzebowałem klasy ClockDriver? Odpowiedni diagram UML zamieszczono na rysunku 24.5. Listing 24.12. MockTimeSink.java public class MockTimeSink implements ClockObserver { private int itsHours; private int itsMinutes; private int itsSeconds; public int getSeconds() { return itsSeconds; } public int getMinutes() { return itsMinutes; }

318

ROZDZIAŁ 24. OBSERWATOR — EWOLUCJA KODU DO WZORCA

public int getHours() { return itsHours; }

}

public void update(int hours, int minutes, int seconds) { itsHours = hours; itsMinutes = minutes; itsSeconds = seconds; }

Rysunek 24.5. Diagram UML bez klasy ClockDriver i interfejsu TimeSink

Wyraźnie widać, że to rozwiązanie jest znacznie prostsze. Możemy teraz obsłużyć wiele obiektów TimeSink, zmieniając funkcję setObserver na registerObserver oraz dbając o to, aby wszystkie zarejestrowane egzemplarze klas implementujących interfejs ClockObserver były zapisane na liście i odpowiednio aktualizowane. To wymaga wprowadzenia jeszcze jednej zmiany w programie testowym. Odpowiednie zmiany zaprezentowano na listingu 24.13. Dodatkowo przeprowadziłem refaktoryzację programu testowego, aby kod stał się krótszy i bardziej czytelny. Listing 24.13. ClockDriverTest.java import junit.framework.*; public class ClockDriverTest extends TestCase { private MockTimeSource source; private MockTimeSink sink; public ClockDriverTest(String name) { super(name); } public void setUp() { source = new MockTimeSource(); sink = new MockTimeSink(); source.registerObserver(sink); }

{

private void assertSinkEquals( MockTimeSink sink, int hours, int minutes, int seconds) assertEquals(hours, sink.getHours());

ZEGAR CYFROWY

}

319

assertEquals(minutes, sink.getMinutes()); assertEquals(seconds, sink.getSeconds());

public void testTimeChange() { source.setTime(3,4,5); assertSinkEquals(sink, 3,4,5); source.setTime(7,8,9); assertSinkEquals(sink, 7,8,9);

} public void testMultipleSinks() { MockTimeSink sink2 = new MockTimeSink(); source.registerObserver(sink2);

}

}

source.setTime(12,13,14); assertSinkEquals(sink, 12,13,14); assertSinkEquals(sink2, 12,13,14);

Zmiany niezbędne do zastosowania nowego modelu są stosunkowo proste. Zmodyfikowaliśmy klasę MockTimeSource w taki sposób, aby wszystkie zarejestrowane obiekty obserwatorów były przechowywane w strukturze typu Vector. W chwili zmiany godziny możemy iteracyjnie przeglądać tę strukturę i wywoływać metodę update dla wszystkich zarejestrowanych egzemplarzy interfejsu ClockObserver. Wprowadzone zmiany zaprezentowano na listingach 24.14 i 24.15. Odpowiedni diagram UML zamieszczono na rysunku 24.6. Listing 24.14. TimeSource.java public interface TimeSource { public void registerObserver(ClockObserver observer); }

Listing 24.15. MockTimeSource.java import java.util.*; public class MockTimeSource implements TimeSource { private Vector itsObservers = new Vector(); public void setTime(int hours, int minutes, int seconds) { Iterator i = itsObservers.iterator(); while (i.hasNext()) { ClockObserver observer = (ClockObserver) i.next(); observer.update(hours, minutes, seconds); }

}

public void registerObserver(ClockObserver observer) { itsObservers.add(observer); }

320

ROZDZIAŁ 24. OBSERWATOR — EWOLUCJA KODU DO WZORCA

Rysunek 24.6. Obsługa wielu egzemplarzy interfejsu TimeSink

To rozwiązanie wygląda dość dobrze, ale nie podoba mi się fakt, że obiekt MockTimeSource musi zajmować się operacjami rejestracji i aktualizacji. To oznacza, że w klasie Clock oraz we wszystkich innych pochodnych interfejsu TimeSource trzeba będzie powielić kod rejestracji i aktualizacji. Uważam, że klasa Clock nie powinna zajmować się rejestracją i aktualizacją. Nie podoba mi się także fakt powielania kodu. Z tego powodu postanowiłem przenieść ten kod na poziom egzemplarzy TimeSource. To oczywiście oznacza konieczność przekształcenia interfejsu TimeSource w klasę. Oznacza to również, że klasa MockTimeSource bardzo się skróci. Wprowadzone zmiany zaprezentowano na listingach 24.16 i 24.17, natomiast właściwy diagram UML pokazano na rysunku 24.7. Listing 24.16. TimeSource.java import java.util.*; public class TimeSource { private Vector itsObservers = new Vector(); protected void notify(int hours, int minutes, int seconds) { Iterator i = itsObservers.iterator(); while (i.hasNext()) { ClockObserver observer = (ClockObserver) i.next(); observer.update(hours, minutes, seconds); } }

}

public void registerObserver(ClockObserver observer) { itsObservers.add(observer); }

Listing 24.17. MockTimeSource.java public class MockTimeSource extends TimeSource { public void setTime(int hours, int minutes, int seconds) { notify(hours, minutes, seconds); } }

ZEGAR CYFROWY

321

Rysunek 24.7. Przeniesienie operacji rejestracji i aktualizacji do klasy TimeSource

To rozwiązanie wydaje się rozsądne. Teraz z klasy TimeSource może skorzystać dowolna klasa. Aby obiekty obserwatorów zostały zaktualizowane, wystarczy wywołać metodę notify. Ale w tym kodzie w dalszym ciągu jest coś, co mi się nie podoba. Obiekt MockTimeSource dziedziczy bezpośrednio z klasy TimeSource. Oznacza to, że także klasa Clock musi dziedziczyć po klasie TimeSource. Z jakiego powodu klasa Clock miałaby zależeć od operacji rejestracji i aktualizacji? Clock jest po prostu klasą, która zarządza informacjami o czasie. Jej zależność od klasy TimeSource wydaje się niepożądana. Wiem, w jaki sposób rozwiązałbym ten problem w języku C++. Stworzyłbym wspólną podklasę klas TimeSource i Clock o nazwie ObservableClock. W klasie ObservableClock przesłoniłbym metody tic i setTime w taki sposób, aby wywoływały metody tic lub setTime obiektu Clock, a następnie wywoływały metodę notify obiektu TimeSource. Omówione rozwiązanie zaprezentowano na listingu 24.18 oraz na rysunku 24.8. Listing 24.18. ObservableClock.cc (C++) class ObservableClock : public Clock, public TimeSource { public: virtual void tic() { Clock::tic(); TimeSource::notify(getHours(), getMinutes(), getSeconds()); }

};

virtual void setTime(int hours, int minutes, int seconds) { Clock::setTime(hours, minutes, seconds); TimeSource::notify(hours, minutes, seconds); }

Rysunek 24.8. Wykorzystanie wielokrotnego dziedziczenia w języku C++ w celu odseparowania klasy Clock od klasy TimeSource

322

ROZDZIAŁ 24. OBSERWATOR — EWOLUCJA KODU DO WZORCA

Niestety, nie mamy takiej możliwości w języku Java, ponieważ w tym języku nie istnieje obsługa wielokrotnego dziedziczenia. Dlatego w Javie trzeba pozostawić rozwiązanie w takiej postaci, w jakiej jest, albo skorzystać z delegacji. Rozwiązanie z wykorzystaniem delegatów pokazano na listingach od 24.19 do 24.21 oraz na rysunku 24.9. Listing 24.19. TimeSource.java public interface TimeSource { public void registerObserver(ClockObserver observer); }

Listing 24.20. TimeSourceImplementation.java import java.util.*; public class TimeSourceImplementation { private Vector itsObservers = new Vector(); public void notify(int hours, int minutes, int seconds) { Iterator i = itsObservers.iterator(); while (i.hasNext()) { ClockObserver observer = (ClockObserver) i.next(); observer.update(hours, minutes, seconds); } }

}

public void registerObserver(ClockObserver observer) { itsObservers.add(observer); }

Listing 24.21. MockTimeSource.java public class MockTimeSource implements TimeSource { TimeSourceImplementation tsImp = new TimeSourceImplementation();

} }

public void registerObserver(ClockObserver observer) { tsImp.registerObserver(observer); } public void setTime(int hours, int minutes, int seconds) { tsImp.notify(hours, minutes, seconds);

Zwróćmy uwagę na to, że klasa MockTimeSource implementuje interfejs TimeSource oraz zawiera referencję do egzemplarza klasy TimeSourceImplementation. Zwróćmy także uwagę, że wszystkie wywołania metody registerObserver obiektu MockTimeSource są delegowane do obiektu TimeSourceImplementation. Zauważmy również, że w metodzie MockTimeSource.setTime wywołano metodę notify egzemplarza obiektu TimeSourceImplementation. To rozwiązanie nie jest eleganckie, ale jego zaletą jest to, że klasa MockTimeSource nie rozszerza innej klasy. Oznacza to, że gdyby trzeba było stworzyć klasę ObservableClock, to rozszerzałaby ona klasę Clock, implementowała interfejs TimeSource i delegowała wywołania do obiektu klasy TimeSourceImplementation (patrz rysunek 24.10). To rozwiązuje problem zależności klasy Clock od operacji rejestracji i aktualizacji, ale cena tego rozwiązania jest dość wysoka.

ZEGAR CYFROWY

323

Rysunek 24.9. Delegowanie obserwatora w Javie

Rysunek 24.10. Zastosowanie delegacji w klasie ObservableClock

Powróćmy na chwilę do rysunku 24.7 — czyli do sytuacji, zanim wpadliśmy w opisaną powyżej pułapkę. Przyjmijmy, że pogodzimy się z koniecznością zależności klasy Clock od operacji rejestracji i aktualizacji. TimeSource to niezbyt dobra nazwa, biorąc pod uwagę operacje, które klasa realizuje. Nazwa ta była właściwa wtedy, kiedy model obejmował klasę ClockDriver. Ale od tamtej pory wiele się zmieniło. Należy zmienić nazwę klasy w taki sposób, aby sugerowała, że klasa realizuje operacje rejestrowania i aktualizacji. We wzorcu projektowym Obserwator taka klasa nosi nazwę Subject. W naszym rozwiązaniu klasa spełnia specyficzne funkcje, dlatego moglibyśmy nadać jej nazwę TimeSubject, ale taka nazwa nie jest zbyt intuicyjna. Moglibyśmy użyć starego przydomka Javy Observable, ale taka nazwa także mi nie odpowiada. TimeObservable? Nie. Być może problemem jest specyfika modelu wzorca Obserwator, która w tym przypadku polega na „wypychaniu” informacji2. Gdybyśmy zastosowali model „wyciągania”, można by przekształcić klasę na generyczną. W takim przypadku moglibyśmy zmienić nazwę klasy TimeSource na Subject, a każdy, kto zna wzorzec projektowy Obserwator, wiedziałby, jaką spełnia funkcję. To nie jest złe rozwiązanie. Zamiast przekazywania informacji o godzinie za pomocą metod notify i update, możemy powierzyć zadanie odpytywania o czas klasie TimeSink, która w tym celu wyśle odpowiednie żądanie do klasy MockTimeSource. Nie chcemy, aby klasa MockTimeSink „wiedziała” cokolwiek o klasie MockTimeSource, dlatego stworzymy interfejs, który klasa MockTimeSink będzie mogła wykorzystać w celu uzyskania godziny. Ten interfejs będą implementowały klasy MockTimeSource (oraz Clock). Interfejsowi możemy nadać nazwę TimeSource. 2

W modelu obserwatora bazującym na „wypychaniu” (ang. push) dane są przesyłane do obserwatorów za pomocą metod powiadamiania i aktualizacji. W przypadku obserwatorów, które „wyciągają” informacje (jest to tzw. model pull) do metod powiadamiania i aktualizacji nie są przekazywane żadne dane. Zamiast tego obserwator musi zapytać obiekt obserwowany o potrzebne informacje. Zobacz [GOF95].

324

ROZDZIAŁ 24. OBSERWATOR — EWOLUCJA KODU DO WZORCA

Ostateczną postać kodu i diagramu UML zaprezentowano na listingach od 24.22 do 24.27 oraz na rysunku 24.11. Listing 24.22. ObserverTest.java import junit.framework.*; public class ObserverTest extends TestCase { private MockTimeSource source; private MockTimeSink sink; public ObserverTest(String name) { super(name); } public void setUp() { source = new MockTimeSource(); sink = new MockTimeSink(source); source.registerObserver(sinkprivate void assertSinkEquals( } private void assertSinkEquals( MockTimeSink sink, int hours, int minutes, int seconds) { assertEquals(hours, sink.getHours()); assertEquals(minutes, sink.getMinutes()); assertEquals(seconds, sink.getSeconds()); } public void testTimeChange() { source.setTime(3,4,5); assertSinkEquals(sink, 3,4,5);

}

source.setTime(7,8,9); assertSinkEquals(sink, 7,8,9);

public void testMultipleSinks() { MockTimeSink sink2 = new MockTimeSink(source); source.registerObserver(sink2);

}

}

source.setTime(12,13,14); assertSinkEquals(sink, 12,13,14); assertSinkEquals(sink2, 12,13,14);

Listing 24.23. Observer.java public interface Observer { public void update(); }

Listing 24.24. Subject.java import java.util.*; public class Subject { private Vector itsObservers = new Vector();

ZEGAR CYFROWY

}

protected void notifyObservers() { Iterator i = itsObservers.iterator(); while (i.hasNext()) { Observer observer = (Observer) i.next(); observer.update(); } } public void registerObserver(Observer observer) { itsObservers.add(observer); }

Listing 24.25. TimeSource.java public interface TimeSource { public int getHours(); public int getMinutes(); public int getSeconds(); }

Listing 24.26. MockTimeSource.java public class MockTimeSource extends Subject implements TimeSource { private int itsHours; private int itsMinutes; private int itsSeconds; public void setTime(int hours, int minutes, int seconds) { itsHours = hours; itsMinutes = minutes; itsSeconds = seconds; notifyObservers(); } public int getHours() { return itsHours; } public int getMinutes() { return itsMinutes; }

}

public int getSeconds() { return itsSeconds; }

Listing 24.27. MockTimeSink.java public class MockTimeSink implements Observer { private int itsHours; private int itsMinutes; private int itsSeconds; private TimeSource itsSource; public MockTimeSink(TimeSource source)

325

326

ROZDZIAŁ 24. OBSERWATOR — EWOLUCJA KODU DO WZORCA

{ }

itsSource = source;

public int getSeconds() { return itsSeconds; } public int getMinutes() { return itsMinutes; } public int getHours() { return itsHours; }

}

public void update() { itsHours = itsSource.getHours(); itsMinutes = itsSource.getMinutes(); itsSeconds = itsSource.getSeconds(); }

Rysunek 24.11. Ostateczna wersja wzorca projektowego Obserwator zastosowana do klas MockTimeSource i MockTimeSink

Wniosek Zatem skończyliśmy. Zaczęliśmy od zaprezentowania problemu projektowego, a następnie w wyniku stosowania ewolucyjnych zmian doszliśmy do kanonicznej postaci wzorca projektowego Obserwator. Niektórzy czytelnicy pewnie uważają, że skoro wiedziałem od początku, że chcę dojść do wzorca Obserwator, to tak zorganizowałem projekt, aby uzyskać założony efekt. Nie będę zaprzeczał. Ale to nie jest najważniejsze. Programiści znający wzorce projektowe mogą po nie sięgać w miarę potrzeb. Zwykle przychodzą im one na myśl po napotkaniu konkretnego problemu projektowego. Warto zadać sobie wtedy pytanie, czy należy bezpośrednio zaimplementować określony wzorzec, czy też wykonać szereg małych kroków, aby doprowadzić projekt do pożądanej postaci. W niniejszym rozdziale zaprezentowaliśmy tę drugą

WZORZEC PROJEKTOWY OBSERWATOR

327

opcję. Zamiast zakładać z góry, że wzorzec Obserwator najbardziej nadaje się do rozwiązania problemu, powoli rozwijaliśmy kod, realizując kolejne fragmenty projektu. W końcu stało się dość oczywiste, że kod zmierza w kierunku wzorca Obserwator, dlatego zmieniłem nazwy i doprowadziłem kod do postaci kanonicznej. Na każdym etapie tej ewolucji mogłem uznać, że problem został rozwiązany, i zaprzestać wprowadzania kolejnych przekształceń. Mogłem także dojść do wniosku, że warto zmienić kurs i pójść w innym kierunku.

Wykorzystanie diagramów w tym rozdziale Niektóre z diagramów, które zostały zaprezentowane w tym rozdziale, narysowałem po to, aby ułatwić czytelnikom zrozumienie tematu. Uznałem, że będzie łatwiej śledzić to, co robię, jeśli zaprezentuję odpowiedni diagram. Gdybym nie próbował pokazywać i objaśniać projektu, nie tworzyłbym diagramów. Jednak kilka spośród pokazanych diagramów wykonałem na własny użytek. Czasami po prostu potrzebowałem spojrzeć na strukturę, którą stworzyłem, abym mógł podjąć decyzję, gdzie pójść dalej. Gdybym nie pisał książki, narysowałbym te diagramy ręcznie na kartce papieru lub na tablicy. Nie marnowałbym czasu na rysowanie ich w aplikacji do tworzenia ilustracji. Nie znam sytuacji, gdy stworzenie rysunku za pomocą programu do rysowania udaje się szybciej niż na skrawku papieru. Po skorzystaniu ze schematów, które pomogły mi stworzyć kod, nie widzę powodu, aby je przechowywać. W każdym przypadku diagramy, które narysowałem dla siebie, były etapem pośrednim. Czy przechowywanie diagramów na tym poziomie szczegółowości przynosi jakąś wartość? Jest oczywiste, że jeśli ktoś chce zilustrować swoje rozumowanie tak, jak ja to robię w tej książce, to tego rodzaju diagramy są bardzo przydatne. Zazwyczaj jednak nie próbujemy dokumentować ewolucyjnej ścieżki kilku godzin kodowania. Zwykle takie schematy mają wartość przejściową i najlepiej je wyrzucić. Na tym poziomie szczegółowości kod jest na ogół wystarczająco dobry w roli własnej dokumentacji. Na wyższych poziomach to nie zawsze jest prawdą.

Wzorzec projektowy Obserwator Gdy udało się przeanalizować przykład i doprowadzić kod do postaci wzorca projektowego Obserwator, może być interesujące przeanalizowanie tego, czym właściwie jest ten wzorzec. Kanoniczną postać wzorca Obserwator zaprezentowano na rysunku 24.12. W tym przykładzie klasa Clock jest obserwowana przez klasę DigitalClock. Klasa DigitalClock rejestruje interfejs Subject klasy Clock. Obiekt klasy Clock wywołuje metodę notify klasy Subject za każdym razem, gdy z jakiegoś powodu zmieni się godzina. Metoda notify klasy Subject wywołuje metodę update dla każdego zarejestrowanego obiektu klasy Observer. W związku z tym obiekt klasy DigitalClock otrzyma komunikat update za każdym razem, gdy zmieni się godzina. Ta sytuacja stwarza okazję do zapytania obiektu klasy Clock o godzinę i wyświetlenia jej.

Rysunek 24.12. Kanoniczna postać modelu „ciągnij” wzorca projektowego Obserwator

328

ROZDZIAŁ 24. OBSERWATOR — EWOLUCJA KODU DO WZORCA

Wzorzec projektowy Obserwator jest jednym z tych wzorców, które — jeśli się je zrozumie — są wykorzystywane wszędzie. Pośrednictwo oferowane przez ten wzorzec jest bardzo atrakcyjne. Można zarejestrować obserwatory dla wszelkiego rodzaju obiektów, zamiast pisać metody na poziomie tych obiektów. Chociaż to pośrednictwo jest przydatnym sposobem zarządzania zależnościami, można łatwo przesadzić z jego wykorzystywaniem. Nadużywanie wzorca projektowego Obserwator sprawia, że systemy stają się bardzo trudne do zrozumienia i analizy. Modele „wypychaj” i „ciągnij”. Istnieją dwa zasadnicze modele wzorca projektowego Obserwator. Na rysunku 24.13 pokazano model „ciągnij” (ang. pull). Nazwa pochodzi stąd, że obiekt klasy DigitalClock musi „wyciągać” informacje o godzinie z obiektu Clock po odebraniu komunikatu update.

Rysunek 24.13. Model „wypychaj” wzorca projektowego Obserwator

Zaletą modelu „ciągnij” jest prostota jego implementacji oraz fakt, że klasy Subject i Observer mogą być standardowymi elementami wielokrotnego użytku w bibliotece. Wyobraźmy sobie jednak, że obserwujemy rekord pracownika z tysiącami pól i że właśnie otrzymaliśmy komunikat update. Które z tysiąca pól się zmieniło? W przypadku wywołania metody update obiektu ClockObserver odpowiedź jest oczywista. Obiekt klasy ClockObserver musi „wyciągnąć” godzinę z obiektu klasy Clock, a następnie tę godzinę wyświetlić. Kiedy jednak wywołamy metodę update na obiekcie klasy EmployeeObserver, odpowiedź nie jest już taka oczywista. Nie wiemy, co się wydarzyło. Nie wiemy, co zrobić. Być może zmieniło się nazwisko pracownika, a może to było jego wynagrodzenie. Być może zmienił się szef. A może chodzi o rachunek bankowy. Potrzebujemy pomocy. Tę pomoc możemy uzyskać dzięki modelowi „pchaj” wzorca projektowego Obserwator. Strukturę modelu „pchaj” wzorca projektowego Obserwator pokazano na rysunku 24.13. Zwróćmy uwagę na to, że zarówno metoda notify, jak i metoda update pobierają argument. Argument jest wskazówką przekazaną od obiektu Employee do obiektu SalaryObserver za pośrednictwem metod notify i update. Ta wskazówka informuje obiekt SalaryObserver o rodzaju zmiany, jaka nastąpiła w rekordzie Employee. Argument EmployeeObserverHint metod notify i update może być wartością jakiegoś typu wyliczeniowego, łańcuchem znaków lub bardziej złożoną strukturą danych zawierającą starą i nową wartość wskazanego pola. Niezależnie od tego, co to jest, wartość ta jest „wypychana” do obserwatora. Wybór pomiędzy dwoma modelami wzorca projektowego Obserwator zależy od złożoności obserwowanego obiektu. Jeśli obserwowany obiekt jest złożony, a obserwator potrzebuje wskazówki, to odpowiedni jest model „pchaj”. Jeśli obserwowany obiekt jest prosty, wtedy dobrze się sprawdza model „ciągnij”.

Zarządzanie zasadami projektu obiektowego dla wzorca projektowego Obserwator Ogólnie rzecz biorąc, wzorcem projektowym Obserwator rządzi zasada otwarte-zamknięte (OCP). Motywacją dla zastosowania wzorca jest możliwość dodania nowych obiektów obserwujących bez konieczności wprowadzania zmian w obiekcie obserwowanym. Tak więc obiekt obserwowany pozostaje zamknięty.

BIBLIOGRAFIA

329

Wystarczy spojrzeć na rysunek 24.12, aby zauważyć, że obiekt klasy Clock można podstawić za obiekt Subject, natomiast obiekt klasy DigitalClock za obiekt Observer. A zatem zastosowano zasadę podstawiania Liskov (LSP). Observer jest klasą abstrakcyjną, a konkretna klasa DigitalClock od niej zależy. Zależą od niej także konkretne metody klasy Subject. A zatem w tym przypadku zastosowano zasadę odwracania zależności (DIP). Można by sądzić, że skoro klasa Subject nie zawiera metod abstrakcyjnych, to zależność pomiędzy klasami Clock i Subject narusza zasadę DIP. Jednak Subject jest klasą, dla której nigdy nie należy tworzyć egzemplarzy. Klasa ta ma sens wyłącznie w kontekście klasy pochodnej. Tak więc klasa Subject jest logicznie abstrakcyjna pomimo tego, że nie zawiera metod abstrakcyjnych. Abstrakcyjność klasy Subject można wymusić w języku C++ poprzez zdefiniowanie czysto wirtualnego destruktora albo poprzez zadeklarowanie konstruktorów tej klasy z modyfikatorem protected. Na rysunku 24.11 można również zauważyć ślady stosowania zasady segregacji interfejsów (ISP). Klasy Subject i TimeSource segregują klienty klasy MockTimeSource, dostarczając specjalizowanych interfejsów dla każdej grupy klientów.

Bibliografia 1. Gamma, et al. Design Patterns, Addison-Wesley, 1995. 2. Robert C. Martin, et al., Pattern Languages of Program Design 3, Addison-Wesley, 1998.

330

ROZDZIAŁ 24. OBSERWATOR — EWOLUCJA KODU DO WZORCA

R OZDZIAŁ 25

Wzorce projektowe Serwer abstrakcyjny i Most

Politycy wszędzie są tacy sami. Obiecują zbudować most nawet tam, gdzie nie ma rzeki — Nikita Chruszczow

W połowie lat dziewięćdziesiątych mocno angażowałem się w dyskusje prowadzone w ramach grupy dyskusyjnej comp.object. Osoby, które publikowały wiadomości w tej grupie dyskusyjnej, spierały się na tematy dotyczące różnych strategii analizy i projektowania. W pewnym momencie zdecydowaliśmy, że konkretny przykład pomoże nam ocenić stanowisko każdego z nas. W związku z tym wybraliśmy bardzo prosty problem projektowy i przystąpiliśmy do prezentowania naszych ulubionych rozwiązań. Problem projektowy był bardzo prosty. Postanowiliśmy zaprojektować oprogramowanie sterujące prostą lampą biurkową. Lampa biurkowa zawiera przełącznik i żarówkę. Można „zapytać” przełącznik, czy jest w stanie włączenia, czy wyłączenia; można też zlecić żarówce, by się zaświeciła lub wyłączyła. Przyjemny, prosty problem do rozwiązania. Dyskusje trwały miesiącami. Każdy z uczestników starał się zasugerować, że wybrany przez niego styl projektowania jest lepszy od tych, które zaproponowali inni. Niektórzy zaproponowali proste podejście polegające na stworzeniu obiektów switch i light. Inni byli zdania, że w rozwiązaniu powinien znaleźć się obiekt lampy zawierający obiekty przełącznika i żarówki. Jeszcze inni sugerowali konieczność zdefiniowania obiektu opisującego elektryczność. Jedna z osób zasugerowała nawet zdefiniowanie obiektu dla przewodu elektrycznego.

332

ROZDZIAŁ 25. WZORCE PROJEKTOWE SERWER ABSTRAKCYJNY I MOST

Pomimo absurdalności większości tych argumentów analiza modelu projektowego w tym przykładzie może być interesująca. Spójrzmy na rysunek 25.1. Z pewnością bez trudu uda nam się zaimplementować ten projekt. Obiekt Switch może odpytywać o stan przełącznika, a następnie wysyłać właściwe komunikaty turnOn i turnOff do obiektu Light.

Rysunek 25.1. Prosty model oprogramowania lampy biurkowej

Co nam się nie podoba w tym projekcie? Powyższy projekt narusza dwie zasady projektu obiektowego: zasadę odwracania zależności (DIP) oraz zasadę otwarte-zamknięte (OCP). Naruszenie zasady DIP można bardzo łatwo dostrzec — istnieje zależność pomiędzy konkretnymi klasami Switch i Light. Zgodnie z zasadą DIP powinniśmy tworzyć zależności od klas abstrakcyjnych. Naruszenie zasady OCP jest nieco mniej bezpośrednie, ale również można je dostrzec. Nie podoba nam się ten projekt, ponieważ zmusza nas do „ciągnięcia” ze sobą klasy Light wszędzie tam, gdzie potrzebujemy klasy Switch. Nie można w łatwy sposób rozszerzyć klasy Switch tak, aby mogła sterować obiektami innymi niż Light.

Wzorzec projektowy Serwer abstrakcyjny Można by sądzić, że dałoby się wydzielić podklasę klasy Switch, która służyłaby do sterowania innym obiektem niż Light w sposób podobny do pokazanego na rysunku 25.3. To jednak nie rozwiązałoby problemu, ponieważ klasa FanSwitch w dalszym ciągu dziedziczy zależność od klasy Light. Wszędzie, gdzie chcielibyśmy zastosować klasę FanSwitch, musielibyśmy „zabrać ze sobą” klasę Light. Taka relacja dziedziczenia również narusza zasadę DIP. W celu rozwiązania problemu zastosujemy jeden z najprostszych wzorców projektowych: Serwer abstrakcyjny (ang. Abstract server) — patrz rysunek 25.2. Dzięki wprowadzeniu interfejsu pomiędzy klasy Switch i Light zapewniliśmy możliwość sterowania przez klasę Switch dowolną klasą, która implementuje ten interfejs. Dzięki temu natychmiast spełniliśmy zarówno zasadę DIP, jak i OCP.

Rysunek 25.2. Zły sposób rozszerzenia klasy Switch

Rysunek 25.3. Rozwiązanie problemu oprogramowania lampki biurkowej z wykorzystaniem wzorca projektowego Serwer abstrakcyjny

WZORZEC PROJEKTOWY ADAPTER

333

Kto jest właścicielem interfejsu? Zwróćmy uwagę na fakt, że nazwa interfejsu pochodzi od klienta. Interfejs nazywa się Switchable zamiast ILight. Pisaliśmy o tym już wcześniej i prawdopodobnie będziemy jeszcze wracać do tego tematu. Interfejsy należą do klientów, a nie do klas pochodnych. Powiązanie logiczne pomiędzy klientem a interfejsem jest silniejsze niż powiązanie logiczne pomiędzy klasą Switch, interfejsem i jego pochodnymi. Powiązanie to jest na tyle silne, że używanie klasy Switch bez klasy implementującej interfejs Switchable nie ma sensu, natomiast jak najbardziej sensowne jest skorzystanie z klasy implementującej interfejs Switchable bez klasy Light. Siła powiązań logicznych jest sprzeczna z siłą powiązań fizycznych. Dziedziczenie jest znacznie silniejszym powiązaniem fizycznym od standardowej relacji. Na początku lat dziewięćdziesiątych uważano, że w projektach decydujące znaczenie powinny mieć związki fizyczne. W renomowanych publikacjach zalecano, aby hierarchie dziedziczenia były umieszczone w tym samym fizycznym pakiecie. To wydawało się sensowne, ponieważ dziedziczenie jest bardzo silnym związkiem fizycznym. Jednak w ciągu ostatnich dekad dowiedzieliśmy się, że fizyczna siła dziedziczenia jest myląca, a hierarchie dziedziczenia zazwyczaj nie powinny być umieszczane we wspólnym pakiecie. Zamiast tego w pakiecie powinny znaleźć się klienty razem z interfejsami, które one wykorzystują. To niedopasowanie siły powiązań logicznych i fizycznych jest artefaktem języków o statycznej kontroli typów, takich jak Java i C++. W językach z dynamiczną kontrolą typów, na przykład Smalltalk, Python i Ruby, takie niedopasowanie nie istnieje, ponieważ w celu osiągnięcia polimorficznego zachowania w tych językach nie jest stosowane dziedziczenie.

Wzorzec projektowy Adapter W projekcie zaprezentowanym na rysunku 25.3 występuje pewien problem. Projekt ten potencjalnie narusza zasadę pojedynczej odpowiedzialności (SRP). Klasy Light i Switchable są ze sobą powiązane, a być może ich zmiany nie będą wynikały z tych samych powodów. Co się stanie, jeśli nie będziemy mogli dodać związku dziedziczenia do klasy Light? Co zrobić, jeśli klasę Light zamówiliśmy od programisty z zewnątrz i nie mamy kodu źródłowego? Albo jak sobie poradzić, jeśli mamy klasę, która ma być kontrolowana przez klasę Switch, a nie możemy zapewnić jej dziedziczenia po interfejsie Switchable? Do tego rodzaju celów można zastosować wzorzec projektowy Adapter1. Na rysunku 25.4 pokazano, jak można zastosować wzorzec projektowy Adapter do rozwiązania naszego problemu. Adapter dziedziczy po interfejsie Switchable i deleguje wywołania do klasy Light. To rozwiązuje nasz problem. Teraz możemy użyć obiektu klasy Switch do kontrolowania dowolnego obiektu, który można włączyć lub wyłączyć. Wystarczy tylko stworzyć odpowiedni adapter. W rzeczywistości obiekty nie muszą nawet zawierać takich samych metod turnOn i turnOff, jakie ma interfejs Switchable. Adapter można zaadaptować do interfejsu obiektu.

Rysunek 25.4. Rozwiązanie problemu sterowania lampą biurową z wykorzystaniem wzorca projektowego Adapter 1

Wzorzec projektowy Adapter był prezentowany wcześniej, na rysunkach 10.2 i 10.3.

334

ROZDZIAŁ 25. WZORCE PROJEKTOWE SERWER ABSTRAKCYJNY I MOST

Nie ma nic za darmo. Zastosowanie wzorca projektowego Adapter wiąże się z kosztami. Trzeba napisać nową klasę, stworzyć egzemplarz adaptera i powiązać z nim adaptowany obiekt. Następnie za każdym razem, kiedy wywołujemy adapter, musimy ponieść koszty czasu i przestrzeni wymaganych do zaimplementowania delegacji. Zatem wyraźnie widać, że adapterów nie należy stosować zawsze. Do rozwiązania większości problemów dobrze nadaje się wzorzec projektowy Serwer abstrakcyjny. Nawet wyjściowe rozwiązanie pokazane na rysunku 25.1 było dobre tak długo, aż dowiedzieliśmy się, że obiekt klasy Switch może być użyty do sterowania innymi obiektami.

Wzorzec projektowy Adapter w formie klasy Rozwiązanie z klasą LightAdapter pokazane na rysunku 25.4 jest znane jako obiektowa forma adaptera. Istnieje inne podejście znane jako klasowa forma adaptera, które pokazano na rysunku 25.5. W tej formie obiekt adaptera dziedziczy zarówno po interfejsie Switchable, jak i po klasie Light. Ta postać jest nieco wydajniejsza od formy obiektowej oraz jest trochę łatwiejsza do zastosowania, ale kosztem wysokiego poziomu sprzężeń związanych z dziedziczeniem.

Rysunek 25.5. Rozwiązanie problemu sterowania lampą biurową z wykorzystaniem wzorca projektowego Adapter w postaci klasowej

Problem modemu. Adaptery i zasada LSP Rozważmy sytuację z rysunku 25.6. Przedstawiono na nim wiele modemów, które korzystają z interfejsu Modem. Interfejs Modem jest zaimplementowany przez kilka klas pochodnych, takich jak HayesModem, USRoboticsModem oraz EarniesModem. To dość częsta sytuacja. Zaprezentowany model spełnia zasady OCP, LSP i DIP. Opracowanie nowych rodzajów modemów nie ma wpływu na aplikacje klienckie interfejsu Modem. Przypuśćmy, że taka sytuacja trwa kilka lat. Załóżmy, że istnieją setki aplikacji klienckich, które z powodzeniem korzystają z interfejsu Modem.

Rysunek 25.6. Problem modemu

WZORZEC PROJEKTOWY ADAPTER

335

Przypuśćmy teraz, że otrzymaliśmy nowe wymaganie od klientów. Istnieje pewna grupa modemów, które nie wybierają numeru. Są one określane jako tzw. modemy dedykowane, ponieważ instaluje się je po obu stronach dedykowanego połączenia2. Jest kilka nowych aplikacji, które używają tych dedykowanych modemów i nie wybierają numerów. Aplikacjom tym nadamy nazwę DedUsers. Jednak nasi klienci chcą, aby wszystkie istniejące klienty modemu mogły korzystać z tych dedykowanych modemów. Dodatkowo powiedzieli nam, że nie chcą modyfikować setek aplikacji klienckich modemu, więc te klienty interfejsu Modem będą wybierały nieistotne numery telefonów. Gdybyśmy to my mieli podjąć decyzję, moglibyśmy zmodyfikować projekt systemu w sposób pokazany na rysunku 25.7. Moglibyśmy zażądać od dostawcy usług internetowych podziału funkcji wybierania numerów i funkcji komunikacyjnych na dwa oddzielne interfejsy. Stare modemy implementowałyby oba interfejsy, a aplikacje klienckie modemów korzystałyby z tych interfejsów. Aplikacje DedUser korzystałyby tylko z interfejsu Modem, natomiast klasa DedicatedModem implementowałaby wyłącznie interfejs Modem. Niestety to wymagałoby wprowadzenia modyfikacji we wszystkich aplikacjach korzystających z modemów. Tego jednak zabronili nam nasi klienci.

Rysunek 25.7. Idealne rozwiązanie problemu modemu

Co można zrobić w takiej sytuacji? Nie możemy rozdzielić interfejsów tak, jak chcieliśmy, a pomimo to musimy znaleźć sposób na to, by wszystkie klienty mogły skorzystać z klasy DedicatedModem. Jednym z możliwych rozwiązań jest dziedziczenie przez klasę DedicatedModem po klasie Modem i zaimplementowanie pustych metod dial i hangup: class DedicatedModem { public: virtual void virtual void virtual void {...} virtual char {...} };

2

public : Modem dial(char phoneNumber[10]) {} hangup() {} send(char c) receive()

Kiedyś wszystkie modemy były dedykowane. Dopiero w ostatnich epokach geologicznych modemy uzyskały zdolność wybierania numerów. We wczesnym okresie jurajskim można było wypożyczyć sporej wielkości modem od firmy telefonicznej i podłączyć go do innego modemu za pomocą dedykowanych łączy, które również dzierżawiło się od firmy telefonicznej (okres jurajski był bardzo dobry dla firm telefonicznych). Jeśli ktoś chciał wybierać numery, musiał wydzierżawić inne urządzenie — tzw. auto dialer.

336

ROZDZIAŁ 25. WZORCE PROJEKTOWE SERWER ABSTRAKCYJNY I MOST

Zdegenerowane funkcje mogą być symptomem naruszenia zasady LSP. Użytkownicy klasy bazowej mogą oczekiwać od metod dial i hangup znaczącej zmiany stanu modemu. Zdegenerowane implementacje w klasie DedicatedModem mogą przeszkadzać w spełnieniu tych oczekiwań. Załóżmy, że aplikacje klienckie oczekują od modemów pozostawania w stanie uśpienia do chwili wywołania metody dial oraz powrotu do stanu spoczynku po wywołaniu metody hangup. Innymi słowy, aplikacje nie spodziewają się od modemów wysyłania żadnych znaków przed wybraniem numeru. Klasa DedicatedModem narusza to oczekiwanie. Zwraca znaki przed wywołaniem metody dial oraz kontynuuje ich wysyłanie nawet po wywołaniu metody hangup. Z tego względu klasa DedicatedModem może doprowadzić do nieprawidłowego działania niektórych klientów modemów. Niektórzy pewnie twierdzą, że problem leży po stronie aplikacji klienckich modemów. Nie zostały napisane dobrze, jeśli wykazują błędy w przypadku przekazania nieoczekiwanych danych wejściowych. Zgadzam się z tym poglądem. Trudno będzie jednak przekonać osoby odpowiedzialne za utrzymywanie klientów modemów do wprowadzenia zmian w oprogramowaniu z powodu dodania nowego rodzaju modemu. To nie tylko narusza zasadę OCP, ale jest po prostu frustrujące. A poza tym nasz klient wyraźnie zabronił nam wprowadzania zmian w aplikacjach klienckich. Rozwiązanie bazujące na „prowizorce”. Możemy zasymulować status połączenia w metodach dial i hangup klasy DedicatedModem. Możemy odmówić zwracania znaków w przypadku, gdy nie wywołano metody dial lub po wywołaniu metody hangup. Wprowadzenie tego rodzaju zmian pozwoli na uniknięcie modyfikowania klientów modemów. Trzeba tylko przekonać programistów aplikacji DedUsers do wywoływania metod dial i hangup (patrz rysunek 25.8).

Rysunek 25.8. Rozwiązanie problemu modemu poprzez symulowanie stanu połączenia w klasie DedicatedModem

Łatwo sobie wyobrazić, że twórcy aplikacji DedUsers nie będą zadowoleni z takiego rozwiązania. W swoich aplikacjach jawnie korzystają z klasy DedicatedModem. Dlaczego mają być zmuszeni do wywoływania metod dial i hangup? Jednak ci programiści jeszcze nie zakończyli pracy nad swoim oprogramowaniem, więc łatwiej będzie ich przekonać do wprowadzenia odpowiednich modyfikacji. Złożona pajęczyna zależności. Kilka miesięcy później, kiedy już będą istniały setki aplikacji DedUsers, nasi klienci poproszą nas o wprowadzenie nowej zmiany. Wydaje się, że przez te wszystkie lata nasze programy nie musiały wybierać międzynarodowych numerów telefonów. Dlatego właśnie metoda dial pobierała argument typu char[10]. Teraz nasi klienci chcą mieć możliwość wybierania numerów telefonicznych o dowolnej długości. Chcą realizować połączenia międzynarodowe, płacić za połączenia kartami kredytowymi, wykonywać połączenia identyfikowane za pomocą numerów PIN itp.

WZORZEC PROJEKTOWY ADAPTER

337

Zastosowanie takiego rozwiązania zmusza do wprowadzenia zmian we wszystkich aplikacjach klienckich. Aplikacje te oczekują reprezentowania numerów telefonów za pomocą tablic char[10]. Nasz klient zaakceptował to rozwiązanie z braku innego wyjścia. Z tego powodu całe rzesze programistów zostały zaangażowane do wprowadzenia odpowiednich zmian w swoich aplikacjach. Nie ma wątpliwości, że trzeba również zmodyfikować klasy w hierarchii modemów, aby uwzględnić nowy rozmiar numerów telefonów. Z tym zadaniem może sobie poradzić nasz niewielki zespół. Niestety, musimy teraz zwrócić się do autorów aplikacji DedUsers i powiedzieć im, że powinni zmodyfikować swój kod! Łatwo sobie wyobrazić, że nie będą z tego zadowoleni. W końcu metoda dial w ogóle nie jest im potrzebna. Wywołują ją tylko dlatego, ponieważ powiedzieliśmy im, że muszą to robić. A teraz ponownie muszą wprowadzić kosztowne zmiany, ponieważ zrobili to, o co ich poprosiliśmy. Jest to rodzaj kłopotliwej plątaniny zależności, z którą można się spotkać w wielu projektach. Prowizorka w jednej części systemu tworzy sieć zależności, która w końcu powoduje problemy w innej części systemu, całkowicie niezwiązanej z tą, w której wprowadziliśmy zmiany. Wzorzec projektowy Adapter w roli koła ratunkowego. Moglibyśmy zapobiec problemom, które napotkaliśmy, gdybyśmy do rozwiązania pierwotnego problemu zastosowali wzorzec projektowy Adapter (patrz rysunek 25.9). W zaprezentowanym modelu klasa DedicatedModem nie dziedziczy po interfejsie Modem. Klienty modemu wykorzystują klasę DedicatedModem za pośrednictwem klasy DedicatedModemAdapter. Obiekt tej klasy implementuje metody dial i hangup w celu zasymulowania stanu połączenia. Adapter deleguje wywołania send i receive do klasy DedicatedModem.

Rysunek 25.9. Rozwiązanie problemu modemu dzięki zastosowaniu wzorca projektowego Adapter

Zwróćmy uwagę, że zaproponowane rozwiązanie eliminuje wszystkie nasze wcześniejsze problemy. Klienty interfejsu Modem mają dostęp do zachowań połączeń zgodnie ze swoimi oczekiwaniami, natomiast aplikacje DedUser nie muszą używać metod dial i hangup. Zmiany w wymaganiach dotyczących numerów telefonów nie będą miały wpływu na aplikacje DedUser. Dzięki zastosowaniu wzorca projektowego Adapter udało się zapewnić zgodność zarówno z zasadą LSP, jak i OCP. Trzeba jednak pamiętać, że prowizorka dalej istnieje. Adapter w dalszym ciągu symuluje stan połączenia. Wiele osób pomyśli pewnie, że to rozwiązanie jest mało eleganckie. Oczywiście zgodzę się z tymi osobami. Warto jednak zwrócić uwagę na to, że wszystkie zależności są skierowane na zewnątrz adaptera (są to zależności wychodzące). Prowizorka (symulowanie stanu połączenia) jest odizolowana od systemu — zaimplementowano ją wewnątrz adaptera, z którego istnienia niewiele osób zdaje sobie sprawę. Jedyną silną zależnością od tego adaptera będzie prawdopodobnie implementacja jakiejś fabryki 3. 3

Więcej informacji na ten temat można znaleźć w rozdziale 21., „Wzorzec projektowy Fabryka”.

338

ROZDZIAŁ 25. WZORCE PROJEKTOWE SERWER ABSTRAKCYJNY I MOST

Wzorzec projektowy Most Na przedstawiony problem można spojrzeć z innej strony. Potrzeba istnienia dedykowanego modemu wprowadziła nowy poziom swobody do hierarchii typu Modem. Początkowo Modem był prostym interfejsem dla zbioru różnych urządzeń sprzętowych. Mieliśmy klasy HayesModem, USRModem i ErniesModem, które były pochodnymi bazowej klasy Modem. Teraz jednak wydaje się, że istnieje sposób uproszczenia tej hierarchii. Można zdefiniować klasy DialModem i DedicatedModem jako pochodne klasy Modem. Te dwie niezależne hierarchie można scalić w sposób pokazany na rysunku 25.10. Każdy z liści hierarchii typów dostarcza funkcji wybierania numerów albo obsługi dedykowanego połączenia dla sprzętu, którym steruje. Obiekt klasy DedicatedHayesModem steruje modemem Hayes w trybie dedykowanym.

Rysunek 25.10. Rozwiązanie problemu modemu dzięki scaleniu hierarchii typów

Ta struktura nie jest idealna. Za każdym razem, gdy dodajemy nowe urządzenie, musimy utworzyć dwie nowe klasy — jedną dla trybu dedykowanego i drugą pozwalającą na wybieranie numerów. Za każdym razem, gdy dodajemy nowy typ połączenia, musimy utworzyć trzy nowe klasy — po jednej dla każdego urządzenia. Jeśli pozostawimy te dwa stopnie swobody, będziemy musieli zaakceptować możliwość szybkiego wzrostu liczby klas potomnych. W sytuacji, gdy w hierarchii typów istnieje więcej niż jeden stopień swobody, można zastosować wzorzec projektowy Most (ang. Bridge). Zamiast scalania hierarchii, można je rozdzielić, a następnie powiązać za pomocą mostu. Odpowiednią strukturę pokazano na rysunku 25.11. Hierarchia typu Modem została podzielona na dwie części. Pierwsza reprezentuje metodę połączenia, natomiast druga — urządzenia sprzętowe. Użytkownicy typu Modem nadal korzystają z interfejsu Modem. Klasa ModemConnectionControlle implementuje interfejs Modem. Pochodne klasy ModemConnectionController zarządzają mechanizmami połączeń. Klasa DialModemController przekazuje wywołania metod dial i hangup do metod dialImp i hangImp w klasie bazowej ModemConnectionController . Następnie te metody delegują wywołania do klasy ModemImplementation , gdzie są one kierowane do odpowiedniego sterownika sprzętowego. Klasa DedModemController implementuje metody dial i hangup w celu zasymulowania stanu połączenia. Przekazuje ona metody send i receive do metod sendImp i receiveImp, skąd są one delegowane do hierarchii ModemImplementation tak jak wcześniej. Zwróćmy uwagę, że cztery funkcje imp klasy bazowej ModemConnectionController są chronione. Wynika to stąd, że mają one być wykorzystywane wyłącznie przez pochodne klasy ModemConnectionController. Nie powinny być wywoływane przez żadną inną klasę.

WNIOSEK

339

Rysunek 25.11. Rozwiązanie problemu modemu z wykorzystaniem wzorca projektowego Most

Zaprezentowana struktura jest złożona, ale interesująca. Można ją było stworzyć bez modyfikowania użytkowników modemów, a pomimo to pozwoliła nam na całkowite odseparowanie strategii połączeń od implementacji urządzeń sprzętowych. Każda pochodna klasy ModemConnectionController reprezentuje odrębną strategię połączenia. Do zaimplementowania tych strategii są wykorzystywane klasy sendImp, receiveImp, dialImp oraz hangImp. Nowe funkcje imp mogą być tworzone bez konieczności dostosowywania użytkowników. Do klas kontrolerów połączeń można również dodawać nowe interfejsy dostawców usług. W ten sposób udało się stworzyć ścieżkę migracji dla klientów modemów w kierunku interfejsów API na wyższym poziomie niż metody dial i hangup.

Wniosek Można by sądzić, że rzeczywisty problem z hierarchią modemów polega na tym, że oryginalny projekt był zły. Należało zauważyć, że połączenia i komunikacja to odrębne pojęcia. Gdyby przeprowadzono dokładniejszą analizę, można by to dostrzec i odpowiednio skorygować projekt. Zatem można by próbować winić projektantów za niedostateczną analizę. Cóż za bzdury! Nie ma czegoś takiego jak wystarczająca analiza. Bez względu na to, ile czasu poświecimy na próby znalezienia doskonałej struktury oprogramowania, zawsze znajdzie się takie żądanie zmiany, które narusza tę strukturę. Nie ma przed tym ucieczki. Nie istnieją struktury doskonałe. Są tylko takie struktury, które próbują zrównoważyć bieżące koszty i korzyści. W miarę upływu czasu i w miarę jak zmieniają się wymagania stawiane systemowi, struktury muszą się zmieniać. Sztuka zarządzania tymi zmianami polega na tym, aby utrzymywać system w stanie jak najprostszym i jak najbardziej elastycznym.

340

ROZDZIAŁ 25. WZORCE PROJEKTOWE SERWER ABSTRAKCYJNY I MOST

Rozwiązanie bazujące na wzorcu projektowym Adapter jest proste i bezpośrednie. Wszystkie zależności są skierowane w odpowiednią stronę, a dodatkowo rozwiązanie jest bardzo proste do zaimplementowania. Rozwiązanie bazujące na wzorcu projektowym Most jest nieco bardziej złożone. Podjęcie decyzji o podążeniu w tym kierunku polecałbym odłożyć do czasu, aż będziemy mieli bardzo mocne dowody na potrzebę całkowitego odseparowania strategii połączenia i komunikacji oraz potrzeby dodawania nowych strategii połączeń. Warto podkreślić, że stosowanie wzorców zawsze wiąże się zarówno z korzyściami, jak i kosztami. Należy stosować te wzorce, które najlepiej nadają się do rozwiązywania bieżących problemów.

Bibliografia 1. Gamma, et al., Design Patterns, Reading, MA: Addison-Wesley, 1995.

R OZDZIAŁ 26

Wzorce projektowe Pełnomocnik i Schody do nieba — zarządzanie zewnętrznymi interfejsami API

Czy ktoś pamięta śmiech? — Robert Plant, The Song Remains the Same

W systemach oprogramowania istnieje wiele barier. Kiedy przenosimy dane z programu do bazy danych, przekraczamy barierę bazy danych. Kiedy wysyłamy wiadomość z jednego komputera do drugiego, przekraczamy barierę sieci. Przekraczanie barier może być skomplikowane. Jeśli nie zachowamy ostrożności, nasze oprogramowanie będzie w większym stopniu dotyczyło pokonywania barier niż rozwiązywania problemów, które powinno rozwiązywać. Wzorce projektowe zaprezentowane w tym rozdziale pomagają pokonać opisane bariery, a jednocześnie pozwalają skoncentrować się na problemie do rozwiązania.

342

ROZDZIAŁ 26. WZORCE PROJEKTOWE PEŁNOMOCNIK I SCHODY DO NIEBA

Wzorzec projektowy Pełnomocnik Wyobraźmy sobie, że piszemy aplikację, która ma obsługiwać koszyk na zakupy w sklepie internetowym. W takim systemie mogłyby się znaleźć obiekty reprezentujące klienta, zamówienie (koszyk) oraz produkty będące przedmiotem zamówienia. Możliwą strukturę takiego systemu pokazano na rysunku 26.1. Zaprezentowana struktura jest uproszczona, ale wystarczy do naszych celów.

Rysunek 26.1. Prosty model obiektowy koszyka na zakupy

Gdybyśmy spróbowali rozwiązać problem dodania nowego towaru do zamówienia, moglibyśmy uzyskać kod zamieszczony na listingu 26.1. Metoda addItem klasy Order tworzy nowy obiekt Item zawierający odpowiedni obiekt Product oraz informację o zamawianej ilości. Następnie metoda dodaje ten obiekt Item do wewnętrznej struktury Vector złożonej z obiektów Item. Listing 26.1. Dodawanie pozycji do modelu obiektowego public class Order { private Vector itsItems = new Vector(); public void addItem(Product p, int qty) { Item item = new Item(p, qty); itsItems.add(item); } }

Wyobraźmy sobie teraz, że te obiekty reprezentują dane, które są przechowywane w relacyjnej bazie danych. Na rysunku 26.2 pokazano tabele i klucze, które mogłyby reprezentować potrzebne obiekty. Aby znaleźć zamówienia składane przez określonego klienta, należy odszukać wszystkie rekordy z wartością identyfikatora tego klienta. Aby znaleźć wszystkie towary w tym zamówieniu, wyszukujemy wszystkie towary z identyfikatorem orderId szukanego zamówienia. Aby znaleźć produkty odpowiadające określonym towarom, należy skorzystać z identyfikatora sku tych produktów.

Rysunek 26.2. Relacyjny model danych koszyka na zakupy

WZORZEC PROJEKTOWY PEŁNOMOCNIK

343

Gdybyśmy chcieli dodać wiersz odpowiadający towarowi do określonego zamówienia, moglibyśmy wykorzystać kod podobny do tego, który pokazano na listingu 26.2. W tym kodzie wykorzystano wywołania JDBC w celu wykonywania operacji bezpośrednio na relacyjnym modelu danych. Listing 26.2. Dodawanie towaru do modelu relacyjnego public class AddItemTransaction extends Transaction { public void addItem(int orderId, String sku, int qty) { Statement s = itsConnection.CreateStatement(); s.executeUpdate("insert into items values(" + orderId + "," + sku + "," + qty + ")"); } }

Choć dwa fragmenty kodu zaprezentowane powyżej bardzo się różnią, to realizują tę samą funkcję logiczną. Oba dodają towar do zamówienia. Pierwszy ignoruje istnienie bazy danych, natomiast drugi akcentuje ten fakt. Jest oczywiste, że w programie dotyczącym koszyka na zakupy występują zamówienia, pozycje zamówień i towary. Niestety, gdybyśmy chcieli skorzystać z kodu z listingu 26.2, musielibyśmy poświęcić mnóstwo pracy na opracowanie instrukcji SQL, obsługi połączeń z bazą danych oraz łączenia ciągów zapytań. Oznaczałoby to poważne naruszenie zasad SRP oraz CCP. Kod z listingu 26.2 łączy ze sobą dwa pojęcia, które mogą się zmieniać z różnych powodów. Pojęcia towarów i zamówień mieszają się z pojęciami schematów relacyjnych baz danych i języka SQL. Zmiana któregoś z tych pojęć z dowolnego powodu ma wpływ na pozostałe. Kod z listingu 26.2 narusza również zasadę DIP, ponieważ strategia programu zależy od szczegółów mechanizmów utrwalania danych. Opisane problemy można złagodzić dzięki zastosowaniu wzorca projektowego Pełnomocnik (ang. Proxy). Aby pokazać jego zastosowanie, stworzymy program testowy, który pokazuje sposób utworzenia zamówienia i obliczenia całkowitej ceny. Najważniejszą część tego programu zamieszczono na listingu 26.3. Listing 26.3. Program testowy tworzy zamówienie i sprawdza poprawność obliczenia ceny public void testOrderPrice() { Order o = new Order("Bogdan"); Product toothpaste = new Product("Pasta do zębów", 129); o.addItem(toothpaste, 1); assertEquals(129, o.total()); Product mouthwash = new Product("Płyn do płukania ust", 342); o.addItem(mouthwash, 2); assertEquals(813, o.total()); }

Prosty program, który pomyślnie przechodzi powyższy test, pokazano na listingach od 26.4 do 26.6. W programie skorzystano z modelu obiektowego z rysunku 26.1. W kodzie nie założono istnienia bazy danych. Przedstawiony kod jest niekompletny pod wieloma względami. Jest to kod w minimalnej postaci niezbędnej do spełnienia testu. Listing 26.4. order.java public class Order { private Vector itsItems = new Vector(); public Order(String cusid) { } public void addItem(Product p, int qty)

344

ROZDZIAŁ 26. WZORCE PROJEKTOWE PEŁNOMOCNIK I SCHODY DO NIEBA

{ }

}

Item item = new Item(p,qty); itsItems.add(item);

public int total() { int total = 0; for (int i = 0; i < itsItems.size(); i++) { Item item = (Item) itsItems.elementAt(i); Product p = item.getProduct(); int qty = item.getQuantity(); total += p.getPrice() * qty; } return total; }

Listing 26.5. product.java public class Product { private int itsPrice; public Product(String name, int price) { itsPrice = price; }

}

public int getPrice() { return itsPrice; }

Listing 26.6. item.java public class Item { private Product itsProduct; private int itsQuantity; public Item(Product p, int qty) { itsProduct = p; itsQuantity = qty; } public Product getProduct() { return itsProduct; }

}

public int getQuantity() { return itsQuantity; }

Na rysunkach 26.3 i 26.4 pokazano sposób działania wzorca projektowego Pełnomocnik. Każdy obiekt, który ma być obsłużony, podzielono na trzy części. Pierwsza to interfejs. Zadeklarowano w nim wszystkie metody, z których muszą skorzystać klienty. Druga część to klasa, która implementuje te metody bez „wiedzy” o bazie danych. Trzecia to pełnomocnik, który „ma świadomość” istnienia bazy danych.

WZORZEC PROJEKTOWY PEŁNOMOCNIK

345

Rysunek 26.3. Statyczny model wzorca projektowego Pełnomocnik

Rysunek 26.4. Dynamiczny model wzorca projektowego Pełnomocnik

Przeanalizujmy klasę Product. Zastosowaliśmy dla niej wzorzec Pełnomocnik poprzez zastąpienie jej interfejsem. Ten interfejs ma dokładnie te same metody co klasa Product. Klasa ProductImplementation implementuje interfejs prawie tak samo jak wcześniej. Klasa ProductDBProxy implementuje wszystkie metody klasy Product w celu pobrania produktu z bazy danych, stworzenia egzemplarza klasy Product Implementation oraz oddelegowania do niej komunikatu. Sposób działania tego wzorca pokazano na rysunku 26.4. Klient wysyła komunikat getPrice do obiektu, który uważa za egzemplarz klasy Product, a który w rzeczywistości jest egzemplarzem klasy ProductDBProxy. Obiekt klasy ProductDBProxy pobiera z bazy danych egzemplarz obiektu ProductImple mentation. Następnie deleguje do niego metodę getPrice. O tym, co się dzieje, „nie wiedzą” ani aplikacja kliencka, ani egzemplarz klasy ProductImplementation. W ten sposób wprowadzono bazę danych do aplikacji bez informowania o tym fakcie zainteresowanych stron. Na tym polega siła wzorca projektowego Pełnomocnik. Teoretycznie można go umieścić pomiędzy dwoma współpracującymi obiektami bez konieczności informowania tych obiektów o tym fakcie. Dzięki temu wzorzec ten można wykorzystać do przekraczania takich barier jak baza danych lub sieć bez konieczności modyfikowania „zainteresowanych stron”. W praktyce zastosowanie klas-pełnomocników nie jest trywialne. Aby zorientować się co do charakteru występujących problemów, spróbujmy dodać wzorzec projektowy Pełnomocnik do prostej aplikacji koszyka na zakupy.

Implementacja wzorca projektowego Pełnomocnik w aplikacji koszyka na zakupy Najprostszą klasę-pełnomocnika można utworzyć dla klasy Product. Dla celów naszego przykładu tabela produktów reprezentuje prosty słownik. Tabela ta zostanie załadowana w jednym miejscu wszystkimi produktami. Na tej tabeli nie są wykonywane inne operacje, dlatego utworzenie klas-pełnomocników jest stosunkowo proste. Na początek potrzebujemy prostego narzędzia dostępu do bazy danych, które umożliwia zapisywanie i pobieranie danych o produktach. Obiekt-pełnomocnik skorzysta z tego interfejsu do wykonywania operacji na bazie danych. Przypadek testowy dla programu, który realizuje te operacje, pokazano na listingu 26.7. Kod z listingów 26.8 i 26.9 pomyślnie przechodzi ten test.

346

ROZDZIAŁ 26. WZORCE PROJEKTOWE PEŁNOMOCNIK I SCHODY DO NIEBA

Listing 26.7. DBTest.java import junit.framework.*; import junit.swingui.TestRunner; public class DBTest extends TestCase { public static void main(String[] args) { TestRunner.main(new String[]{"DBTest"}); } public DBTest(String name) { super(name); } public void setUp() throws Exception { DB.init(); } public void tearDown() throws Exception { DB.close(); }

}

public void testStoreProduct() throws Exception { ProductData storedProduct = new ProductData(); storedProduct.name = "MyProduct"; storedProduct.price = 1234; storedProduct.sku = "999"; DB.store(storedProduct); ProductData retrievedProduct = DB.getProductData("999"); DB.deleteProductData("999"); assertEquals(storedProduct, retrievedProduct); }

Listing 26.8. ProductData.java public class ProductData { public String name; public int price; public String sku; public ProductData() { } public ProductData(String name, int price, String sku) { this.name = name; this.price = price; this.sku = sku; }

}

public boolean equals(Object o) { ProductData pd = (ProductData)o; return name.equals(pd.name) && sku.equals(pd.sku) && price==pd.price; }

WZORZEC PROJEKTOWY PEŁNOMOCNIK

Listing 26.9. DB.java import java.sql.*; public class DB { private static Connection con; public static void init() throws Exception { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); con = DriverManager.getConnection( "jdbc:odbc:PPP Shopping Cart"); } public static void store(ProductData pd) throws Exception { PreparedStatement s = buildInsertionStatement(pd); executeStatement(s); } private static PreparedStatement buildInsertionStatement(ProductData pd) throws SQLException { PreparedStatement s = con.prepareStatement( "INSERT into Products VALUES (?, ?, ?)"); s.setString(1, pd.sku); s.setString(2, pd.name); s.setInt(3, pd.price); return s; } public static ProductData getProductData(String sku) throws Exception { PreparedStatement s = buildProductQueryStatement(sku); ResultSet rs = executeQueryStatement(s); ProductData pd = extractProductDataFromResultSet(rs); rs.close(); s.close(); return pd; } private static PreparedStatement buildProductQueryStatement(String sku) throws SQLException { PreparedStatement s = con.prepareStatement( "SELECT * FROM Products WHERE sku = ?;"); s.setString(1, sku); return s; } private static ProductData extractProductDataFromResultSet(ResultSet rs) throws SQLException { ProductData pd = new ProductData(); pd.sku = rs.getString(1); pd.name = rs.getString(2); pd.price = rs.getInt(3); return pd; } public static void deleteProductData(String sku) throws Exception { executeStatement(buildProductDeleteStatement(sku)); } private static PreparedStatement buildProductDeleteStatement(String sku) throws SQLException

347

348

ROZDZIAŁ 26. WZORCE PROJEKTOWE PEŁNOMOCNIK I SCHODY DO NIEBA

{

}

PreparedStatement s = con.prepareStatement( "DELETE from Products where sku = ?"); s.setString(1, sku); return s;

private static void executeStatement(PreparedStatement s) throws SQLException { s.execute(); s.close(); } private static ResultSet executeQueryStatement(PreparedStatement s) throws SQLException { ResultSet rs = s.executeQuery(); rs.next(); return rs; }

}

public static void close() throws Exception { con.close(); }

Następnym krokiem w implementacji wzorca projektowego Pełnomocnik jest napisanie testu, który pokazuje, jak on działa. Ten test dodaje produkt do bazy danych. Następnie tworzy obiekt klasy ProductProxy z identyfikatorem sku właściwym dla tego produktu i próbuje skorzystać z metod dostępowych klasy Product w celu uzyskania dostępu do danych z obiektu-pełnomocnika (patrz listing 26.10). Listing 26.10. ProxyTest.java import junit.framework.*; import junit.swingui.TestRunner; public class ProxyTest extends TestCase { public static void main(String[] args) { TestRunner.main(new String[]{"ProxyTest"}); } public ProxyTest(String name) { super(name); } public void setUp() throws Exception { DB.init(); ProductData pd = new ProductData(); pd.sku = "ProxyTest1"; pd.name = "ProxyTestName1"; pd.price = 456; DB.store(pd); } public void tearDown() throws Exception { DB.deleteProductData("ProxyTest1"); DB.close(); }

WZORZEC PROJEKTOWY PEŁNOMOCNIK

}

349

public void testProductProxy() throws Exception { Product p = new ProductProxy("ProxyTest1"); assertEquals(456, p.getPrice()); assertEquals("ProxyTestName1", p.getName()); assertEquals("ProxyTest1", p.getSku()); }

Aby zastosowany wzorzec mógł działać, musimy oddzielić interfejs klasy Product od jej implementacji. Z tego powodu przekształciłem klasę Product na interfejs i stworzyłem klasę ProductImp, która implementuje ten interfejs (patrz listingi 26.11 i 26.12). Listing 26.11. Product.java public interface Product { public int getPrice() throws Exception; public String getName() throws Exception; public String getSku() throws Exception; }

Listing 26.12. ProductImp.java public class ProductImp implements Product { private int itsPrice; private String itsName; private String itsSku; public ProductImp(String sku, String name, int price) { itsPrice = price; itsName = name; itsSku = sku; } public int getPrice() { return itsPrice; } public String getName() { return itsName; }

}

public String getSku() { return itsSku; }

Zwróćmy uwagę, że dodałem wyjątki do interfejsu Product. Zrobiłem tak, ponieważ pisałem klasę ProductProxy (listing 26.13) w tym samym czasie co klasy Product, ProductImp oraz ProxyTest. Zaimplementowałem po jednej metodzie dostępowej na raz. Jak się przekonamy, obiekt klasy ProductProxy wywołuje bazę danych, a to powoduje zgłoszenie wyjątków. Nie chciałem, aby te wyjątki zostały przechwycone przez klasę-pełnomocnika i tam ukryte, dlatego pozwoliłem, żeby wyszły poza interfejs. Listing 26.13. ProductProxy.java public class ProductProxy implements Product { private String itsSku; public ProductProxy(String sku)

350

ROZDZIAŁ 26. WZORCE PROJEKTOWE PEŁNOMOCNIK I SCHODY DO NIEBA

{

itsSku = sku; } public int getPrice() throws Exception { ProductData pd = DB.getProductData(itsSku); return pd.price; } public String getName() throws Exception { ProductData pd = DB.getProductData(itsSku); return pd.name; }

}

public String getSku() throws Exception { return itsSku; }

Implementacja tej klasy-pełnomocnika jest prosta. Właściwie zaprezentowana implementacja nie pasuje do kanonicznej formy wzorca przedstawionej na rysunkach 26.3 i 26.4. To była niespodzianka. Moim zamiarem było zaimplementowanie wzorca projektowego Pełnomocnik. Kiedy jednak ostatecznie implementacja zmaterializowała się, kanoniczna postać wzorca projektowego przestała mieć sens. Zgodnie z tym, co pokazano poniżej, w kanonicznej postaci wzorca obiekt klasy ProductProxy tworzy obiekt ProductImp w każdej metodzie. Następnie ta metoda powinna być oddelegowana do klasy ProductImp. public int getPrice() throws Exception { ProductData pd = DB.getProductData(itsSku); ProductImp p = new ProductImp(pd.sku, pd.name, pd.price); return p.getPrice(); }

Tworzenie obiektów ProductImp w taki sposób jest całkowitym marnotrawstwem pracy programistów i zasobów komputerowych. Obiekt ProductProxy już dysponuje danymi, które powinny zwracać metody dostępowe klasy ProductImp. Nie ma zatem potrzeby tworzenia obiektów ProductImp, a następnie delegowania do nich metod. To kolejny przykład sytuacji, w której kod źródłowy może odwieść programistę od oczekiwanych wzorców i modeli. Zwróćmy uwagę, że w metodzie getSku klasy ProductProxy z listingu 26.13 posunięto się o jeden krok dalej. Wcale nie odwołano się do wartości identyfikatora sku zapisanej w bazie danych. Do czego miałoby służyć takie odwołanie? Przecież wartość identyfikatora sku jest już dostępna. Można by sądzić, że implementacja klasy ProductProxy w takiej postaci jest bardzo niewydajna. Każda metoda dostępowa odwołuje się do bazy danych. Czyż nie byłoby lepiej, gdyby wartość ProductData została zbuforowana tak, by uniknąć ciągłego sięgania do bazy danych? Wprowadzenie potrzebnej zmiany jest bardzo proste, ale jedyne, co skłania nas do wprowadzenia tej zmiany, to nasze obawy. W tym momencie nie mamy danych sugerujących, że w tym programie występuje problem wydajności. Poza tym zdajemy sobie sprawę z tego, że sam silnik bazy danych korzysta z mechanizmów buforowania. Z tego względu nie mamy pewności, co dałoby nam stworzenie własnego mechanizmu buforowania. Powinniśmy poczekać do czasu wystąpienia problemów z wydajnością, zanim sami stworzymy sobie problemy. Tworzenie pełnomocników dla relacji. Drugim krokiem w implementacji omawianego wzorca jest stworzenie pełnomocnika dla klasy Order. Każdy egzemplarz klasy Order zawiera wiele egzemplarzy klasy Item. W schemacie relacyjnym (rysunek 26.2) ta relacja została uwzględniona w obrębie tabeli Item. Każdy wiersz tabeli Item zawiera klucz rekordu tabeli Order reprezentującego zamówienie, na którym

WZORZEC PROJEKTOWY PEŁNOMOCNIK

351

znalazł się określony towar. Jednak w modelu obiektowym ta relacja jest zaimplementowana za pomocą struktury Vector wewnątrz obiektu klasy Order (patrz listing 26.4). Obiekt-pełnomocnik musi w jakiś sposób przekształcać jedną z tych form w drugą. Rozpoczniemy od stworzenia przypadku testowego, który będzie sprawdzał poprawność klasy-pełnomocnika. Ten test dodaje do bazy danych kilka przykładowych produktów. Następnie uzyskuje obiekty-pełnomocników do tych produktów i wywołuje metodę addItem obiektu OrderProxy. Na koniec zadaje pytanie obiektowi OrderProxy o łączną wartość zamówienia (patrz listing 26.14). Celem tego przypadku testowego jest pokazanie, że obiekt klasy OrderProxy zachowuje się tak samo jak obiekt klasy Order, ale uzyskuje swoje dane z bazy danych zamiast z obiektów rezydujących w pamięci. Listing 26.14. ProxyTest.java public void testOrderProxyTotal() throws Exception { DB.store(new ProductData("Wheaties", 349, "wheaties")); DB.store(new ProductData("Crest", 258, "crest")); ProductProxy wheaties = new ProductProxy("wheaties"); ProductProxy crest = new ProductProxy("crest"); OrderData od = DB.newOrder("testOrderProxy"); OrderProxy order = new OrderProxy(od.orderId); order.addItem(crest, 1); order.addItem(wheaties, 2); assertEquals(956, order.total()); }

Aby ten przypadek testowy przechodził, trzeba zaimplementować kilka nowych klas i metod. Najpierw spróbujemy zaimplementować metodę newOrder klasy DB. Wygląda na to, że ta metoda zwraca egzemplarz obiektu pod nazwą OrderData. Klasa OrderData spełnia podobną rolę co klasa ProductData. To prosta struktura danych reprezentująca wiersz tabeli Order z bazy danych. Jej implementację zamieszczono na listingu 26.15. Listing 26.15. OrderData.java public class OrderData { public String customerId; public int orderId; public OrderData() { }

}

public OrderData(int orderId, String customerId) { this.orderId = orderId; this.customerId = customerId; }

Nie należy zbytnio przejmować się wykorzystaniem publicznych składowych danych. Ta struktura nie jest obiektem w ścisłym znaczeniu. Spełnia jedynie rolę kontenera dla danych. Nie implementuje interesujących zachowań, które warto by zamknąć w klasie. Zadeklarowanie prywatnych zmiennych reprezentujących dane i zdefiniowanie dla nich metod dostępowych get i set byłoby jedynie zbędną komplikacją. Teraz należy napisać metodę newOrder klasy DB. Zwróćmy uwagę, że w kodzie, który ją wywołuje, na listingu 26.14, przekazujemy identyfikator klienta, ale nie przekazujemy wartości orderId. Każdy obiekt klasy Order powinien mieć identyfikator orderId spełniający rolę klucza. Co więcej, w schemacie relacyjnym każdy obiekt Item odwołuje się do tego identyfikatora orderId. W ten sposób jest zaprezentowane

352

ROZDZIAŁ 26. WZORCE PROJEKTOWE PEŁNOMOCNIK I SCHODY DO NIEBA

połączenie obiektu Item z odpowiednim wierszem tabeli Order. Jest oczywiste, że wartość identyfikatora orderId musi być unikatowa. W jaki sposób się ją tworzy? Spróbujmy napisać test, który pokazuje nasze zamiary (patrz listing 26.16). Listing 26.16. DBTest.java public void testOrderKeyGeneration() throws Exception { OrderData o1 = DB.newOrder("Bogdan"); OrderData o2 = DB.newOrder("Bartosz"); int firstOrderId = o1.orderId; int secondOrderId = o2.orderId; assertEquals(firstOrderId+1, secondOrderId); }

Ten test pokazuje, że oczekujemy automatycznej inkrementacji wartości orderId podczas tworzenia każdego egzemplarza klasy Order. Można to z łatwością zaimplementować poprzez odpytanie bazy danych o maksymalną wartość aktualnie używanego identyfikatora orderId i dodanie jedynki do tej wartości (patrz listing 26.17). Listing 26.17. DB.java public static OrderData newOrder(String customerId) throws Exception { int newMaxOrderId = getMaxOrderId() + 1; PreparedStatement s = con.prepareStatement( "Insert into Orders(orderId,cusid) Values(?,?);"); s.setInt(1, newMaxOrderId); s.setString(2,customerId); executeStatement(s); return new OrderData(newMaxOrderId, customerId); }

}

private static int getMaxOrderId() throws SQLException { Statement qs = con.createStatement(); ResultSet rs = qs.executeQuery( "Select max(orderId) from Orders;"); rs.next(); int maxOrderId = rs.getInt(1); rs.close(); return maxOrderId;

Możemy teraz przystąpić do napisania klasy OrderProxy. Tak jak było w przypadku klasy Product, klasę Order trzeba podzielić na interfejs i implementację. Zatem klasę Order przekształcimy w interfejs, natomiast klasa OrderImp stanie się jego implementacją (patrz listingi 26.18 i 26.19). Listing 26.18. Order.java public interface Order { public String getCustomerId(); public void addItem(Product p, int quantity); public int total(); }

Listing 26.19. OrderImp.java import java.util.Vector; public class OrderImp implements Order { private Vector itsItems = new Vector();

WZORZEC PROJEKTOWY PEŁNOMOCNIK

353

private String itsCustomerId; public String getCustomerId() { return itsCustomerId; } public OrderImp(String cusid) { itsCustomerId = cusid; } public void addItem(Product p, int qty) { Item item = new Item(p,qty); itsItems.add(item); }

}

public int total() { try { int total = 0; for (int i = 0; i < itsItems.size(); i++) { Item item = (Item) itsItems.elementAt(i); Product p = item.getProduct(); int qty = item.getQuantity(); total += p.getPrice() * qty; } return total; } catch (Exception e) { throw new Error(e.toString()); } }

W klasie OrderImp musiałem dodać kod obsługi wyjątków, ponieważ interfejs Product zgłasza wyjątki. Trochę denerwują mnie te wyjątki. Implementacje klas-pełnomocników za interfejsem nie powinny wywierać wpływu na ten interfejs, a jednak obiekty-pełnomocnicy zgłaszają wyjątki, które są propagowane przez interfejs. Aby rozwiązać ten problem, zastąpię wszystkie obiekty Exceptions obiektami Error. Dzięki temu nie będę musiał zaśmiecać interfejsów klauzulami throws, a użytkowników tych interfejsów — blokami try-catch. W jaki sposób należy zaimplementować metodę addItem wewnątrz klasy-pełnomocnika? Bez wątpienia klasa-pełnomocnik nie może delegować wywołań do metody OrderImp.addItem! Zamiast tego pełnomocnik powinien wstawić wiersz reprezentujący obiekt Item do bazy danych. Z drugiej strony, naprawdę chcę oddelegować wywołanie OrderProxy.total do wywołania OrderImp.total, ponieważ chcę, aby reguły biznesowe (tzn. strategia obliczania wartości zamówień) były zamknięte w klasie OrderImp. Sens budowania klas-pełnomocników sprowadza się do oddzielenia implementacji bazy danych od reguł biznesowych. Aby można było oddelegować funkcję total, obiekt-pełnomocnik musi stworzyć kompletny obiekt Order razem z wszystkimi obiektami Item, które ten obiekt zawiera. Zatem w metodzie OrderProxy.total trzeba odczytać wszystkie rekordy item z bazy danych, wywołać metodę addItem na pustym obiekcie OrderImp dla każdego odczytanego obiektu item, a następnie wywołać metodę total tego obiektu OrderImp. W związku z tym implementacja klasy OrderProxy powinna przypominać kod pokazany na listingu 26.20.

354

ROZDZIAŁ 26. WZORCE PROJEKTOWE PEŁNOMOCNIK I SCHODY DO NIEBA

Listing 26.20. OrderProxy.java import java.sql.SQLException; public class OrderProxy implements Order { private int orderId; public OrderProxy(int orderId) { this.orderId = orderId; } public int total() { try { OrderImp imp = new OrderImp(getCustomerId()); ItemData[] itemDataArray = DB.getItemsForOrder(orderId); for (int i = 0; i < itemDataArray.length; i++) { ItemData item = itemDataArray[i]; imp.addItem(new ProductProxy(item.sku), item.qty); } return imp.total(); } catch (Exception e) { throw new Error(e.toString()); } } public String getCustomerId() { try { OrderData od = DB.getOrderData(orderId); return od.customerId; } catch (SQLException e) { throw new Error(e.toString()); } } public void addItem(Product p, int quantity) { try { ItemData id = new ItemData(orderId, quantity, p.getSku()); DB.store(id); } catch (Exception e) { throw new Error(e.toString()); } }

}

public int getOrderId() { return orderId; }

WZORZEC PROJEKTOWY PEŁNOMOCNIK

355

Powyższa implementacja sugeruje istnienie klasy ItemData oraz kilku funkcji klasy DB służących do wykonywania operacji na wierszach ItemData. Odpowiedni kod zamieszczono na listingach od 26.21 do 26.23. Listing 26.21. ItemData.java public class ItemData { public int orderId; public int qty; public String sku = "junk"; public ItemData() { }

}

public ItemData(int orderId, int qty, String sku) { this.orderId = orderId; this.qty = qty; this.sku = sku; } public boolean equals(Object o) { ItemData id = (ItemData)o; return orderId == id.orderId && qty == id.qty && sku.equals(id.sku); }

Listing 26.22. DBTest.java public void testStoreItem() throws Exception { ItemData storedItem = new ItemData(1, 3, "sku"); DB.store(storedItem); ItemData[] retrievedItems = DB.getItemsForOrder(1); assertEquals(1, retrievedItems.length); assertEquals(storedItem, retrievedItems[0]); } public void testNoItems() throws Exception { ItemData[] id = DB.getItemsForOrder(42); assertEquals(0, id.length); }

Listing 26.23. DB.java public static void store(ItemData id) throws Exception { PreparedStatement s = buildItemInsersionStatement(id); executeStatement(s); } private static PreparedStatement buildItemInsersionStatement(ItemData id) throws SQLException { PreparedStatement s = con.prepareStatement( "Insert into Items(orderId,quantity,sku) " + "VALUES (?, ?, ?);"); s.setInt(1,id.orderId); s.setInt(2,id.qty); s.setString(3, id.sku); return s;

356

ROZDZIAŁ 26. WZORCE PROJEKTOWE PEŁNOMOCNIK I SCHODY DO NIEBA

} public static ItemData[] getItemsForOrder(int orderId) throws Exception { PreparedStatement s = buildItemsForOrderQueryStatement(orderId); ResultSet rs = s.executeQuery(); ItemData[] id = extractItemDataFromResultSet(rs); rs.close(); s.close(); return id; } private static PreparedStatement buildItemsForOrderQueryStatement(int orderId) throws SQLException { PreparedStatement s = con.prepareStatement( "SELECT * FROM Items WHERE orderid = ?;"); s.setInt(1, orderId); return s; } private static ItemData[] extractItemDataFromResultSet(ResultSet rs) throws SQLException { LinkedList l = new LinkedList(); for (int row = 0; rs.next(); row++) { ItemData id = new ItemData(); id.orderId = rs.getInt("orderid"); id.qty = rs.getInt("quantity"); id.sku = rs.getString("sku"); l.add(id); } return (ItemData[]) l.toArray(new ItemData[l.size()]); } public static OrderData getOrderData(int orderId) throws SQLException { PreparedStatement s = con.prepareStatement( "Select cusid from orders where orderid = ?;"); s.setInt(1, orderId); ResultSet rs = s.executeQuery(); OrderData od = null; if (rs.next()) od = new OrderData(orderId, rs.getString("cusid")); rs.close(); s.close(); return od; }

Podsumowanie wiadomości o wzorcu projektowym Pełnomocnik Ten przykład powinien rozwiać wszelkie fałszywe złudzenia co do elegancji i prostoty korzystania ze wzorca projektowego Pełnomocnik. Stosowanie wzorca projektowego Pełnomocnik nie jest łatwe. Prosty model delegacji sugerowany przez postać kanoniczną rzadko tak zgrabnie się materializuje. Przeciwnie — często delegacje są zastępowane trywialnymi metodami dostępowymi get i set. W przypadku metod zarządzających relacjami 1:N często rezygnuje się z delegacji, które są przenoszone do innych metod — podobnie jak delegacja metody addItem została przeniesiona do metody total. Na koniec trzeba rozwiązać problem buforowania.

WZORZEC PROJEKTOWY PEŁNOMOCNIK

357

W tym przykładzie nie stosowaliśmy żadnych mechanizmów buforowania. Wszystkie testy były wykonywane w czasie poniżej sekundy, dlatego nie było powodu, żeby zbytnio przejmować się wydajnością. Ale w rzeczywistej aplikacji może pojawić się kwestia wydajności i potrzeba inteligentnego buforowania danych. Nie sugeruję, że należy automatycznie implementować strategię buforowania ze względu na obawy o zbytnie obniżenie wydajności. Właściwie z moich doświadczeń wynika, że dodanie mechanizmów buforowania zbyt wcześnie to bardzo dobry sposób na obniżenie wydajności. Osobom, które obawiają się, że wydajność może być problemem, polecam przeprowadzenie eksperymentów, które udowodnią, że to istotnie będzie problem. Kiedy taki dowód zostanie przeprowadzony i tylko wtedy, można zastanowić się nad tym, jak przyspieszyć działanie systemu. Korzyści ze stosowania wzorca projektowego Pełnomocnik. Pomimo wszystkich kłopotów, jakie sprawia stosowanie wzorca projektowego Pełnomocnik, trzeba pamiętać, że stosowanie tego wzorca przynosi jedną ważną korzyść: rozdzielenie pojęć. W naszym przykładzie udało się nam całkowicie oddzielić reguły biznesowe od kodu obsługi bazy danych. Klasa OrderImp nie ma żadnych zależności od bazy danych. Jeśli zajdzie potrzeba zmiany schematu bazy danych lub wymiany „silnika” bazy danych, będzie można to zrobić bez wpływu na klasy Order, OrderImp lub dowolne inne klasy należące do dziedziny biznesowej. W przypadkach, gdy oddzielenie reguł biznesu od implementacji bazy danych ma kluczowe znaczenie, warto rozważyć zastosowanie wzorca projektowego Pełnomocnik. Wzorzec projektowy Pełnomocnik może być używany w celu oddzielenia reguł biznesowych od dowolnego rodzaju kwestii związanych z implementacją. Można go użyć do zabezpieczenia reguł biznesowych przed „zanieczyszczeniem” przez takie technologie jak COM, CORBA, EJB itp. Jest to dobry sposób na oddzielenie zestawu reguł biznesowych projektu od mechanizmów implementacji, które są obecnie w modzie.

Obsługa baz danych, oprogramowania middleware oraz zewnętrznych interfejsów API Posługiwanie się interfejsami API zewnętrznych dostawców jest nieodłącznym problemem inżynierów oprogramowania. Kupujemy systemy obsługi baz danych, programy warstwy pośredniej (ang. midlleware), biblioteki klas, biblioteki obsługi wątków itp. Początkowo korzystamy z tych API za pomocą bezpośrednich wywołań w kodzie aplikacji (patrz rysunek 26.5).

Rysunek 26.5. Początkowa relacja pomiędzy aplikacją a zewnętrznym interfejsem API

Z czasem jednak okazuje się, że kod aplikacji staje się coraz bardziej zanieczyszczony takimi wywołaniami API. Na przykład w aplikacji bazodanowej możemy spotkać coraz więcej ciągów zapytań SQL w kodzie, który zawiera również reguły biznesowe. To może stać się problemem w sytuacji, gdy interfejsy API zewnętrznych dostawców zmienią się. W przypadku baz danych problemy mogą wystąpić również w wyniku zmian w schemacie bazy danych. W miarę wydawania nowych wersji dystrybucyjnych API lub nowych schematów trzeba modyfikować coraz więcej kodu aplikacji, tak by dostosować się do tych zmian.

358

ROZDZIAŁ 26. WZORCE PROJEKTOWE PEŁNOMOCNIK I SCHODY DO NIEBA

Ostatecznie deweloperzy podejmują decyzję o konieczności odizolowania się od tych zmian. Z tego powodu opracowują warstwę aplikacji, która oddziela reguły aplikacji od zewnętrznych interfejsów API (rysunek 26.6). W tej warstwie — zamiast w warstwie reguł biznesowych aplikacji — jest umieszczany cały kod, który korzysta z zewnętrznego API, oraz wszystkie pojęcia związane z API.

Rysunek 26.6. Wprowadzenie warstwy pośredniej w aplikacji

Czasami całe warstwy takiego oprogramowania są kupowane od zewnętrznych dostawców. Przykładem tego rodzaju warstw są mechanizmy ODBC lub JDBC. Ich zastosowanie pozwala oddzielić kod aplikacji od stosowanego silnika bazy danych. Trzeba jednak pamiętać, że te warstwy same są zewnętrznymi interfejsami API, dlatego często trzeba oddzielić kod aplikacji także od nich. Warto zwrócić uwagę na przejściową zależność pomiędzy aplikacją a interfejsem API. W niektórych aplikacjach tego rodzaju pośrednia zależność jest wystarczającym powodem wystąpienia problemów. Na przykład technologia JDBC nie izoluje aplikacji od szczegółów schematu bazy danych. Aby uzyskać jeszcze lepszą izolację, należy odwrócić zależność pomiędzy aplikacją a warstwą pośrednią (patrz rysunek 26.7). Dzięki temu aplikacja nie musi nic „wiedzieć” o zewnętrznym API — ani bezpośrednio, ani pośrednio. W przypadku bazy danych aplikacja nie musi bezpośrednio niczego „wiedzieć” o schemacie. W przypadku warstwy middleware aplikacja nie musi niczego „wiedzieć” o typach danych wykorzystywanych przez procesor warstwy pośredniej.

Rysunek 26.7. Odwrócenie zależności pomiędzy aplikacją a warstwą pośrednią

Właśnie taki układ zależności można osiągnąć w przypadku zastosowania wzorca projektowego Pełnomocnik. Aplikacja w ogóle nie zależy od klas-pełnomocników. Zamiast tego klasy-pełnomocnicy zależą do aplikacji oraz od API. To sprawia, że cała wiedza związana z odwzorowaniem pomiędzy aplikacją a API jest skoncentrowana w klasach-pełnomocnikach.

SCHODY DO NIEBA

359

Rysunek 26.8. Odwrócenie zależności pomiędzy aplikacją a warstwą pośrednią dzięki zastosowaniu wzorca projektowego Pełnomocnik

Z powodu tej koncentracji wiedzy utrzymywanie klas-pełnomocników staje się koszmarem. Za każdym razem, gdy zmieni się API, trzeba zmienić klasy-pełnomocników. Za każdym razem, gdy zmieni się aplikacja, trzeba modyfikować klasy-pełnomocników. Obsługa klas-pełnomocników staje się bardzo uciążliwa. Warto zdawać sobie sprawę, co jest źródłem naszych problemów. Bez stosowania wzorca projektowego Pełnomocnik problemy byłyby rozsiane po całym kodzie aplikacji. W większości aplikacji nie ma potrzeby stosowania klas-pełnomocników. Rozwiązanie polegające na ich stosowaniu jest dość kosztowne. Kiedy spotykam się z rozwiązaniami bazującymi na wzorcu projektowym Pełnomocnik, często zalecam pozbycie się go i użycie w zamian czegoś prostszego. Ale istnieją przypadki, kiedy zdecydowane oddzielenie aplikacji od interfejsu API, jakie gwarantuje zastosowanie wzorca projektowego Pełnomocnik, przynosi korzyści. Takie przypadki prawie zawsze dotyczą dużych systemów, w których często dochodzi do zmian schematu bazy danych lub stosowanych interfejsów API. Inną grupę stanowią systemy pracujące ponad wieloma systemami baz danych i pakietami oprogramowania middleware.

Schody do nieba1 Schody do nieba (ang. Stairway to heaven) to kolejny wzorzec projektowy, który pozwala osiągnąć takie samo odwrócenie zależności jak w przypadku zastosowania wzorca projektowego Pełnomocnik. Wzorzec ten wykorzystuje odmianę wzorca projektowego Adapter w postaci klasowej (patrz rysunek 26.9).

Rysunek 26.9. Wzorzec projektowy Schody do nieba 1

[Martin 97].

360

ROZDZIAŁ 26. WZORCE PROJEKTOWE PEŁNOMOCNIK I SCHODY DO NIEBA

PersistentObject to klasa abstrakcyjna, która ma dostęp do bazy danych. Definiuje dwie metody abstrakcyjne: read i write. Dostarcza również zestaw metod potrzebnych do zaimplementowania metod read i write. Na przykład klasa PersistentProduct wykorzystuje te narzędzia do zaimplementowania metod read i write, które odczytują i zapisują wszystkie pola obiektu Product z bazy danych i do bazy danych. Na takiej samej zasadzie klasa PersistentAssembly implementuje metody read i write do wykonania tych samych operacji na polach klasy Assembly. Klasa ta dziedziczy zdolność odczytywania i zapisywania pól obiektu Product od klasy PersistentProduct i tworzy struktury metod read i write w taki sposób, aby wykorzystywały ten fakt. Przedstawiony wzorzec można wykorzystać tylko w tych językach, które umożliwiają wielokrotne dziedziczenie. Zwróćmy uwagę, że klasy PersistentProduct i PersistentAssembly dziedziczą od dwóch zaimplementowanych klas bazowych. Co więcej, pomiędzy klasą PersistentAssembly a klasą Product zachodzi relacja dziedziczenia w układzie rombu. W języku C++ wykorzystuje się wirtualne dziedziczenie, aby nie dopuścić do tego, żeby dwa egzemplarze klasy Product były dziedziczone przez egzemplarz klasy PersistentAssembly. Potrzeba stosowania dziedziczenia wirtualnego lub podobnych relacji w innych językach oznacza, że korzystanie z prezentowanego wzorca jest dość uciążliwe. Można to odczuć w przypadku hierarchii klasy Product, ale uciążliwość jest minimalna. Korzyść wynikająca z zastosowania tego wzorca projektowego polega na tym, że powoduje on całkowite odseparowanie operacji na bazie danych od reguł biznesowych aplikacji. W tych krótkich fragmentach kodu, gdzie trzeba wywołać metody read i write, można to zrobić za pomocą kodu następującej postaci: PersistentObject* o = dynamic_cast(product); if (o) o->write();

Inaczej mówiąc, zadajemy obiektowi aplikacji pytanie o to, czy jest zgodny z interfejsem PersistentObject, a jeśli tak jest, to wywołujemy metodę read bądź write. Dzięki temu ta część aplikacji, która nie musi „nic wiedzieć” o operacjach odczytu i zapisu, jest całkowicie niezależna od tej części hierarchii, w której występuje klasa PersistentObject.

Przykład zastosowania wzorca Schody do nieba Przykład zastosowania wzorca projektowego Schody do nieba w języku C++ zaprezentowano na listingach od 26.24 do 26.34. Tak jak zwykle najlepiej zacząć od opracowania przypadku testowego. Pakiet CppUnit2 jest nieco zbyt rozbudowany, dlatego na listingu 26.24 uwzględniłem tylko te metody, które dotyczą przypadku testowego. Pierwszy przypadek testowy sprawdza, czy można przekazać w systemie obiekt PersistentProduct w roli obiektu Product, a następnie przekształcić go na obiekt PersistentObject i zapisać na żądanie. Zakładamy, że obiekt PersistentProduct będzie zapisywany w prostym formacie XML. Drugi przypadek testowy weryfikuje to samo dla obiektu PersistentAssembly. Jedyna różnica polega na dodaniu drugiego pola do obiektu Assembly. Listing 26.24. productPersistenceTestCase.cpp {skrócony} void ProductPersistenceTestCase::testWriteProduct() { ostrstream s; Product* p = new PersistentProduct("Cheerios"); PersistentObject* po = dynamic_cast(p); assert(po); po->write(s); char* writtenString = s.str(); 2

Jeden z frameworków testów jednostkowych z rodziny XUnit. Więcej informacji można znaleźć na stronach www.junit.org oraz www.xprogramming.com.

SCHODY DO NIEBA

}

361

assert(strcmp("Cheerios", writtenString) == 0);

void ProductPersistenceTestCase::testWriteAssembly() { ostrstream s; Assembly* a = new PersistentAssembly("Wheaties", "7734"); PersistentObject* po = dynamic_cast(a); assert(po); po->write(s); char* writtenString = s.str(); assert(strcmp("Wheaties" "7734", writtenString) == 0); }

Na listingach od 26.25 do 26.28 zamieszczono definicje i implementacje klas Product i Assembly. W trosce o oszczędność miejsca implementacja tych klas została skrócona. W rzeczywistej aplikacji klasy te zawierałyby metody implementujące reguły biznesowe. Warto zauważyć, że żadna z tych klas nie zawiera kodu związanego z utrwalaniem. Nie istnieją żadne zależności pomiędzy regułami biznesowymi a mechanizmem utrwalania. Na tym właśnie polega sens stosowania tego wzorca projektowego. Listing 26.25. product.h #ifndef STAIRWAYTOHEAVENPRODUCT_H #define STAIRWAYTOHEAVENPRODUCT_H #include class Product { public: Product(const string& name); virtual ~Product(); const string& getName() const {return itsName;} private: string itsName; }; #endif

Listing 26.26. product.cpp #include "product.h" Product::Product(const string& name) : itsName(name) { } Product::~Product() { }

Listing 26.27. assembly.h #ifndef STAIRWAYTOHEAVENASSEMBLY_H #define STAIRWAYTOHEAVENASSEMBLY_H #include #include "product.h" class Assembly : public virtual Product {

362

ROZDZIAŁ 26. WZORCE PROJEKTOWE PEŁNOMOCNIK I SCHODY DO NIEBA

public: Assembly(const string& name, const string& assyCode); virtual ~Assembly(); const string& getAssyCode() const {return itsAssyCode;} private: string itsAssyCode;

}; #endif

Listing 26.28. assembly.cpp #include "assembly.h" Assembly::Assembly(const string& name, const string& assyCode) :Product(name), itsAssyCode(assyCode) { } Assembly::~Assembly() { }

Chociaż charakterystyka zależności jest dobra, na listingu 26.27 występuje artefakt, którego obecność jest związana wyłącznie z zastosowaniem wzorca projektowego Schody do nieba. Klasa Assembly dziedziczy po klasie Product z wykorzystaniem słowa kluczowego virtual. Jest to konieczne z uwagi na zabezpieczenie przed podwójnym dziedziczeniem po klasie Product przez klasę PersistentAssembly. Jeśli wrócimy do rysunku 26.9, zauważymy, że klasa Product jest wierzchołkiem dziedziczenia w układzie rombu3 obejmującego klasy Assembly, PersistentProduct i PersistentObject. Aby nie dopuścić do podwójnego dziedziczenia po klasie Product, dziedziczenie musi być wirtualne. Na listingach 26.29 i 26.30 zamieszczono definicję i implementację klasy PersistentObject. Zwróćmy uwagę, że o ile klasa PersistentObject nic „nie wie” o hierarchii klasy Product, o tyle wydaje się „posiadać wiedzę” o sposobie zapisywania obiektów w formacie XML. Klasa „rozumie”, że obiekty są zapisywane w kolejności: nagłówek, pola oraz stopka. Listing 26.29. persistentObject.h #ifndef STAIRWAYTOHEAVENPERSISTENTOBJECT_H #define STAIRWAYTOHEAVENPERSISTENTOBJECT_H #include class PersistentObject { public: virtual ~PersistentObject(); virtual void write(ostream&) const; protected: virtual void writeFields(ostream&) const = 0;

};

private: virtual void writeHeader(ostream&) const = 0; virtual void writeFooter(ostream&) const = 0;

#endif

3

Czasami żartobliwie nazywana „śmiertelnym rombem śmierci”.

SCHODY DO NIEBA

363

Listing 26.30. persistentObject.cpp #include "persistentObject.h" PersistentObject::~PersistentObject() { } void PersistentObject::write(ostream& s) const { writeHeader(s); writeFields(s); writeFooter(s); s << ends; }

W metodzie write klasy PersistentObject wykorzystano wzorzec projektowy Metoda szablonowa4 w celu zarządzania zapisem wszystkich pochodnych. Tak więc część wzorca projektowego Schody do nieba odpowiedzialna za utrwalanie wykorzystuje mechanizmy klasy bazowej PersistentObject. Na listingach 26.31 i 26.32 zamieszczono implementację klasy PersistentProduct. Klasa implementuje metody writeHeader, writeFooter oraz writeField, które mają na celu stworzenie odpowiedniego kodu XML dla obiektów klasy Product. Klasa dziedziczy pola i metody dostępowe po klasie Product i jest sterowana przez metodę write swojej klasy bazowej PersistentObject. Listing 26.31. persistentProduct.h #ifndef STAIRWAYTOHEAVENPERSISTENTPRODUCT_H #define STAIRWAYTOHEAVENPERSISTENTPRODUCT_H #include "product.h" #include "persistentObject.h" class PersistentProduct : public virtual Product , public PersistentObject { public: PersistentProduct(const string& name); virtual ~PersistentProduct(); protected: virtual void writeFields(ostream& s) const;

};

private: virtual void writeHeader(ostream& s) const; virtual void writeFooter(ostream& s) const;

#endif

Listing 26.32. persistentProduct.cpp #include "persistentProduct.h" PersistentProduct::PersistentProduct(const string& name) :Product(name) { } PersistentProduct::~PersistentProduct() { } void PersistentProduct::writeHeader(ostream& s) const 4

Więcej informacji na ten temat znajduje się w rozdziale 14., „Metoda szablonowa i Strategia: dziedziczenie a delegacja”.

364

{ }

ROZDZIAŁ 26. WZORCE PROJEKTOWE PEŁNOMOCNIK I SCHODY DO NIEBA

s << "";

void PersistentProduct::writeFooter(ostream& s) const { s << ""; } void PersistentProduct::writeFields(ostream& s) const { s << "" << getName() << ""; }

Na listingach 26.33 i 26.34 pokazano sposób, w jaki klasa PersistentAssembly unifikuje klasy Assembly oraz PersistentProduct. Podobnie jak klasa PersistentProduct, również klasa PersistentAssembly przesłania metody writeHeader, writeFooter oraz writeFields. Implementuje jednak metodę writeFields, która wywołuje metodę PersistentProduct::writeFields. A zatem zdolność zapisywania części Product obiektu Assembly dziedziczy po klasie PersistentProduct, natomiast pola Product i Assembly oraz metody dostępowe dziedziczy po klasie Assembly. Listing 26.33. persistentAssembly.h #ifndef STAIRWAYTOHEAVENPERSISTENTASSEMBLY_H #define STAIRWAYTOHEAVENPERSISTENTASSEMBLY_H #include "assembly.h" #include "persistentProduct.h" class PersistentAssembly : public Assembly, public PersistentProduct { public: PersistentAssembly(const string& name, const string& assyCode); virtual ~PersistentAssembly(); protected: virtual void writeFields(ostream& s) const; private: virtual void writeHeader(ostream& s) const; virtual void writeFooter(ostream& s) const; }; #endif

Listing 26.34. persistentAssembly.cpp #include "persistentAssembly.h" PersistentAssembly::PersistentAssembly(const string& name, const string& assyCode) : Assembly(name, assyCode) , PersistentProduct(name) , Product(name) { } PersistentAssembly::~PersistentAssembly() { } void PersistentAssembly::writeHeader(ostream& s) const { s << "";

KTÓRE MOŻNA WYKORZYSTYWAĆ Z BAZAMI DANYCH

INNE WZORCE PROJEKTOWE, 365

} void PersistentAssembly::writeFooter(ostream& s) const { s << ""; } void PersistentAssembly::writeFields(ostream& s) const { PersistentProduct::writeFields(s); s << "" << getAssyCode() << ""; }

Wniosek Z zastosowaniem wzorca projektowego Schody do nieba spotkałem się w wielu różnych scenariuszach. Zwykle przynosiło to dobre efekty. Wzorzec jest stosunkowo łatwy w konfiguracji i ma minimalny wpływ na obiekty, które zawierają reguły biznesowe. Z drugiej strony, jego implementacja wymaga zastosowania języka z obsługą wielokrotnego dziedziczenia, takiego jak C++.

Inne wzorce projektowe, które można wykorzystywać z bazami danych Obiekt rozszerzenia (ang. Extension Object). Wyobraźmy sobie obiekt rozszerzenia5, który „wie”, w jaki sposób zapisywać rozszerzone obiekty w bazie danych. Aby zapisać taki obiekt, należałoby zażądać obiektu rozszerzenia pasującego do klucza bazy danych, zrzutować go do postaci egzemplarza klasy DatabaseWriterExtension, a następnie wywołać metodę write. Product p = /* jakaś funkcja zwracająca obiekt Product */ ExtensionObject e = p.getExtension("Database"); if (e != null) { DatabaseWriterExtension dwe = (DatabaseWriterExtension) e; e.write(); }

Wizytator (ang. Visitor)6. Wyobraźmy sobie hierarchię wizytatora, która „wie”, w jaki sposób zapisywać wizytowane obiekty w bazie danych. Zapisanie obiektu w bazie danych wymagałoby stworzenia odpowiedniego typu wizytatora, a następnie wywołania metody accept na obiekcie, który ma być zapisany. Product p = /* jakaś funkcja zwracająca obiekt Product */ DatabaseWriterVisitor dwv = new DatabaseWriterVisitor(); p.accept(dwv);

Dekorator7. Istnieją dwa sposoby wykorzystania wzorca projektowego Dekorator w celu implementacji baz danych. Możemy „udekorować” obiekt biznesowy, dodając do niego metody read i write, albo możemy „udekorować” obiekt danych, który „wie”, w jaki sposób czytać i zapisywać obiekty, dodając do niego reguły biznesowe. To drugie podejście często spotyka się w przypadku korzystania z obiektowych baz danych. Reguły biznesowe są utrzymywane z dala od schematu obiektowej bazy danych i dodawane wraz z dekoratorami.

5

Patrz „Wzorzec projektowy Obiekt rozszerzenia” w rozdziale 28.

6

Patrz „Wizytator” w rozdziale 28.

7

Patrz „Wzorzec projektowy Dekorator” w rozdziale 28.

366

ROZDZIAŁ 26. WZORCE PROJEKTOWE PEŁNOMOCNIK I SCHODY DO NIEBA

Fasada. To mój ulubiony wzorzec projektowy, który wykorzystuję do obsługi baz danych. Jest prosty i efektywny. Jego wadą jest sprzężenie obiektów reprezentujących reguły biznesowe z bazą danych. Strukturę wzorca pokazano na rysunku 26.10. Klasa DatabaseFacade zapewnia metody do czytania i zapisywania wszystkich niezbędnych obiektów. Zadanie sprowadza się do sprzęgania obiektów z klasą DatabaseFacade. Obiekty „wiedzą” o istnieniu fasady, ponieważ najczęściej to one wywołują metody read i write. Fasada „wie” o obiektach, ponieważ musi korzystać z ich metod akcesorów i mutatorów w celu zaimplementowania metod read i write.

Rysunek 26.10. Fasada bazy danych

Takie sprzężenie może spowodować wiele problemów w większych aplikacjach, ale w przypadku niewielkich programów oraz w programach, które dopiero zaczynają się rozrastać, zastosowanie wzorca projektowego Fasada jest dość skuteczną techniką. Wzorzec projektowy Fasada jest również łatwy do zrefaktoryzowania, co jest istotne w przypadku, gdy użyjemy tego wzorca, a następnie zdecydujemy się zastąpić go innym, aby zmniejszyć ilość sprzężeń.

Wniosek Przewidywanie potrzeby zastosowania wzorców projektowych Pełnomocnik lub Schody do nieba na długo przed rzeczywistym istnieniem takiej potrzeby jest bardzo kuszące. Jednak prawie nigdy nie jest to dobrym pomysłem. Zwłaszcza jeśli chodzi o wzorzec projektowy Pełnomocnik. Osobiście polecam zastosowanie wzorca projektowego Fasada, a następnie zrefaktoryzowanie kodu, jeśli zajdzie taka konieczność. W ten sposób można zaoszczędzić wiele czasu i uniknąć wielu problemów.

Bibliografia 1. Gamma, et al., Design Patterns, Reading, MA: Addison-Wesley, 1995. 2. Robert C. Martin, Design Patterns for Dealing with Dual Inheritance Hierarchies, „C++ Report”, kwiecień 1997.

R OZDZIAŁ 27

Analiza przypadku: stacja pogodowa Napisane we współpracy z Jimem Newkirkiem

Poniższa historia jest fikcją, choć możesz rozpoznać wiele elementów z własnego doświadczenia.

Firma Chmura Firma Chmura od kilku lat jest liderem wśród producentów przemysłowych systemów monitoringu pogody (Weather Monitoring Systems — WMS). Jej sztandarowym produktem jest system WMS, który śledzi temperaturę, wilgotność, ciśnienie atmosferyczne, prędkość i kierunek wiatru itp. System wyświetla wartości tych parametrów w czasie rzeczywistym na wyświetlaczu. Ponadto śledzi informacje historyczne z minionych godzin i dób. Te historyczne dane mogą być wyświetlone na wyświetlaczu na żądanie użytkownika. Głównymi odbiorcami produktów firmy Chmura są instytucje z branż lotniczej, morskiej, rolnej i komunikacyjnej. Dla tych branż systemy WMS mają krytyczne znaczenie. Firma Chmura ma dobrą reputację. Słynie z budowy wysoce niezawodnych produktów, które mogą być instalowane w środowiskach z niewielką kontrolą użytkowników. Systemy produkowane przez tę firmę są jednak dosyć drogie.

368

ROZDZIAŁ 27. ANALIZA PRZYPADKU: STACJA POGODOWA

Z powodu wysokich kosztów tych systemów z produktów firmy Chmura rezygnują klienci, którzy nie potrzebują wysoce niezawodnych systemów tej firmy lub nie mogą sobie na nie pozwolić. Menedżerowie firmy Chmura uważają, że to potencjalnie duży rynek i chcieliby się na nim znaleźć. Problem. Konkurencyjna firma Microburst, Inc. niedawno zapowiedziała wprowadzenie na rynek linii produktów obejmujących proste systemy, które będą stopniowo uaktualniane do wyższej niezawodności. Menedżerowie firmy Chmura rozpoznają w tym zagrożenie. Obawiają się odejścia klientów reprezentujących mniejsze, ale rozwijające się firmy. Ci klienci, zanim rozwiną się do rozmiarów, które pozwoliłyby im na korzystanie z produktów firmy Chmura, będą już użytkownikami systemów firmy Microburst. Jeszcze bardziej niepokojące jest to, że przedstawiciele Microburst oferują możliwości łączenia ich produktów z systemami wysokiej klasy. Oznacza to, że wysokowydajne systemy mogą być łączone w sieć i tworzyć rozległy system monitorowania pogody. To grozi osłabieniem bieżącej bazy klientów firmy Chmura. Strategia. Chociaż firmie Microburst udało się zaprezentować swoje tanie urządzenia na targach, nie oferuje produkcji w ilościach przemysłowych od co najmniej sześciu miesięcy. Oznacza to, że mogły wystąpić problemy techniczne lub produkcyjne, których firmie Microburst nie udało się rozwiązać. Co więcej, aktualizacje do systemów o wysokiej niezawodności obiecywane przez Microburst w ramach tej samej linii produktów są obecnie niedostępne. Wydaje się, że firma Microburst zapowiedziała swój produkt przedwcześnie. Jeśli firma Chmura zapowie tani produkt z możliwością aktualizacji i łączenia w sieć, a następnie wprowadzi go do produkcji w ciągu sześciu miesięcy, to może się jej udać przechwycić tę grupę niezdecydowanych klientów, którzy w przeciwnym razie kupiliby produkty firmy Microburst. Poprzez wprowadzenie niepewności na rynku firma Chmura może pozbawić firmę Microburst zleceń. Co więcej, może ona podważyć wiarę klientów w zdolności firmy Microburst do rozwiązywania problemów technicznych i produkcyjnych. Osiągnięcie takich celów jest dla firmy Chmura bardzo pożądane. Dylemat. Opracowanie nowej linii tanich i rozszerzalnych produktów wymaga znacznej ilości nakładów prac inżynieryjnych. Inżynierowie pracujący nad sprzętem kategorycznie odmówili złożenia zobowiązania do sześciomiesięcznego terminu wprowadzenia systemu do produkcji. Twierdzą, że zdolność do sprzedaży systemu w ilościach przemysłowych zajmie co najmniej dwanaście miesięcy. Specjaliści w dziedzinie marketingu uważają, że za dwanaście miesięcy firma Microburst będzie dostarczać swoje produkty w ilościach przemysłowych, a przez to przechwyci znaczącą część klientów firmy Chmura. Plan. Menedżerowie firmy Chmura postanowili natychmiast zapowiedzieć swoją nową linię produktów i rozpocząć przyjmowanie zamówień, które zostaną zrealizowane przed upływem sześciu miesięcy. Produktom z nowej linii nadano nazwę Nimbus-LC 1.0. Plan polega na zamknięciu starego, drogiego sprzętu o wysokiej niezawodności w nowej obudowie z ładnym panelem dotykowym LCD. Wysokie koszty produkcji tych urządzeń oznaczają, że firma będzie faktycznie tracić pieniądze na każdym sprzedanym egzemplarzu. W tym samym czasie inżynierowie sprzętowi zaczną rozwijać prawdziwy, tani sprzęt, który będzie dostępny na rynku w ciągu 12 miesięcy. Produktom z tej linii nadano nazwę Nimbus-LC 2.0. Kiedy firmie Chmura uda się wyprodukować produkty Nimbus-LC 2.0 w ilościach przemysłowych, produkty z linii Nimbus-LC 1.0 zostaną wycofane. Kiedy właściciele produktów Nimbus-LC 1.0 zechcą uaktualnić swoje produkty do wyższego poziomu usług, ich urządzenia zostaną zastąpione urządzeniami Nimbus-LC 2.0 bez dodatkowych kosztów. Zatem firma ma zamiar tracić pieniądze na tym produkcie przez okres sześciu miesięcy tylko po to, by przechwycić potencjalnych klientów firmy Microburst.

PROJEKT OPROGRAMOWANIA SYSTEMU NIMBUS-LC

369

Oprogramowanie WMS-LC Projekt oprogramowania dla produktów linii Nimbus-LC jest złożony. Deweloperzy muszą stworzyć oprogramowanie, które może wykorzystywać zarówno istniejący sprzęt, jak również tani sprzęt 2.0. Prototypowe jednostki urządzeń serii 2.0 nie będą dostępne przez dziewięć miesięcy. Co więcej, na płycie urządzenia 2.0 prawdopodobnie zostanie zastosowany inny procesor niż w urządzeniu 1.0. Mimo różnic pomiędzy platformami sprzętowymi system musi działać identycznie. Inżynierowie sprzętowi będą pisali sterowniki sprzętowe najniższego poziomu. W związku z tym potrzebują inżynierów oprogramowania w celu zaprojektowania interfejsów API dla tych sterowników. Ten interfejs API musi być dostępny dla inżynierów sprzętowych w ciągu następnych czterech miesięcy. Oprogramowanie musi być gotowe do produkcji w ciągu 6 miesięcy i musi pracować ze sprzętem 2.0 za 12 miesięcy. Urządzenie 1.0 wymaga co najmniej 6 tygodni testowania, zatem programiści mają tylko 20 tygodni na to, aby stworzyć działające oprogramowanie. Ponieważ platforma sprzętowa dla wersji 2.0 jest nowa, potrzeba 8 – 10 tygodni testowania. To pochłania większość z trzymiesięcznego okresu od stworzenia pierwszego prototypu do ostatecznej publikacji. Zatem inżynierowie sprzętowi mają bardzo mało czasu na uruchomienie nowego sprzętu. Dokumenty planowania oprogramowania. Programiści wspólnie z pracownikami działu marketingu stworzyli szereg dokumentów opisujących projekt Nimbus-LC: 1. „Przegląd wymagań projektu Nimbus-LC”. Ten dokument opisuje wymagania operacyjne systemu Nimbus-LC w taki sposób, w jaki były one rozumiane w momencie rozpoczęcia projektu 1. 2. „Przypadki użycia systemu Nimbus-LC”. Dokument opisuje użytkowników i przypadki użycia na podstawie analizy dokumentu wymagań. 3. „Plan wersji dystrybucyjnych systemu Nimbus-LC”. Dokument opisuje plan publikacji wersji dystrybucyjnych oprogramowania. Ten plan próbuje rozwiązać główne zagrożenia wczesnego etapu cyklu życia projektu przy jednoczesnym zapewnieniu kompletności oprogramowania we wskazanych terminach.

Wybór języka Najważniejszym ograniczeniem związanym z językiem jest przenośność. Krótki czas rozwoju i jeszcze krótszy czas kontaktu programistów z platformą sprzętową 2.0 stwarza wymaganie, aby obie wersje — 1.0 i 2.0 — używały tego samego oprogramowania. Oznacza to, że kod źródłowy powinien być identyczny lub prawie identyczny. Jeśli wybrany język nie pozwoli na pokonanie ograniczenia przenośności, wydanie wersji 2.0 przed upływem 12 miesięcy będzie pod wielkim znakiem zapytania. Na szczęście nie istnieje zbyt wiele innych ograniczeń. Oprogramowanie nie jest zbytnio rozbudowane, zatem miejsce w pamięci nie stanowi problemu. Nie ma presji działania w czasie rzeczywistym. Nie istnieją sytuacje wymagające reakcji w czasie krótszym niż jedna sekunda, zatem szybkość działania także nie jest problemem. W istocie ograniczenia działania w czasie rzeczywistym są tak słabe, że umiarkowanie szybki język wyposażony w mechanizm odśmiecania wydaje się właściwy. Ze względu na ograniczenia przenośności i brak innych poważnych ograniczeń wybór języka Java dla projektu wydaje się całkiem właściwy.

Projekt oprogramowania systemu Nimbus-LC Zgodnie z planem publikacji wersji dystrybucyjnych jednym z głównych celów fazy I jest stworzenie architektury, która pozwoli większej części oprogramowania na niezależność od sprzętu, którym to oprogramowania steruje. W istocie chcemy oddzielić abstrakcyjne zachowanie stacji pogodowej od konkretnej implementacji. 1

Wszyscy wiemy, że dokumenty opisujące wymagania są najbardziej ulotne w każdym projekcie oprogramowania.

370

ROZDZIAŁ 27. ANALIZA PRZYPADKU: STACJA POGODOWA

Na przykład oprogramowanie powinno być w stanie wyświetlać aktualną temperaturę niezależnie od konfiguracji sprzętowej. To implikuje projekt, który przedstawiono na rysunku 27.1.

Rysunek 27.1. Wstępny projekt sensora temperatury

Abstrakcyjna klasa bazowa TemperatureSensor definiuje polimorficzną funkcję read(). Pochodne tej klasy bazowej zapewniają możliwość stworzenia oddzielnych implementacji metody read(). Klasy testowe. Zwróćmy uwagę na istnienie po jednej klasie potomnej dla każdej ze znanych platform sprzętowych. Jest również specjalna klasa potomna o nazwie TestTemperatureSensor. Ta klasa będzie wykorzystana do testowania oprogramowania w stacji, która nie jest podłączona do urządzeń Nimbus. Dzięki temu programiści mogą napisać testy jednostkowe i testy akceptacyjne dla swojego oprogramowania nawet wtedy, gdy nie mają dostępu do systemu Nimbus. Ponadto mamy bardzo mało czasu na zintegrowanie sprzętu Nimbus 2.0 z oprogramowaniem. Ze względu na ten krótki czas opublikowanie wersji Nimbus 2.0 jest zagrożone. Dzięki przystosowaniu oprogramowania Nimbus do działania zarówno ze sprzętem Nimbus 1.0, jak i z klasą testową oprogramowanie Nimbus będzie mogło działać na wielu platformach. To łagodzi ryzyko wystąpienia znaczących problemów przenośności w urządzeniach Nimbus 2.0. Klasy testowe dają również możliwość testowania funkcji lub warunków, które są trudne do uchwycenia w oprogramowaniu. Na przykład możemy skonfigurować klasy testowe w taki sposób, aby generowały awarie, które są trudne do zasymulowania w przypadku pracy ze sprzętem. Dokonywanie okresowych pomiarów. Najpopularniejszy tryb pracy systemu Nimbus polega na wyświetlaniu bieżących danych monitorowania pogody. Poszczególne wartości parametrów są aktualizowane w indywidualnym tempie. Temperatura jest aktualizowana raz na minutę, natomiast ciśnienie atmosferyczne jest aktualizowane co pięć minut. Oczywiście potrzebujemy jakiegoś mechanizmu czasowego, który zainicjuje te odczyty, a wyniki pomiarów przekaże użytkownikowi. Możliwą strukturę takiego systemu pokazano na rysunku 27.2.

Rysunek 27.2. Wstępna architektura systemu pomiaru i wyświetlania parametrów pogody

PROJEKT OPROGRAMOWANIA SYSTEMU NIMBUS-LC

371

Można sobie wyobrazić, że Scheduler jest klasą bazową, która ma wiele możliwych implementacji — po jednej dla każdej platformy sprzętowej i testowej. Klasa Scheduler zawiera metodę tic, która ma być wywoływana co 10 ms. Obowiązek wykonywania tego wywołania spoczywa na klasie potomnej (patrz rysunek 27.3). Klasa Scheduler zlicza wywołania tic(). Co minutę wywołuje metodę read() klasy TemperatureSensor i przekazuje odczytaną temperaturę do obiektu klasy MonitoringScreen. W fazie I nie ma potrzeby wyświetlania temperatury w interfejsie GUI, zatem klasa potomna klasy MonitoringScreen po prostu wysyła wynik do strumienia wyjściowego.

Rysunek 27.3. Wstępny diagram sekwencji klasy Scheduler

Trend ciśnienia atmosferycznego. Zgodnie z dokumentem wymagań należy obserwować trend ciśnienia atmosferycznego. Ta wartość może mieć trzy stany: wzrastające, opadające lub stabilne. W jaki sposób określa się wartość tej zmiennej? Według Federal Meteorological Handbook2 trend ciśnienia atmosferycznego oblicza się w następujący sposób: Jeśli ciśnienie rośnie lub spada w tempie co najmniej 0,06 cala na godzinę, a zmiana ciśnienia w czasie obserwacji wynosi 0,02 cala lub więcej [wartość należy odczytywać co trzy godziny], to należy zgłosić zmianę ciśnienia. Gdzie należy umieścić implementację tego algorytmu? Jeśli umieścimy ją wewnątrz klasy Barometric PressureSensor, to obiekt tej klasy będzie potrzebował informacji o godzinie każdego odczytu i będzie musiał śledzić serię odczytów z okresu ostatnich trzech godzin. Bieżący projekt na to nie pozwala. Można to naprawić, dodając bieżącą godzinę jako argument metody Read klasy BarometricPressureSensor oraz zapewniając wywoływanie tej funkcji w regularnych odstępach czasu. Jednak takie rozwiązanie powoduje sprzężenie obliczeń trendu z częstotliwością aktualizacji. Nie jest wykluczone, że zmiany w interfejsie użytkownika mechanizmu aktualizacji mogą mieć wpływ na algorytm obliczania trendu ciśnienia. Ponadto wymaganie od czujnika regularnych odczytów jako warunku poprawnego funkcjonowania jest bardzo niewygodne. Trzeba znaleźć lepsze rozwiązanie. Można by powierzyć zadanie śledzenia historii ciśnienia atmosferycznego obiektowi Scheduler, a następnie obliczać trendy w miarę potrzeby. Czy jednak w takim przypadku należałoby również zlecić klasie Scheduler zadanie śledzenia temperatury i siły wiatru? Każdy nowy rodzaj czujnika lub wymagania dotyczące historii odczytów powodowałyby konieczność wprowadzania zmian w klasie Scheduler. Tego rodzaju rozwiązanie może bardzo utrudniać pielęgnację oprogramowania. Modyfikacja projektu klasy Scheduler. Spójrzmy ponownie na rysunek 27.2. Zwróćmy uwagę, że klasa Scheduler jest powiązana ze wszystkimi czujnikami oraz z interfejsem użytkownika. W przypadku dodawania nowych czujników oraz nowych ekranów do interfejsu użytkownika trzeba je będzie uwzględniać w klasie Scheduler. Zatem klasa Scheduler nie jest zamknięta na dodawanie nowych czujników 2

Federal Meteorological Handbook nr 1, rozdział 11., punkt 11.4.6 (http://www.nws.noaa.gov).

372

ROZDZIAŁ 27. ANALIZA PRZYPADKU: STACJA POGODOWA

bądź elementów interfejsu użytkownika. To jest naruszenie zasady OCP. Chcielibyśmy zaprojektować klasę Scheduler w taki sposób, aby była niezależna dla zmian i dodatków dotyczących czujników oraz interfejsu użytkownika. Eliminowanie sprzężeń z interfejsem użytkownika. Interfejsy użytkownika są zmienne. Są uzależnione od kaprysów klientów, specjalistów od marketingu oraz upodobań prawie każdego, kto ma styczność z produktem. Wydaje się prawdopodobne, że jeśli w dowolnej części systemu powstaną nowe wymagania, to będą one miały wpływ na interfejs użytkownika. Z tego powodu w pierwszej kolejności należy zadbać o wyeliminowanie sprzężeń związanych z interfejsem. Na rysunkach 27.4 i 27.5 zamieszczono nowy projekt, w którym skorzystano z wzorca projektowego Obserwator. Wyeliminowaliśmy zależność interfejsu użytkownika od czujnika. Dlatego gdy zmieni się wartość odczytu na czujniku, interfejs użytkownika natychmiast otrzyma informację. Zauważmy, że zależność nie jest bezpośrednia. Właściwym obserwatorem jest klasa-adapter3 o nazwie TemperatureObserver. Ten obiekt otrzymuje informację od obiektu klasy TemperatureSensor w przypadku, gdy zmieni się odczyt temperatury. W odpowiedzi na ten fakt obiekt klasy TemperatureObsever wywołuje metodę DisplayTemp obiektu MonitoringScreen.

Rysunek 27.4. Zastosowanie wzorca Obserwator eliminuje sprzężenie interfejsu użytkownika z klasą Scheduler

Rysunek 27.5. Diagram sekwencji po usunięciu sprzężenia pomiędzy interfejsem użytkownika a klasą Scheduler

3

[GOF 95], str. 139.

PROJEKT OPROGRAMOWANIA SYSTEMU NIMBUS-LC

373

Dzięki zastosowaniu tego projektu udało się wyeliminować sprzężenie pomiędzy interfejsem użytkownika a klasą Scheduler. Teraz klasa Scheduler nic „nie wie” o interfejsie użytkownika. Jej zadanie sprowadza się do informowania czujników o tym, kiedy należy przeprowadzić odczyt. Interfejs użytkownika jest powiązany z czujnikami i oczekuje od nich zgłaszania wszelkich zmian. Jednak interfejs użytkownika „nie wie” nic o konkretnych czujnikach. Komunikuje się ze zbiorem obiektów, które implementują interfejs Observable. Dzięki temu możemy dodawać czujniki bez wprowadzania istotnych zmian w interfejsie użytkownika. Udało nam się również rozwiązać problem obliczania trendu ciśnienia atmosferycznego. Ten odczyt może być teraz zrealizowany przez osobny obiekt BarometricPressureTrendSensor, który obserwuje obiekt BarometricPressureSensor (patrz rysunek 27.6).

Rysunek 27.6. Obserwatory ciśnienia atmosferycznego

Kolejna modyfikacja projektu klasy Scheduler. Główne zadanie klasy Scheduler sprowadza się do poinformowania czujników o tym, kiedy powinny przeprowadzić kolejne odczyty. Jeśli jednak w wyniku przyszłych zmian powstanie konieczność dodania lub usunięcia czujnika, będzie trzeba również wprowadzić modyfikacje w klasie Scheduler. Klasę Scheduler będzie trzeba modyfikować nawet w przypadku wprowadzenia prostej zmiany, na przykład częstotliwości odczytu czujnika. To bardzo niefortunne naruszenie zasady OCP. Wydaje się, że wiedza o tempie odczytów realizowanych przez czujnik należy do samego czujnika, a nie do żadnej innej części systemu. Aby usunąć sprzężenie pomiędzy klasą Scheduler a sensorami, można skorzystać z paradygmatu Listener4 z biblioteki klas Javy. Jest to mechanizm podobny do wzorca projektowego Obserwator. Podobieństwo polega na tym, że w tym przypadku również rejestrujemy chęć otrzymania powiadomienia o określonej informacji, ale chcemy uzyskać powiadomienie o tym, kiedy wystąpi określone zdarzenie (interesuje nas czas jego wystąpienia) (patrz rysunek 27.7). Czujniki tworzą anonimowe klasy-adaptery, które implementują interfejs AlarmListener. Następnie czujniki rejestrują te adaptery w obiekcie klasy AlarmClock (klasa, której używaliśmy do wywoływania klasy Scheduler). W ramach tej rejestracji czujniki informują klasę AlarmClock o tym, jak często mają być budzone (np. co sekundę lub co pięćdziesiąt milisekund). Po upływie tego czasu obiekt AlarmClock wysyła komunikat „pobudki” do adaptera, a ten wysyła polecenie odczytu wartości do czujnika.

4

[JAVA98], str. 360.

374

ROZDZIAŁ 27. ANALIZA PRZYPADKU: STACJA POGODOWA

Rysunek 27.7. Klasa AlarmClock bez sprzężeń

Ta zmiana całkowicie zmieniła naturę klasy Scheduler. Zgodnie z rysunkiem 27.2 klasa ta stanowiła centralną część naszego systemu i „wiedziała” o większości pozostałych komponentów. Natomiast teraz klasa jest umieszczona „z boku”. „Nie wie” nic o pozostałych komponentach. Klasa jest zgodna z zasadą SRP, ponieważ realizuje jedno zadanie — planowanie — które nie ma nic wspólnego z monitorowaniem pogody. Taką klasę można bez trudu wykorzystać w wielu różnych rodzajach aplikacji. Wprowadzona zmiana jest tak istotna, że zmieniliśmy nazwę klasy na AlarmClock. Struktura czujników. Po usunięciu sprzężeń pomiędzy klasami reprezentującymi sensory a resztą systemu warto przyjrzeć się wewnętrznej strukturze tych klas. Sensory spełniają teraz trzy osobne funkcje. Po pierwsze, muszą stworzyć i zarejestrować anonimową klasę potomną klasy AlarmListener. Po drugie, muszą wykryć, czy wartość odczytu zmieniła się, a jeśli tak, to wywołać metodę notifyObservers klasy Observable. Po trzecie, muszą komunikować się ze sprzętem Nimbus, aby odczytać odpowiednie wartości. Na rysunku 27.1 pokazano możliwy sposób oddzielenia od siebie tych funkcji. Na rysunku 27.8 zaprezentowano sposób integracji tego projektu z innymi zmianami, które wprowadziliśmy. Za pierwsze dwie funkcje, które mają uniwersalny charakter, odpowiada klasa bazowa TemperatureSensor. Klasa potomna TemperatureSensor może skomunikować się ze sprzętem i wykonać właściwy odczyt.

Rysunek 27.8. Struktura czujnika

Na rysunku 27.8 w celu osiągnięcia separacji pomiędzy ogólnymi a szczegółowymi aspektami klasy TemperatureSensor zastosowano wzorzec projektowy Metoda szablonowa. Wykorzystanie tego wzorca można zaobserwować w prywatnych metodach check i read klasy TemperatureSensor. Kiedy obiekt klasy AlarmClock wywoła metodę wakeup anonimowej klasy, wywołanie to zostanie przekierowane do metody check klasy TemperatureSensor. Następnie metoda check wywoła abstrakcyjną metodę read klasy TemperatureSensor. Ta metoda będzie zaimplementowana w klasie potomnej, co umożliwi właściwą interakcję ze sprzętem i zrealizowanie odczytu z czujnika. Następnie metoda check sprawdzi, czy wartość

nowego odczytu różni się od poprzedniego. Jeśli zostanie wykryta różnica, będzie wysłane powiadomienie do oczekujących obserwatorów.

PROJEKT OPROGRAMOWANIA SYSTEMU NIMBUS-LC

375

Zaprezentowany projekt właściwie zapewnia rozdzielenie pojęć, którego potrzebujemy. W celu obsługi każdego nowego sprzętu lub platformy testowej można bez trudu stworzyć pochodną klasy TemperatureSensor. Co więcej, ta pochodna musi tylko przesłaniać jedną, bardzo prostą metodę: read(). Pozostała część funkcjonalności czujnika pozostaje w klasie bazowej. Gdzie jest API? Jednym z celów II wydania wersji dystrybucyjnej jest stworzenie nowego API dla platformy sprzętowej Nimbus 2.0. Ten interfejs API powinien być napisany w Javie, zapewniać możliwości rozszerzania oraz gwarantować prosty i bezpośredni dostęp do sprzętu Nimbus 2.0. Co więcej, musi on równocześnie obsługiwać sprzęt Nimbus 1.0. Bez tego interfejsu API wszystkie proste narzędzia do debugowania i kalibracji, które napisaliśmy w ramach tego projektu, musiałyby być zmienione wraz z wprowadzeniem nowej platformy sprzętowej. Gdzie jest ten interfejs API wewnątrz projektu w bieżącej postaci? Okazuje się, że nic, co do tej pory stworzyliśmy, nie może pełnić roli prostego interfejsu API. Szukamy konstrukcji, która miałaby postać zbliżoną do następującej: public interface TemperatureSensor { public double read(); }

Chcemy uzyskać możliwość pisania narzędzi, które będą miały bezpośredni dostęp do tego API, bez konieczności obsługi rejestrowania obserwatorów. Nie chcemy również, aby czujniki na tym poziomie były odpytywane automatycznie lub by komunikowały się z obiektem klasy AlarmClock. Potrzebujemy prostej i niezależnej konstrukcji, która pełniłaby rolę bezpośredniego interfejsu ze sprzętem. Może się wydawać, że w tym momencie wszystkie nasze wcześniejsze argumenty przedstawiliśmy odwrotnie. Ostatecznie na rysunku 27.1 zaprezentowaliśmy projekt, o który teraz nam chodzi. Jednak zmiany, które wprowadziliśmy później, miały sensowne uzasadnienie. Potrzebujemy rozwiązania hybrydowego, które łączy ze sobą oba podejścia. W projekcie przedstawionym na rysunku 27.9 zastosowano wzorzec projektowy Most (ang. Bridge) w celu wyodrębnienia rzeczywistego interfejsu API z klasy TemperatureSensor. Celem tego wzorca jest oddzielenie implementacji od abstrakcji, tak aby obie mogły się zmieniać niezależnie od siebie. W naszym przypadku klasa TemperatureSensor jest abstrakcją, natomiast jej implementacja jest umieszczona w klasie TemperatureSensorImp. Zwróćmy uwagę na to, że słowo „implementacja” zostało użyte do opisania abstrakcyjnego interfejsu oraz że ta „implementacja” jest właściwie zaimplementowana przez klasę Nimbus1.0TemperatureSensor.

Rysunek 27.9. Diagram czujnika temperatury z uwzględnieniem interfejsu API

376

ROZDZIAŁ 27. ANALIZA PRZYPADKU: STACJA POGODOWA

Problemy dotyczące tworzenia. Spójrzmy ponownie na rysunek 27.9. Aby można było zrealizować ten projekt, trzeba stworzyć obiekt TemperatureSensor i powiązać go z obiektem Nimbus1.0TemperatureSensor. Jaka klasa jest za to odpowiedzialna? Nie ulega wątpliwości, że niezależnie od tego, jaka część oprogramowania będzie odpowiedzialna za tę operację, nie będzie ona niezależna od platformy, ponieważ musi mieć dostęp do zależnej od platformy klasy Nimbus1.0TemperatureSensor. Do realizacji wszystkich tych elementów moglibyśmy użyć programu głównego. Mógłby on mieć postać podobną do pokazanej na listingu 27.1. Listing 27.1. WeatherStation public class WeatherStation { public static void main(String[] args) { AlarmClock ac = new AlarmClock( new Nimbus1_0AlarmClock; TemperatureSensor ts = new TemperatureSensor(ac, new Nimbus1_0TemperatureSensor); BarometricPressureSensor bps = new BarometricPressureSensor(ac, new Nimbus1_0BarometricPressureSensor);

}

}

BarometricPressureTrend bpt = new BarometricPressureTrend(bps)

Zaprezentowane rozwiązanie działa, ale wymaga bardzo dużo nakładów „pracy biurowej”. Zamiast tego moglibyśmy zastosować fabryki, które pozwolą wyeliminować większość pracy związanej z tworzeniem obiektów. Odpowiednią strukturę pokazano na rysunku 27.10.

Rysunek 27.10. Interfejs StationToolkit

Klasie-fabryce nadaliśmy nazwę StationToolkit. Klasa implementuje interfejs, który zawiera metody tworzące egzemplarze klas API. Każdej platformie odpowiada odrębna pochodna klasy StationToolkit. Ta pochodna tworzy odpowiednie pochodne klas API.

PROJEKT OPROGRAMOWANIA SYSTEMU NIMBUS-LC

377

Możemy teraz przepisać funkcję main. W zmodyfikowanej postaci przedstawiono ją na listingu 27.2. Zauważmy, że w celu zmiany programu głównego do pracy na innej platformie należało jedynie zmienić dwie linijki kodu odpowiedzialne za tworzenie obiektów Nimbus1.0AlarmClock oraz Nimbus1.0Toolkit. To znaczące usprawnienie w porównaniu z kodem z listingu 27.1, gdzie trzeba było wprowadzać zmiany dla każdego stworzonego obiektu czujnika. Listing 27.2. WeatherStation public class WeatherStation { public static void main(String[] args) { AlarmClock ac = new AlarmClock( new Nimbus1_0AlarmClock; StationToolkit st = new Nimbus1_0Toolkit(); TemperatureSensor ts = new TemperatureSensor(ac,st); BarometricPressureSensor bps = new BarometricPressureSensor(ac,st);

}

}

BarometricPressureTrend bpt = new BarometricPressureTrend(bps)

Zwróćmy uwagę, że do każdego obiektu czujnika przekazywany jest obiekt klasy StationToolkit. Dzięki temu można stworzyć osobne implementacje czujników. Konstruktor klasy TemperatureSensor zamieszczono na listingu 27.3. Listing 27.3. TemperatureSensor public class TemperatureSensor extends Observable { public TemperatureSensor(AlarmClock ac, StationToolkit st) { itsImp = st.makeTemperature(); } private TemperatureSensorImp itsImp; }

Wykorzystanie obiektu Station Toolkit do stworzenia obiektu AlarmClock. Powyższy kod można usprawnić jeszcze bardziej poprzez powierzenie klasie StationToolkit zadania tworzenia odpowiednich pochodnych klasy AlarmClock. Tak jak wcześniej zastosujemy wzorzec projektowy Most w celu odseparowania abstrakcji AlarmClock, która ma znaczenie dla aplikacji monitorowania pogody, od implementacji obsługującej określoną platformę sprzętową. Strukturę klasy AlarmClock pokazano na rysunku 27.11. Teraz klasa AlarmClock otrzymuje komunikaty tic() za pośrednictwem interfejsu ClockListener. Te komunikaty są przesyłane z właściwej pochodnej klasy AlarmClockImp w interfejsie API. Na rysunku 27.12 pokazano sposób tworzenia obiektu klasy AlarmClock. Odpowiednia pochodna klasy StationToolkit jest przekazywana do konstruktora klasy AlarmClock. Obiekt klasy AlarmClock „powierza jej zadanie” stworzenia właściwej pochodnej klasy AlarmClockImp. Stworzony obiekt jest przekazywany z powrotem do obiektu AlarmClock, który się w nim rejestruje. Dzięki temu będzie otrzymywał od obiektu AlarmClock komunikaty tic().

378

ROZDZIAŁ 27. ANALIZA PRZYPADKU: STACJA POGODOWA

Rysunek 27.11. Diagram klas StationToolkit i AlarmClock

Rysunek 27.12. Tworzenie obiektu klasy AlarmClock

Tak jak poprzednio zaprezentowana struktura ma wpływ na program główny przedstawiony na listingu 27.4. Zwróćmy uwagę, że teraz tylko jedna linijka kodu jest zależna od platformy. Aby cały system korzystał z innej platformy, wystarczy zmienić tę linijkę. Listing 27.4. WeatherStation public class WeatherStation { public static void main(String[] args) { StationToolkit st = new Nimbus1_0Toolkit(); AlarmClock ac = new AlarmClock(st); TemperatureSensor ts = new TemperatureSensor(ac,st); BarometricPressureSensor bps = new BarometricPressureSensor(ac,st);

}

}

BarometricPressureTrend bpt = new BarometricPressureTrend(bps)

PROJEKT OPROGRAMOWANIA SYSTEMU NIMBUS-LC

379

Zaprezentowane rozwiązanie jest dość dobre, choć w Javie można opracować lepsze. Język Java umożliwia tworzenie obiektów na podstawie nazwy. Aby program z listingu 27.5 mógł działać z nową platformą, nie trzeba wprowadzać w nim żadnych zmian. Nazwa pochodnej klasy StationToolkit jest po prostu przekazywana w postaci argumentu wiersza polecenia. Jeśli zostanie przekazana prawidłowa nazwa, zostanie stworzony właściwy egzemplarz klasy StationToolkit, a pozostała część systemu będzie się zachowywała prawidłowo. Listing 27.5. WeatherStation public class WeatherStation { public static void main(String[] args) { try { Class tkClass = Class.forName(args[0]); StationToolkit st = (StationToolkit)tkClass.newInstance(); AlarmClock ac = new AlarmClock(st); TemperatureSensor ts = new TemperatureSensor(ac,st); BarometricPressureSensor bps = new BarometricPressureSensor(ac,st); BarometricPressureTrend bpt = new BarometricPressureTrend(bps)

}

}

} catch (Exception e) { }

Podział klas na pakiety. Istnieje kilka części tego oprogramowania, których wersje dystrybucyjne chcielibyśmy publikować oddzielnie. Interfejs API oraz każda z jego implementacji mogą być wykorzystywane bez pozostałej części aplikacji. Można je stosować w narzędziach testerów oraz pracowników kontroli jakości. Klasy interfejsu użytkownika oraz czujników powinny być oddzielne, tak by mogły się zmieniać niezależnie od siebie. Trzeba wziąć pod uwagę, że nowe produkty mogą mieć lepsze interfejsy użytkownika stworzone na bazie tej samej architektury systemu. Pierwszym przykładem tego rodzaju ewolucji będzie wydanie II. Na rysunku 27.13 pokazano strukturę pakietów dla fazy I. Ta struktura pakietów kłóci się z klasami, które opracowaliśmy dotychczas. Jest jeden pakiet dla każdej platformy, a klasy należące do tych pakietów dziedziczą po klasach wchodzących w skład pakietu tworzącego API. Jedynym klientem pakietu API jest pakiet WeatherMonitoringSystem, który zawiera wszystkie pozostałe klasy. Pomimo że wydanie I ma bardzo okrojony interfejs użytkownika, został on niefortunnie połączony z klasami WeatherMonitoringSystem. Byłoby lepiej, gdyby te klasy zostały umieszczone w oddzielnym pakiecie. Istnieje jednak pewien problem. W zaprezentowanej postaci obiekt WeatherStation tworzy obiekt MonitoringScreen, ale obiekt MonitoringScreen musi „mieć świadomość” istnienia wszystkich czujników. Ta wiedza jest potrzebna do dodania obserwatorów za pośrednictwem interfejsu Observable. Gdybyśmy więc umieścili klasę MonitoringScreen w odrębnym pakiecie, stworzyłaby się cykliczna zależność pomiędzy tym pakietem a pakietem WeatherMonitoringSystem. Takie rozwiązanie narusza zasadę acyklicznych zależności (ADP) i powoduje, że te dwa pakiety nie mogłyby być publikowane niezależnie od siebie.

380

ROZDZIAŁ 27. ANALIZA PRZYPADKU: STACJA POGODOWA

Rysunek 27.13. Struktura pakietów fazy I

Problem ten można rozwiązać poprzez wydzielenie programu głównego z klasy WeatherStation. Klasa WeatherStation w dalszym ciągu będzie tworzyć obiekt klasy StationToolkit oraz obiekty wszystkich czujników, ale nie będzie tworzyć obiektu MonitoringScreen. Za tworzenie obiektów MonitoringScreen i WeatherStation będzie odpowiedzialny program główny. Następnie program główny przekaże obiekt klasy WeatherStation do obiektu MonitoringScreen, dzięki czemu obiekt MonitoringScreen będzie mógł dodać obserwatory do czujników. W jaki sposób obiekt MonitoringScreen pobiera czujniki z obiektu WeatherStation? Trzeba dodać do klasy WeatherStation metody, które to umożliwią. Odpowiednie rozwiązanie zaprezentowano na listingu 27.6. Listing 27.6. WeatherStation public class WeatherStation { public WeatherStation(String tkName) { }

// stworzenie obiektów StationToolkit i czujników tak jak poprzednio.

public void addTempObserver(Observer o) { itsTS.addObserver(o); } public void addBPObserver(Observer o) { itsBPS.addObserver(o); } public void addBPTrendObserver(Observer o) { itsBPT.addObserver(o); }

// zmienne prywatne...

}

private TemperatuerSensor itsTS; private BarometricPressureSensor itsBPS; private BarometricPressureTrend itsBPT;

PROJEKT OPROGRAMOWANIA SYSTEMU NIMBUS-LC

381

Możemy teraz zmodyfikować diagram pakietów do postaci pokazanej na rysunku 27.14. Udało się pominąć większość pakietów, które nie mają związku z klasą MonitoringScreen. Diagram wygląda zadowalająco. Nie ulega wątpliwości, że pakiet UI może się zmieniać bez wpływu na pakiet WeatherMonitoringSystem. Jednak zależność pakietu UI od pakietu WeatherMonitoringSystem spowoduje problemy za każdym razem, gdy zmieni się pakiet WeatherMonitoringSystem.

Rysunek 27.14. Diagram pakietów z przerwanym cyklem

Zarówno UI, jak i WeatherMonitoringSystem to pakiety konkretne. Kiedy jeden konkretny pakiet zależy od innego konkretnego pakietu, to projekt narusza zasadę odwracania zależności (DIP). W tym przypadku byłoby lepiej, gdyby pakiet UI zależał od jakiejś abstrakcji zamiast od pakietu WeatherMonitoringSystem. Aby to poprawić, można stworzyć interfejs, który klasa MonitoringScreen mogłaby wykorzystać, natomiast klasa WeatherStation mogłaby po nim dziedziczyć (patrz rysunek 27.15).

Rysunek 27.15. Abstrakcyjny interfejs WeatherStation

Gdybyśmy teraz umieścili interfejs WeatherStationComponent w oddzielnym pakiecie, uzyskalibyśmy separację, o którą nam chodzi (patrz rysunek 27.16). Zwróćmy uwagę, że teraz całkowicie wyeliminowaliśmy sprzężenie pomiędzy pakietami UI oraz WeatherMonitoringSystem. Oba pakiety mogą się zmieniać całkowicie niezależnie od siebie. Taka sytuacja jest bardzo pozytywna.

382

ROZDZIAŁ 27. ANALIZA PRZYPADKU: STACJA POGODOWA

Rysunek 27.16. Diagram pakietów komponentów wchodzących w skład aplikacji stacji pogodowej

Historia 24-godzinna i utrwalanie W punktach czwartym i piątym założeń do publikacji wydania I jest mowa o konieczności utrzymywania trwałej, 24-godzinnej historii. Wiemy, że zarówno platforma sprzętowa Nimbus 1.0, jak i Nimbus 2.0 są wyposażone w jakiś rodzaj nieulotnej pamięci (NVRAM). Z kolei na platformie testowej nieulotna pamięć będzie symulowana za pomocą dysku. Musimy stworzyć mechanizm utrwalania, który byłby niezależny od poszczególnych platform, a jednocześnie zapewniałby niezbędną funkcjonalność. Trzeba również powiązać ten mechanizm ze strukturami odpowiedzialnymi za utrzymywanie 24-godzinnych historycznych danych. Nie ulega wątpliwości, że niskopoziomowy mechanizm utrwalania należy zdefiniować w postaci interfejsu wewnątrz pakietu z interfejsem API. Jaką postać powinien przyjąć ten interfejs? API w języku C platformy Nimbus I udostępnia wywołania pozwalające na odczyt i zapis bloków bajtów spod określonych adresów wewnątrz nieulotnej pamięci. Chociaż przedstawione rozwiązanie jest efektywne, jest również w pewnym sensie prymitywne. Czy istnieje lepszy sposób? API utrwalania. Środowisko Javy zawiera mechanizmy pozwalające na natychmiastową konwersję dowolnego obiektu na tablicę bajtów. Taki proces nazywa się serializacją. Tablice bajtów uzyskane w wyniku takiego procesu można przywrócić do postaci obiektów w procesie zwanym deserializacją. Byłoby wygodne, gdyby niskopoziomowe API pozwalało na określenie obiektu wraz z nazwą tego obiektu. Propozycję takiego interfejsu przedstawiono na listingu 27.7.Listing 27.7. PersistentImp package api; import java.io.Serializable; import java.util.AbstractList; public interface PersistentImp { void store(String name, Serializable obj); Object retrieve(String name); AbstractList directory(String regExp); };

Interfejs PersistentImp pozwala na utrwalanie całych obiektów (metoda store) oraz ich przywracanie (metoda retrieve) na podstawie nazwy. Jedynym ograniczeniem jest konieczność implementowania przez te obiekty interfejsu Serializable. Jest to bardzo niewielkie ograniczenie.

PROJEKT OPROGRAMOWANIA SYSTEMU NIMBUS-LC

383

Historia 24-godzinna. Kiedy już podjęliśmy decyzję dotyczącą niskopoziomowych mechanizmów przechowywania trwałych danych, przyjrzyjmy się, jakiego rodzaju dane będą utrwalane. Ekspert twierdzi, że musimy przechowywać rejestr wysokich i niskich wartości odczytów w poprzednim 24-godzinnym okresie. Wykres dla tych danych zaprezentowano na rysunku 27.23. Nie wydaje się, aby ten wykres miał zbyt wiele sensu. Odczyty niskich i wysokich wartości są redundantne. Co gorsza, pochodzą z poprzednich 24 godzin zegarowych, a nie z poprzedniego dnia kalendarzowego. Zazwyczaj gdy mówimy o minimalnej i maksymalnej wartości odczytu z ostatnich 24 godzin, mamy na myśli odczyt z poprzedniego dnia kalendarzowego. Czy to jest wada specyfikacji, czy też wada naszej interpretacji? Nie ma żadnego pożytku z zaimplementowania czegoś zgodnie ze specyfikacją, jeżeli specyfikacja nie określa tego, czego naprawdę chce klient. Krótka konsultacja z zainteresowanymi stronami pokazała, że nasza intuicja była prawidłowa. Rzeczywiście chcemy zachować kroczącą historię z ostatnich 24 godzin. Jednak historyczne wartości minimalne i maksymalne powinny dotyczyć poprzedniego dnia kalendarzowego. Maksymalny i minimalny odczyt z ostatniej doby. Dobowe wartości maksymalne i minimalne będą bazowały na odczytach czujników w czasie rzeczywistym. Na przykład za każdym razem, gdy zmieni się wartość temperatury, zostaną odpowiednio zaktualizowane maksymalna i minimalna wartość temperatury z 24 godzin. Widać wyraźnie, że jest to relacja typowa dla wzorca projektowego Obserwator. Statyczną strukturę rozwiązania pokazano na rysunku 27.17, natomiast na rysunku 27.18 pokazano odpowiednią strukturę dynamiczną.

Rysunek 27.17. Struktura klasy TemperatureHiLo

Rysunek 27.18. Scenariusze wyznaczania wartości minimalnych i maksymalnych

384

ROZDZIAŁ 27. ANALIZA PRZYPADKU: STACJA POGODOWA

Wzorzec projektowy Obserwator zaprezentowaliśmy z asocjacją oznaczoną stereotypem <>. Stworzyliśmy klasę TemperatureHiLo, która jest „budzona” codziennie o północy przez obiekt klasy AlarmClock. Zwróćmy uwagę na dodanie do klasy AlarmClock metody wakeEveryDay. Po utworzeniu obiektu TemperatureHiLo obiekt ten rejestruje się zarówno w obiekcie AlarmClock, jak i TemperatureSensor. Za każdym razem, gdy zmieni się temperatura, obiekt TemperatureHiLo otrzymuje powiadomienie za pośrednictwem wzorca projektowego Obserwator. Następnie obiekt TemperatureHiLo informuje o tym obiekt implementujący interfejs HiLoData za pomocą metody currentReading. Interfejs HiLoData musi być zaimplementowany w jakiejś klasie, która „wie”, w jaki sposób zapisywać maksymalne i minimalne wartości dla bieżącej doby kalendarzowej. Klasę TemperatureHiLo odseparowaliśmy od klasy HiLoData z dwóch powodów. Po pierwsze: chcieliśmy oddzielić informacje o obiektach TemperatureSensor i AlarmClock od algorytmów wyznaczających dobowe wartości maksymalne i minimalne. Po drugie i ważniejsze: algorytm wyznaczania dobowych wartości maksymalnych i minimalnych można wykorzystać ponownie dla ciśnienia atmosferycznego, szybkości wiatru, punktu rosy itp. W związku z tym, chociaż potrzebujemy obiektów BarometricPressureHiLo, DewPointHiLo, WindSpeedHiLo itp. do obserwacji odpowiednich czujników, każdy z nich będzie mógł skorzystać z klasy HiLoData w celu obliczenia i zapisania danych. O północy obiekt AlarmClock wysyła komunikat „pobudki” do obiektu TemperatureHiLo. Obiekt TemperatureHiLo odpowiada, pobierając bieżącą temperaturę z obiektu TemperatureSensor i przekazując ją do interfejsu HiLoData. Obiekt implementujący interfejs HiLoData będzie musiał zapisać wartości z poprzedniego dnia kalendarzowego, wykorzystując interfejs PersistentImp. Ponadto będzie musiał również stworzyć nowy dzień kalendarzowy z wartością początkową. Obiekt PersistentImp uzyskuje dostęp do obiektów w pamięci trwałej za pomocą ciągów znaków. Te ciągi znaków spełniają rolę klucza dostępu. Obiekty HiLoData będą zapisywane i odczytywane za pomocą ciągów znaków o następującym formacie: +HiLo+

, na przykład "temperatureHiLo04161998".

Implementacja algorytmów HiLo W jaki sposób zaimplementujemy klasę HiLoData? Wydaje się to dość proste. Na listingu 27.8 pokazano, jak może wyglądać implementacja tej klasy w Javie. Listing 27.8. HiLoDataImp public class HiLoDataImp implements HiLoData,java.io.Serializable { public HiLoDataImp(StationToolkit st, String type, Date theDate, double init, long initTime) { itsPI = st.getPersistentImp(); itsType = type; itsStorageKey = calculateStorageKey(theDate); try { HiLoData t =(HiLoData)itsPI.retrieve(itsStorageKey); itsHighTime = t.getHighTime(); itsLowTime = t.getLowTime(); itsHighValue = t.getHighValue(); itsLowValue = t.getLowValue(); currentReading(init, initTime); } catch (RetrieveException re) { itsHighValue = itsLowValue = init; itsHighTime = itsLowTime = initTime; } } public long getHighTime() {return itsHighTime;}

PROJEKT OPROGRAMOWANIA SYSTEMU NIMBUS-LC

385

public double getHighValue() {return itsHighValue;} public long getLowTime() {return itsLowTime;} public double getLowValue() {return itsLowValue;}

// Sprawdzenie, czy nowy odczyt zmienia wartości // maksymalną i minimalną. Zwrócenie true, jeśli odczyt zmienił się.

public void currentReading(double current, long time) { if (current > itsHighValue) { itsHighValue = current; itsHighTime = time; store(); } else if (current < itsLowValue) { itsLowValue = current; itsLowTime = time; store(); } } public void newDay(double initial, long time) { store();

// Wyzerowanie dnia i wygenerowanie nowego klucza:

itsLowValue = itsHighValue = intial; itsLowTime = itsHighTime = time;

// obliczenie nowego klucza utrwalania na podstawie // bieżącej daty i zapisanie nowego rekordu.

}

itsStorageKey = calculateStorageKey(new Date()); store()

private store() { try { itsPI.store(itsStorageKey, this); } catch (StoreException) { }

}

// zarejestrowanie błędu w jakiś sposób.

private String calculateStorageKey(Date d) { SimpleDateFormat df = new SimpleDateFormat("MMddyyyy"); return(itsType + "HiLo" + df.format(d)); } private double itsLowValue; private long itsLowTime; private double itsHightValue; private long itsHighTime; private String itsType;

// nie chcemy zapisywać poniższych wartości

}

transient private String itsStorageKey; transient private api.PersistentImp itsPI;

Być może ta implementacja nie była aż tak prosta. Spróbujmy przeanalizować ten kod i zobaczmy, jakie działania wykonuje. Na początku klasy znajdują się definicje zmiennych prywatnych. Pierwsze cztery zmienne mają oczywiste przeznaczenie. Rejestrują wartości maksymalne i minimalne w czasie, gdy te wartości zostały zmierzone. Zmienna itsType służy do zapamiętania typu odczytu zapisanego w obiekcie HiLoData. W tej zmiennej będzie zapisana wartość "Temp" dla temperatury, "BP" dla ciśnienia atmosferycznego, "DP" dla

386

ROZDZIAŁ 27. ANALIZA PRZYPADKU: STACJA POGODOWA

punktu rosy (ang. dew point). Ostatnie dwie zmienne zadeklarowano ze słowem kluczowym transient. Oznacza to, że nie będą one przechowywane w pamięci trwałej. Zmienne te służą do zapamiętania bieżącego klucza pamięci trwałej oraz referencji do obiektu PersistentImp. Konstruktor pobiera pięć argumentów. Argument StationToolkit jest potrzebny w celu uzyskania dostępu do obiektu PersistentImp. Argumenty type i Date będą użyte do stworzenia klucza pamięci trwałej, który posłuży do zapamiętania i odczytania obiektu. Na koniec argumenty init i initTime będą użyte do zainicjowania obiektu na wypadek, gdyby obiekt PersistentImp nie mógł znaleźć klucza pamięci trwałej. Konstruktor próbuje pobrać dane z obiektu PersistentImp. Jeśli dane są dostępne, kopiuje te informacje, które są przeznaczone do utrwalenia, do własnych zmiennych składowych. Następnie wywołuje metodę currentReading z argumentami — wartością początkową i godziną — aby te wartości zostały zarejestrowane. Jeśli metoda currentReading rozpozna, że nastąpiła zmiana w wartości maksymalnej lub minimalnej, zwraca true oraz wywołuje funkcję Store, aby zapewnić zaktualizowanie pamięci trwałej. Metoda currentReading jest najważniejszym elementem tej klasy. Jej zadanie polega na porównaniu starych wartości maksymalnych i minimalnych z nowymi odczytanymi wartościami. Jeśli nowy odczyt ma większą wartość od starej wartości maksymalnej lub mniejszą od starej wartości minimalnej, to metoda zastępuje odpowiednią wartość, rejestruje czas odczytu i zapisuje zmiany w pamięci trwałej. O północy wywoływana jest metoda newDay. Po pierwsze, metoda ta zapisuje bieżący obiekt HiLoData w pamięci trwałej. Następnie resetuje wartości w obiekcie HiLoData zgodnie z odczytami na początku nowego dnia. Przelicza klucz pamięci trwałej dla nowej daty, po czym zapisuje nowy obiekt HiLoData w pamięci trwałej. Metoda Store wykorzystuje bieżący klucz pamięci trwałej w celu zapisania obiektu HiLoData do pamięci trwałej z wykorzystaniem obiektu PersistentImp. Na koniec metoda calculateStorageKey buduje klucz pamięci trwałej na podstawie typu obiektu HiLoData oraz argumentu date. Brzydota kodu. Bez wątpienia zrozumienie kodu z listingu 27.8 nie jest zbyt trudne. Ten kod jest jednak „brzydki” z innego powodu. Strategia zaimplementowana wewnątrz funkcji currentReading i newDay ma związek z zarządzaniem danymi dotyczącymi wartości maksymalnych i minimalnych oraz niezależnością mechanizmu utrwalania. Z drugiej strony, metody store, calculateStorageKey, konstruktor oraz zmienne transient są specyficzne dla utrwalania i nie mają nic wspólnego z zarządzaniem wartościami maksymalnymi i minimalnymi. To jest naruszenie zasady SRP. W obecnym, „pomieszanym” stanie pielęgnacja tej klasy może być koszmarnym zadaniem. Jeśli zmieni się jakaś podstawowa własność związana z utrwalaniem do tego stopnia, że funkcje calculateStorageKey i store staną się nieodpowiednie, wówczas w klasie trzeba będzie zaimplementować nowe mechanizmy utrwalania. Trzeba będzie zmodyfikować metody newDay i currentReading tak, aby wywoływały nowe mechanizmy utrwalania. Separacja utrwalania od strategii. Można uniknąć tych potencjalnych problemów poprzez oddzielenie wysokopoziomowej strategii zarządzania wartościami minimalnymi i maksymalnymi od mechanizmów utrwalania. Do tego celu można zastosować wzorzec projektowy Pełnomocnik. Przyjrzyjmy się jeszcze raz rysunkowi 26.7. Zwróćmy uwagę na sposób oddzielenia warstwy strategii (aplikacji) od warstwy mechanizmu (API). Na schemacie przedstawionym na rysunku 27.19 zastosowano wzorzec projektowy Pełnomocnik w celu wyeliminowania niepotrzebnych sprzężeń. Schemat ten różni się od tego, który przedstawiono na rysunku 27.17, dodaniem klasy HiLoDataProxy. W rzeczywistości obiekt TemperatureHiLo zawiera referencję do klasy-pełnomocnika. Z kolei pełnomocnik utrzymuje referencję do obiektu HiLoDataImp i deleguje do niego wywołania. Sposób implementacji kluczowych funkcji obiektów HiLoDataProxy i HiLoDataImp zaprezentowano na listingu 27.9.

PROJEKT OPROGRAMOWANIA SYSTEMU NIMBUS-LC

Rysunek 27.19. Wzorzec projektowy Pełnomocnik zastosowany do utrwalania wartości maksymalnych i minimalnych Listing 27.9. Fragmenty implementacji wzorca projektowego Pełnomocnik class HiLoDataProxy implements HiLoData { public boolean currentReading(double current, long time) { boolean change; change = itsImp.currentReading(current, time); if (change) store(); return change; } public void newDay(double initial, long time) { store(); itsImp.newDay(initial, time); calculateStorageKey(new Date(time)); store(); } private HiLoDataImp itsImp; } class HiLoDataImp implements HiLoData, java.io.Serializable { public boolean currentReading(double current, long time) { boolean changed = false; if (current > itsHighValue) { itsHighValue = current; itsHighTime = time; changed = true; } else if (current < itsLowValue) { itsLowValue = current; itsLowTime = time; changed = true; } return changed; }

387

388

};

ROZDZIAŁ 27. ANALIZA PRZYPADKU: STACJA POGODOWA

public void newDay(double initial, long time) { itsHighTime = itsLowTime = time; itsHighValue = itsLowValue = initial; }

Zwróćmy uwagę, że klasa HiLoDataImp nic „nie wie” o utrwalaniu. Zwróćmy także uwagę, że klasa HiLoDataProxy wykonuje wszystkie operacje związane z utrwalaniem, a następnie deleguje odpowiednie wywołania do klasy HiLoDataImp. To bardzo eleganckie rozwiązanie. Zwróćmy także uwagę na to, że klasa-pełnomocnik zależy zarówno od klasy HiLoDataImp (warstwa strategii), jak i od klasy PersistentImp (warstwa mechanizmu). To jest dokładnie takie rozwiązanie, do jakiego dążyliśmy. Ale nie jest to rozwiązanie doskonałe. Uważny czytelnik zapewne zauważył zmianę, którą wprowadziliśmy w metodzie currentReading. Zmodyfikowaliśmy ją tak, aby zwracała wartość boolean. Potrzebujemy tej wartości boolean wewnątrz klasy-pełnomocnika, by obiekt tej klasy „wiedział”, kiedy należy wywołać metodę store. Dlaczego nie chcemy wywoływać metody store za każdym razem, gdy jest wywoływana metoda currentReading? Istnieje wiele rodzajów pamięci NVRAM. Niektóre z nich mają określony górny limit liczby zapisów. Dlatego aby przedłużyć życie pamięci NVRAM, zapisujemy w nich wartości tylko wtedy, gdy nastąpiła zmiana. Po raz kolejny „wkracza” prawdziwe życie. Fabryki i inicjalizacja. Nie ulega wątpliwości, że nie chcemy, aby klasa TemperatureHiLo „wiedziała” cokolwiek o klasie-pełnomocniku. Klasa ta powinna „wiedzieć” wyłącznie o klasie HiLoData (patrz rysunek 27.19). Mimo to gdzieś trzeba stworzyć obiekt HiLoDataProxy, aby klasa TemperatureHiLo mogła z niego skorzystać. Trzeba też gdzieś stworzyć obiekt HiLoDataImp, do którego obiekt-pełnomocnik deleguje wywołania. Potrzebujemy mechanizmu tworzenia obiektów, nie wiedząc dokładnie, jakiego typu obiekty tworzymy. Potrzebujemy sposobu, aby obiekt klasy TemperatureHiLo utworzył obiekt HiLoData, nie wiedząc o tym, że w rzeczywistości tworzy obiekty HiLoDataProxy i HiLoDataImp. Także tym razem możemy sięgnąć po wzorzec projektowy Fabryka (patrz rysunek 27.20).

Rysunek 27.20. Wykorzystanie abstrakcyjnej fabryki do utworzenia obiektu-pełnomocnika

Klasa TemperatureHiLo korzysta z interfejsu DataToolkit w celu stworzenia obiektu implementującego interfejs HiLoData. Metoda getTempHiLoData jest zaimplementowana w obiekcie DataToolkitImp. Tworzy obiekt HiLoDataProxy z kodem typu "Temp" i zwraca obiekt HiLoData.

PROJEKT OPROGRAMOWANIA SYSTEMU NIMBUS-LC

389

Zastosowanie tego wzorca dobrze rozwiązuje problem tworzenia obiektów. Klasa TemperatureHiLo nie musi zależeć od obiektu klasy HiLoDataProxy, aby go utworzyć. W jaki sposób obiekt klasy TemperatureHiLo uzyskuje dostęp do obiektu DataToolkitImp? Nie chcemy, aby obiekt klasy TemperatureHiLo „wiedział” cokolwiek o obiekcie DataToolkitImp, ponieważ to stworzyłoby zależność warstwy strategii od warstwy mechanizmu. Struktura pakietu. Aby odpowiedzieć na to pytanie, przyjrzyjmy się strukturze pakietu pokazanej na rysunku 27.21. Skrót WMS pochodzi od nazwy pakietu Weather Monitoring System opisywanego na rysunku 27.16.

Rysunek 27.21. Struktura pakietów po zastosowaniu wzorców projektowych Pełnomocnik i Fabryka

Schemat pokazany na rysunku 27.21 wzmacnia nasze dążenie do tego, aby warstwa utrwalania zależała od warstw strategii i mechanizmu. Pokazuje również sposób rozmieszczenia klas w pakietach. Zwróćmy uwagę, że abstrakcyjna fabryka DataToolkit została zdefiniowana w pakiecie WMSData razem z klasą HiLoData. Klasa HiLoData jest zaimplementowana w pakiecie WMSDataImp, natomiast klasa DataToolkit jest zaimplementowana w pakiecie persistence. Kto tworzy fabrykę? Po raz kolejny postawimy pytanie: W jaki sposób egzemplarz klasy wms.Tem peratureHiLo uzyska dostęp do egzemplarza klasy persistence.DataToolkitImp, tak aby mógł wywołać metodę getTempHiLoData oraz stworzyć egzemplarze klasy persistence.HiLoDataProxy? Potrzebujemy zmiennej statycznej, która byłaby dostępna dla klas w pakiecie wmsdata. Ta zmienna powinna przechowywać obiekt wmsdata.DataToolkit, ale powinna być zainicjowana obiektem persistence.DataToolkitImp. Ponieważ w Javie wszystkie zmienne, ze statycznymi włącznie, muszą być zadeklarowane w jakiejś klasie, możemy stworzyć klasę Scope, która będzie zawierać potrzebne statyczne zmienne. Tę klasę umieścimy w pakiecie wmsdata. Odpowiednią implementację zamieszczono na listingach 27.10 i 27.11. W klasie Scope z pakietu wmsdata zadeklarowano statyczną zmienną składową, w której zapisano referencję do obiektu DataToolkit. W klasie Scope należącej do pakietu persistence zadeklarowano funkcję init(), która tworzy egzemplarz klasy DataToolkitImp i zapisuje go w zmiennej wmsdata.Scope.itsDataToolkit. Listing 27.10. wmsdata.Scope package wmsdata; public class Scope { public static DataToolkit itsDataToolkit; }

390

ROZDZIAŁ 27. ANALIZA PRZYPADKU: STACJA POGODOWA

Listing 27.11. persistence.Scope package persistence; public class Scope { public static void init() { wmsdata.Scope.itsDataToolkit = new DataToolkit(); } }

Na uwagę zasługuje interesująca symetria pomiędzy pakietami a klasami scope. Wszystkie klasy należące do pakietu wmsdata poza klasą Scope są interfejsami, które zawierają metody abstrakcyjne i nie zawierają zmiennych. Z kolei klasa wmsdata.Scope zawiera zmienną, ale nie zawiera metod. Z drugiej strony, wszystkie klasy należące do pakietu persistence poza klasą Scope są klasami konkretnymi, które mają zmienne. Natomiast klasa persistence.Scope zawiera funkcję i nie posiada zmiennych. Sposób przedstawienia tego schematu w postaci diagramu klas pokazano na rysunku 27.22. Klasy Scope są klasami narzędziowymi. Wszystkie składowe takich klas — zarówno zmienne, jak i funkcje — są statyczne. Jest to ostateczny element symetrii. Wydaje się, że pakiety, które zawierają abstrakcyjne interfejsy, obejmują narzędzia, które mają dane i nie mają funkcji, natomiast pakiety, które zawierają konkretne klasy, zazwyczaj zawierają narzędzia, które mają funkcje i nie mają danych.

Rysunek 27.22. Narzędzia klas Scope

Skąd jest wywoływana metoda persistence.Scope.init()? Najprawdopodobniej z funkcji main(). Klasa zawierająca tę funkcję main musi być w pakiecie, któremu nie przeszkadza zależność od klasy persistence. Często pakietowi zawierającemu funkcję main jest nadawana nazwa root. Ale wcześniej napisaliśmy... Warstwa implementacji utrwalania nie powinna zależeć od warstwy strategii. Jednak wystarczy uważnie przeanalizować zawartość rysunku 27.21, aby dostrzec zależność pomiędzy klasami persistence i wmsDataImp. Tę zależność można zaobserwować również na rysunku 27.20, na którym klasa HiLoDataProxy zależy od klasy HiLoDataImp. Powodem tej zależności jest fakt, że obiekt klasy HiLoDataProxy może stworzyć obiekt klasy HiLoDataImp, od której zależy. W większości przypadków obiekt klasy-pełnomocnika nie będzie zmuszony do tworzenia implementacji, ponieważ obiekt klasy-pełnomocnika czyta implementację z trwałego magazynu. A zatem obiekt klasy HiLoDataImp zostanie zwrócony do pełnomocnika w wyniku wywołania PersistentImp.retrieve. Jednak w tych rzadkich sytuacjach, gdy funkcja retrieve nie znajdzie obiektu w trwałym magazynie, obiekt klasy HiLoDataProxy stworzy pusty obiekt HiLoDataImp. Zatem wygląda na to, że potrzebujemy kolejnej fabryki, która „wie”, jak utworzyć egzemplarze klasy HiLoDataImp, którą będzie mógł wywołać egzemplarz klasy-pełnomocnika. To oznacza więcej pakietów, więcej klas Scope itp. Czy to jest naprawdę konieczne? Prawdopodobnie w tym przypadku nie. Stworzyliśmy fabrykę dla obiektu-pełnomocnika, ponieważ chcieliśmy, aby obiekty klasy TemperatureHiLo mogły współdziałać z wieloma różnymi mechanizmami utrwalania. A zatem uzyskaliśmy wyraźną korzyść, co uzasadniało

PRZEGLĄD WYMAGAŃ DLA OPROGRAMOWANIA NIMBUS-LC

391

stworzenie fabryki DataToolkit. Ale jakie korzyści można uzyskać poprzez wstawienie fabryki pomiędzy klasami HiLoDataProxy i HiLoDataImp? Gdyby istniało wiele różnych implementacji klasy HiLoDataImp, a zależałoby nam na tym, by klasa-pełnomocnik współdziałała z nimi wszystkimi, wtedy można by znaleźć takie uzasadnienie. Nie uważamy jednak, aby wymagania aż tak bardzo się zmieniły. Pakiet wmsDataImp zawiera zasady monitorowania pogody i reguły biznesowe, które nie zmieniały się przez dłuższy czas. Wydaje się mało prawdopodobne, że będą się one zmieniać kiedykolwiek w przyszłości. Te ostatnie słowa mogły zabrzmieć znajomo, ale gdzieś trzeba narysować grubą kreskę. W tym przypadku zdecydowaliśmy, że zależność implementacji od pełnomocnika nie stwarza dużych problemów z utrzymaniem, zatem możemy obyć się bez fabryki.

Wniosek Rozdział ten napisałem wraz z Jimem Newkirkiem na początku 1998 roku. Jim napisał większość kodu, a ja przetłumaczyłem kod na diagramy UML i opatrzyłem je komentarzami. Wyjściowy kod jest już bardzo przestarzały. Ale to tworzenie tamtego kodu doprowadziło do projektu, który można zobaczyć na stronach niniejszego rozdziału. Większość diagramów UML powstała już po stworzeniu kodu. W 1998 roku ani Jim, ani ja nie słyszeliśmy o programowaniu ekstremalnym. Z tego względu projekt zaprezentowany w tym rozdziale nie powstał w środowisku programowania w parach czy w wyniku stosowania techniki programowania sterowanego testami. Mimo to Jim i ja zawsze blisko ze sobą współpracowaliśmy. Wspólnie ślęczeliśmy nad kodem, który pisaliśmy, uruchamialiśmy go w miarę możliwości, razem wprowadzaliśmy zmiany w kodzie oraz tworzyliśmy diagramy UML oraz komentarze. Zatem mimo że projekt zaprezentowany w tym rozdziale powstał przed erą programowania ekstremalnego, stworzyliśmy go, ściśle ze sobą współpracując oraz kładąc akcent na kod.

Bibliografia 1. Gamma, et al., Design Patterns, Reading, MA: Addison-Wesley, 1995. 2. Bertrand Meyer, Object-Oriented Software Construction, wydanie drugie, Upper Saddle River, NJ: Prentice Hall, 1997. 3. Ken Arnold i James Gosling, The Java Programming Language, wydanie drugie, Reading, MA: Addison-Wesley, 1998.

Przegląd wymagań dla oprogramowania Nimbus-LC Wymagania użytkowe System powinien umożliwiać automatyczne monitorowanie różnych parametrów pogodowych. W szczególności powinien umożliwiać pomiar następujących zmiennych:      

kierunku i szybkości wiatru; temperatury; ciśnienia atmosferycznego; wilgotności względnej; temperatury odczuwalnej; temperatury punktu rosy.

392

ROZDZIAŁ 27. ANALIZA PRZYPADKU: STACJA POGODOWA

System powinien również dostarczać wskazówek dotyczących aktualnego trendu wskazań ciśnienia barometrycznego. Trzy możliwe wartości to stabilne, wzrastające i opadające. Na przykład bieżące ciśnienie wynosi 979 hPa i spada. Urządzenie powinno mieć wyświetlacz, który stale wskazuje wszystkie pomiary, a także aktualną godzinę i datę.

Historia 24-godzinna Dzięki zastosowaniu ekranu dotykowego użytkownik może zażądać od systemu wyświetlenia 24-godzinnej historii dowolnego z następujących pomiarów:  temperatury;  ciśnienia atmosferycznego;  wilgotności względnej.

Historia powinna być zaprezentowana użytkownikom w formie wykresu liniowego (patrz rysunek 27.23).

Konfiguracja użytkownika System powinien zawierać niżej wymienione mechanizmy pozwalające użytkownikowi na konfigurowanie stacji podczas instalacji:  ustawianie bieżącej godziny, daty i strefy czasowej;  ustawianie systemu jednostek (angielski lub metryczny).

Rysunek 27.23. Historia pomiarów temperatury

Wymagania administracyjne System powinien zapewniać mechanizm zabezpieczeń dostępu do funkcji administracyjnych stacji pogody. Są to następujące funkcje:  kalibracja czujników;  resetowanie stacji.

PRZYPADKI UŻYCIA SYSTEMU NIMBUS-LC

393

Przypadki użycia systemu Nimbus-LC Aktorzy W tym systemie użytkownicy mogą pełnić jedną z dwóch odrębnych ról. Użytkownik. Użytkownicy mogą przeglądać w czasie rzeczywistym informacje pogodowe mierzone przez stację. Mogą również zlecać systemowi zadanie wyświetlania historycznych danych powiązanych z pojedynczymi czujnikami. Administrator. Administrator zarządza aspektami bezpieczeństwa systemu, kalibracją poszczególnych czujników, ustawieniami godziny i daty, ustawieniami jednostek miary oraz resetowaniem stacji, gdy jest to potrzebne.

Przypadki użycia Przypadek użycia nr 1: monitorowanie danych pogodowych. System wyświetla aktualną temperaturę, ciśnienie atmosferyczne, względną wilgotność, prędkość wiatru, kierunek wiatru, temperaturę odczuwalną, temperaturę punktu rosy oraz trend ciśnienia atmosferycznego.

Historia pomiarów System wyświetla wykres liniowy przedstawiający odczyty czujników w systemie z ostatnich 24 godzin. Oprócz tego wykresu system wyświetla również bieżącą datę i godzinę oraz maksymalną i minimalną wartość odczytu z ostatnich 24 godzin. Przypadek użycia nr 2: przeglądanie historii pomiarów temperatury. Przypadek użycia nr 3: przeglądanie historii pomiarów ciśnienia atmosferycznego. Przypadek użycia nr 4: przeglądanie historii pomiarów wilgotności względnej.

Konfiguracja Przypadek użycia nr 5: ustawienia jednostek. Użytkownik ustawia typ jednostek, które będą wyświetlane. Możliwy jest wybór pomiędzy jednostkami angielskimi a metrycznymi. Domyślny jest system metryczny. Przypadek użycia nr 6: ustawianie daty. Użytkownik może ustawiać bieżącą datę. Przypadek użycia nr 7: ustawianie godziny. Użytkownik może ustawić bieżącą godzinę oraz strefę czasową obowiązującą w systemie.

Administracja Przypadek użycia nr 8: resetowanie stacji pogodowej. Administrator ma możliwość zresetowania stacji do ustawień fabrycznych. Należy zwrócić uwagę, że ta operacja spowoduje usunięcie wszystkich historycznych danych zapisanych w stacji oraz usunięcie wprowadzonych kalibracji. Przed wykonaniem tej operacji system poinformuje administratora o konsekwencjach i zada ostateczne pytanie o zamiar kontynuacji operacji zresetowania stacji. Przypadek użycia nr 9: kalibracja czujnika temperatury. Administrator na podstawie znanego dobrego źródła temperatury wprowadzi tę wartość do systemu. System zapamięta tę wartość i będzie jej używał wewnętrznie do kalibracji właściwych odczytów z wartościami bieżących pomiarów. Szczegółowy opis kalibracji czujników można znaleźć w dokumencie opisującym platformę sprzętową.

394

ROZDZIAŁ 27. ANALIZA PRZYPADKU: STACJA POGODOWA

Przypadek użycia nr 10: kalibracja czujnika ciśnienia atmosferycznego. Przypadek użycia nr 11: kalibracja czujnika wilgotności względnej. Przypadek użycia nr 12: kalibracja czujnika prędkości wiatru. Przypadek użycia nr 13: kalibracja czujnika kierunku wiatru. Przypadek użycia nr 14: kalibracja czujnika temperatury punktu rosy. Przypadek użycia nr 15: log kalibracji. System wyświetli administratorowi historię kalibracji urządzenia. Ta historia obejmuje godzinę i datę kalibracji, kalibrowany czujnik oraz wartość, która została wykorzystana do skalibrowania czujnika.

Plan publikacji wersji dystrybucyjnych systemu Nimbus-LC Wprowadzenie Implementacja stacji pogodowej będzie wykonana w kilku iteracjach. Każda iteracja będzie bazować na tym, co zostało zrobione wcześniej. Ostatecznym celem będzie dostarczenie użytkownikom wymaganych funkcjonalności. W niniejszym dokumencie opisano wydania trzech wersji dystrybucyjnych tego projektu.

Wydanie I Publikacja ma dwa cele. Pierwszym jest stworzenie architektury, która obsłuży większą część aplikacji w sposób niezależny od platformy sprzętowej Nimbus. Drugim celem jest zarządzanie dwoma największymi zagrożeniami. 1. Przystosowanie starego API Nimbus 1.0 do pracy z nową płytą i nowym systemem operacyjnym. Jest to z pewnością wykonalne, ale bardzo trudno oszacować, jak długo to potrwa, ponieważ trudno zidentyfikować wszystkie niezgodności. 2. Wirtualna maszyna Javy. Nigdy wcześniej nie używaliśmy JVM na wbudowanej płycie. Nie wiemy, czy będzie działać prawidłowo z naszym systemem operacyjnym ani czy poprawnie implementuje wszystkie kody bajtowe Javy. Nasi dostawcy zapewniają nas, że wszystko pójdzie sprawnie, ale nadal dostrzegamy znaczące zagrożenie. Integracja maszyny JVM z ekranem dotykowym i podsystemem graficznym przebiega równolegle z publikacją tej wersji. Oczekuje się, że będzie gotowa przed rozpoczęciem drugiej fazy.

Zagrożenia 1. Aktualizacja systemu operacyjnego — obecnie korzystamy ze starszej wersji tego systemu na wybranej platformie sprzętowej. Aby skorzystać z maszyny JVM, trzeba zaktualizować system operacyjny do najnowszej wersji. To wymaga również użycia najnowszej wersji narzędzi programistycznych. 2. Dostawca systemu operacyjnego dostarcza najnowszą wersję maszyny JVM dla tej wersji systemu operacyjnego. Aby być na bieżąco, chcemy wykorzystać wersję 1.2 maszyny JVM. Jednak wersja 1.2 jest obecnie dostępna w wersji beta i będzie się zmieniać w trakcie realizacji projektu. 3. W nowej architekturze trzeba zweryfikować natywny interfejs Javy do interfejsu API w języku C platformy sprzętowej.

PLAN PUBLIKACJI WERSJI DYSTRYBUCYJNYCH SYSTEMU NIMBUS-LC

395

Produkty projektu 1. Sprzęt z zainstalowanym nowym systemem operacyjnym oraz najnowszą wersją maszyny JVM. 2. Strumieniowe wyjście zdolne do wyświetlania odczytów bieżącej temperatury i ciśnienia atmosferycznego (wyrzucić kod niewykorzystany w ostatecznej wersji). 3. Gdy nastąpi zmiana ciśnienia atmosferycznego, system poinformuje użytkownika, czy ciśnienie wzrasta, spada, czy jest stabilne. 4. Co godzinę system wyświetli historię z ostatnich 24 godzin pomiarów temperatury i ciśnienia atmosferycznego. Dane zostaną utrwalone — tzn. będą dostępne po wyłączeniu i ponownym włączeniu zasilania. 5. Codziennie o północy system wyświetli maksymalną i minimalną wartość temperatury i ciśnienia atmosferycznego z poprzedniego dnia. 6. Wszystkie pomiary będą wyrażone w systemie metrycznym.

Wydanie II W tej fazie projektu do produktów pierwszego wydania zostaną dodane podstawy interfejsu użytkownika. Nie będą dodane funkcjonalności związane z dodatkowymi pomiarami. Jedyną zmianą w mechanizmach związanych z samymi pomiarami jest dodanie mechanizmu kalibracji. Podstawowym celem tej fazy są aspekty prezentacji systemu. Głównym zagrożeniem jest interfejs programowy do dotykowego panelu LCD. A ponieważ jest to pierwsza wersja, w której będzie wyświetlany interfejs użytkownika w widocznej dla niego postaci, mogą zacząć pojawiać się nowe wymagania. Oprócz oprogramowania dostarczymy specyfikację dla nowego sprzętu. To jest główny powód dodania mechanizmów kalibracji w tej fazie projektu. Ten interfejs API będzie wyspecyfikowany w Javie.

Zaimplementowane przypadki użycia       

Nr 2 — przeglądanie historii pomiarów temperatury. Nr 3 — przeglądanie historii pomiarów ciśnienia atmosferycznego. Nr 5 — ustawianie jednostek. Nr 6 — ustawianie daty. Nr 7 — ustawianie godziny i strefy czasowej. Nr 9 — kalibracja czujnika temperatury. Nr 10 — kalibracja czujnika ciśnienia atmosferycznego.

Zagrożenia 1. Interfejs dotykowego panelu LCD do maszyny wirtualnej Java musi być przetestowany na rzeczywistym sprzęcie. 2. Zmieniające się wymagania. 3. Zmiany w maszynie JVM obejmujące zmiany w bibliotekach Java Foundation Classes w miarę przechodzenia z wersji beta do wersji finalnej.

Produkty projektu 1. System, który realizuje pełną funkcjonalność określoną w przypadkach użycia wymienionych powyżej. 2. Zaimplementowana zostanie również część przypadku użycia nr 1 dotycząca temperatury, ciśnienia atmosferycznego oraz daty i godziny. 3. W ramach tej fazy zostanie zrealizowana część architektury oprogramowania związana z GUI. 4. Zrealizowana zostanie administracyjna część oprogramowania związana z obsługą kalibracji temperatury i ciśnienia atmosferycznego. 5. Specyfikacja API nowej platformy sprzętowej — API w Javie zamiast w języku C.

396

ROZDZIAŁ 27. ANALIZA PRZYPADKU: STACJA POGODOWA

Wydanie III To jest publikacja poprzedzająca prezentację produktu klientowi.

Zaimplementowane przypadki użycia        

Nr 1 — monitorowanie danych pogodowych. Nr 4 — przeglądanie historii pomiarów wilgotności względnej. Nr 8 — resetowanie stacji pogodowej. Nr 11 — kalibracja czujnika wilgotności względnej. Nr 12 — kalibracja czujnika prędkości wiatru. Nr 13 — kalibracja czujnika kierunku wiatru. Nr 14 — kalibracja czujnika temperatury punktu rosy. Nr 15 — log kalibracji.

Zagrożenia 1. Zmieniające się wymagania — oczekuje się, że w miarę jak produkt będzie się stawał coraz bardziej kompletny, będą pojawiały się zmiany wymagań. 2. Ukończenie całego produktu może dawać podstawy do zmiany w interfejsie API sprzętu, określonego na koniec wydania II. 3. Ograniczenia sprzętowe — podczas finalizowania produktu możemy napotkać ograniczenia sprzętu (tzn. pamięci, mocy procesora itp.).

Produkty projektu 1. Nowe oprogramowanie działające na starej platformie sprzętowej. 2. Specyfikacja nowego sprzętu, która została zweryfikowana za pomocą tej implementacji.

CZĘŚĆ VI Studium przypadku: ETS Aby stać się licencjonowanym architektem w Stanach Zjednoczonych lub Kanadzie, należy zdać egzamin. Osobie, która go pomyślnie przejdzie, stanowa komisja licencyjna przyznaje licencję na wykonywanie zawodu architekta. Egzamin został opracowany przez Educational Testing Service (ETS) pod nadzorem National Council of Architectural Registration Boards (NCARB) i jest obecnie zarządzany przez międzynarodową grupę Chauncey Group International. W przeszłości kandydaci pisali egzamin, używając ołówka i papieru. Wypełnione testy egzaminacyjne były następnie przekazywane jurorom do oceny. Jurorami byli doświadczeni architekci, którzy analizowali testy i podejmowali decyzję o tym, czy kandydat zdał egzamin, czy go nie zdał. W 1989 roku organizacja NCARB poleciła ETS przeprowadzenie badania, czy dla części egzaminu można wykorzystać automatyczny system oceniania. W rozdziałach należących do tej części opisano fragmenty powstałego projektu. Tak jak w poprzednich rozdziałach w czasie projektowania tego oprogramowania napotkamy szereg przydatnych wzorców projektowych, więc rozdziały opisujące te wzorce poprzedzają faktyczne studium przypadku.

398

ROZDZIAŁ 28. WZORZEC PROJEKTOWY WIZYTATOR

RODZINA WZORCÓW PROJEKTOWYCH WIZYTATOR

399

R OZDZIAŁ 28

Wzorzec projektowy Wizytator

To jakiś gość — mruknąłem — stuka w drzwi mojej izby. Tylko gość, nic więcej — Edgar Allan Poe, Kruk

Problem: Trzeba dodać nową metodę do hierarchii klas, ale fakt dodania tej klasy może być trudny lub szkodliwy dla projektu. To jest powszechny problem. Dla przykładu przypuśćmy, że mamy hierarchię obiektów Modem. Klasa bazowa zawiera uniwersalne metody, wspólne dla wszystkich modemów. Klasy potomne reprezentują sterowniki modemów wielu różnych producentów i typów. Przypuśćmy, że pojawiło się wymaganie, aby dodać do hierarchii nową metodę o nazwie configureForUnix. Ta metoda ma służyć do skonfigurowania modemu do pracy z systemem operacyjnym UNIX. Metoda będzie robić co innego w każdej klasie potomnej modemu, ponieważ każdy modem charakteryzuje się własnymi osobliwościami dotyczącymi ustawiania konfiguracji i obsługi systemu UNIX.

400

ROZDZIAŁ 28. WZORZEC PROJEKTOWY WIZYTATOR

Niestety, dodanie metody configureForUnix rodzi mnóstwo pytań. Co z systemem Windows? Co z systemem Mac OS? Co z Linuksem? Czy naprawdę trzeba dodać nową metodę do hierarchii klas Modem dla każdego nowego systemu operacyjnego, którego używamy? Nie ulega wątpliwości, że takie rozwiązanie jest brzydkie. Nigdy nie uda nam się zamknąć interfejsu Modem. Za każdym razem, gdy będzie trzeba obsłużyć nowy system operacyjny, będzie się to wiązało z koniecznością modyfikacji interfejsu oraz ponowną instalacją całego oprogramowania modemu.

Rodzina wzorców projektowych Wizytator Rodzina wzorców projektowych Wizytator pozwala dodawać nowe metody do istniejących hierarchii klas bez modyfikowania tych hierarchii. Do wspomnianej rodziny należą następujące wzorce projektowe:    

Wizytator (ang. Visitor); Acykliczny wizytator (ang. Acyclic visitor); Dekorator (ang. Decorator); Obiekt rozszerzenia (ang. Extension Object).

Wizytator1 Rozważmy hierarchię klas Modem z rysunku 28.1. Interfejs Modem zawiera uniwersalne metody, które mogą zaimplementować wszystkie modemy. Na rysunku pokazano trzy klasy potomne — jedna steruje modemami Hayes, druga modemami Zoom, a trzecia steruje kartą modemową produkowaną przez Erniego, inżyniera sprzętowego pracującego w naszej firmie.

Rysunek 28.1. Hierarchia klas Modem

W jaki sposób można skonfigurować te modemy do obsługi systemu Unix bez umieszczania metody ConfigureForUnix wewnątrz interfejsu Modem? Można zastosować technikę podwójnego przydziału (ang.

dual dispatch) — mechanizm, który leży u podstaw wzorca projektowego Wizytator. Strukturę wzorca projektowego Wizytator pokazano na rysunku 28.2, natomiast na listingach od 28.1 do 28.6 zamieszczono właściwy kod w Javie. Na listingu 28.7 zamieszczono kod testu, który zarówno weryfikuje, że wzorzec projektowy Wizytator działa, jak również pokazuje, w jaki sposób może być wykorzystywany przez innych programistów.

1

[GOF 95], str. 331.

WIZYTATOR

Rysunek 28.2. Wzorzec projektowy Wizytator Listing 28.1. Modem.java public interface Modem { public void dial(String pno); public void hangup(); public void send(char c); public char recv(); public void accept(ModemVisitor v); }

Listing 28.2. ModemVisitor.java public interface ModemVisitor { public void visit(HayesModem modem); public void visit(ZoomModem modem); public void visit(ErnieModem modem); }

Listing 28.3. HayesModem.java public class HayesModem implements Modem { public void dial(String pno){} public void hangup(){} public void send(char c){} public char recv() {return 0;} public void accept(ModemVisitor v) {v.visit(this);} }

String configurationString = null;

Listing 28.4. ZoomModem.java public class ZoomModem implements Modem { public void dial(String pno){} public void hangup(){} public void send(char c){}

401

402

ROZDZIAŁ 28. WZORZEC PROJEKTOWY WIZYTATOR

public char recv() {return 0;} public void accept(ModemVisitor v) {v.visit(this);} }

int configurationValue = 0;

Listing 28.5. ErnieModem.java public class ErnieModem implements Modem { public void dial(String pno){} public void hangup(){} public void send(char c){} public char recv() {return 0;} public void accept(ModemVisitor v) {v.visit(this);} }

String internalPattern = null;

Listing 28.6. UnixModemConfigurator.java public class UnixModemConfigurator implements ModemVisitor { public void visit(HayesModem m) { m.configurationString = "&s1=4&D=3"; } public void visit(ZoomModem m) { m.configurationValue = 42; }

}

public void visit(ErnieModem m) { m.internalPattern = "Język C jest zbyt wolny"; }

Listing 28.7. TestModemVisitor.java import junit.framework.*; public class TestModemVisitor extends TestCase { public TestModemVisitor(String name) { super(name); } private private private private

UnixModemConfigurator v; HayesModem h; ZoomModem z; ErnieModem e;

public void { v = new h = new z = new e = new }

setUp() UnixModemConfigurator(); HayesModem(); ZoomModem(); ErnieModem();

public void testHayesForUnix() { h.accept(v); assertEquals("&s1=4&D=3", h.configurationString);

WZORZEC PROJEKTOWY ACYKLICZNY WIZYTATOR

403

} public void testZoomForUnix() { z.accept(v); assertEquals(42, z.configurationValue); }

}

public void testErnieForUnix() { e.accept(v); assertEquals("Język C jest zbyt wolny", e.internalPattern); }

Zauważmy, że w hierarchii wizytatora jest metoda dla każdej pochodnej wizytowanej hierarchii (Modem). Jest to rodzaj obrotu o 90° — od pochodnych w kierunku metod. Kod testu pokazuje, że w celu skonfigurowania modemu do obsługi systemu Unix programista musi stworzyć egzemplarz klasy UnixModemConfigurator, a następnie przekazać go do metody accept klasy Modem. Następnie z odpowiedniej pochodnej klasy Modem zostanie wywołana metoda visit(this) względem obiektu ModemVisitor — klasy bazowej dla klasy UnixModemConfigurator. Jeśli tą pochodną jest Hayes, to wywołanie visit(this) spowoduje wywołanie metody public void visit(Hayes). To z kolei sprowadzi się do wywołania funkcji public void visit(Hayes) w klasie UnixModemConfigurator, która skonfiguruje modem Hayes do obsługi systemu Unix. Dzięki stworzeniu tej struktury można dodać funkcje konfiguracji nowych systemów operacyjnych poprzez dodanie nowych pochodnych klasy ModemVisitor — bez konieczności modyfikowania w jakikolwiek sposób hierarchii klasy Modem. Zatem wzorzec projektowy Wizytator umożliwia podstawianie pochodnych klasy ModemVisitor za metody należące do hierarchii klasy Modem. Technika ta nazywa się podwójnym przydziałem, ponieważ obejmuje dwa polimorficzne przydziały. Pierwszym jest metoda accept. Ten przydział pozwala ustalić typ obiektu, dla którego jest wywoływana metoda accept. Drugi przydział to metoda visit, która określa konkretną funkcję, która ma być wywołana. Zastosowanie tych dwóch przydziałów powoduje, że wzorzec projektowy Wizytator działa bardzo szybko.

Wzorzec projektowy Wizytator działa jak macierz Dwa przydziały stosowane we wzorcu projektowym Wizytator tworzą macierz funkcji. W przykładzie hierarchii modemów jedną oś macierzy stanowią różne typy modemów. Druga oś to różne rodzaje systemów operacyjnych. Każda komórka w tej macierzy jest wypełniona funkcją, która opisuje, w jaki sposób zainicjować określony modem dla określonego systemu operacyjnego.

Wzorzec projektowy Acykliczny wizytator Zwróćmy uwagę, że klasa bazowa odwiedzanej hierarchii (Modem) zależy od klasy bazowej hierarchii wizytatora (ModemVisitor). Zauważmy także, że klasa bazowa hierarchii wizytatora zawiera metodę dla każdej pochodnej wizytowanej hierarchii. Zatem powstaje cykl zależności, który wiąże ze sobą wszystkie wizytowane pochodne (wszystkie modemy). To sprawia, że przyrostowa kompilacja struktury wizytatora lub dodanie nowych pochodnych do wizytowanej hierarchii staje się bardzo trudne. Wzorzec projektowy Wizytator dobrze się sprawdza w programach, w których modyfikowane hierarchie nie wymagają zbyt częstego wprowadzania nowych pochodnych. Jeśli Hayes, Zoom i Ernie są jedynymi potrzebnymi pochodnymi klasy Modem, albo jeśli potrzeba zastosowania nowej pochodnej klasy Modem nie jest oczekiwana zbyt często, wówczas wzorzec projektowy Wizytator świetnie spełni swoją rolę.

404

ROZDZIAŁ 28. WZORZEC PROJEKTOWY WIZYTATOR

Z drugiej strony, jeśli wizytowana hierarchia jest bardzo zmienna i należy oczekiwać konieczności tworzenia wielu nowych klas pochodnych, to klasa bazowa Visitor (np. ModemVisitor) będzie musiała być modyfikowana i ponownie kompilowana razem ze wszystkimi pochodnymi — za każdym razem, kiedy do wizytowanej hierarchii zostanie dodana nowa klasa potomna. W przypadku stosowania języka C++ sytuacja jest jeszcze gorsza. Dodanie nowej klasy pochodnej każdorazowo wymaga ponownej kompilacji i instalacji całej wizytowanej hierarchii. W celu rozwiązania tych problemów można zastosować wariant wzorca projektowego Wizytator znany pod nazwą Acykliczny wizytator2 (patrz rysunek 28.3). W przypadku zastosowania tej odmiany wzorca następuje przerwanie cyklu zależności poprzez zdegenerowanie klasy bazowej wizytatora (ModemVisitor)3. Brak jakichkolwiek metod w tej klasie oznacza, że klasa ta nie zależy od pochodnych w wizytowanej hierarchii.

Rysunek 28.3. Wzorzec projektowy Acykliczny wizytator

Pochodne wizytatora dziedziczą również po interfejsach wizytatora. Istnieje jeden interfejs wizytatora dla każdej pochodnej wizytowanej hierarchii. Jest to obrót o 180° — od pochodnych do interfejsów. Metody accept w wizytowanych pochodnych rzutują klasę bazową Visitor 4 na odpowiedni interfejs wizytatora. Jeśli rzutowanie zakończy się powodzeniem, metoda wywołuje odpowiednią funkcję visit. Odpowiedni kod zaprezentowano na listingach od 28.8 do 28.16.

2

[PLOPD3], str. 93.

3

Klasa zdegenerowana to klasa całkowicie pozbawiona metod. W języku C++ taka klasa zawiera czysto wirtualny destruktor. W Javie takie klasy określa się jako interfejs znacznikowy (ang. marker interface).

4

W języku C++ w tym celu wykorzystuje się konstrukcję dynamic_cast.

WZORZEC PROJEKTOWY ACYKLICZNY WIZYTATOR

Listing 28.8. Modem.java public interface Modem { public void dial(String pno); public void hangup(); public void send(char c); public char recv(); public void accept(ModemVisitor v); }

Listing 28.9. ModemVisitor.java public interface ModemVisitor { }

Listing 28.10. ErnieModemVisitor.java public interface ErnieModemVisitor { public void visit(ErnieModem m); }

Listing 28.11. HayesModemVisitor.java public interface HayesModemVisitor { public void visit(HayesModem m); }

Listing 28.12. ZoomModemVisitor.java public interface ZoomModemVisitor { public void visit(ZoomModem m); }

Listing 28.13. ErnieModem.java public class ErnieModem implements Modem { public void dial(String pno){} public void hangup(){} public void send(char c){} public char recv() {return 0;} public void accept(ModemVisitor v) { try { ErnieModemVisitor ev = (ErnieModemVisitor)v; ev.visit(this); } catch (ClassCastException e) { } } }

String internalPattern = null;

Listing 28.14. HayesModem.java public class HayesModem implements Modem { public void dial(String pno){} public void hangup(){} public void send(char c){}

405

406

}

ROZDZIAŁ 28. WZORZEC PROJEKTOWY WIZYTATOR

public char recv() {return 0;} public void accept(ModemVisitor v) { try { HayesModemVisitor hv = (HayesModemVisitor)v; hv.visit(this); } catch (ClassCastException e) { } } String configurationString = null;

Listing 28.15. ZoomModem.java public class ZoomModem implements Modem { public void dial(String pno){} public void hangup(){} public void send(char c){} public char recv() {return 0;} public void accept(ModemVisitor v) { try { ZoomModemVisitor zv = (ZoomModemVisitor)v; zv.visit(this); } catch(ClassCastException e) { } } int configurationValue = 0; }

Listing 28.16. TestModemVisitor.java import junit.framework.*; public class TestModemVisitor extends TestCase { public TestModemVisitor(String name) { super(name); } private private private private

UnixModemConfigurator v; HayesModem h; ZoomModem z; ErnieModem e;

public void { v = new h = new z = new e = new }

setUp() UnixModemConfigurator(); HayesModem(); ZoomModem(); ErnieModem();

public void testHayesForUnix() { h.accept(v); assertEquals("&s1=4&D=3", h.configurationString); } public void testZoomForUnix() {

WZORZEC PROJEKTOWY ACYKLICZNY WIZYTATOR

}

}

407

z.accept(v); assertEquals(42, z.configurationValue);

public void testErnieForUnix() { e.accept(v); assertEquals("Język C jest zbyt wolny", e.internalPattern); }

Zastosowanie powyższego wzorca powoduje przerwanie cyklu zależności. Jednocześnie ułatwia dodawanie wizytowanych pochodnych oraz wykonywanie kompilacji przyrostowych. Niestety, to sprawia także, że rozwiązanie staje się znacznie bardziej złożone. Co gorsza, czas rzutowania może być uzależniony od szerokości wizytowanej hierarchii, a zatem jest trudny do scharakteryzowania. W przypadku systemów sprzętowych działających w czasie rzeczywistym nieprzewidywalny czas wykonywania może spowodować, że wzorzec projektowy Acykliczny wizytator stanie się nieodpowiedni. W przypadku innych systemów dyskwalifikująca może być złożoność wzorca. Ale dla tych systemów, w których wizytowana hierarchia jest zmienna, a przyrostowe kompilacje są ważne, zastosowanie wzorca Acykliczny wizytator może być dobrym rozwiązaniem.

Wzorzec projektowy Wizytator działa jak macierz rzadka Wcześniej napisaliśmy, że wzorzec projektowy Wizytator działa jak macierz funkcji, w której jedną oś tworzą wizytowane typy, natomiast drugą — funkcje do wywołania. Wzorzec projektowy Acykliczny wizytator tworzy macierz rzadką. Klasy wizytatora nie muszą implementować metod visit dla każdej wizytowanej pochodnej. Na przykład jeśli modemy Ernie nie mogą być skonfigurowane do obsługi systemu Unix, to klasa UnixModemConfigurator nie będzie implementować interfejsu ErnieVisitor. Zatem wzorzec projektowy Acykliczny wizytator umożliwia zignorowanie określonych kombinacji klas pochodnych i metod. Taka własność czasami może być przydatną zaletą.

Wykorzystanie wzorca projektowego Wizytator w generatorach raportów Bardzo popularnym zastosowaniem wzorca projektowego Wizytator jest przeglądanie rozbudowanych struktur danych w celu generowania raportów. Dzięki temu można usunąć z obiektów struktury danych kod odpowiedzialny za generowanie raportów. Zamiast modyfikować kod w strukturach danych, nowe raporty można dodawać, tworząc nowe klasy-wizytatorów. Oznacza to, że raporty mogą być umieszczone w oddzielnych komponentach i indywidualnie instalowane tylko dla tych klientów, którzy ich potrzebują. Rozważmy prostą strukturę danych, która reprezentuje zestawienie materiałów (patrz rysunek 28.4). Istnieje nieograniczona liczba raportów, które możemy wygenerować z tej struktury danych. Na przykład możemy wygenerować raport całkowitego kosztu komponentu albo raport zawierający zestawienie wszystkich części użytych do budowy tego komponentu.

Rysunek 28.4. Struktura generatora raportów dotyczących zestawienia materiałów

408

ROZDZIAŁ 28. WZORZEC PROJEKTOWY WIZYTATOR

Każdy z tych raportów mógłby być wygenerowany za pomocą metod klasy Part. Na przykład do klasy Part można by dodać metody getExplodedCost i getPieceCount. Implementacja tych metod powinna się znaleźć w każdej pochodnej klasy Part, tak aby można było wygenerować właściwy raport. Niestety to oznaczałoby, że z każdym nowym raportem, którego żądaliby klienci, konieczna byłaby zmiana hierarchii klasy Part. Zgodnie z zasadą pojedynczej odpowiedzialności (SRP) powinniśmy rozdzielić kod, który zmienia się z różnych powodów. Hierarchia klasy Part może się zmieniać w miarę pojawiania się zapotrzebowania na nowe części. Nie powinna się jednak zmieniać z powodu zapotrzebowania na nowe rodzaje raportów. Z tego względu należałoby odseparować raporty od hierarchii klasy Part. Można to osiągnąć za pomocą struktury wzorca projektowego Wizytator, którą pokazano na rysunku 28.4. Każdy nowy raport można zaimplementować jako nową klasę-wizytatora. Można napisać metodę accept klasy Assembly, aby „złożyć” wizytę, oraz wywołać metodę accept na rzecz wszystkich egzemplarzy klasy Part wchodzących w skład obiektu Assembly. W ten sposób można przeglądać całe drzewo. Podczas generowania raportu dla każdego węzła w drzewie wywoływana jest odpowiednia metoda visit. Raport kumuluje niezbędne statystyki. Następnie można „odpytywać” raport o interesujące dane i prezentować te dane użytkownikom. Zaprezentowana struktura pozwala na tworzenie nieograniczonej liczby raportów całkowicie bez wpływu na hierarchię klasy Part. Co więcej, każdy raport może być skompilowany i zainstalowany niezależnie od pozostałych. To bardzo eleganckie rozwiązanie. Odpowiednią implementację w Javie zamieszczono na listingach od 28.17 do 28.23. Listing 28.17. Part.java public interface Part { public String getPartNumber(); public String getDescription(); public void accept(PartVisitor v); }

Listing 28.18. Assembly.java import java.util.*; public class Assembly implements Part { public Assembly(String partNumber, String description) { itsPartNumber = partNumber; itsDescription = description; } public void accept(PartVisitor v) { v.visit(this); Iterator i = getParts(); while (i.hasNext()) { Part p = (Part)i.next(); p.accept(v); } } public void add(Part part) { itsParts.add(part); } public Iterator getParts() { return itsParts.iterator();

WZORZEC PROJEKTOWY ACYKLICZNY WIZYTATOR

} public String getPartNumber() { return itsPartNumber; } public String getDescription() { return itsDescription; }

}

private List itsParts = new LinkedList(); private String itsPartNumber; private String itsDescription;

Listing 28.19. PiecePart.java public class PiecePart implements Part { public PiecePart(String partNumber, String description, double cost) { itsPartNumber = partNumber; itsDescription = description; itsCost = cost; } public void accept(PartVisitor v) { v.visit(this); } public String getPartNumber() { return itsPartNumber; } public String getDescription() { return itsDescription; } public double getCost() { return itsCost; }

}

private String itsPartNumber; private String itsDescription; private double itsCost;

Listing 28.20. PartVisitor.java public interface PartVisitor { public void visit(PiecePart pp); public void visit(Assembly a); }

Listing 28.21. ExplodedCostVisitor.java public class ExplodedCostVisitor implements PartVisitor { private double cost = 0; public double cost() {return cost;}

409

410

ROZDZIAŁ 28. WZORZEC PROJEKTOWY WIZYTATOR

public void visit(PiecePart p) {cost += p.getCost();} public void visit(Assembly a) {} }

Listing 28.22. PartCountVisitor.java import java.util.*; public class PartCountVisitor implements PartVisitor { public void visit(PiecePart p) { itsPieceCount++; String partNumber = p.getPartNumber(); int partNumberCount = 0; if (itsPieceMap.containsKey(partNumber)) { Integer carrier = (Integer)itsPieceMap.get(partNumber); partNumberCount = carrier.intValue(); } partNumberCount++; itsPieceMap.put(partNumber, new Integer(partNumberCount)); } public void visit(Assembly a) { } public int getPieceCount() {return itsPieceCount;} public int getPartNumberCount() {return itsPieceMap.size();} public int getCountForPart(String partNumber) { int partNumberCount = 0; if (itsPieceMap.containsKey(partNumber)) { Integer carrier = (Integer)itsPieceMap.get(partNumber); partNumberCount = carrier.intValue(); } return partNumberCount; }

}

private int itsPieceCount = 0; private HashMap itsPieceMap = new HashMap();

Listing 28.23. TestBOMReport.java import junit.framework.*; import java.util.*; public class TestBOMReport extends TestCase { public TestBOMReport(String name) { super(name); } private PiecePart p1; private PiecePart p2; private Assembly a; public void setUp() { p1 = new PiecePart("997624", "MojaCzęść", 3.20); p2 = new PiecePart("7734", "Piekło", 666);

WZORZEC PROJEKTOWY ACYKLICZNY WIZYTATOR

}

a = new Assembly("5879", "MójKomponent");

public void testCreatePart() { assertEquals("997624", p1.getPartNumber()); assertEquals("MojaCzęść", p1.getDescription()); assertEquals(3.20, p1.getCost(), .01); } public void testCreateAssembly() { assertEquals("5879", a.getPartNumber()); assertEquals("MójKomponent", a.getDescription()); } public void testAssembly() { a.add(p1); a.add(p2); Iterator i = a.getParts(); PiecePart p = (PiecePart)i.next(); assertEquals(p, p1); p = (PiecePart)i.next(); assertEquals(p, p2); assert(i.hasNext() == false); } public void testAssemblyOfAssemblies() { Assembly subAssembly = new Assembly("1324", "SubAssembly"); subAssembly.add(p1); a.add(subAssembly);

}

Iterator i = a.getParts(); assertEquals(subAssembly, i.next());

private boolean p1Found = false; private boolean p2Found = false; private boolean aFound = false; public void testVisitorCoverage() { a.add(p1); a.add(p2); a.accept(new PartVisitor(){ public void visit(PiecePart p) { if (p == p1) p1Found = true; else if (p == p2) p2Found = true; } public void visit(Assembly assy) { if (assy == a) aFound = true; }

}

}); assert(p1Found); assert(p2Found); assert(aFound);

411

412

ROZDZIAŁ 28. WZORZEC PROJEKTOWY WIZYTATOR

private Assembly cellphone; void setUpReportDatabase() { cellphone = new Assembly("CP-7734", "Telefon komórkowy"); PiecePart display = new PiecePart("DS-1428", "Wyświetlacz LCD", 14.37); PiecePart speaker = new PiecePart("SP-92", "Głośnik", 3.50); PiecePart microphone = new PiecePart("MC-28", "Mikrofon", 5.30); PiecePart cellRadio = new PiecePart("CR-56", "Radioodbiornik", 30); PiecePart frontCover = new PiecePart("FC-77", "Przednia pokrywa", 1.4); PiecePart backCover = new PiecePart("RC-77", "Tylna pokrywa", 1.2); Assembly keypad = new Assembly("KP-62", "Klawiatura"); Assembly button = new Assembly("B52", "Przycisk"); PiecePart buttonCover = new PiecePart("CV-15", "Pokrywa", .5); PiecePart buttonContact = new PiecePart("CN-2", "Styk", 1.2); button.add(buttonCover); button.add(buttonContact); for (int i=0; i<15; i++) keypad.add(button); cellphone.add(display); cellphone.add(speaker); cellphone.add(microphone); cellphone.add(cellRadio); cellphone.add(frontCover); cellphone.add(backCover); cellphone.add(keypad); } public void testExplodedCost() { setUpReportDatabase(); ExplodedCostVisitor v = new ExplodedCostVisitor(); cellphone.accept(v); assertEquals(81.27, v.cost(), .001); }

}

public void testPartCount() { setUpReportDatabase(); PartCountVisitor v = new PartCountVisitor(); cellphone.accept(v); assertEquals(36, v.getPieceCount()); assertEquals(8, v.getPartNumberCount()); assertEquals("DS-1428", 1, v.getCountForPart("DS-1428")); assertEquals("SP-92", 1, v.getCountForPart("SP-92")); assertEquals("MC-28", 1, v.getCountForPart("MC-28")); assertEquals("CR-56", 1, v.getCountForPart("CR-56")); assertEquals("RC-77", 1, v.getCountForPart("RC-77")); assertEquals("CV-15", 15, v.getCountForPart("CV-15")); assertEquals("CN-2", 15, v.getCountForPart("CN-2")); assertEquals("Bob", 0, v.getCountForPart("Bob")); }

Inne zastosowania wzorca projektowego Wizytator Ogólnie rzecz biorąc, wzorzec projektowy Wizytator może być używany w dowolnej aplikacji korzystającej ze struktury danych, która ma być interpretowana na różne sposoby. Kompilatory często tworzą pośrednie struktury danych reprezentujące poprawny pod względem składni kod źródłowy. Te struktury danych są następnie wykorzystywane do generowania skompilowanego kodu. Można sobie wyobrazić zastosowanie klas-wizytatorów dla różnych typów procesorów bądź mechanizmów optymalizacji. Można sobie również wyobrazić klasę-wizytatora, która przekształca pośrednią strukturę danych na listę odsyłaczy lub nawet na diagram UML.

WZORZEC PROJEKTOWY DEKORATOR

413

W wielu aplikacjach wykorzystywane są konfiguracyjne struktury danych. Można sobie wyobrazić różne podsystemy aplikacji inicjujące się na podstawie danych konfiguracyjnych w wyniku „inspekcji” przeprowadzanych za pomocą właściwych wizytatorów. W każdym przypadku, gdy są używane wizytatory, wykorzystywana struktura danych jest niezależna od zastosowań, do których została użyta. Można tworzyć nowe wizytatory, zmieniać istniejące i wdrażać w instalacjach bez konieczności ponownej kompilacji lub ponownego wdrażania istniejących struktur danych. Na tym polega siła wzorca projektowego Wizytator.

Wzorzec projektowy Dekorator5 Wzorzec projektowy Wizytator pozwala dodawać nowe metody do istniejących hierarchii klas bez modyfikowania tych hierarchii. Innym wzorcem projektowym, który pozwala osiągnąć podobny efekt, jest Dekorator (ang. Decorator). Rozważmy ponownie hierarchię klas Modem z rysunku 28.1. Wyobraźmy sobie, że mamy aplikację, z której korzysta wielu użytkowników. Każdy użytkownik, siedząc przy swoim komputerze, może zażądać od systemu połączenia z innym komputerem za pomocą modemu podłączonego do komputera. Niektórzy użytkownicy lubią słyszeć, jak modem wybiera numer. Inni wolą, jeśli modem nie wydaje żadnych dźwięków. Moglibyśmy zaimplementować tę funkcjonalność za pośrednictwem pytania o preferencje użytkowników w każdym miejscu w kodzie, w którym modem wybiera numer. Jeśli użytkownik chce słyszeć modem, ustawiamy wysoką wartość siły głosu. W przeciwnym razie wyłączamy głośnik. ... Modem m = user.getModem(); if (user.wantsLoudDial()) m.setVolume(11); // to o jeden więcej niż 10, prawda? m.dial(...); ...

Widmo oglądania tego fragmentu kodu powielonego setki razy w aplikacji wywołuje obrazy 80-godzinnych tygodni i haniebnych sesji debugowania. To jest coś, czego należy unikać. Inną możliwością mogłoby być ustawienie flagi wewnątrz obiektu modem. Metoda dial mogłaby sprawdzać tę flagę i odpowiednio ustawiać głośność. ... public class HayesModem implements Modem { private boolean wantsLoudDial = false;

}

public void dial(...) { if (wantsLoudDial) { setVolume(11); } ... } ...

To lepsze rozwiązanie, ale nadal wymaga powielania kodu dla każdej pochodnej klasy Modem. Autorzy nowych pochodnych klasy Modem będą musieli pamiętać o konieczności replikacji tego kodu. Poleganie na pamięci programistów jest jednak bardzo ryzykowne.

5

[GOF95].

414

ROZDZIAŁ 28. WZORZEC PROJEKTOWY WIZYTATOR

Problem można by rozwiązać, stosując wzorzec projektowy Metoda szablonowa6. W tym celu należałoby zmodyfikować typ Modem z interfejsu na klasę, zadeklarować w niej składową wantsLoudDial i sprawdzać tę składową w metodzie dial przed wywołaniem metody dialForReal. ... public abstract class Modem { private boolean wantsLoudDial = false; public void dial(...) { if (wantsLoudDial) { setVolume(11); } dialForReal(...) } }

public abstract void dialForReal(...);

To rozwiązanie jest jeszcze lepsze, ale po co mielibyśmy modyfikować klasę Modem z powodu kaprysów użytkownika? Z jakiego powodu klasa Modem ma „wiedzieć” o głośnym wybieraniu numerów? W takim przypadku trzeba by ją modyfikować za każdym razem, gdy użytkownik przedstawi inne dziwne żądania — na przykład wylogowania się przed rozłączeniem. Także w tym przypadku do głosu dochodzi zasada otwarte-zamknięte (CCP). Chcemy oddzielić od siebie te elementy, które zmieniają się z różnych powodów. Możemy także powołać się na zasadę pojedynczej odpowiedzialności, ponieważ potrzeba głośnego wybierania numerów nie ma nic wspólnego z wewnętrznymi metodami klasy Modem i dlatego nie powinna być częścią klasy Modem. Te problemy rozwiązuje zastosowanie wzorca projektowego Dekorator poprzez stworzenie zupełnie nowej klasy o nazwie LoudDialModem. Klasa LoudDialModem dziedziczy po klasie Modem i deleguje wywołania do zawartego w niej egzemplarza klasy Modem. Przed delegowaniem przechwytuje funkcję dial i ustawia opcję głośnego wybierania numeru. Strukturę wzorca pokazano na rysunku 28.5.

Rysunek 28.5. Wzorzec projektowy Dekorator — klasa LoudDialModem

6

Patrz „Metoda szablonowa” w rozdziale 14.

WZORZEC PROJEKTOWY DEKORATOR

415

Teraz decyzję o głośnym wybieraniu numeru można podjąć w jednym miejscu. Jeśli użytkownik poprosi o głośne wybieranie numeru w ramach swoich preferencji, to w tym miejscu w kodzie można utworzyć egzemplarz klasy LoudDialModem i przekazać do niego obiekt modemu użytkownika. Obiekt LoudDialModem będzie przekazywał wszystkie wywołania do modemu użytkownika, zatem użytkownik nie zauważy żadnej różnicy. Jednak w przypadku wywołania metody dial przed oddelegowaniem jej do modemu użytkownika najpierw nastąpi ustawienie trybu głośnego wybierania numeru. W tym przypadku klasa LoudDialModem może spełniać rolę modemu użytkownika bez wpływu na inne części systemu. Odpowiedni kod zaprezentowano na listingach od 28.24 do 28.27. Listing 28.24. Modem.java public interface Modem { public void dial(String pno); public void setSpeakerVolume(int volume); public String getPhoneNumber(); public int getSpeakerVolume(); }

Listing 28.25. HayesModem.java public class HayesModem implements Modem { public void dial(String pno) { itsPhoneNumber = pno; } public void setSpeakerVolume(int volume) { itsSpeakerVolume = volume; } public String getPhoneNumber() { return itsPhoneNumber; } public int getSpeakerVolume() { return itsSpeakerVolume; }

}

private String itsPhoneNumber; private int itsSpeakerVolume;

Listing 28.26. LoudDialModem.java public class LoudDialModem implements Modem { public LoudDialModem(Modem m) { itsModem = m; } public void dial(String pno) { itsModem.setSpeakerVolume(10); itsModem.dial(pno); } public void setSpeakerVolume(int volume)

416

ROZDZIAŁ 28. WZORZEC PROJEKTOWY WIZYTATOR

{ }

itsModem.setSpeakerVolume(volume);

public String getPhoneNumber() { return itsModem.getPhoneNumber(); } public int getSpeakerVolume() { return itsModem.getSpeakerVolume();

}

} private Modem itsModem;

Listing 28.27. ModemDecoratorTest.java import junit.framework.*; public class ModemDecoratorTest extends TestCase { public ModemDecoratorTest(String name) { super(name); } public void testCreateHayes() { Modem m = new HayesModem(); assertEquals(null, m.getPhoneNumber()); m.dial("5551212"); assertEquals("5551212", m.getPhoneNumber()); assertEquals(0, m.getSpeakerVolume()); m.setSpeakerVolume(10); assertEquals(10, m.getSpeakerVolume()); } public void testLoudDialModem() { Modem m = new HayesModem(); Modem d = new LoudDialModem(m); assertEquals(null, d.getPhoneNumber()); assertEquals(0, d.getSpeakerVolume()); d.dial("5551212"); assertEquals("5551212", d.getPhoneNumber()); assertEquals(10, d.getSpeakerVolume()); }

}

Wiele dekoratorów Czasami w tej samej hierarchii mogą występować dwa lub więcej dekoratorów. Na przykład możemy „udekorować” hierarchię Modem klasą LogoutExitModem, która wysyła ciąg 'exit' w przypadku wywołania metody Hangup. W drugim dekoratorze trzeba by zdublować kod odpowiedzialny za delegację, który wcześniej napisaliśmy w klasie LoudDialModem. Aby wyeliminować ten zdublowany kod, możemy stworzyć nową klasę ModemDecorator dostarczającą kod odpowiedzialny za delegację. W tym przypadku właściwe dekoratory mogą dziedziczyć po klasie ModemDecorator i przesłaniać tylko te metody, których potrzebują. Odpowiednią strukturę pokazano na rysunku 28.6 oraz na listingach 28.28 i 28.29.

WZORZEC PROJEKTOWY DEKORATOR

Rysunek 28.6. Klasa ModemDecorator Listing 28.28. ModemDecorator.java public class ModemDecorator implements Modem { public ModemDecorator(Modem m) { itsModem = m; } public void dial(String pno) { itsModem.dial(pno); } public void setSpeakerVolume(int volume) { itsModem.setSpeakerVolume(volume); } public String getPhoneNumber() { return itsModem.getPhoneNumber(); } public int getSpeakerVolume() { return itsModem.getSpeakerVolume(); } protected Modem getModem() { return itsModem; } }

private Modem itsModem;

417

418

ROZDZIAŁ 28. WZORZEC PROJEKTOWY WIZYTATOR

Listing 28.29. LoudDialModem.java public class LoudDialModem extends ModemDecorator { public LoudDialModem(Modem m) { super(m); } public void dial(String pno) { getModem().setSpeakerVolume(10); getModem().dial(pno); } }

Wzorzec projektowy Obiekt rozszerzenia Jeszcze innym sposobem na dodanie funkcji do hierarchii klas bez zmiany tej hierarchii jest zastosowanie wzorca projektowego Obiekt rozszerzenia (ang. Extension object) 7. Ten wzorzec jest bardziej złożony od poprzednich, ale także gwarantuje znacznie większe możliwości i jest bardziej elastyczny. Każdy obiekt w hierarchii utrzymuje listę specjalnych obiektów rozszerzenia. Każdy z tych obiektów zawiera metodę, która pozwala wyszukać odpowiedni obiekt rozszerzenia na podstawie nazwy. Obiekt rozszerzenia oferuje metody służące do wykonywania operacji z wyjściowym obiektem hierarchii. Dla przykładu ponownie załóżmy, że mamy do czynienia z systemem oferującym zestawienie materiałów. Chcemy, aby każdy obiekt w tej hierarchii miał możliwość tworzenia swojej reprezentacji XML. Moglibyśmy umieścić metody toXML w hierarchii, ale to powodowałoby naruszenie zasady pojedynczej odpowiedzialności. Umieszczenie kodu odpowiedzialnego za tworzenie zestawień materiałów z kodem dotyczącym generowania XML w jednej klasie może być niezgodne z naszymi celami. Moglibyśmy utworzyć XML z wykorzystaniem wzorca projektowego Wizytator, ale to nie pozwala odseparować kodu generującego XML od każdego typu obiektów odpowiedzialnych za tworzenie zestawień materiałów (ang. Bill of Material — BOM). W przypadku zastosowania wzorca projektowego Wizytator kod generujący XML dla każdej klasy zestawień materiałów znalazłby się w tym samym obiekcie wizytatora. Co zrobić, aby odseparować kod odpowiedzialny za generowanie XML dla każdej klasy BOM i umieścić go w osobnych klasach? Wygodny sposób osiągnięcia tego celu zapewnia wzorzec projektowy Obiekt rozszerzenia. Kod z listingów od 28.30 do 28.41 pokazuje hierarchię klas BOM z dwoma różnymi rodzajami obiektów rozszerzenia. Jeden z tych obiektów rozszerzenia konwertuje obiekty BOM na XML. Inny rodzaj obiektu konwertuje obiekty BOM na ciągi CSV (wartości rozdzielane przecinkami). Dostęp do pierwszego można uzyskać za pomocą metody getExtension("XML"), natomiast do drugiego — za pomocą metody getExtension("CSV"). Strukturę rozwiązania pokazano na rysunku 28.7. Stworzono ją na podstawie kompletnego kodu. Stereotyp <> oznacza interfejs znacznikowy (ang. marker interface) — tzn. interfejs bez metod. Warto zwrócić uwagę, że kodu zamieszczonego na listingach od 28.30 do 28.41 nie napisałem od podstaw. Kod ewoluował w miarę tworzenia nowych przypadków testowych. Wszystkie przypadki testowe zamieszczono na listingu 28.30. Napisano je w takiej kolejności, w jakiej występują na listingu. Każdy przypadek testowy został napisany przed kodem, który spowodował jego przejście. Najpierw pisałem przypadek testowy, który nie przechodził, a następnie kod, który sprawiał, że test zaczynał przechodzić. Kod nigdy nie był bardziej złożony, niż było to niezbędne do tego, by istniejące przypadki testowe zaczęły przechodzić. Tak więc kod stopniowo ewoluował od jednej działającej wersji do drugiej. Wiedziałem, że próbuję zastosować wzorzec projektowy Obiekt rozszerzenia, i skorzystałem z tego zamiaru do przeprowadzenia ewolucji. 7

[PLOPD3], str. 79.

WZORZEC PROJEKTOWY OBIEKT ROZSZERZENIA

Rysunek 28.7. Wzorzec projektowy Obiekt rozszerzenia Listing 28.30. TestBOMXML.java import junit.framework.*; import java.util.*; import org.jdom.*; public class TestBOMXML extends TestCase { public TestBOMXML(String name) { super(name); } private PiecePart p1; private PiecePart p2; private Assembly a; public void setUp() { p1 = new PiecePart("997624", "MojaCzęść", 3.20); p2 = new PiecePart("7734", "Piekło", 666); a = new Assembly("5879", "MójKomponent"); } public void testCreatePart() { assertEquals("997624", p1.getPartNumber()); assertEquals("MojaCzęść", p1.getDescription()); assertEquals(3.20, p1.getCost(), .01); } public void testCreateAssembly() { assertEquals("5879", a.getPartNumber()); assertEquals("MójKomponent", a.getDescription()); } public void testAssembly() { a.add(p1);

419

420

ROZDZIAŁ 28. WZORZEC PROJEKTOWY WIZYTATOR

}

a.add(p2); Iterator i = a.getParts(); PiecePart p = (PiecePart)i.next(); assertEquals(p, p1); p = (PiecePart)i.next(); assertEquals(p, p2); assert(i.hasNext() == false);

public void testAssemblyOfAssemblies() { Assembly subAssembly = new Assembly("1324", "SubAssembly"); subAssembly.add(p1); a.add(subAssembly);

}

Iterator i = a.getParts(); assertEquals(subAssembly, i.next());

public void testPiecePart1XML() { PartExtension e = p1.getExtension("XML"); XMLPartExtension xe = (XMLPartExtension)e; Element xml = xe.getXMLElement(); assertEquals("PiecePart", xml.getName()); assertEquals("997624",xml.getChild("PartNumber").getTextTrim()); assertEquals("MojaCzęść", xml.getChild("Description").getTextTrim()); assertEquals(3.2, Double.parseDouble(xml.getChild("Cost").getTextTrim()), .01); } public void testPiecePart2XML() { PartExtension e = p2.getExtension("XML"); XMLPartExtension xe = (XMLPartExtension)e; Element xml = xe.getXMLElement(); assertEquals("PiecePart", xml.getName()); assertEquals("7734", xml.getChild("PartNumber").getTextTrim()); assertEquals("Piekło", xml.getChild("Description").getTextTrim()); assertEquals(666, Double.parseDouble(xml.getChild("Cost").getTextTrim()), .01); } public void testSimpleAssemblyXML() { PartExtension e = a.getExtension("XML"); XMLPartExtension xe = (XMLPartExtension)e; Element xml = xe.getXMLElement(); assertEquals("Assembly", xml.getName()); assertEquals("5879", xml.getChild("PartNumber").getTextTrim()); assertEquals("MójKomponent", xml.getChild("Description").getTextTrim()); Element parts = xml.getChild("Parts"); List partList = parts.getChildren(); assertEquals(0, partList.size()); } public void testAssemblyWithPartsXML() { a.add(p1); a.add(p2); PartExtension e = a.getExtension("XML"); XMLPartExtension xe = (XMLPartExtension)e; Element xml = xe.getXMLElement(); assertEquals("Assembly", xml.getName()); assertEquals("5879", xml.getChild("PartNumber").getTextTrim()); assertEquals("MójKomponent", xml.getChild("Description").getTextTrim()); Element parts = xml.getChild("Parts"); List partList = parts.getChildren();

WZORZEC PROJEKTOWY OBIEKT ROZSZERZENIA

assertEquals(2, partList.size()); Iterator i = partList.iterator(); Element partElement = (Element)i.next(); assertEquals("PiecePart", partElement.getName()); assertEquals("997624", partElement.getChild("PartNumber").getTextTrim());

}

partElement = (Element)i.next(); assertEquals("PiecePart", partElement.getName()); assertEquals("7734", partElement.getChild("PartNumber").getTextTrim());

public void testPiecePart1toCSV() { PartExtension e = p1.getExtension("CSV"); CSVPartExtension ce = (CSVPartExtension)e; String csv = ce.getCSV(); assertEquals("PiecePart,997624,MojaCzęść,3.2", csv); } public void testPiecePart2toCSV() { PartExtension e = p2.getExtension("CSV"); CSVPartExtension ce = (CSVPartExtension)e; String csv = ce.getCSV(); assertEquals("PiecePart,7734,Piekło,666.0", csv); } public void testSimpleAssemblyCSV() { PartExtension e = a.getExtension("CSV"); CSVPartExtension ce = (CSVPartExtension)e; String csv = ce.getCSV(); assertEquals("Assembly,5879,MójKomponent", csv); } public void testAssemblyWithPartsCSV() { a.add(p1); a.add(p2); PartExtension e = a.getExtension("CSV"); CSVPartExtension ce = (CSVPartExtension)e; String csv = ce.getCSV();

}

assertEquals("Assembly,5879,MójKomponent," + "{PiecePart,997624,MojaCzęść,3.2}," + "{PiecePart,7734,Piekło,666.0}" , csv);

public void testBadExtension() { PartExtension pe = p1.getExtension("ThisStringDoesn'tMatchAnyException"); assert(pe instanceof BadPartExtension); } }

Listing 28.31. Part.java import java.util.*; public abstract class Part { HashMap itsExtensions = new HashMap(); public abstract String getPartNumber();

421

422

ROZDZIAŁ 28. WZORZEC PROJEKTOWY WIZYTATOR

public abstract String getDescription(); public void addExtension(String extensionType, PartExtension extension) { }

}

itsExtensions.put(extensionType, extension);

public PartExtension getExtension(String extensionType) { PartExtension pe = (PartExtension) itsExtensions.get(extensionType); if (pe == null) pe = new BadPartExtension(); return pe; }

Listing 28.32. PartExtension.java public interface PartExtension { }

Listing 28.33. PiecePart.java public class PiecePart extends Part { public PiecePart(String partNumber, String description, double cost) { itsPartNumber = partNumber; itsDescription = description; itsCost = cost; addExtension("CSV", new CSVPiecePartExtension(this)); addExtension("XML", new XMLPiecePartExtension(this)); } public String getPartNumber() { return itsPartNumber; } public String getDescription() { return itsDescription; } public double getCost() { return itsCost; }

}

private String itsPartNumber; private String itsDescription; private double itsCost;

Listing 28.34. Assembly.java import java.util.*; public class Assembly extends Part { public Assembly(String partNumber, String description) { itsPartNumber = partNumber; itsDescription = description; addExtension("CSV", new CSVAssemblyExtension(this));

WZORZEC PROJEKTOWY OBIEKT ROZSZERZENIA

}

addExtension("XML", new XMLAssemblyExtension(this));

public void add(Part part) { itsParts.add(part); } public Iterator getParts() { return itsParts.iterator(); } public String getPartNumber() { return itsPartNumber; } public String getDescription() { return itsDescription; }

}

private List itsParts = new LinkedList(); private String itsPartNumber; private String itsDescription;

Listing 28.35. XMLPartExtension.java import org.jdom.*; public interface XMLPartExtension extends PartExtension { public Element getXMLElement(); }

Listing 28.36. XMLPiecePartException.java import org.jdom.*; public class XMLPiecePartExtension implements XMLPartExtension { public XMLPiecePartExtension(PiecePart part) { itsPiecePart = part; }

}

public Element getXMLElement() { Element e = new Element("PiecePart"); e.addContent( new Element("PartNumber").setText( itsPiecePart.getPartNumber())); e.addContent( new Element("Description").setText( itsPiecePart.getDescription())); e.addContent( new Element("Cost").setText( Double.toString(itsPiecePart.getCost()))); return e; } private PiecePart itsPiecePart = null;

423

424

ROZDZIAŁ 28. WZORZEC PROJEKTOWY WIZYTATOR

Listing 28.37. XMLAssemblyExtension.java import org.jdom.*; import java.util.*; public class XMLAssemblyExtension implements XMLPartExtension { public XMLAssemblyExtension(Assembly assembly) { itsAssembly = assembly; } public Element getXMLElement() { Element e = new Element("Assembly"); e.addContent(new Element("PartNumber").setText(itsAssembly.getPartNumber())); e.addContent(new Element("Description").setText(itsAssembly.getDescription())); Element parts = new Element("Parts"); e.addContent(parts); Iterator i = itsAssembly.getParts(); while (i.hasNext()) { Part p = (Part) i.next(); PartExtension pe = p.getExtension("XML"); XMLPartExtension xpe = (XMLPartExtension)pe; parts.addContent(xpe.getXMLElement()); } return e; } }

private Assembly itsAssembly = null;

Listing 28.38. CSVPartExtension.java public interface CSVPartExtension extends PartExtension { public String getCSV(); }

Listing 28.39. CSVPiecePartExtension.java public class CSVPiecePartExtension implements CSVPartExtension { private PiecePart itsPiecePart = null; public CSVPiecePartExtension(PiecePart part) { itsPiecePart = part; }

}

public String getCSV() { StringBuffer b = new StringBuffer("PiecePart,"); b.append(itsPiecePart.getPartNumber()); b.append(","); b.append(itsPiecePart.getDescription()); b.append(","); b.append(itsPiecePart.getCost()); return b.toString(); }

WZORZEC PROJEKTOWY OBIEKT ROZSZERZENIA

425

Listing 28.40. CSVAssemblyExtension.java import java.util.Iterator; public class CSVAssemblyExtension implements CSVPartExtension { private Assembly itsAssembly = null; public CSVAssemblyExtension(Assembly assy) { itsAssembly = assy; } public String getCSV() { StringBuffer b = new StringBuffer("Assembly,"); b.append(itsAssembly.getPartNumber()); b.append(","); b.append(itsAssembly.getDescription());

}

}

Iterator i = itsAssembly.getParts(); while (i.hasNext()) { Part p = (Part) i.next(); CSVPartExtension ce = (CSVPartExtension)p.getExtension("CSV"); b.append(",{"); b.append(ce.getCSV()); b.append("}"); } return b.toString();

Listing 28.41. BadPartExtension.java public class BadPartExtension implements PartExtension { }

Zwróćmy uwagę, że obiekty rozszerzenia są ładowane do każdego obiektu BOM za pomocą konstruktora tego obiektu. To oznacza, że do pewnego stopnia obiekty BOM w dalszym ciągu zależą od klas XML i CSV. Gdyby zaistniała potrzeba przerwania nawet tej niewielkiej zależności, można by utworzyć obiekt-fabrykę8 tworzący obiekty BOM i ładujący ich rozszerzenia. Możliwość ładowania obiektów rozszerzenia do obiektów gwarantuje olbrzymią elastyczność. W zależności od stanu systemu można wstawiać lub usuwać z obiektu obiekty rozszerzenia. Bardzo łatwo można dać się ponieść tej elastyczności. Jednak w większości przypadków nie jest to konieczne. Pierwotna implementacja metody PiecePart.getExtention(String extensionType) miała następującą postać: public PartExtension getExtension(String extensionType) {

}

if (extensionType.equals("XML")) return new XMLPiecePartExtension(this); else if (extensionType.equals("CSV")) return new XMLAssemblyExtension(this); return new BadPartExtension();

Nie byłem szczególnie zadowolony z tej implementacji, ponieważ była praktycznie identyczna z kodem metody Assembly.getExtension. Rozwiązanie z konstrukcją HashMap w klasie Part pozwala uniknąć dublowania kodu i jest po prostu prostsze. Każdy, kto będzie czytał kod, z łatwością zorientuje się, jak można uzyskać dostęp do obiektów rozszerzenia. 8

Patrz „Wzorzec projektowy Fabryka” w rozdziale 21.

426

ROZDZIAŁ 28. WZORZEC PROJEKTOWY WIZYTATOR

Wniosek Rodzina wzorców projektowych Wizytator dostarcza kilku sposobów zmodyfikowania działania hierarchii klas bez konieczności zmiany tych klas. Zatem wzorce te pozwalają nam zachować zgodność z zasadą OCP. Dodatkowo zapewniają one mechanizmy segregacji różnego rodzaju funkcjonalności. To pozwala uniknąć zaśmiecania klas wieloma różnymi funkcjami. W ten sposób wzorce z rodziny Wizytator ułatwiają zachowanie zgodności z zasadą CCP. Nie ulega wątpliwości, że struktura wzorców projektowych Wizytator jest również zgodna z zasadami SRP, LSP i DIP. Wzorce projektowe z rodziny Wizytator są kuszące. Łatwo jednak wpaść w pułapkę stosowania ich w sposób przesadny. Należy z nich korzystać wtedy, gdy są pomocne, ale trzeba zachować zdrowy rozsądek przy ocenie, kiedy zastosowanie określonego wzorca jest uzasadnione. Bardzo często problemy, które można rozwiązać za pomocą wzorca projektowego Wizytator, można również rozwiązać w prostszy sposób.

Przypomnienie Po przeczytaniu niniejszego rozdziału możesz powrócić do rozdziału 9. i spróbować rozwiązać problem porządkowania figur.

Bibliografia 1. Gamma, et al., Design Patterns, Reading, MA: Addison-Wesley, 1995. 2. Robert C. Martin, et al., Pattern Languages of Program Design 3, Reading, MA: Addison-Wesley, 1998.

R OZDZIAŁ 29

Wzorzec projektowy Stan

Stan bez możliwości zmiany pozostaje bez środków do jego ochrony — Edmund Burke (1729 – 1797)

Automaty stanów skończonych należą do najbardziej przydatnych abstrakcji w arsenale oprogramowania. Zapewniają prosty i elegancki sposób badania i definiowania zachowania złożonych systemów. Stanowią również silną strategię implementacji, która jest łatwa do zrozumienia i modyfikacji. Używam ich na wszystkich poziomach systemu — począwszy od kontrolowania wysokopoziomowego GUI1, do protokołów komunikacyjnych najniższego poziomu. Ich zastosowanie jest niemal uniwersalne.

Przegląd informacji o automatach stanów skończonych Działanie prostego automatu stanów skończonych (ang. finite state machine — FSM) można zaobserwować na przykładzie kołowrotka w metrze. Jest to urządzenie sterujące bramką, przez którą pasażerowie uzyskują dostęp do wagonów metra. Na rysunku 29.1 pokazano schemat maszyny FSM sterującej kołowrotkiem w metrze. Jest to tzw. diagram przejść stanów (state transition diagram — STD)2. 1

Patrz „Architektura menedżera zadań” w rozdziale 30.

2

Patrz „Stany i wewnętrzne przejścia”, „Przejścia pomiędzy stanami” oraz „Stany zagnieżdżone” w dodatku B.

428

ROZDZIAŁ 29. WZORZEC PROJEKTOWY STAN

Rysunek 29.1. Prosty automat stanów skończonych kołowrotu

Diagramy STD składają się co najmniej z czterech części. Pęcherzyki reprezentują stany. Połączenia pomiędzy stanami są reprezentowane przez strzałki zwane przejściami. Przejścia są oznaczone za pomocą nazwy zdarzenia, za którym występuje nazwa akcji. Diagram STD z rysunku 29.1 należy czytać w następujący sposób:  Jeżeli maszyna jest w stanie Zablokowany i wystąpi zdarzenie moneta, to następuje przejście do stanu

Odblokowany i wywołanie akcji odblokowanie.  Jeżeli maszyna jest w stanie Odblokowany i wystąpi zdarzenie przejście, to następuje przejście do

stanu Zablokowany i wywołanie akcji zablokowanie. Te dwa zdania całkowicie opisują schemat pokazany na rysunku 29.1. Każde zdanie opisuje jedną strzałkę przejścia w kontekście czterech elementów: stan początkowy, zdarzenie inicjujące przejście, stan końcowy oraz akcja do wykonania. Zdania opisujące przejścia można zredukować do tabeli nazywanej tabelą przejść pomiędzy stanami (ang. state transition table — STT). Może ona wyglądać następująco: Zablokowany Odblokowany

moneta przejście

Odblokowany Zablokowany

odblokowanie zablokowanie

W jaki sposób maszyna działa? Załóżmy, że maszyna FSM zaczyna swoje życie w stanie Zablokowany. Pasażer podchodzi do kołowrotu i wrzuca monetę. To sprawia, że w oprogramowaniu powstaje zdarzenie moneta. Pierwsze przejście w tabeli STT wskazuje, że jeśli jesteśmy w stanie Zablokowany i otrzymamy zdarzenie moneta, to powinniśmy przejść do stanu Odblokowany i wywołać akcję odblokowanie. Zatem oprogramowanie zmienia stan na Odblokowany i wywołuje funkcję odblokowanie. Pasażer przechodzi przez bramkę, co powoduje, że oprogramowanie wykrywa zdarzenie przejście. Ponieważ maszyna FSM jest w stanie Odblokowany, to zostaje wywołane drugie przejście, co powoduje zmianę stanu na Zablokowany i wywołanie akcji zablokowanie. Wyraźnie widać, że diagram STD i tabela STT są prostymi i eleganckimi opisami zachowań maszyny. Ale są one również świetnymi narzędziami projektowymi. Jedną z korzyści, jakie przynosi ich zastosowanie, jest łatwość, z jaką projektant może wykryć dziwne i nieobsłużone warunki. Dla przykładu spróbujmy przeanalizować każdy ze stanów z rysunku 29.1 i zastosować oba znane zdarzenia. Zwróćmy uwagę, że nie istnieje zmiana stanu dla zdarzenia moneta w stanie Odblokowany ani nie ma zmiany stanu dla zdarzenia przejście w stanie Zablokowany. Te braki są poważnymi błędami logicznymi i bardzo często są źródłem błędów programistów. Programiści często rozważają prawidłowy przebieg wydarzeń staranniej niż te sytuacje, które są uznawane za nieprawidłowe. Diagram STD lub tabela STT pozwala programiście łatwo sprawdzić, czy projekt obsługuje wszystkie zdarzenia w każdym stanie. Możemy poprawić maszynę FSM, dodając potrzebne przejścia pomiędzy stanami. Nową wersję pokazano na rysunku 29.2. Tutaj widzimy, że jeśli pasażer wrzucił więcej monet po pierwszej, to urządzenie pozostaje w stanie Zablokowany i wyświetla niewielki komunikat „dziękuję”, który zachęca pasażera do dalszego wrzucania monet3. Ponadto jeśli pasażerowi uda się przejść przez bramkę, gdy jest ona zablokowana (być może z wykorzystaniem młotka), to maszyna FSM pozostanie w stanie Zablokowany i zainicjuje alarm dźwiękowy.

3

:^)

TECHNIKI IMPLEMENTACJI

429

Rysunek 29.2. Maszyna FSM kołowrotu z uwzględnieniem nadzwyczajnych zdarzeń

Techniki implementacji Zagnieżdżone instrukcje Switch/Case Istnieje wiele różnych strategii implementacji maszyn FSM. Pierwszy i najbardziej bezpośredni polega na wykorzystaniu zagnieżdżonych instrukcji switch-case. Przykładową implementację zaprezentowano na listingu 29.1. Listing 29.1. Turnstile.java (implementacja z wykorzystaniem zagnieżdżonych instrukcji switch-case) package com.objectmentor.PPP.Patterns.State.turnstile; public class Turnstile {

// Stany

public static final int LOCKED = 0; public static final int UNLOCKED = 1;

// Zdarzenia

public static final int COIN = 0; public static final int PASS = 1; /*private*/ int state = LOCKED; private TurnstileController turnstileController; public Turnstile(TurnstileController action) { turnstileController = action; } public void event(int event) { switch (state) { case LOCKED: switch (event) { case COIN: state = UNLOCKED; turnstileController.unlock(); break; case PASS: turnstileController.alarm(); break; } break; case UNLOCKED: switch (event) { case COIN: turnstileController.thankyou(); break; case PASS:

430

ROZDZIAŁ 29. WZORZEC PROJEKTOWY STAN

state = LOCKED; turnstileController.lock(); break;

}

}

}

} break;

Zagnieżdżona instrukcja switch-case dzieli kod na cztery wzajemnie rozłączne strefy, z których każda odpowiada jednej zmianie stanu wewnątrz diagramu STD. Każda zmiana strefy zmienia stan zgodnie z wymaganiami, po czym wywołuje odpowiednią akcję. A zatem strefa dla stanów Lcked i Coin zmienia stan na Unlocked i wywołuje akcję unlock. Istnieje kilka interesujących aspektów tego kodu, które nie mają nic wspólnego z zagnieżdżoną instrukcją switch-case. Aby zrozumieć ich sens, należy zapoznać się z testem jednostkowym, który wykorzystałem do sprawdzenia tego kodu (patrz listingi 29.2 i 29.3). Listing 29.2. TurnstileController.java package com.objectmentor.PPP.Patterns.State.turnstile; public interface TurnstileController { public void lock(); public void unlock(); public void thankyou(); public void alarm(); }

Listing 29.3. TestTurnstile.java package com.objectmentor.PPP.Patterns.State.turnstile; import junit.framework.*; import junit.swingui.TestRunner; public class TestTurnstile extends TestCase { public static void main(String[] args) { TestRunner.main(new String[]{"TestTurnstile"}); } public TestTurnstile(String name) { super(name); private Turnstile t; private boolean lockCalled = false; private boolean unlockCalled = false; private boolean thankyouCalled = false; private boolean alarmCalled = false; public void setUp() { TurnstileController controllerSpoof = new TurnstileController() { public void lock() {lockCalled = true;} public void unlock() {unlockCalled = true;} public void thankyou() {thankyouCalled = true;} public void alarm() {alarmCalled = true;} }; t = new Turnstile(controllerSpoof); } public void testInitialConditions()

TECHNIKI IMPLEMENTACJI

{ }

431

assertEquals(Turnstile.LOCKED, t.state);

public void testCoinInLockedState() { t.state = Turnstile.LOCKED; t.event(Turnstile.COIN); assertEquals(Turnstile.UNLOCKED, t.state); assert(unlockCalled); } public void testCoinInUnlockedState() { t.state = Turnstile.UNLOCKED; t.event(Turnstile.COIN); assertEquals(Turnstile.UNLOCKED, t.state); assert(thankyouCalled); } public void testPassInLockedState() { t.state = Turnstile.LOCKED; t.event(Turnstile.PASS); assertEquals(Turnstile.LOCKED, t.state); assert(alarmCalled); } public void testPassInUnlockedState() { t.state = Turnstile.UNLOCKED; t.event(Turnstile.PASS); assertEquals(Turnstile.LOCKED, t.state); assert(lockCalled); } }

Zasięg zmiennej stanu. Zwróćmy uwagę na cztery funkcje o nazwach testCoinInLockedState, testCoinInUnlockedState, testPassInLockedState oraz testPassInUnlockedState. Te funkcje oddzielnie sprawdzają cztery przejścia pomiędzy stanami maszyny FSM. W tym celu ustawiają wartość zmiennej state klasy Turnstile na stan, który chcą sprawdzić, a następnie wywołują zdarzenie, które ma być zweryfikowane. Aby zmienna state mogła być dostępna dla testu, nie może być prywatna. Z tego powodu została zadeklarowana na poziomie pakietu. Dodatkowo umieściłem komentarz, który wskazuje na to, że zgodnie z moim zamiarem zmienna miała być prywatna. Zgodnie z zasadami programowania obiektowego wszystkie zmienne egzemplarza klasy powinny być prywatne. Jawnie zignorowałem tę regułę, a przez to naruszyłem hermetyzację klasy Turnstile. Czy na pewno? Bez żadnych wątpliwości wolałbym zadeklarować zmienną state jako prywatną. Jednak gdybym to zrobił, to kod testowy nie miałby możliwości ustawienia tej zmiennej. Mógłbym stworzyć odpowiednie metody setState i getState o zasięgu pakietu, ale to wydaje się śmieszne. Nie próbuję udostępniać zmiennej state żadnej klasie innej niż TestTurnstile. Dlaczego zatem miałbym tworzyć metody dostępowe get i set, które sugerują, że wszystkie klasy w zasięgu pakietu mogą pobierać wartość tej zmiennej i ją ustawiać? Jedną ze słabości języka Java jest brak odpowiednika słowa kluczowego friend z języka C++. Gdyby w Javie była instrukcja friend, to mógłbym zadeklarować zmienną state ze słowem kluczowym private, a następnie zadeklarować klasę TestTurnstile jako „zaprzyjaźnioną” z klasą Turnstile. Jednak w obecnym stanie rzeczy uważam, że zadeklarowanie zmiennej state na poziomie pakietu i skorzystanie z komentarza w celu zadeklarowania moich zamiarów jest najlepszą z możliwości.

432

ROZDZIAŁ 29. WZORZEC PROJEKTOWY STAN

Testowanie akcji. Zwróćmy uwagę na interfejs TurnstileController z listingu 29.2. Zdefiniowano go specjalnie po to, aby klasa TestTurnstile mogła zadbać, by obiekt klasy Turnstile wywołał właściwe metody akcji we właściwej kolejności. Bez tego interfejsu zapewnienie poprawnego działania maszyny stanów byłoby znacznie trudniejsze. Jest to jeden z przykładów wpływu testowania na projekt. Gdybym po prostu napisał kod maszyny stanów, nie myśląc o testowaniu, to jest mało prawdopodobne, że stworzyłbym interfejs TurnstileController. To byłoby niefortunne. Interfejs TurnstileController świetnie oddziela logikę maszyny stanów skończonych od akcji, które musi wykonać. Inna maszyna FSM, korzystająca z zupełnie innej logiki, może skorzystać z interfejsu TurnstileController bez żadnego wpływu na inne klasy. Potrzeba stworzenia kodu testu, który sprawdza każdą jednostkę oddzielnie, zmusza nas do rozdzielania kodu w taki sposób, o jakim w przeciwnym razie nawet byśmy nie pomyśleli. Zatem możliwość testowania jest siłą, która kieruje projekt do lepszego stanu (z mniejszą liczbą sprzężeń). Koszty i korzyści wynikające z implementacji bazującej na zagnieżdżonej instrukcji switch-case. Dla prostych maszyn stanów implementacja bazująca na zagnieżdżonej instrukcji switch-case jest zarówno elegancka, jak i wydajna. Wszystkie stany i zdarzenia są widoczne na jednej lub dwóch stronach kodu. Jednak w przypadku większych maszyn FSM sytuacja się zmienia. W maszynie stanów obejmującej kilkadziesiąt stanów i zdarzeń kod zawiera wiele stron złożonych z instrukcji case. Brakuje wygodnych lokalizatorów, które pomogłyby zorientować się, która część maszyny stanów jest odczytywana. Utrzymywanie długiej listy zagnieżdżonych instrukcji switch-case może być zadaniem bardzo trudnym i stwarzającym wiele okazji do popełnienia błędów. Kolejnym kosztem stosowania zagnieżdżonych instrukcji switch-case jest brak dobrej separacji pomiędzy logiką maszyny stanów skończonych a kodem implementującym akcje. Tę separację zaprezentowano na listingu 29.1, ponieważ akcje zostały zaimplementowane w pochodnej klasy TurnstileController. Jednak w większości maszyn FSM zaimplementowanych za pomocą zagnieżdżonych instrukcji switch-case, z jakimi się spotkałem, implementacja akcji jest „zaszyta” w instrukcjach case. W kodzie z listingu 29.1 to jest nadal możliwe.

Interpretacja tabeli przejść Bardzo popularną techniką implementacji maszyn FSM jest utworzenie tabeli danych opisującej przejścia. Tabela jest interpretowana przez „silnik” obsługujący zdarzenia. Silnik wyszukuje przejście odpowiadające zdarzeniu, wywołuje odpowiednią akcję, po czym zmienia stan. Kod tworzący tabelę przejść zamieszczono na listingu 29.4, natomiast silnik przejść zaprezentowano na listingu 29.5. Oba te listingi są fragmentami pełnej implementacji z listingu 29.12 z końca tego rozdziału. Listing 29.4. Utworzenie tabeli przejść kołowrotu public Turnstile(TurnstileController action) { turnstileController = action; addTransition(LOCKED, COIN, UNLOCKED, unlock() ); addTransition(LOCKED, PASS, LOCKED, alarm() ); addTransition(UNLOCKED, COIN, UNLOCKED, thankyou()); addTransition(UNLOCKED, PASS, LOCKED, lock() ); }

Listing 29.5. Silnik przejść public void event(int event) { for (int i = 0; i < transitions.size(); i++) { Transition transition = (Transition) transitions.elementAt(i); if (state == transition.currentState && event == transition.event) {

WZORZEC PROJEKTOWY STAN

}

}

}

433

state = transition.newState; transition.action.execute();

Koszty i korzyści wynikające z implementacji bazującej na interpretacji tabeli przejść. Jedną z potężnych zalet implementacji bazującej na interpretacji tabeli przejść jest to, że tabela przejść przypomina tabelę zmian stanów w kanonicznej postaci. Cztery linijki wywołania funkcji addTransaction są bardzo łatwe do zrozumienia. Logika maszyny stanów znajduje się w jednym miejscu i nie jest zanieczyszczona implementacją akcji. Utrzymywanie maszyny stanów skończonych w tej postaci jest bardzo proste w porównaniu z implementacją opartą na zagnieżdżonej instrukcji switch-case. Aby dodać nowe przejście, wystarczy dodać nową linijkę addTransition do konstruktora klasy Turnstile. Inną zaletą tego podejścia jest możliwość łatwej zmiany tabeli w czasie działania programu. Pozwala to na dynamiczną modyfikację logiki maszyny stanów. Używałem podobnych mechanizmów w celu „modyfikowania na gorąco” bardzo złożonych maszyn stanów skończonych. Kolejną zaletą jest możliwość tworzenia wielu tabel. W takim przypadku każda tabela może reprezentować inną logikę maszyny FSM. Wspomniane tabele można wybierać w czasie działania programu na podstawie określonych warunków. Wadą tego rozwiązania jest przede wszystkim prędkość. Przeglądanie tabeli przejść wymaga czasu. W przypadku rozbudowanych maszyn stanu może to być znaczący czas. Kolejną wadą jest ilość kodu, który trzeba napisać, aby obsłużyć tabelę. Na listingu 29.12 można zauważyć wiele krótkich funkcji pomocniczych, których celem jest umożliwienie prostego wyrażenia tabeli przejść pomiędzy stanami z listingu 29.4.

Wzorzec projektowy Stan4 Kolejnym sposobem implementacji maszyny stanów skończonych jest zastosowanie wzorca projektowego Stan (ang. State). Ten wzorzec łączy w sobie wydajność zagnieżdżonych instrukcji switch-case z elastycznością interpretacji tabeli przejść. Strukturę rozwiązania przedstawiono na rysunku 29.3. Klasa Turnstile zawiera metody publiczne dla zdarzeń oraz metody chronione dla akcji. Klasa zawiera referencję do interfejsu TurnstileState. Dwie pochodne interfejsu TurnstileState reprezentują dwa stany maszyny FSM.

Rysunek 29.3. Wzorzec projektowy Stan dla kołowrotu

4

[GOF 95], str. 305.

434

ROZDZIAŁ 29. WZORZEC PROJEKTOWY STAN

Kiedy zostanie wywołana jedna z dwóch metod obsługi zdarzeń klasy Turnstile, zdarzenie to jest delegowane do obiektu TurnstileState. Metody interfejsu TurnstileLockedState implementują właściwe akcje dla stanu LOCKED. Metody interfejsu TurnstileUnlockedState implementują właściwe akcje dla stanu UNLOCKED. Zmiana stanu maszyny FSM wymaga przypisania referencji w obiekcie Turnstile do egzemplarza jednej z tych pochodnych. Na listingu 29.6 zamieszczono kod interfejsu TurnstileState oraz jego dwóch pochodnych. Można wyraźnie zobaczyć maszynę stanów, która ma postać czterech metod tych pochodnych. Na przykład metoda coin interfejsu LockedTurnstileState zleca obiektowi Turnstile zmianę stanu na odblokowany, a następnie wywołuje funkcję akcji unlock klasy Turnstile. Listing 29.6. TurnstileState.java interface TurnstileState { void coin(Turnstile t); void pass(Turnstile t); } class LockedTurnstileState implements TurnstileState { public void coin(Turnstile t) { t.setUnlocked(); t.unlock(); } public void pass(Turnstile t) { t.alarm(); } } class UnlockedTurnstileState implements TurnstileState { public void coin(Turnstile t) { t.thankyou(); }

}

public void pass(Turnstile t) { t.setLocked(); t.lock(); }

Klasę Turnstile zamieszczono na listingu 29.7. Zwróćmy uwagę na zmienne statyczne, które przechowują pochodne interfejsu TurnstileState. Klasy te nie mają składowych, dlatego nigdy nie muszą mieć więcej niż jednego egzemplarza. Utrzymywanie egzemplarzy pochodnych interfejsu TurnstileState w zmiennych eliminuje potrzebę tworzenia nowego egzemplarza za każdym razem, gdy zmieni się stan. Zadeklarowanie tych zmiennych jako statycznych eliminuje konieczność tworzenia nowych egzemplarzy pochodnych w przypadku, gdy wystąpi potrzeba istnienia więcej niż jednego egzemplarza klasy Turnstile. Listing 29.7. Turnstile.java public class Turnstile { private static TurnstileState lockedState = new LockedTurnstileState(); private static TurnstileState unlockedState = new UnlockedTurnstileState(); private TurnstileController turnstileController; private TurnstileState state = lockedState;

WZORZEC PROJEKTOWY STAN

435

public Turnstile(TurnstileController action) { turnstileController = action; } public void coin() { state.coin(this); } public void pass() { state.pass(this); } public void setLocked() { state = lockedState; } public void setUnlocked() { state = unlockedState; } public boolean isLocked() { return state == lockedState; } public boolean isUnlocked() { return state == unlockedState; } void thankyou() { turnstileController.thankyou(); } void alarm() { turnstileController.alarm(); } void lock() { turnstileController.lock(); }

}

void unlock() { turnstileController.unlock(); }

Wzorzec projektowy Stan a Strategia. Diagram z rysunku 29.3 bardzo przypomina diagram wzorca projektowego Strategia5. W obydwu występuje klasa kontekstu, oba delegują wywołania do polimorficznej klasy bazowej, która ma kilka pochodnych. Różnica (patrz rysunek 29.4) polega na tym, że w przypadku wzorca Stan pochodne zawierają referencje do obiektu kontekstu. Podstawową funkcją pochodnych jest wykorzystanie tej referencji w celu wybierania i wywoływania metod klasy kontekstu. We wzorcu projektowym Strategia nie występuje ani takie ograniczenie, ani zamiar. Pochodne we wzorcu projektowym Strategia nie muszą zawierać referencji do kontekstu i nie muszą wywoływać metod kontekstu. 5

Patrz „Wzorzec projektowy Strategia” w rozdziale 14.

436

ROZDZIAŁ 29. WZORZEC PROJEKTOWY STAN

Rysunek 29.4. Wzorzec projektowy Stan a Strategia

W związku z tym wszystkie implementacje wzorca projektowego Stan są jednocześnie implementacjami wzorca projektowego Strategia, ale nie wszystkie implementacje wzorca projektowego Strategia są implementacjami wzorca projektowego Stan. Wady i zalety wzorca projektowego Stan. Wzorzec projektowy Stan zapewnia bardzo silną separację pomiędzy akcjami a logiką maszyny stanów. Akcje są implementowane w klasie Context, natomiast logika jest rozproszona za pośrednictwem pochodnych klasy State. W ten sposób można w łatwy sposób zmieniać jedną klasę bez wpływu na drugą. Na przykład z łatwością można skorzystać z akcji klasy Context dla innej logiki stanów poprzez wykorzystanie innych pochodnych klasy State. Można również stworzyć podklasy klasy Context, które modyfikują lub zastępują akcje bez wpływu na logikę pochodnych klasy State. Inną zaletą tej techniki jest jej wysoka wydajność. Rozwiązanie bazujące na wzorcu projektowym Stan jest prawdopodobnie równie wydajne jak implementacja oparta na zagnieżdżonych konstrukcjach switch-case. Dzięki temu zyskujemy elastyczność wynikającą z zastosowania tabeli przejść, a jednocześnie zapewniamy wydajność właściwą sposobowi bazującemu na zagnieżdżonych konstrukcjach switch-case. Wady stosowania wzorca Stan są dwóch rodzajów. Po pierwsze, pisanie pochodnych klasy State jest, najdelikatniej mówiąc, żmudne. Pisanie kodu maszyny z 20 stanami może być „paraliżujące” dla umysłu. Po drugie, logika jest rozproszona. Nie ma jednego miejsca, w którym można ją zobaczyć w całości. To sprawia, że kod staje się trudny w utrzymaniu. Przypomina to nieczytelność rozwiązania bazującego na zagnieżdżonych instrukcjach switch-case.

SMC — kompilator maszyny stanów Pracochłonność pisania pochodnych opisujących stany oraz potrzeba występowania jednego miejsca, gdzie można by wyrazić logikę maszyny stanów, skłoniły mnie do napisania kodu kompilatora, który konwertuje tekstową tabelę przejść na klasy niezbędne do zaimplementowania wzorca projektowego Stan. Kompilator jest darmowy. Można go pobrać w witrynie http://www.objectmentor.com. Dane wejściowe dla kompilatora zamieszczono na listingu 29.8. Składnia jest następująca: currentState { event newState action ... }

Cztery linijki na początku opisują nazwę maszyny stanów, nazwę klasy-kontekstu, stan początkowy oraz nazwę wyjątku, który będzie zgłoszony w przypadku nieprawidłowego zdarzenia.

WZORZEC PROJEKTOWY STAN

437

Listing 29.8. Turnstile.sm FSMName Turnstile Context TurnstileActions Initial Locked Exception FSMError { Locked { coin Unlocked unlock pass Locked alarm } Unlocked { coin Unlocked thankyou pass Locked lock } }

Aby skorzystać z kompilatora, trzeba napisać klasę, która deklaruje funkcje opisujące akcje. Nazwę tej klasy określono w linijce Context. Ja nazwałem ją TurnstileActions (patrz listing 29.9). Listing 29.9. TurntstyleActions.java public abstract { public void public void public void public void }

class TurnstileActions lock() {} unlock() {} thankyou() {} alarm() {}

Kompilator generuje klasę, która dziedziczy po kontekście. Nazwa generowanej klasy jest określona w linijce FSMName. Ja nazwałem ją Turnstile. Funkcje opisujące akcje mogły być zaimplementowane w klasie TurnstileActions. Jednak wolałem napisać inną klasę, która dziedziczy z wygenerowanej klasy i implementuje funkcje akcji. To rozwiązanie zamieszczono na listingu 29.10. Listing 29.10. TurnstileFSM.java public class TurnstileFSM extends Turnstile { private TurnstileController controller; public TurnstileFSM(TurnstileController controller) { this.controller = controller; } public void lock() { controller.lock(); } public void unlock() { controller.unlock(); } public void thankyou() { controller.thankyou(); }

438

}

ROZDZIAŁ 29. WZORZEC PROJEKTOWY STAN

public void alarm() { controller.alarm(); }

To wszystko, co trzeba było napisać. Kompilator SMC generuje resztę. Wynikową strukturę pokazano na rysunku 29.5. Nazywamy to trójpoziomową maszyną stanów skończonych6.

Rysunek 29.5. Trójpoziomowa maszyna FSM

Trzy poziomy zapewniają maksymalną elastyczność minimalnym kosztem. Można stworzyć wiele różnych maszyn stanów skończonych w wyniku dziedziczenia po interfejsie TurnstileActions. Możemy także zaimplementować akcje na wiele różnych sposobów poprzez dziedziczenie po klasie Turnstile. Warto zwrócić uwagę, że wygenerowany kod jest całkowicie odizolowany od kodu, który trzeba napisać. Wygenerowanego kodu nigdy nie trzeba modyfikować. Nie trzeba nawet go oglądać. Wymaga on tyle samo uwagi co kod binarny. Wygenerowany kod razem z pozostałym kodem pomocniczym dla tego przykładu można zobaczyć na listingach od 29.13 do 29.15 w punkcie „Listingi” na końcu rozdziału. Wady i zalety zastosowania kompilatora SMC do implementacji wzorca projektowego Stan. Nie ulega wątpliwości, że udało nam się zmaksymalizować korzyści z różnych podejść. Opis maszyny stanów skończonych znajduje się w jednym miejscu i jest łatwy do utrzymania. Logika maszyny stanów skończonych jest mocno odizolowana od implementacji akcji. Dzięki temu obie mogą być zmieniane niezależnie od siebie. Rozwiązanie jest wydajne, eleganckie i wymaga niewiele kodowania. Wadą jest konieczność zastosowania kompilatora SMC. Trzeba zainstalować nowe narzędzie i nauczyć się nim posługiwać. Jednak w tym przypadku instalacja narzędzia przebiega łatwo, a posługiwanie się nim nie powinno przysporzyć trudności (patrz listing 29.16 powyżej). Ponadto narzędzie jest darmowe!

6

[PLoPD1], str. 383.

KIEDY NALEŻY KORZYSTAĆ Z MASZYN STANÓW?

439

Kiedy należy korzystać z maszyn stanów? Osobiście używam maszyn stanów (i kompilatora SMC) dla kilku różnych typów aplikacji.

Wysokopoziomowe strategie obsługi GUI Jednym z celów rewolucji graficznej lat osiemdziesiątych było stworzenie bezstanowych interfejsów do wykorzystania przez ludzi. W tamtych czasach interfejsy komputerów w większości były tekstowe i korzystały z hierarchicznych menu. Łatwo było się zgubić w strukturze menu, nie wiedząc, w jakim stanie jest ekran. Interfejsy GUI pomogły złagodzić ten problem poprzez minimalizację liczby zmian stanów ekranu. W nowoczesnych GUI najwięcej pracy wymaga utrzymywanie wspólnych własności na ekranie przez cały czas i zadbanie o to, aby użytkownicy nie pogubili się z powodu ukrytych stanów. Ironią losu jest to, że kod implementujący te „bezstanowe” interfejsy GUI jest zdecydowanie sterowany przez stany. W takich interfejsach GUI kod musi „dowiedzieć się”, które elementy menu i przyciski mają być nieaktywne, które okna pomocnicze powinny się wyświetlić, które zakładki należy aktywować, gdzie powinien znaleźć się fokus itp. Wszystkie takie decyzje są związane ze stanem interfejsu. Bardzo dawno temu nauczyłem się, że zarządzanie tymi aspektami staje się koszmarem, jeśli nie zorganizujemy ich w jednej strukturze zarządzania. Tę strukturę zarządzania najlepiej scharakteryzować za pomocą maszyny FSM. Od tamtego czasu prawie wszystkie moje GUI implementuję za pomocą maszyn FSM generowanych z wykorzystaniem kompilatora SMC (lub jego poprzedników). Rozważmy maszynę stanów z listingu 29.11. Ta maszyna zarządza interfejsem GUI mechanizmu logowania do aplikacji. Po otrzymaniu zdarzenia start maszyna wyświetla ekran logowania. Kiedy użytkownik wciśnie klawisz Enter, maszyna sprawdza hasło. Jeśli hasło jest poprawne, maszyna przechodzi do stanu loggedIn i rozpoczyna proces interakcji z użytkownikiem (tutaj go nie pokazano). Jeśli hasło jest nieprawidłowe, to wyświetla ekran informujący o tym użytkownika. Jeśli użytkownik chce ponowić próbę, klika przycisk OK, w przeciwnym razie klika przycisk Anuluj. Jeśli użytkownik wprowadzi złe hasło trzy razy z rzędu (zdarzenie thirdBadPassword), maszyna blokuje ekran do czasu wprowadzenia hasła administratora. Listing 29.11. login.sm Initial init { init { start logginIn displayLoginScreen } logginIn { enter checkingPassword checkPassword cancel init clearScreen } checkingPassword { passwordGood loggedIn startUserProcess passwordBad notifyingPasswordBad displayBadPasswordScreen thirdBadPassword screenLocked displayLockScreen } notifyingPasswordBad { OK checkingPassword displayLoginScreen cancel init clearScreen } screenLocked { enter checkingAdminPassword checkAdminPassword

440

ROZDZIAŁ 29. WZORZEC PROJEKTOWY STAN

}

}

checkingAdminPassword { passwordGood init clearScreen passwordBad screenLocked displayLockScreen }

W tym przykładzie uchwyciliśmy wysokopoziomową strategię aplikacji w maszynie stanów. Ta trójpoziomowa strategia jest zaimplementowana w jednym miejscu i jest łatwa do utrzymania. To znacznie upraszcza pozostałą część kodu w systemie, ponieważ kod tamtych części aplikacji nie miesza się z kodem strategii. Bez trudu takie podejście można zastosować do interfejsów innych niż GUI. Podobne podejście z powodzeniem stosowałem dla interfejsów tekstowych, a także do implementacji interfejsów maszynamaszyna. Jednak interfejsy GUI zazwyczaj są bardziej złożone od interfejsów innego typu, zatem potrzeba ich właściwej obsługi jest większa.

Kontrolery interakcji z GUI Wyobraźmy sobie, że chcemy umożliwić użytkownikom rysowanie prostokątów na ekranie. Użytkownicy wykonują następujące działania: najpierw klikają ikonę prostokąta w oknie palety. Potem umieszczają mysz w oknie „płótna” w jednym z narożników prostokąta. Następnie naciskają przycisk myszy i przeciągają w kierunku żądanego drugiego narożnika. W czasie przeciągania na ekranie pojawia się animowany obraz potencjalnego prostokąta. Użytkownik manipuluje prostokątem do pożądanego kształtu, przytrzymując przycisk myszy podczas przeciągania nią. Kiedy prostokąt ma właściwą postać, użytkownik zwalnia przycisk myszy. Wtedy program zatrzymuje animację i wykreśla na ekranie prostokąt w ustalonej pozycji. Oczywiście użytkownik może przerwać w dowolnym momencie, klikając inną ikonę na palecie. Jeśli użytkownik przeciągnie wskaźnik myszy na obszar poza oknem „płótna”, animacja znika. Jeśli wskaźnik myszy powróci do obszaru „płótna”, animacja powraca. Wreszcie po zakończeniu rysowania prostokąta użytkownik może narysować kolejny, po prostu wykonując ponownie kliknięcie i przeciąganie w oknie „płótna”. Aby narysować kolejny prostokąt, nie musi jeszcze raz klikać ikony na palecie. Powyżej opisałem maszynę stanów skończonych. Diagram przejść tej maszyny zaprezentowano na rysunku 29.6. Okrąg narysowany linią ciągłą ze strzałką oznacza początkowy stan maszyny 7. Okrąg z kółkiem na końcu oznacza końcowy stan maszyny.

Rysunek 29.6. Maszyna stanów rysowania prostokąta 7

Patrz „Stany i wewnętrzne przejścia” w dodatku B.

LISTINGI

441

W operacjach implementujących interakcje z GUI „roi się” od maszyn stanów skończonych. Są one sterowane zdarzeniami inicjowanymi przez użytkownika. Te zdarzenia powodują zmiany stanu interakcji.

Przetwarzanie rozproszone Przetwarzanie rozproszone to kolejna sytuacja, w której w odpowiedzi na przychodzące zdarzenia zmienia się stan systemu. Załóżmy, że chcemy przesłać duży blok informacji z jednego węzła w sieci do innego. Załóżmy także, że czas odpowiedzi sieci jest cenny, więc trzeba podzielić blok i wysłać go w postaci grupy małych pakietów. Maszynę stanów ilustrującą ten scenariusz pokazano na rysunku 29.7. Proces zaczyna się od żądania sesji transmisji, jest kontynuowany poprzez wysyłanie kolejnych pakietów i oczekiwanie na potwierdzenie, kończy się zakończeniem sesji.

Rysunek 29.7. Wysyłanie dużego bloku z wykorzystaniem wielu pakietów

Wniosek Maszyny stanów skończonych są wykorzystywane zbyt rzadko. Istnieje wiele scenariuszy, w których zastosowanie maszyn stanów skończonych mogłoby pomóc w stworzeniu czystszego, bardziej elastycznego i dokładniejszego kodu. Wykorzystanie wzorca projektowego Stan i prostych narzędzi do generowania kodu na podstawie tabel przejść pomiędzy stanami może być bardzo pomocne.

Listingi Implementacja klasy Turnstile.java z wykorzystaniem interpretacji tabeli przejść Na poniższym listingu pokazano sposób implementacji maszyny stanów skończonych poprzez interpretację wektora struktur danych opisujących przejścia. Kod jest w całości kompatybilny z kodem klasy TurnstileController z listingu 29.2 oraz TurnstileTest z listingu 29.3.

442

ROZDZIAŁ 29. WZORZEC PROJEKTOWY STAN

Listing 29.12. Klasa Turnstile.java z wykorzystaniem tabeli przejść import java.util.Vector; public class Turnstile {

// Stany

public static final int LOCKED = 0; public static final int UNLOCKED = 1;

// Zdarzenia

public static final int COIN = 0; public static final int PASS = 1; /*private*/ int state = LOCKED; private TurnstileController turnstileController; private Vector transitions = new Vector(); private interface Action { void execute(); } private class Transition { public Transition(int currentState, int event, int newState, Action action) { this.currentState = currentState; this.event = event; this.newState = newState; this.action = action; }

}

int currentState; int event; int newState; Action action;

public Turnstile(TurnstileController action) { turnstileController = action; addTransition(LOCKED, COIN, UNLOCKED, unlock() ); addTransition(LOCKED, PASS, LOCKED, alarm() ); addTransition(UNLOCKED, COIN, UNLOCKED, thankyou()); addTransition(UNLOCKED, PASS, LOCKED, lock() ); } private void addTransition(int currentState, int event, int newState, Action action) { transitions.add( new Transition(currentState, event, newState, action)); } private Action lock() { return new Action(){public void execute(){doLock();}}; } { }

private Action thankyou() return new Action(){public void execute(){doThankyou();}};

private Action alarm()

LISTINGI

{ }

443

return new Action(){public void execute(){doAlarm();}};

private Action unlock() { return new Action(){public void execute(){doUnlock();}}; } private void doUnlock() { turnstileController.unlock(); } private void doLock() { turnstileController.lock(); } private void doAlarm() { turnstileController.alarm(); } private void doThankyou() { turnstileController.thankyou(); } public void event(int event) { for (int i = 0; i < transitions.size(); i++) { Transition transition = (Transition) transitions.elementAt(i); if (state == transition.currentState && event == transition.event) { state = transition.newState; transition.action.execute(); } } } }

Klasa Turnstile.java wygenerowana przez kompilator SMC oraz inne pliki pomocnicze Na listingach od 29.13 do 29.16 zamieszczono kod obsługi maszyny stanów kołowrotu stworzony z wykorzystaniem kompilatora SMC. Klasa Turnstile.java została wygenerowana za pomocą kompilatora SMC. Generator robi trochę bałaganu, ale kod nie jest zły. Listing 29.13. Klasa Turnstile.java (wygenerowana za pomocą kompilatora SMC) //---------------------------------------------// // FSM: Turnstile // Context: TurnstileActions // Exception: FSMError // Version: // Generated: Thursday 09/06/2001 at 12:23:59 CDT // //---------------------------------------------//---------------------------------------------// // class Turnstile

444

// //

ROZDZIAŁ 29. WZORZEC PROJEKTOWY STAN

To jest klasa maszyny stanów skończonych

public class Turnstile extends TurnstileActions { private State itsState; private static String itsVersion = "";

// składowe egzemplarza dla każdego stanu

private static Locked itsLockedState; private static Unlocked itsUnlockedState;

// konstruktor

public Turnstile() { itsLockedState = new Locked(); itsUnlockedState = new Unlocked(); itsState = itsLockedState;

// Funkcje obsługi stanu: Locked }

// funkcje dostępowe public String getVersion() { return itsVersion; } public String getCurrentStateName() { return itsState.stateName(); }

// funkcje obsługi zdarzeń — przejście do bieżącego stanu public void pass() throws FSMError { itsState.pass(); } public void coin() throws FSMError { itsState.coin(); }

//-------------------------------------------// // private class State // To jest bazowa klasa State //

private abstract class State { public abstract String stateName();

// domyślne funkcje obsługi zdarzeń public void pass() throws FSMError { throw new FSMError( "pass", itsState.stateName()); } public void coin() throws FSMError { throw new FSMError( "coin", itsState.stateName()); }

LISTINGI

}

//-------------------------------------------// // klasa Locked // obsługuje stan Locked i związane z nim zdarzenia //

private class Locked extends State { public String stateName() { return "Locked"; }

// // odpowiedź na zdarzenie coin (moneta) //

public void coin() { unlock();

// zmiana stanu

}

itsState = itsUnlockedState;

// // odpowiedź na zdarzenie pass (przejście) //

public void pass() { alarm();

// zmiana stanu

}

}

itsState = itsLockedState;

//-------------------------------------------// // klasa Unlocked // obsługuje stan Unlocked i związane z nim zdarzenia //

private class Unlocked extends State { public String stateName() { return "Unlocked"; }

// // odpowiedź na zdarzenie pass (przejście) //

public void pass() { lock();

// zmiana stanu

}

itsState = itsLockedState;

// // odpowiedź na zdarzenie coin (moneta) //

public void coin() { thankyou();

// zmiana stanu

} }

}

itsState = itsUnlockedState;

445

446

ROZDZIAŁ 29. WZORZEC PROJEKTOWY STAN

FSMError to wyjątek, który poleciliśmy zgłosić kompilatorowi SMC w przypadku nieprawidłowego zdarzenia. Przykład obsługi kołowrotu jest tak prosty, że nie może być nieprawidłowych zdarzeń, zatem wyjątek jest bezużyteczny. Jednak w większych maszynach stanów mogą wystąpić zdarzenia, które nie powinny występować w niektórych stanach. O takich przejściach nie ma mowy w danych wejściowych dla kompilatora SMC. Gdyby więc takie zdarzenie wystąpiło, to wygenerowany kod zgłosi wyjątek.

Listing 29.14. FSMError.java public class FSMError extends Exception { public FSMError(String event, String state) { super("Nieprawidłowe zdarzenie:" + event + " in state:" + state); } }

Kod testowy dla maszyny stanów wygenerowanej przez kompilator SMC jest bardzo podobny do pozostałych programów testowych, które pisaliśmy w tym rozdziale. Jest kilka drobnych różnic. Listing 29.15. SMCTurnstileTest.java import junit.framework.*; import junit.swingui.TestRunner; public class SMCTurnstileTest extends TestCase { public static void main(String[] args) { TestRunner.main(new String[]{"SMCTurnstileTest"}); } public SMCTurnstileTest(String name) { super(name); } private private private private private

TurnstileFSM t; boolean lockCalled = false; boolean unlockCalled = false; boolean thankyouCalled = false; boolean alarmCalled = false;

public void setUp() { TurnstileController controllerSpoof = new TurnstileController() { public void lock() {lockCalled = true;} public void unlock() {unlockCalled = true;} public void thankyou() {thankyouCalled = true;} public void alarm() {alarmCalled = true;} }; }

t = new TurnstileFSM(controllerSpoof);

public void testInitialConditions() { assertEquals("Locked", t.getCurrentStateName()); } {

public void testCoinInLockedState() throws Exception t.coin(); assertEquals("Unlocked", t.getCurrentStateName());

BIBLIOGRAFIA

447

assert(unlockCalled); } public void testCoinInUnlockedState() throws Exception { t.coin(); // moneta w stanie Unlocked t.coin(); assertEquals("Unlocked", t.getCurrentStateName()); assert(thankyouCalled); } public void testPassInLockedState() throws Exception { t.pass(); assertEquals("Locked", t.getCurrentStateName()); assert(alarmCalled); }

}

public void testPassInUnlockedState() throws Exception { t.coin(); // odblokowanie t.pass(); assertEquals("Locked", t.getCurrentStateName()); assert(lockCalled); }

Klasa TurnstileController w tym rozwiązaniu jest identyczna z wszystkimi pozostałymi implementacjami, które prezentowaliśmy w tym rozdziale. Jej kod zamieszczono na listingu 29.2. Plik wejściowy dla kompilatora SMC, który wykorzystano do wygenerowania kodu Turnstile.java, zamieszczono na listingu 29.16. Jak można zauważyć, nie ma w nim niczego skomplikowanego. W wierszu polecenia komenda do generowania klasy ma następującą postać: java smc.Smc -f TurnstileFSM.sm

Listing 29.16. build.xml

Bibliografia 1. Gamma, et al., Design Patterns, Reading, MA: Addison-Wesley, 1995. 2. Coplien i Schmidt, Pattern Languages of Program Design, Reading, MA: Addison-Wesley, 1995.

448

ROZDZIAŁ 29. WZORZEC PROJEKTOWY STAN

R OZDZIAŁ 30

Framework ETS

Robert Martin i James Newkirk

W tym rozdziale opisano dość duży projekt oprogramowania, który był rozwijany od marca 1993 do końca 1997 roku. Aplikacja powstała na zlecenie Educational Testing Service (ETS). Większą część prac wykonaliśmy we dwóch. Pomagało nam kilku innych deweloperów z firmy Object Mentor, Inc. Naszym celem w tym rozdziale było zaprezentowanie metod, zarówno technicznych, jak i menedżerskich, stosowanych podczas tworzenia frameworków wielokrotnego użytku. Stworzenie takiego frameworka było istotnym krokiem na drodze do powodzenia projektu, a rozwój prac projektowych i historia rozwoju projektu mogą mieć znaczenie edukacyjne. Nie istnieje taki projekt oprogramowania, który powstawałby w idealnym środowisku. Ten projekt nie był pod tym względem wyjątkowy. Aby zrozumieć techniczne aspekty projektu, należy wziąć pod uwagę także kwestie środowiskowe. Dlatego zanim zagłębimy się w aspekty projektu dotyczące inżynierii oprogramowania, zaprezentujemy tło projektu oraz środowisko, w którym projekt był opracowywany.

Wprowadzenie Przegląd informacji o projekcie Aby stać się licencjonowanym architektem w Stanach Zjednoczonych lub Kanadzie, należy zdać egzamin. Osobie, która go pomyślnie przejdzie, stanowa komisja licencyjna przyznaje licencję na wykonywanie zawodu architekta. Egzamin został opracowany przez Educational Testing Service (ETS) pod nadzorem National Council of Architectural Registration Boards (NCARB) i jest obecnie zarządzany przez międzynarodową grupę Chauncey Group International. Test składa się z dziewięciu części i jest przeprowadzany w ciągu kilku dni. W trzech graficznych częściach egzaminu kandydaci są proszeni o stworzenie rozwiązań w środowisku przypominającym narzędzie CAD poprzez narysowanie lub umieszczenie obiektów. Przykładowe zadania w tej części egzaminu to:  zaprojektowanie planu podłogi określonego rodzaju budynku;  zaprojektowanie dachu w taki sposób, aby pasował do istniejącego budynku;  umieszczenie proponowanego budynku na działce, zaprojektowanie parkingu, układu dróg i chod-

ników wokół budynku.

450

ROZDZIAŁ 30. FRAMEWORK ETS

W przeszłości kandydaci rozwiązywali zadania przy użyciu ołówka i papieru. Dokumenty te były następnie przekazywane jurorom do oceny. Jurorami byli doświadczeni architekci, którzy analizowali rozwiązania kandydatów i podejmowali decyzję o tym, czy kandydat pomyślnie zdał egzamin, czy nie. W 1989 roku NCARB zleciła komisji ETS przeprowadzenie badania, czy istnieje możliwość stworzenia zautomatyzowanego systemu zdawania i oceniania graficznej części egzaminu. W 1992 komisja ETS i NCARB doszły do wspólnego wniosku, że stworzenie takiego systemu jest możliwe. Ponadto ustalono, że najwłaściwsze będzie podejście obiektowe — ze względu na stale zmieniające się wymagania. Dlatego zwrócono się do firmy Object Mentor, Inc. (OMI) o pomoc w zaprojektowaniu takiego systemu. W marcu 1993 roku podpisano kontrakt z firmą OMI na stworzenie części testu. Rok później, po pomyślnym zakończeniu tej części, OMI otrzymała drugi kontrakt na stworzenie większości pozostałej części systemu. Struktura programu. Komisja ETS podjęła decyzję o dość eleganckiej formule egzaminu. Egzamin graficzny będzie obejmował rozwiązanie 15 różnych problemów, zwanych winietami. Każda winieta ma sprawdzać określony obszar wiedzy. Jedna winieta może testować wiedzę kandydata dotyczącą konstrukcji dachu, natomiast inna  jego umiejętności w zakresie projektowania planów pięter. Każdy winieta zostanie dodatkowo podzielona na dwie sekcje. Sekcja zdawania ma być graficznym interfejsem użytkownika, za pomocą którego kandydat „rysuje” rozwiązanie zadania. Sekcja punktacji ma za zadanie odczytać rozwiązanie stworzone przez sekcję zdawania i je ocenić. Kandydat może zdawać egzamin w dogodnym dla siebie miejscu. Rozwiązania będą następnie przekazane do centralnej lokalizacji w celu oceny. Skrypty. Mimo że zaplanowano tylko 15 winiet, każda może się składać z wielu możliwych „skryptów”. Skrypt będzie określał charakter problemu, który kandydat ma rozwiązać. Na przykład winieta planowania pięter może zawierać jeden skrypt, który prosi kandydata o zaprojektowanie biblioteki, oraz inny, który żąda od kandydata zaprojektowania sklepu spożywczego. Zatem programy obsługi winiet muszą być napisane w sposób ogólny. Winiety muszą być dostarczone i ocenione w sposób zarządzany przez skrypt. Platforma. Oba programy — zarówno obsługujący zdawanie, jak i ocenianie  miały działać w systemie Windows 3.1 (później wymaganie zaktualizowano do systemu W95/NT). Programy miały być napisane w języku C++ z wykorzystaniem technik obiektowych. Pierwszy kontrakt. W marcu 1993 roku podpisano kontrakt z firmą OMI na stworzenie modułu zdawania i punktacji dla najbardziej złożonej winiety: „Projekt budynku”. Na tę decyzję wpłynęły zalecenia Boocha, aby najpierw zostały zaprogramowane komponenty o największym ryzyku. Miało to pomóc w zarządzaniu ryzykiem oraz umożliwić skalibrowanie procesu szacowania możliwości zespołu. Projekt budynku. Winieta Projekt budynku miała za zadanie sprawdzenie umiejętności kandydata w projektowaniu rzutu piętra stosunkowo prostego dwupiętrowego budynku. Kandydat otrzyma opis budynku do zaprojektowania wraz z wymaganiami i ograniczeniami. Następnie kandydat wykorzysta program do zdawania w celu umieszczenia w swoim rozwiązaniu pokoi, drzwi, okien, korytarzy, schodów i wind. Program oceniający będzie sprawdzić rozwiązanie pod kątem różnych „własności” mających na celu ocenę wiedzy kandydata. Charakter tych cech jest poufny. Ogólnie rzecz biorąc, ocenie będą podlegały następujące elementy:    

Czy budynek spełnia wymagania klienta? Czy kod budynku jest zgodny? Czy kandydat zademonstrował logikę konstrukcji? Czy budynek i pokoje są odpowiednio ustawione w lokalizacji?

WPROWADZENIE

451

Wczesny okres 1993 – 1994 Na tym wczesnym etapie było tylko dwóch deweloperów pracujący nad tym projektem (Martin i Newkirk). Zgodnie ze zleceniem od ETS naszym zadaniem miało być stworzenie zarówno modułu zdawania, jak i oceny dla winiety Projekt budynku. Jednak oprócz implementacji winiety Projekt budynku chcieliśmy także stworzyć framework wielokrotnego użytku. Do roku 1997 musiały być gotowe moduły zdawania i oceny dla 15 winiet. Zatem mieliśmy cztery lata. Mieliśmy przeczucie, że framework wielokrotnego użytku bardzo przybliży nam osiągnięcie tego celu. Taki framework mógłby również bardzo pomóc w zapewnieniu spójności i jakości winiet. W końcu nie chcielibyśmy, aby podobne funkcje w różnych winietach działały w nieco inny sposób. Tak więc w marcu 1993 roku przystąpiliśmy do tworzenia dwóch komponentów winiety Projekt budynku, a także frameworka, który mógłby być wykorzystany w pozostałych czternastu winietach. Sukces. We wrześniu 1993 roku pierwsze wersje programów do zdawania i oceniania były gotowe. Programy te zostały zademonstrowane przedstawicielom NCARB i ETS. Te demonstracje zostały dobrze przyjęte, a pierwsze próby praktycznego zastosowania produktu zaplanowano na styczeń 1994. Tak jak bywa w przypadku większości projektów, kiedy użytkownicy zobaczą działający program, zaczynają zdawać sobie sprawę, że to, o co prosili, nie było do końca tym, czego chcieli. W ciągu 1993 roku co tydzień wysyłaliśmy przejściowe winiety do ETS. Do wspomnianej wrześniowej prezentacji wprowadziliśmy bardzo dużo zmian i usprawnień. Po demonstracji zbliżająca się próba spowodowała, że tempo wprowadzania zmian i ulepszeń osiągnęło olbrzymie rozmiary. Obaj byliśmy zajęci w pełnym wymiarze godzin wprowadzaniem i testowaniem tych zmian oraz przygotowywaniem programów do próby. To rozrastanie się specyfikacji winiety Projekt budynku zostało jeszcze bardziej przyspieszone przez wyniki próby. W związku z tym przez pierwszy kwartał 1994 roku byliśmy jeszcze bardziej zajęci. W grudniu 1993 roku rozpoczęły się negocjacje kontraktu na tworzenie pozostałych winiet. Negocjacje te zajęły trzy miesiące. W marcu 1994 roku komisja ETS podpisała z firmą OMI kontrakt na stworzenie dodatkowych 10 winiet. Pozostałych 5 winiet mieli stworzyć inżynierowie ETS, korzystając z dostarczonego przez nas frameworka.

Framework? Pod koniec 1993 roku w czasie najbardziej dynamicznych zmian w winiecie Projekt budynku jeden z nas (Newkirk) spędził tydzień z jednym z inżynierów z ETS w celu przygotowania go do wykonywania zadań w czasie realizacji przyszłego kontraktu. Celem było pokazanie, jak można wykorzystać do budowy innych winiet kod z zawierającego 60 000 linii i napisanego w C++ frameworka wielokrotnego użytku. Jednak nie wyglądało to najlepiej. Pod koniec tego tygodnia było jasne, że jedynym sposobem na ponowne wykorzystanie frameworka było wycięcie i wklejenie fragmentów kodu źródłowego do nowych winiet. Oczywiście nie było to dobre rozwiązanie. Z perspektywy czasu można wskazać dwa powody naszego niepowodzenia stworzenia użytecznego frameworka. Po pierwsze, skupialiśmy się na winiecie Projekt budynku, nie zajmując się pozostałymi winietami. Po drugie, przez całe miesiące zmagaliśmy się ze zmieniającymi się wymaganiami i presją harmonogramu. Te dwa elementy spowodowały, że we frameworku znalazły się elementy specyficzne dla winiety Projekt budynku. Do pewnego stopnia naiwnie uznaliśmy korzyści ze stosowania technologii obiektowych za pewnik. Uznaliśmy, że jeśli zastosujemy język C++ i starannie wykonamy projekt obiektowy, to stworzenie frameworka wielokrotnego użytku nie przysporzy nam żadnych problemów. Myliliśmy się. Odkryliśmy to, co było wiadome od lat — budowanie frameworków wielokrotnego użytku jest trudne.

452

ROZDZIAŁ 30. FRAMEWORK ETS

Framework W marcu 1994 roku, po podpisaniu nowego kontraktu, wprowadziliśmy do projektu dwóch nowych inżynierów i rozpoczęliśmy prace nad nowymi winietami. Nadal uważaliśmy, że potrzebujemy frameworka, i byliśmy przekonani, że to, czym dysponujemy, nie spełnia tej funkcji. Stało się oczywiste, że musimy zmienić strategię.

Zespół z roku 1994    

Robert C. Martin — architekt i główny projektant, ponad 20 lat doświadczenia; James W. Newkirk — projektant i kierownik projektu, ponad 15 lat doświadczenia; Bhama Rao — projektant i programista, ponad 12 lat doświadczenia; William Mitchell — projektant i programista, ponad 15 lat doświadczenia.

Termin Termin został wyznaczony z uwzględnieniem faktu, że sposób egzaminowania miał zacząć obowiązywać od 1997 roku. Kandydaci mieli przejść test w lutym i otrzymać ocenę w maju. To było kluczowe wymaganie.

Strategia Aby wykonać ten plan oraz zapewnić właściwą jakość i spójność programu, przyjęliśmy nową strategię budowy frameworka. Niektóre fragmenty pierwotnego frameworka składającego się z 60 000 wierszy zostały wykorzystane, ale większość „poszła do kosza”. Odrzucona alternatywa. Jedną z możliwości było podjęcie próby stworzenia nowego projektu frameworka „z góry” i zrealizowanie go przed przystąpieniem do prac nad winietami. Wielu czytelników rozpoznaje w tym podejście „sterowane architekturą”. Jednak nie zdecydowaliśmy się pójść tą drogą, ponieważ to spowodowałoby stworzenie dużych ilości kodu frameworka, które nie mogły być testowane wewnątrz działających winiet. Nie zaufaliśmy naszym zdolnościom do wyczerpującej oceny potrzeb winiet. Krótko mówiąc: czuliśmy, że architektura wymaga niemal natychmiastowej weryfikacji poprzez wykorzystanie jej w działających winietach. Nie chcieliśmy zgadywać. Rebecca Wirfs Brock powiedziała kiedyś: „Trzeba zbudować co najmniej trzy lub więcej aplikacji na bazie frameworka (a potem je wyrzucić), aby mieć przekonanie, że zbudowaliśmy odpowiednią architekturę dla danej dziedziny1”. Po niepowodzeniu w stworzeniu frameworka mieliśmy podobne odczucia. W związku z tym zdecydowaliśmy, że będziemy pracować nad frameworkiem równolegle z pracą nad rozwojem kilku nowych winiet. Dzięki takiemu podejściu będziemy mogli porównać podobne własności winiet i zaprojektować je w uniwersalny sposób, pozwalający na wielokrotny użytek. Prace nad czterema winietami rozpoczęły się równolegle. Podczas tych prac odkryliśmy, że niektóre fragmenty są podobne. Zostały one zrefaktoryzowane do bardziej ogólnej formy i zastosowane do wszystkich czterech winiet. W ten sposób żaden kod nie został wprowadzony do frameworka bez skutecznej weryfikacji w co najmniej czterech winietach. W podobny sposób zostały wycięte i zrefaktoryzowane fragmenty winiety Projekt budynku. Dopiero kiedy te fragmenty zaczęły działać we wszystkich czterech winietach, były umieszczane we frameworku. Wśród wspólnych własności, które zostały dodane do frameworka, były następujące:  struktura okien interfejsu użytkownika — okna komunikatów, okna rysowania, palety przycisków itp.;  tworzenie, przenoszenie, dostosowanie, identyfikowanie i usuwanie elementów graficznych;  powiększanie i przewijanie; 1

[BOOCH-OS], str. 275.

FRAMEWORK

453

 szkicowanie prostych elementów, takich jak linie, okręgi i linie łamane;  liczenie czasu winiety i automatyczne przerywanie;  zapisywanie i odtwarzanie plików rozwiązania, z działaniami „naprawczymi” po wystąpieniu błę-

dów włącznie;  modele matematyczne wielu elementów geometrycznych: linii, promienia, segmentu, punktu, pro-

stokąta, okręgu, łuku, trójkąta, wielokąta itp. — w tych modelach zaimplementowano takie metody jak Intersection, Area, IsPointIn, IsPointOn itp.;  wyznaczanie ocen i waga poszczególnych elementów punktacji. W ciągu kolejnych ośmiu miesięcy framework rozrósł się do ponad 60 000 wierszy kodu C++, co reprezentowało ponad rok bezpośredniej pracy programisty. Ten framework był jednak wykorzystany w czterech różnych winietach.

Wyniki Wyrzucenie jednej winiety. Co powinniśmy zrobić ze starą winietą Projekt budynku? W miarę rozwoju frameworka i skutecznego stosowania go w nowych winietach winieta Projekt budynku w coraz większym stopniu stawała się outsiderem. Była inna od pozostałych winiet i musiałaby być utrzymywana i rozwijana osobno. Pomimo że stworzenie winiety Projekt budynku wymagało ponad roku prac, zdecydowaliśmy się być bezwzględni i całkowicie wyrzucić starą wersję. Zobowiązaliśmy się do ponownego zaprojektowania i zaimplementowania jej na dalszym etapie projektu. Długi początkowy czas rozwoju. Negatywnym rezultatem strategii bazującej na frameworku był stosunkowo długi czas rozwoju pierwszych winiet. Nakład pracy potrzebny do stworzenia programów zdawania dla pierwszych czterech winiet wymagał blisko czterech lat. Efektywność wielokrotnego wykorzystywania. Po zakończeniu prac nad pierwszymi winietami framework zawierał 60 000 linii kodu C++, a programy zdawania były bardzo małe. Każdy program miał około 4000 linii kodu, które były identyczne dla każdej winiety. Ponadto każdy program zawierał średnio 6000 linii kodu specyficznego dla aplikacji. Najmniejsza winieta zawierała zaledwie 500 linii kodu specyficznego dla aplikacji, natomiast największa zawierała aż 12 000 linii takiego kodu. Dużym sukcesem było to, że średnio prawie pięć szóstych kodu w każdej winiecie pochodziło z frameworka. Zaledwie jedna dziesiąta kodu tych programów była unikatowa. Wydajność prac rozwojowych. Po stworzeniu pierwszych czterech winiet czas rozwoju kolejnych znacznie się skrócił. Siedem dodatkowych programów zdawania (z przepisaniem winiety Projekt budynku włącznie) zajęło 18 miesięcy. Współczynniki liczby linii dla tych nowych winiet miały w przybliżeniu takie same wartości jak dla pierwszych czterech. Ponadto przepisanie programu winiety Projekt budynku, którego opracowanie pierwotnie zajęło ponad rok, w przypadku wykorzystania frameworka zajęło zaledwie dwa i pół miesiąca. To oznaczało wzrost produktywności w stosunku niemal 6:1. Aby spojrzeć na te rezultaty w inny sposób, należy wziąć pod uwagę, że wykonanie pierwszych pięciu winiet, w tym winiety Projekt budynku, wymagało w każdym przypadku jednego roku. Jednak kolejne winiety wymagały zaledwie 2,6 miesiąca na sztukę — co oznaczało wzrost o prawie 400%. Cotygodniowe dostarczanie. Od początku projektu przez cały czas jego aktywnego rozwoju co tydzień wysyłaliśmy do ETS wersje tymczasowe. ETS testowała i oceniała te wersje, a następnie wysyłała do nas listę zmian. Ocenialiśmy te zmiany, a następnie wspólnie z ETS planowaliśmy tydzień, w którym te zmiany zostaną uwzględnione. Trudne zmiany lub zmiany o mniejszym znaczeniu często były planowane na później. Najpierw wprowadzaliśmy zmiany o wysokim priorytecie. Tak więc ETS utrzymywała kontrolę nad projektem i harmonogramem w całym cyklu jego trwania.

454

ROZDZIAŁ 30. FRAMEWORK ETS

Wytrzymały i elastyczny projekt. Jednym z najbardziej satysfakcjonujących aspektów projektu jest sposób, w jaki architektura i framework przetrwały intensywny strumień zmian w wymaganiach. W szczytowym okresie rozwoju niemal w każdym tygodniu powstawała długa lista zmian i poprawek do wprowadzenia. Niektóre z tych zmian były odpowiedzią na błędy, ale znacznie więcej wynikało ze zmian w wymaganiach. Jednak bez względu na wszystkie zmiany, poprawki i modyfikacje w czasie intensywnego rozwoju „projekt oprogramowania nie upadł”2. Ostateczny wynik. W lutym 1997 roku kandydaci na architektów rozpoczęli używanie programów do zdawania egzaminów rejestracyjnych. W maju 1997 roku ich wyniki zaczęto oceniać. System z powodzeniem działa od tamtego czasu. Każdy kandydat na architekta w Stanach Zjednoczonych zdaje teraz egzamin przy użyciu tego oprogramowania.

Projekt frameworka Wspólne wymagania dla aplikacji oceniających Zastanówmy się nad tym, w jaki sposób można sprawdzić czyjąś wiedzę i umiejętności. Mechanizm, który został przyjęty przez ETS w odniesieniu do programów NCARB, jest dość skomplikowany. Spróbujemy go zilustrować na prostym, fikcyjnym przykładzie testu z zakresu podstawowej matematyki. W teście podstawowej wiedzy matematycznej uczniowie mają do rozwiązania 100 zadań matematycznych — począwszy od prostych działań dodawania i odejmowania, do problemów pisemnego mnożenia i dzielenia dużych liczb. W celu oceny wiedzy uczniów z zakresu podstawowej matematyki sprawdzimy rozwiązania tych zadań. Celem jest nadanie uczniom oceny „zaliczony” lub „niezaliczony”. „Zaliczony” oznacza pewność co do tego, że uczeń nabył podstawową wiedzę i umiejętności potrzebne do rozwiązywania problemów podstawowej matematyki. „Niezaliczony” oznacza pewność, że uczeń nie posiada wymaganych umiejętności. W tych przypadkach, w których nie jesteśmy pewni, zwracamy wynik „nieokreślony”. Jednak stawiamy sobie także inny cel. Chcemy wskazać mocne i słabe strony ucznia. Chcielibyśmy podzielić zagadnienie podstawowej wiedzy matematycznej na podtematy, a następnie ocenić ucznia na podstawie każdego z tych podpunktów. Rozważmy na przykład problem ucznia, który dowiedział się, że ma kłopoty z mnożeniem. Załóżmy, że zawsze błędnie podaje wynik mnożenia 78=42. Ten uczeń będzie miał duży procent błędnie rozwiązanych zadań z mnożenia i dzielenia. Nie ulega wątpliwości, że taki uczeń nie zasługuje na zaliczenie testu. Z drugiej strony, załóżmy, że ten uczeń zrobił wszystko pozostałe prawidłowo! Uczeń poprawnie wyliczył częściowe iloczyny w mnożeniu pisemnym i prawidłowo wykonał pisemne dzielenie. W rzeczywistości jedynym błędem tego ucznia jest wynik mnożenia 78=42. Z całą pewnością chcielibyśmy to wiedzieć. Ponieważ działania korekcyjne dla takiego ucznia są bardzo proste, możemy równie dobrze dać uczniowi ocenę pozytywną oraz kilka wskazówek co do tego, w czym uczeń powinien się poprawić. Jak więc możemy zorganizować punktację testu, aby określić te dziedziny podstawowej matematyki, w której uczeń zdobył wiedzę, oraz te, w których jej nie zdobył? Rozważmy diagram z rysunku 30.1. Prostokąty na tym diagramie pokazują zagadnienia, które chcemy testować. Linie reprezentują hierarchiczne zależności. Tak więc znajomość podstaw matematyki zależy od znajomości pojęć i czynników. Znajomość pojęć zależy od znajomości zasad dodawania oraz mechanicznej umiejętności dodawania i odejmowania. Umiejętność dodawania zależy od znajomości zasad przemienności i łączności dodawania oraz mechaniki przenoszenia.

2

Pete Brittingham, menedżer projektu NCARB, ETS.

PROJEKT FRAMEWORKA

455

Rysunek 30.1. Hierarchia cech testu podstawowej wiedzy matematycznej

Prostokąty-liście są określane jako tzw. cechy. Cechy są jednostkami wiedzy, którym może być nadana ocena o wartości „zaliczone” (ang. acceptable) — (A), „niezaliczone” (ang. unacceptable) — (U) lub nieokreślone (ang. indeterminate) — (I). A zatem dla rozwiązań 100 zadań danego ucznia chcemy zastosować poszczególne cechy do każdego problemu i wyznaczyć ocenę. W przypadku cechy Przenoszenie chcemy przyjrzeć się wszystkim zadaniom dotyczącym dodawania i porównać ją z odpowiedziami udzielonymi przez ucznia. Jeśli uczeń rozwiązał wszystkie zadania dodawania prawidłowo, to dla cechy Przenoszenie oczywiście otrzyma ocenę „A”. Jednak dla każdego zadania dodawania, które uczeń rozwiązał źle, chcemy ustalić, czy popełniony błąd dotyczy przenoszenia. Możemy spróbować różnych kombinacji błędów przenoszenia, aby zobaczyć, czy jeden z tych błędów mógłby doprowadzić do odpowiedzi, jakiej udzielił uczeń. Gdybyśmy mogli określić z dużą dozą prawdopodobieństwa, że popełniono błąd przy przenoszeniu, moglibyśmy odpowiednio dostosować ocenę za cechę Przenoszenie. W efekcie końcowym ocena za cechę Przenoszenie byłaby wynikiem statystycznym wyznaczonym w oparciu o całkowitą liczbę błędnych odpowiedzi, które mogły doprowadzić do błędów w przenoszeniu. Jeśli na przykład uczeń nieprawidłowo rozwiązał połowę zadań z dodawania, a większość z nich jest spowodowana nieprawidłowym przenoszeniem, z pewnością powinniśmy zwrócić ocenę „U” dla cechy Przenoszenie. Z drugiej strony, jeśli tylko jedna czwarta błędów jest związana z przenoszeniem, możemy zwrócić ocenę „I”. W ten sposób będą oceniane wszystkie cechy. Dla każdej cechy są badane odpowiedzi na test w celu wyznaczenia oceny dla tej cechy. Oceny różnych cech reprezentują analizę wiedzy ucznia z zakresu podstawowej matematyki. Następnym krokiem jest wyznaczenie końcowej oceny z tej analizy. Aby to zrobić, scalamy oceny z poszczególnych cech, korzystając z macierzy i wag. Zwróćmy uwagę na rysunku 30.1 na ikony macierzy w połączeniach pomiędzy poziomami hierarchii. Macierz kojarzy współczynnik wagi z wynikiem dla każdej cechy i w ten sposób tworzy mapę oceny dla tego poziomu w hierarchii. Na przykład macierz bezpośrednio poniżej węzła Dodawanie służy do ustalenia wag, które należy zastosować do ocen Przenoszenie i Własności. Następnie macierz ta określi odwzorowanie, które pozwoli wygenerować ogólną ocenę dla Dodawania. Postać jednej z takich macierzy pokazano na rysunku 30.2. Ocena cechy Przenoszenie jest uważana za ważniejszą od oceny cechy Własności, dlatego waga cechy Przenoszenie ma dwukrotną wartość wagi cechy Własności. Oceny ważone są następnie do siebie dodawane. Wynik tego dodawania jest przypisywany do macierzy.

456

ROZDZIAŁ 30. FRAMEWORK ETS

Rysunek 30.2. Macierz dodawania

Dla przykładu przyjmijmy, że ocena cechy Przenoszenie to „I”, natomiast cechy Własności to „A”. Nie ma ocen „U”, zatem korzystamy ze skrajnej lewej kolumny macierzy. Waga oceny „I” wynosi 2, zatem używamy trzeciego wiersza macierzy, co daje wynik „I”. Zwróćmy uwagę, że macierz zawiera luki. Niektóre warunki nie mogą wystąpić. Biorąc pod uwagę bieżące wagi, nie istnieje taka kombinacja cech, która może doprowadzić do wybrania pustych komórek w macierzy. Ten system wag i macierzy jest stosowany na każdym poziomie hierarchii, aż do uzyskania końcowego wyniku. Tak więc końcowy wynik jest wyznaczany przez scalenie ocen poszczególnych cech. Struktura hierarchii pozwala na wyznaczenie dokładnej oceny psychometrycznej ucznia.

Projekt frameworka do wyznaczania ocen Na rysunku 30.3 zaprezentowano statyczną strukturę frameworka wyznaczania ocen. Strukturę można podzielić na dwie główne części. Trzy klasy z prawej oznaczone inną czcionką nie należą do frameworka. Reprezentują klasy, które należy napisać dla każdej konkretnej aplikacji wyznaczania ocen. Pozostałe klasy z rysunku 30.3 to klasy frameworka wspólne dla wszystkich aplikacji wyznaczania ocen.

Rysunek 30.3. Framework wyznaczania ocen

PROJEKT FRAMEWORKA

457

Najważniejszą klasą we frameworku wyznaczania ocen jest Evaluator. Jest to klasa abstrakcyjna, która reprezentuje zarówno węzły liści, jak i węzły macierzy drzewa ocen. Funkcja Evaluate(ostream&) jest wywoływana za każdym razem, gdy chcemy wyznaczyć ocenę węzła w drzewie ocen. W celu zapewnienia standardowego sposobu wyświetlania ocen na urządzeniu wyjściowym w tej funkcji wykorzystano wzorzec projektowy Metoda szablonowa3. Spójrzmy na listingi 30.1 i 30.2. Funkcja Evaluate() wywołuje prywatną, czysto wirtualną funkcję DoEval(). Funkcja ta będzie przesłonięta w celu przeprowadzenia właściwej oceny węzła drzewa ocen. Funkcja zwraca ocenę, a następnie przekazuje ją do funkcji Evaluate() w celu wyświetlenia jej w standardowej formie. Listing 30.1. Evaluator class Evaluator { public: enum Score {A,I,U,F,X}; Evaluator(); virtual ~Evaluator(); Score Evaluate(ostream& scoreOutput); void SetName(const String& theName) {itsName = theName;} const String& GetName() {return itsName;}

};

private: virtual Score DoEval() = 0; String itsName;

Listing 30.2. Evaluator::Evaluate Evaluator::Score Evaluator::Evaluate(ostream& o) { static char scoreName[] = {’A’, ’I’, ’U’, ’F’, ’X’}; o << itsName << ":"; score = DoEval(); o << scoreName[score] << endl; return score; }

Węzły liści drzewa ocen z rysunku 30.3 są reprezentowane przez klasę VignetteFeature. W rzeczywistości w każdej aplikacji oceniającej będą dziesiątki takich klas. Każda z nich będzie przesłaniać funkcję DoEval() w celu obliczenia oceny swojej cechy. Węzły macierzy drzewa ocen z rysunku 30.3 są reprezentowane przez klasę FeatureGroup. Kod tej klasy zamieszczono na listingu 30.3. Tworzenie obiektu klasy FeatureGroup wspomagają dwie funkcje. Pierwsza to AddEvaluator, natomiast druga to AddMatrixElement. Listing 30.3. FeatureGroup class FeatureGroup : public Evaluator { public: FeatureGroup(const RWCString& name); virtual ~FeatureGroup(); void AddEvaluator(Evaluator* e , int rank); void AddMatrixElement(int i, int u, Score s); private: Evaluator::Score DoEval(); Matrix itsMatrix; vector > itsEvaluators; }; 3

[GOF95], str. 325.

458

ROZDZIAŁ 30. FRAMEWORK ETS

Funkcja AddEvaluator pozwala dodawać do klasy FeatureGroup węzły potomne. Dla przykładu wróćmy na chwilę do rysunku 30.1. Węzeł Dodawanie będzie reprezentowany przez klasę FeatureGroup, natomiast w celu załadowania do niego węzłów Przenoszenie i Własności dwukrotnie wywołamy funkcję AddEvaluator. Funkcja AddEvaluator pozwala wyznaczyć rangę konkretnego ewaluatora. Ranga określa mnożnik stosowany w odniesieniu do wyniku generowanego przez ten ewaluator. Zatem kiedy wywołujemy funkcję AddEvaluator w celu dodania do grupy FeatureGroup Addition ewaluatora Carry, określamy rangę 2, ponieważ cecha Przenoszenie (Carry) ma dwukrotność wagi cechy Własności (Properties). Funkcja AddMatrixElement dodaje komórkę do macierzy. Funkcję należy wywołać dla każdej komórki, która wymaga wypełnienia. Na przykład macierz z rysunku 30.2 można by stworzyć, korzystając z sekwencji wywołań z listingu 30.4. Listing 30.4. Tworzenie macierzy dla dodawania addition.AddMatrixElement(0,0,Evaluator::A); addition.AddMatrixElement(0,1,Evaluator::I); addition.AddMatrixElement(0,2,Evaluator::U); addition.AddMatrixElement(0,3,Evaluator::U); addition.AddMatrixElement(1,0,Evaluator::A); addition.AddMatrixElement(1,2,Evaluator::U); addition.AddMatrixElement(2,0,Evaluator::I); addition.AddMatrixElement(2,1,Evaluator::U); addition.AddMatrixElement(3,0,Evaluator::U);

Funkcja DoEval po prostu iteruje po liście ewaluatorów, mnożąc swój wynik przez wagę i dodając iloczyn do odpowiednich akumulatorów dla ocen „I” oraz „U”. Po zakończeniu iteracji te akumulatory są wykorzystywane jako indeksy macierzy do pobrania ostatecznej oceny (patrz listing 30.5). Listing 30.5. FeatureGroup::DoEval Evaluator::Score FeatureGroup::DoEval() { int sumU, sumI; sumU = sumI = 0; Evaluator::Score s, rtnScore; Vector >::iterator ei; ei = itsEvaluators.begin() for(; ei != itsEvaluators.end(); ei++) { Evaluator* e = (*ei).first; int rank = (*ei).second; s = e.Evaluate(outputStream); switch(s) { case I: sumI += rank; break; case U: sumU += rank; break; }

}

} // dla ei rtnScore = itsMatrix.GetScore( sumI, sumU ); return rtnScore;

PRZYPADEK ZASTOSOWANIA WZORCA METODA SZABLONOWA

459

Pozostaje ostatnia kwestia. Jak jest budowane drzewo ocen? Było dość oczywiste, że specjaliści z psychometrii w ETS chcieliby mieć możliwość zmiany topologii i wag dla drzewa bez konieczności zmian w aplikacji. Z tego powodu drzewo ocen jest budowane przez klasę VignetteScoringApp (patrz rysunek 30.3). Każda aplikacja oceniająca miała własną implementację tej klasy. Jednym z zadań tej klasy jest utworzenie pochodnej klasy FeatureDictionary. Ta klasa zawiera odwzorowanie ciągów znaków na wskaźniki Evaluator. Kiedy aplikacja oceniająca rozpoczyna działanie, sterowanie przejmuje framework punktacji. Wywołuje metodę w klasie ScoringApplication, która powoduje utworzenie właściwej pochodnej klasy FeatureDictionary. Następnie czyta specjalny plik tekstowy opisujący topologię drzewa ocen oraz obowiązujących wag. Cechy w tym pliku tekstowym są reprezentowane za pomocą specjalnych nazw. Są to nazwy, które zostały powiązane z odpowiednimi wskaźnikami na obiekty Evaluator wewnątrz obiektu FeatureDictionary. Tak więc aplikacja oceniająca w najprostszej postaci nie jest niczym więcej jak zestawem cech oraz metodą, która tworzy obiekt klasy FeatureDictionary. Budowanie i ocena drzewa punktacji jest realizowana przez framework, dlatego jest wspólna dla wszystkich aplikacji oceniających.

Przypadek zastosowania wzorca Metoda szablonowa Jedna z winiet testuje umiejętności kandydatów w zakresie tworzenia planów pięter budynków takich jak biblioteki lub posterunki policji. W tej winiecie kandydat musi narysować pokoje, korytarze, drzwi, okna, otwory ścienne, schody, windy itp. Program konwertuje rysunek na strukturę danych, która jest poddawana interpretacji przez program oceniający. Model obiektowy ma postać zbliżoną do pokazanej na rysunku 30.4.

Rysunek 30.4. Struktura danych planu piętra

Analizując tę strukturę danych, należy wziąć pod uwagę istotną kwestię. Obiekty tej struktury danych mają minimalną funkcjonalność. Nie są to obiekty polimorficzne w żadnym znaczeniu tego słowa. Są to raczej proste nośniki danych — czysto reprezentacyjny model. Budynek składa się z dwóch pięter. Na każdym piętrze jest wiele obszarów. Każdy obszar składa się z wielu portali. Każdy portal rozdziela dwa obszary. Portalami mogą być okna lub przejścia dla ludzi. Portale reprezentujące przejścia dla ludzi to albo otwory ścienne, albo drzwi.

460

ROZDZIAŁ 30. FRAMEWORK ETS

Ocena jest wykonywana poprzez sprawdzenie rozwiązania pod kątem zbioru określonych cech. Cechy określają między innymi poniższe elementy:         

Czy kandydat narysował wszystkie wymagane obszary? Czy każdy obszar ma akceptowalne proporcje? Czy do każdego obszaru istnieje wejście? Czy obszary zewnętrzne mają okna? Czy damskie i męskie toalety są połączone drzwiami? Czy z okna prezesa jest widok na góry? Czy z kuchni jest łatwy dostęp do tylnej alei? Czy ze stołówki jest łatwy dostęp do kuchni? Czy osoba poruszająca się po systemie korytarzy ma dostęp do każdego pokoju?

Specjaliści w dziedzinie psychometrii z ETS chcą mieć możliwość łatwej zmiany kształtu macierzy ocen. Chcą mieć możliwość zmiany wag, przegrupowania cech do poszczególnych pomocniczych hierarchii itp. Chcą mieć opcję do usuwania cech uznawanych za bezwartościowe lub dodawania nowych. Większość z tych operacji sprowadza się do modyfikacji pojedynczego pliku tekstowego konfiguracji. Ze względów wydajności chcemy obliczyć tylko te cechy, które zostały zawarte w macierzy. Z tego powodu dla każdej cechy utworzyliśmy klasę. Każda z tych klas Feature zawiera metodę Evaluate, która przetwarza strukturę danych z rysunku 30.4 i oblicza wynik. To oznacza, że mamy dziesiątki klas Feature, które przetwarzają tę samą strukturę danych. Takie rozwiązanie oznaczało dublowanie kodu na olbrzymią skalę.

Napisać pętlę raz Aby złagodzić problem dublowania kodu, zaczęliśmy używać wzorca projektowego Metoda szablonowa. To było w 1993 i 1994 roku, na długo zanim cokolwiek wiedzieliśmy o wzorcach projektowych. Rozwiązaniu, które zastosowaliśmy, nadaliśmy nazwę „Napisz pętlę raz” (patrz listingi 30.6 i 30.7). Są to rzeczywiste moduły C++ pochodzące z tamtego programu. Listing 30.6. solspcft.h /* $Header: /Space/src_repository/ets/grande/vgfeat/ solspcft.h,v 1.2 1994/04/11 17:02:02 rmartin Exp $ */ #ifndef FEATURES_SOLUTION_SPACE_FEATURE_H #define FEATURES_SOLUTION_SPACE_FEATURE_H #include "scoring/eval.h" template class Query; class SolutionSpace;

//-------------------------------------------// Name // SolutionSpaceFeature // // Opis // To jest klasa bazowa zawierająca pętlę, która // przetwarza zbiór obszarów rozwiązania, a następnie // znajduje wszystkie pasujące obszary rozwiązania. Czysto wirtualna. // Klasy potomne zawierają metody przetwarzania obszarów. // class SolutionSpaceFeature : public Evaluator { public: SolutionSpaceFeature(Query&); virtual ~SolutionSpaceFeature();

PRZYPADEK ZASTOSOWANIA WZORCA METODA SZABLONOWA

461

virtual Evaluator::Score DoEval(); virtual void NewSolutionSpace(const SolutionSpace&) = 0; virtual Evaluator::Score GetScore() = 0; private: SolutionSpaceFeature(const SolutionSpaceFeature&); SolutionSpaceFeature& operator= (const SolutionSpaceFeature&); }; #endif

Query& itsSolutionSpaceQuery;

Listing 30.7. solspcft.cpp /* $Header: /Space/src_repository/ets/grande/vgfeat/

solspcft.cpp,v 1.2 1994/04/1 1 17:02:00 rmartin Exp $ */ #include "componen/set.h" #include #include #include #include

"vgsolut/solspc.h" "componen/query.h" "vgsolut/scfilter.h" "vgfeat/solspcft.h"

extern ScoringFilter* GscoreFilter; SolutionSpaceFeature::SolutionSpaceFeature(Query& q) : itsSolutionSpaceQuery(q) {} SolutionSpaceFeature::~SolutionSpaceFeature() {} Evaluator::Score SolutionSpaceFeature::DoEval() { Set& theSet = GscoreFilter->GetSolutionSpaces(); SelectiveIteratorai(theSet,itsSolutionSpaceQuery);

}

for (; ai; ai++) { SolutionSpace& as = **ai; NewSolutionSpace(as); } return GetScore();

Jak widać z komentarza w nagłówku, ten kod został napisany w 1994 roku. Z tego powodu może wyglądać trochę dziwnie dla tych czytelników, którzy są przyzwyczajeni do używania biblioteki STL. Jeśli jednak zignorujemy bałagan i dziwaczne iteratory, możemy zobaczyć klasyczny wzorzec projektowy Metoda szablonowa. Funkcja DoEval przetwarza w pętli wszystkie obiekty SolutionSpace. Następnie wywołuje czysto wirtualną funkcję NewSolutionSpace. Pochodne klasy SolutionSpaceFeature implementują metodę NewSolutionSpace i realizują pomiar każdego obszaru pod kątem określonego kryterium oceny. Pochodne klasy SolutionSpaceFeature zawierają metody sprawdzające, czy odpowiednie obszary zostały umieszczone w rozwiązaniu, czy obszary mają odpowiednią powierzchnię i proporcje, czy windy są prawidłowo rozmieszczone itp. Zaletą tego rozwiązania jest to, że pętla, która przetwarza strukturę danych, znajduje się w jednym miejscu. Wszystkie klasy oceniające cechy dziedziczą ją, zamiast ponownie implementować. Niektóre z cech mają za zadanie mierzenie właściwości portali przyłączonych do obszarów. Z tego powodu powieliliśmy wzorzec. Utworzyliśmy klasę PortalFeature — pochodną klasy SolutionSpaceFeature. Implementacja metody NewSolutionSpace w klasie PortalFeature przetwarza w pętli wszystkie portale przekazane za pomocą argumentu SolutionSpace i wywołuje czysto wirtualną funkcję NewPortal(const Portal&) (patrz rysunek 30.5).

462

ROZDZIAŁ 30. FRAMEWORK ETS

Rysunek 30.5. Struktura wzorca projektowego Metoda szablonowa dla klas oceniających

Ta struktura pozwoliła nam stworzyć dziesiątki różnych klas ocen, z których każda przetwarzała strukturę danych planu piętra, „nie wiedząc” o tym, jaką postać ma ta struktura danych. Gdyby szczegóły dotyczące struktury danych planu piętra zmieniły się (np. gdybyśmy zdecydowali się na używanie STL zamiast własnych iteratorów), musielibyśmy zmienić dwie klasy, a nie kilkadziesiąt. Dlaczego zdecydowaliśmy się na użycie wzorca Metoda szablonowa, a nie Strategia4? Zastanówmy się, o ile luźniejsze byłyby sprzężenia, gdybyśmy użyli wzorca Strategia (patrz rysunek 30.6).

Rysunek 30.6. Struktura klas oceny planu piętra z wykorzystaniem wzorca projektowego Strategia

W przypadku zastosowania struktury wzorca projektowego Metoda szablonowa w sytuacji konieczności zmiany algorytmów, które przetwarzają strukturę danych, musielibyśmy zmodyfikować klasy SpaceFeature i PortalFeature. Według wszelkiego prawdopodobieństwa to zmusiłoby nas do kompilacji wszystkich klas reprezentujących cechy. Natomiast w przypadku użycia wzorca Strategia zmiany ograniczyłyby się do dwóch klas Driver. Praktycznie nie ma żadnych okoliczności, które spowodowałyby konieczność kompilacji klas reprezentujących cechy.

4

Oczywiście nie myśleliśmy o tym w tych kategoriach. Gdy podejmowaliśmy tę decyzję, nazwy wzorców nie były jeszcze znane.

PRZYPADEK ZASTOSOWANIA WZORCA METODA SZABLONOWA

463

Dlaczego zatem wybraliśmy wzorzec Metoda szablonowa? Ponieważ jest prostszy. Ponieważ struktura danych raczej nie będzie się często zmieniać. A ponowna kompilacja wszystkich klas reprezentujących cechy zajmuje zaledwie kilka minut. Choć zastosowanie dziedziczenia w strukturze Metoda szablonowa spowodowało powstanie projektu o ściślejszych sprzężeniach oraz pomimo tego, że wzorzec Strategia jest w większym stopniu zgodny z zasadą DIP niż wzorzec Metoda szablonowa, stwierdziliśmy, że nie warto tworzyć dwóch dodatkowych klas po to, by zaimplementować wzorzec Strategia.

Wspólne wymagania dla aplikacji zdawania Programy do zdawania miały sporo cech wspólnych. Na przykład struktura ekranu była taka sama dla wszystkich winiet. Po lewej stronie ekranu było okno, które zawierało kolumnę przycisków. To okno miało nazwę Command Window. Przyciski w oknie Command Window spełniały rolę kontrolek aplikacji. Miały takie etykiety jak Place Item, Erase, Move/Adjust, Zoom i Done. Kliknięcie tych przycisków inicjowało pożądane działania aplikacji. Z prawej strony okna Command Window było okno zadania (Task Window). Był to duży obszar z możliwością przewijania i powiększania, w którym użytkownik mógł narysować swoje rozwiązanie. Standardowo polecenia inicjowane w oknie Command Window były wykorzystywane do modyfikowania zawartości okna Task Window. W rzeczywistości większość poleceń, które zostały zainicjowane w oknie poleceń, wymagała interakcji w oknie Task Window. Na przykład jeśli użytkownik chciał umieścić pokój na planie piętra, musiał kliknąć w oknie Command Window przycisk Place Item. Powodowało to wyświetlenie menu zawierającego dostępne pokoje. Użytkownik miał możliwość wyboru rodzaju pokoju, który chciał umieścić na planie piętra. Następnie użytkownik przenosił wskaźnik myszy do okna Task Window i klikał lokalizację, w której chciał umieścić pokój. W przypadku niektórych winiet powodowało to zakotwiczenie lewego górnego rogu pokoju w miejscu, w którym użytkownik kliknął. Lewy dolny róg pokoju rozciągał się zgodnie z ruchami myszy w oknie zadań do czasu, aż użytkownik kliknął po raz drugi. To kliknięcie powodowało zakotwiczenie lewego dolnego rogu we wskazanej pozycji. Działania te były podobne, ale nie identyczne dla każdej winiety. Niektóre winiety nie obsługiwały pokoi, ale dotyczyły linii konturów, granic działek lub dachów. Chociaż istniały różnice, ogólny paradygmat wykonywania działań w ramach winiety był bardzo podobny. To podobieństwo oznaczało możliwość ponownego wykorzystania kodu. Wskazywało na możliwość utworzenia obiektowego frameworka, który implementuje podobieństwa i pozwala na wygodne wyrażanie różnic. Utworzenie takiego frameworka zakończyło się powodzeniem.

Projekt frameworka do zdawania Framework ETS ostatecznie rozrósł się prawie do 75 000 linii kodu. Oczywiście nie możemy zaprezentować w tej książce wszystkich jego szczegółów. Dlatego wybraliśmy do zaprezentowania dwa najbardziej poglądowe elementy: model zdarzeń i architekturę menedżera zadań. Model zdarzeń. Każde działanie podejmowane przez użytkownika powodowało generowanie zdarzeń. Jeśli użytkownik kliknął przycisk, to było generowane zdarzenie o nazwie zgodnej z tym przyciskiem. Jeśli użytkownik wybrał pozycję z menu, generowane było zdarzenie o nazwie zgodnej z tą pozycją menu. Obsługa tych zdarzeń była istotnym problemem dla frameworka. Przyczyną problemu było to, że bardzo duża część wszystkich zdarzeń mogła być obsłużona przez framework, ale w każdej winiecie mogła wystąpić potrzeba przesłonięcia sposobu, w jaki framework obsługiwał określone zdarzenie. Tak więc był potrzebny sposób, aby w niektórych winietach pozwolić na zmodyfikowanie przetwarzania zdarzeń w razie potrzeby.

464

ROZDZIAŁ 30. FRAMEWORK ETS

Problem dodatkowo komplikował fakt, że lista zdarzeń nie była zamknięta. Każda winieta miała możliwość wyboru własnego zestawu przycisków w oknie Command Window oraz własnego zestawu elementów menu. Tak więc framework powinien obsługiwać zdarzenia, które były wspólne dla wszystkich winiet, a jednocześnie umożliwiać przesłonięcie w każdej winiecie domyślnego przetwarzania. Ponadto gdyby wystąpiła taka potrzeba, powinna istnieć możliwość obsługi zdarzeń specyficznych dla winiety. Spełnienie tego wymagania nie było łatwym zadaniem. Dla przykładu rozważmy diagram z rysunku 30.7. Ten diagram 5 pokazuje niewielki fragment automatu stanów skończonych, który zostanie użyty do obsługi zdarzeń występujących w oknie Command Window winiety. Każda winieta miała własną, specjalną wersję tej maszyny stanów skończonych.

Rysunek 30.7. Procesor zdarzeń okna Command Window

Sposób obsługi trzech różnych rodzajów zdarzeń pokazano na rysunku 30.7. Najpierw rozważmy najprostszy przypadek — zdarzenie ScreenCursor. To zdarzenie jest generowane w odpowiedzi na kliknięcie przycisku Change Cursor. Za każdym razem, gdy użytkownik kliknie ten przycisk, kursor w oknie Task Window przełącza się pomiędzy strzałką a krzyżykiem pełnoekranowym. Tak więc pomimo że kursor zmienił stan, w procesorze zdarzeń nie nastąpiła zmiana stanu. Kiedy użytkownik chce usunąć obiekt, który narysował, klika przycisk Erase. Następnie klika w oknie Task Window ten element bądź elementy, które chce usunąć. Na koniec ponownie klika przycisk Erase, aby zatwierdzić usunięcie. Sposób obsługi tych operacji przez procesor zdarzeń okna Command Window pokazano na rysunku 30.7. Pierwsze zdarzenie Erase powodowało przejście ze stanu Idle do stanu Erasing i uruchomienie zadania EraseTask. Więcej informacji na temat zadań (klas Task) zawiera następny punkt. Na razie wystarczy, jeśli napiszemy, że klasa EraseTask będzie obsługiwała wszystkie zdarzenia, które wystąpią w oknie Task Window. Zwróćmy uwagę, że nawet w stanie Erasing zdarzenie ScreenCursor będzie działać prawidłowo i nie będzie przeszkadzać w operacji usuwania. Zauważmy także, że ze stanu Erasing możliwe jest przejście do dwóch stanów. Jeśli wystąpi kolejne zdarzenie Erase, to następuje zakończenie zadania EraseTask, co powoduje zatwierdzenie usunięcia, a maszyna stanów powraca do stanu bezczynności. To jest normalny sposób zakończenia operacji usuwania. 5

Notacja dla diagramów stanów tego rodzaju została szczegółowo opisana w dodatku B.

PRZYPADEK ZASTOSOWANIA WZORCA METODA SZABLONOWA

465

Innym sposobem zakończenia operacji usuwania jest kliknięcie jakiegoś innego przycisku w oknie Command Window. Jeśli użytkownik kliknie w oknie Command Window przycisk, który uruchamia inne zadanie (np. przycisk Sketch), to następuje przerwanie wykonywania zadania EraseTask i anulowanie operacji usuwania. Sposób działania tego anulowania dla zdarzenia Sketch pokazano na rysunku 30.7. Jest jednak wiele innych zdarzeń, których tu nie pokazano, a które działają w taki sam sposób. Jeśli użytkownik kliknie przycisk Sketch w czasie, kiedy system jest w stanie Erasing bądź Idle, system przejdzie do stanu Idle i wywoła funkcję GetSketchChoices. Funkcja ta wyświetla menu Sketch zawierające listę operacji, które użytkownik może wykonać. Jedną z tych operacji jest pomiar. Kiedy użytkownik wybierze tę operację z menu, zachodzi zdarzenie Measure. To powoduje uruchomienie zadania MeasureTask. Podczas pomiaru użytkownik może kliknąć w dwóch punktach okna Task Window. Te dwa punkty będą oznaczone ikoną celownika, a odległość pomiędzy nimi wyświetli się w niewielkim oknie komunikatów na dole ekranu. Użytkownik może następnie kliknąć dwa kolejne punkty, dwa następne itd. Nie istnieje standardowe wyjście z zadania MeasureTask. Aby zakończyć to zadanie, użytkownik musi kliknąć przycisk, który uruchamia inne zadanie, na przykład Erase lub Sketch. Projekt modelu zdarzeń. Na rysunku 30.8 pokazano statyczny model klas implementujących procesor zdarzeń okna Command Window. Hierarchia po prawej stronie reprezentuje klasę CommandWindow, natomiast hierarchia po lewej reprezentuje maszynę stanów skończonych, która przekształca zdarzenia na akcje.

Rysunek 30.8. Statyczny model procesora zdarzeń okna Command Window CommandWindow, StandardCommandWindow oraz StandardFSM to klasy frameworka. Pozostałe klasy są specyficzne dla winiety. Klasa CommandWindow dostarcza implementacji standardowych akcji, takich jak MeasureTask oraz EraseTask. Zdarzenia są obsługiwane przez klasę VignetteCommandWindow. Są one przesyłane do maszyny stanów skończonych, która przekształca je na akcje. Akcje są następnie przesyłane do hierarchii klas CommandWindow, gdzie są zaimplementowane.

466

ROZDZIAŁ 30. FRAMEWORK ETS

Klasa CommandWindow dostarcza implementacji standardowych akcji, takich jak MeasureTask oraz EraseTask. Akcje „standardowe” są wspólne dla wszystkich winiet. Klasa StandardCommandWindow umożliwia przekazywanie standardowych zdarzeń do maszyny stanów skończonych. Klasa VignetteCommandWindow jest specyficzna dla winiety i zawiera zarówno implementację specyficznych akcji, jak i przekazywanie specyficznych zdarzeń. Pozwala także na nadpisywanie standardowych operacji implementacji i przekazywania. Tak więc framework zapewnia domyślne implementacje i operacje przekazywania dla wszystkich typowych zadań. Jednak wszystkie te implementacje mogą być przesłonięte na poziomie konkretnych winiet. Obsługa zdarzenia standardowego. Na rysunku 30.9 pokazano sposób przekazywania standardowego zdarzenia do maszyny stanów skończonych i przekształcania na standardową akcję. Pierwszym komunikatem jest zdarzenie Measure. Jego źródłem jest GUI. To zdarzenie jest przekazywane do obiektu klasy VignetteCommandWindow. Domyślna obsługa tego zdarzenia jest dostarczana przez obiekt StandardCommandWindow, który przekazuje zdarzenie do obiektu StandardFSM za pomocą komunikatu 1.1.

Rysunek 30.9. Przetwarzanie zdarzenia Measure StandardFSM jest klasą frameworka, która zapewnia interfejs dla wszystkich przychodzących standardowych zdarzeń i wszystkich wychodzących standardowych akcji. Żadna z tych funkcji nie jest implementowana na tym poziomie. Klasa VignetteFSMContext dodaje interfejsy, ale nie dodaje implementacji dla wszystkich specyficznych dla winiety zdarzeń i akcji. Najważniejsza część operacji przekształcenia zdarzenia na akcję zachodzi w klasach VignetteFSM i VignetteFSMState. Klasa VignetteFSM zawiera implementacje wszystkich funkcji obsługi zdarzeń. A zatem komunikat 1.1:Measure dociera do tego poziomu. Obiekt VignetteFSM odpowiada, przesyłając komunikat 1.1.1:Measure(this) do obiektu VignetteFSMState. VignetteFSMState jest klasą abstrakcyjną. Istnieją pochodne tej klasy dla każdego stanu maszyny stanów skończonych. W sytuacji z rysunku 30.9 zakładamy, że bieżącym stanem maszyny FSM jest Idle (patrz rysunek 30.7). W związku z tym komunikat 1.1.1:Measure(this) jest przekazywany do

PRZYPADEK ZASTOSOWANIA WZORCA METODA SZABLONOWA

467

obiektu IdleState. Ten obiekt odpowiada, przesyłając dwa komunikaty do obiektu VignetteFSM. Pierwszy to 1.1.1.1:SetState(ms). Ten komunikat zmienia stan maszyny FSM na wartość Measuring. Drugi komunikat to 1.1.1.2:MeasureTask(). Jest to akcja wymagana przez zdarzenie Measure w stanie Idle. Ostateczna implementacja zadania MeasureTask mieści się w obiekcie klasy VignetteFSMGlue, który rozpoznaje ją jako standardową akcję zadeklarowaną w obiekcie CommandWindow i dlatego przekazuje ją w komunikacie 1.1.1.2.1:MeasureTask, tym samym zamykając obwód. Mechanizmem konwersji zdarzeń na akcje jest wzorzec projektowy Stan. Z tego wzorca bardzo często korzystaliśmy w wielu obszarach frameworka. Pokażemy to w kolejnych punktach. Stereotyp «generated» występujący w klasach należących do wzorca Stan oznacza, że te klasy zostały wygenerowane automatycznie przez kompilator SMC. Obsługa zdarzenia specyficznego dla winiety. Na rysunku 30.10 pokazano, co się dzieje w sytuacji, gdy zajdzie zdarzenie specyficzne dla winiety. Tak jak wcześniej komunikat 1:SpecificEvent jest przechwytywany przez obiekt klasy VignetteCommandWindow. Ponieważ jednak przekazywanie specyficznych zdarzeń jest implementowane na tym poziomie, obiekt klasy VignetteCommandWindow przesyła komunikat 1.1:SpecificEvent. Dodatkowo przesyła go do obiektu klasy VignetteFSMContext, gdzie metoda SpecificEvent była pierwotnie zadeklarowana.

Rysunek 30.10. Przetwarzanie zdarzenia specyficznego dla winiety

Tak jak poprzednio zdarzenie jest dostarczane do obiektu VignetteFSM, który w komunikacie 1.1.1:SpecificEv negocjuje z obiektem reprezentującym bieżący stan w celu wygenerowania odpowiedniej akcji. Tak jak poprzednio obiekt odpowiada dwoma komunikatami: 1.1.1.1:SetState oraz 1.1.1.2:SpecificTask. Komunikat jest przekazywany do obiektu VignetteFSMGlue. Jednak tym razem jest on rozpoznawany jako akcja specyficzna dla winiety, dlatego jest on kierowany bezpośrednio do obiektu klasy Vignette CommandWindow, gdzie są zaimplementowane specyficzne akcje.

468

ROZDZIAŁ 30. FRAMEWORK ETS

Generowanie i wielokrotne wykorzystywanie maszyny stanów okna Command Window. W tym momencie można się zastanawiać, dlaczego obsługa zdarzeń i akcji wymaga tak wielu klas. Weźmy jednak pod uwagę, że chociaż istnieje wiele klas, jest bardzo mało obiektów. W rzeczywistości egzemplarze są tworzone dla klas VignetteCommandWindow, VignetteFSMGlue oraz obiektów reprezentujących niektóre stany. Są to jednak trywialne operacje, które są generowane automatycznie. Chociaż przepływ komunikatów sprawia wrażenie złożonego, w rzeczywistości jest dość prosty. Okno wykrywa zdarzenie, przekazuje je do maszyny FSM w celu przekształcenia na akcję, a następnie pobiera akcję z maszyny FSM. Pozostała złożoność dotyczy oddzielenia standardowych działań znanych dla frameworka od konkretnych akcji znanych dla winiety. Kolejnym czynnikiem, który wpłynął na decyzję o takim podziale na klasy, było wykorzystanie kompilatora SMC do automatycznego wygenerowania klas maszyny stanów skończonych. Przeanalizujmy poniższy opis i powróćmy do rysunku 30.7: Idle { Measure Measuring MeasureTask Erase Erasing StartEraseTask Sketch Idle GetSketchChoice }

Zwróćmy uwagę, że ten prosty tekst opisuje wszystkie przejścia, które występują w sytuacji, kiedy maszyna jest w stanie Idle. Trzy linijki w nawiasie klamrowym identyfikują zdarzenie wyzwalające przejście, docelowy stan przejścia oraz akcję wykonywaną w ramach przejścia. Kompilator SMC6 pobiera tekst w tej postaci i generuje klasy opisane stereotypem «generated». Kod wygenerowany przez SMC nie wymaga edycji ani inspekcji. Dzięki wykorzystaniu kompilatora SMC do stworzenia maszyny stanów utworzenie tej części procesora zdarzeń dla winiety jest dość proste. Deweloper musi napisać klasę VignetteCommandWindow zawierającą właściwe implementacje specyficznych zdarzeń i akcji. Musi także napisać klasę VignetteFSMContext, która zawiera deklaracje interfejsów dla specyficznych zdarzeń i akcji. Na koniec musi napisać klasę VignetteFSMGlue, której zadaniem jest dostarczanie akcji do obiektu klasy VignetteCommandWindow. Napisanie żadnej z tych klas nie jest szczególnie trudne. Jest jeszcze jedna rzecz, którą deweloper powinien zrobić. Musi napisać opis maszyny stanów skończonych dla kompilatora SMC. Ta maszyna stanów jest dość złożona. Schemat na rysunku 30.7 nie usprawiedliwia tej złożoności. Rzeczywista winieta musi obsługiwać wiele dziesiątek różnych zdarzeń. Każde z tych zdarzeń charakteryzuje się zupełnie innym zachowaniem. Na szczęście większość winiet zachowuje się podobnie. Dzięki temu mogliśmy użyć standardowego opisu maszyny stanów jako modelu i wprowadzić w nim stosunkowo niewielkie zmiany dla każdej winiety. Zatem każda winieta ma własny opis maszyny FSM. Takie podejście jest w pewnym stopniu niezadowalające, ponieważ zawartość plików z opisami FSM była bardzo podobna. Było kilka sytuacji, kiedy musieliśmy zmienić ogólny stan maszyny. To oznaczało konieczność wprowadzenia identycznych lub prawie identycznych zmian w każdym z plików opisów FSM. Wykonywanie tego rodzaju zmian jest zarówno żmudne, jak i stwarza okazje do popełnienia błędów. Moglibyśmy stworzyć kolejny mechanizm do oddzielania uniwersalnej część opisu FSM od części specyficznej, ale ostatecznie stwierdziliśmy, że nie byłoby to warte podejmowania wysiłku. Podjęcia tej decyzji wielokrotnie żałowaliśmy.

6

SMC — kompilator maszyn stanów jest dostępny za darmo pod adresem http://www.objectmentor.com.

PRZYPADEK ZASTOSOWANIA WZORCA METODA SZABLONOWA

469

Architektura menedżera zadań Powyżej opisaliśmy sposób przekształcania zdarzeń na akcje. Widzieliśmy, że ta konwersja jest uzależniona od stosunkowo skomplikowanej maszyny stanów skończonych. W tym punkcie przyjrzymy się sposobom przetwarzania akcji. Nie powinno nikogo dziwić, że zasadniczą częścią każdej akcji także steruje maszyna stanów skończonych. Przeanalizujmy zadanie MeasureTask, które omawialiśmy w poprzednim punkcie. Użytkownik wywołuje to zadanie, gdy chce zmierzyć odległość między dwoma punktami. Po wywołaniu zadania użytkownik klika punkt w oknie Task Window. W tym miejscu pojawia się mały celownik. Kiedy użytkownik przesuwa wskaźnik myszy, rysowany jest odcinek od punktu, w którym kliknął użytkownik, do punktu wskazującego bieżącą pozycję myszy. Ponadto aktualna długość tego odcinka jest wyświetlana w osobnym oknie komunikatów. Kiedy użytkownik kliknie myszą po raz drugi, rysowany jest drugi celownik. Rozciągany odcinek znika, a w oknie komunikatu jest wyświetlana odległość dzieląca dwa wskazane punkty. Jeżeli użytkownik ponownie kliknie jakiś punkt, proces się powtarza. Kiedy procesor zdarzeń wybierze zadanie MeasureTask, tak jak pokazano na rysunku 30.9, obiekt CommandWindow tworzy właściwy obiekt MeasureTask, który następnie uruchamia maszynę stanów skończonych pokazaną na rysunku 30.11.

Rysunek 30.11. Maszyna stanów skończonych dla zadania MeasureTask

Zadanie MeasureTask rozpoczyna swoje życie od wywołania funkcji init. Następnie przechodzi do stanu GetFirstPoint. Zdarzenia GUI zachodzące w oknie Task Window są kierowane do obiektu aktualnie wykonywanego zadania. W związku z tym kiedy użytkownik przesunie wskaźnik myszy w oknie Task Window, bieżące zadanie otrzymuje komunikat MovePoint. Zwróćmy uwagę, że w stanie GetFirstPoint nie powoduje to wykonania żadnej akcji (zgodnie z oczekiwaniem). Kiedy użytkownik w końcu kliknie w oknie Task Window, zachodzi zdarzenie GotPoint. To powoduje przejście do stanu GetSecondPoint i wywołanie akcji RecordStartPt. Akcja ta powoduje narysowanie pierwszego celownika oraz zapamiętanie lokalizacji kliknięcia pierwszego punktu. W stanie GetSecondPoint zdarzenie MovePoint powoduje wywołanie akcji Dragline. Ta akcja ustawia tryb XOR7 i powoduje narysowanie linii od zapamiętanego punktu początkowego do bieżącej lokalizacji wskaźnika myszy. Oblicza również odległość między tymi dwoma punktami i wyświetla ją w oknie komunikatów.

7

Tryb XOR jest jednym z trybów interfejsu GUI. Ten tryb znacznie upraszcza problem przeciągania rozciągalnych linii i kształtów nad kształtami narysowanymi na ekranie. Jeśli nie rozumiesz działania tego trybu, nie musisz się tym przejmować.

470

ROZDZIAŁ 30. FRAMEWORK ETS

Zdarzenia MovePoint zachodzą często — zawsze wtedy, gdy przesuwamy wskaźnik myszy w oknie Task Window. Zatem rysunek linii oraz wartość długości wyświetlana w oknie komunikatów w czasie, gdy wskaźnik myszy jest w ruchu, są stale aktualizowane. Kiedy użytkownik kliknie w oknie Task Window po raz drugi, następuje ponowne przejście do stanu GetSecondPoint i wywołanie akcji RecordEndPt. Ta akcja wyłącza tryb XOR, usuwa odcinek łączący pierwszy punkt z bieżącą pozycją myszy, wykreśla ikonę celownika w punkcie pierwszego kliknięcia, a następnie wyświetla w oknie komunikatu odległość pomiędzy punktem początkowym a punktem kliknięcia. Ta sekwencja zdarzeń jest powtarzana tak długo, jak długo życzy sobie tego użytkownik. Przerwanie sekwencji następuje tylko w wyniku anulowania jej przez obiekt CommandWindow — najprawdopodobniej w odpowiedzi na kliknięcie przez użytkownika przycisku polecenia. Na rysunku 30.12 pokazano schemat maszyny stanów nieco bardziej złożonego zadania — rysowania ramki wyznaczonej przez dwa punkty. Ramka jest prostokątem rysowanym na ekranie w odpowiedzi na dwa kliknięcia. Pierwsze kliknięcie powoduje zakotwiczenie pierwszego narożnika ramki. Rozciągalna ramka rozszerza się zgodnie z ruchem myszy. Kiedy użytkownik kliknie po raz drugi, ramka staje się trwała.

Rysunek 30.12. Maszyna stanów ramki wyznaczonej przez dwa punkty

Tak jak poprzednio zadanie rozpoczyna się w stanie GetPoint1, po wywołaniu metody Init. W tym stanie ruch myszy jest ignorowany. Po kliknięciu myszą następuje przejście do stanu GetPoint2 i wywołanie akcji RecordPoint1. Akcja rejestruje punkt kliknięcia jako początkowy. W stanie GetPoint2 ruch myszą powoduje wywołanie akcji DragBox. Ta akcja ustawia tryb XOR i powoduje narysowanie rozciągalnej ramki od punktu początkowego do bieżącej lokalizacji wskaźnika myszy. Kiedy użytkownik zwolni przycisk myszy, następuje przejście do stanu WaitingForUp i wywołanie akcji RecordPoint2. Ta funkcja po prostu rejestruje punkt końcowy ramki. Nie wyłącza trybu XOR, nie usuwa rozciągalnej ramki ani nie rysuje trwałej ramki, ponieważ w tym momencie nie jesteśmy jeszcze pewni, czy ramka jest prawidłowa. W tym momencie przycisk myszy jest nadal wciśnięty, a użytkownik ma zamiar podnieść palec, by go zwolnić. Musimy czekać na to zdarzenie. W przeciwnym razie może zajść inne zdarzenie wyzwalane zwolnieniem przycisku myszy, co wprowadzi zamieszanie. Podczas oczekiwania ignorujemy wszelkie ruchy myszą. Ramka pozostaje zakotwiczona w punkcie ostatniego kliknięcia.

PRZYPADEK ZASTOSOWANIA WZORCA METODA SZABLONOWA

471

Kiedy użytkownik zwolni przycisk myszy, następuje przejście do stanu AddingBox i wywołanie akcji AddBox. Ta funkcja sprawdza, czy ramka jest prawidłowa. Ramka może być nieprawidłowa z wielu powodów. Może być zdegenerowana (tzn. punkt kliknięcia po raz pierwszy i po raz drugi są takie same) albo występuje konflikt z inną figurą na rysunku. Program każdej winiety ma prawo odrzucić coś, co użytkownik próbował narysować. Jeśli okaże się, że ramka jest nieprawidłowa, generowane jest zdarzenie Invalid, a maszyna stanów ponownie przechodzi do stanu GetPoint1, wywołując funkcję StartOver. Jeżeli jednak okaże się, że ramka jest prawidłowa, generowane jest zdarzenie BoxAdded. To powoduje wywołanie funkcji CheckComplete. To jest kolejna funkcja specyficzna dla winiety. Określa ona, czy użytkownik powinien mieć możliwość rysowania dalszych ramek, czy też zadanie powinno zostać zakończone. Istnieją dosłownie dziesiątki takich zadań we frameworku. Każde z nich jest reprezentowane przez pochodną klasy Task (patrz rysunek 30.13). Implementacja każdego zadania bazuje na wewnętrznej maszynie stanów skończonych i jest znacząco bardziej złożona od tego, co zdołaliśmy pokazać w tym rozdziale. Chciałbym jeszcze raz podkreślić, że wszystkie te maszyny stanów zostały wygenerowane za pomocą kompilatora SMC.

Rysunek 30.13. Architektura menedżera zadań

Architekturę menedżera zadań zaprezentowano na rysunku 30.13. Ta architektura łączy klasy CommandWindow z TaskWindow oraz tworzy zadania wskazane przez użytkownika i zarządza nimi.

472

ROZDZIAŁ 30. FRAMEWORK ETS

Diagram prezentuje dwa zadania, których maszyny stanów FSM zostały przedstawione na rysunkach 30.11 i 30.12. Zwróćmy uwagę na zastosowanie wzorca projektowego Stan oraz klasy wygenerowane dla każdego z zadań. Wszystkie te klasy, wraz z MeasureTaskImplementation oraz TwoPointBoxImplementation, należą do frameworka. Jedynymi klasami, które deweloper musi napisać, są VignetteTaskWindow oraz szczegółowe pochodne klas reprezentujących zadania. Klasy MeasureTaskImplementation i TwoPoint BoxImplementation reprezentują wiele różnych zadań zawartych we frameworku. Zwróćmy jednak uwagę, że te klasy są abstrakcyjne. Jest tylko kilka funkcji, na przykład AddBox oraz CheckComplete, które nie są zaimplementowane. Funkcje te muszą być zaimplementowane w każdej z winiet zgodnie z indywidualnymi wymaganiami. Zatem zadania zawarte we frameworku zarządzają większością interakcji we wszystkich winietach. Za każdym razem, kiedy deweloper chce narysować ramkę lub obiekt związany z ramką, może utworzyć nową pochodną klasy TwoPointBoxImplementation. A zawsze gdy chce umieścić jakiś obiekt na ekranie za pomocą pojedynczego kliknięcia, może utworzyć pochodną klasy SinglePointPlacementTask. Natomiast jeśli chce coś narysować, korzystając z łamanej, może stworzyć pochodną klasy PolylineTask. Te zadania zarządzają interakcjami, pozwalają na wykonywanie wymaganego przeciągania i dają inżynierowi narzędzia potrzebne do sprawdzania poprawności i tworzenia obiektów, których potrzebuje.

Wniosek Oczywiście framework zawiera wiele innych elementów, których nie zdołaliśmy opisać w tym rozdziale. Mogliśmy omówić te elementy frameworka, które dotyczą obsługi geometrii obliczeniowej, lub fragmenty dotyczące zapisywania rozwiązań w plikach i odczytywania ich z plików. Mogliśmy omówić strukturę plików parametrów, które pozwoliłyby aplikacji każdej winiety na stworzenie wielu różnych odmian tej samej winiety. Niestety, nie pozwoliły na to ani miejsce, ani czas. Jednak uważamy, że opisaliśmy te aspekty frameworka, które są najbardziej pouczające. Strategie wykorzystane do tworzenia tego frameworka mogą być wykorzystywane przez innych projektantów do tworzenia własnych frameworków wielokrotnego użytku.

Bibliografia 1. Grady Booch, Object-Oriented Design with Applications, Redwood City, CA: Benjamin Cummings, 1991. 2. Grady Booch, Object Solutions, Menlo Park, CA: Addison-Wesley, 1996. 3. Gamma, et al., Design Patterns, Reading, MA: Addison-Wesley, 1995.

D ODATEK A

Notacja UML. Część I: Przykład CGI Analiza i projektowanie oprogramowania to proces, który potrzebuje jakiejś notacji. Było wiele prób ich tworzenia. Schematy przepływu sterowania, diagramy przepływu danych, diagramy relacji pomiędzy encjami itp. Pojawienie się programowania obiektowego spowodowało eksplozję różnych notacji. Powstały dosłownie dziesiątki konkurencyjnych sposobów opisu służących do reprezentowania analiz i projektów obiektowych. Do najbardziej popularnych należały następujące notacje:    

Booch 941. OMT (Object Modeling Technique) opisana przez Rumbaugha i współautorów2. RDD (Responsibility Driven Design) opisana przez Wirfs-Brock i współautorów3. Coad/Yourdon opisana przez Petera Coada i Eda Yourdona4.

Spośród wymienionych najważniejszymi były notacje Booch 94 i OMT. Booch 94 zdobyła uznanie jako dobra notacja projektów, natomiast OMT była uważana za lepszą w dziedzinie notacji analizy. Ta dychotomia jest interesująca. Pod koniec lat osiemdziesiątych i na początku dziewięćdziesiątych za jedną z zalet paradygmatu obiektowego uznano to, że analiza i projektowanie mogą być reprezentowane przy użyciu tego samego zapisu. Być może była to reakcja na silną separację pomiędzy notacjami analizy strukturalnej i projektowania strukturalnego. Było powszechnie wiadome, że pokonanie przepaści od analizy strukturalnej do strukturalnego projektu jest bardzo trudne. Gdy na scenie po raz pierwszy pojawiły się notacje obiektowe, uznano, że ten sam zapis będzie służył zarówno do analizy, jak i projektowania. Jednak w miarę upływu lat analitycy i projektanci zaczęli migrować do swoich ulubionych notacji. Analitycy zwykle faworyzowali notację OMT, natomiast projektanci wykazywali tendencję do faworyzowania notacji Booch 94. W związku z tym stało się jasne, że jeden sposób zapisu nie będzie wystarczający. Notacja zoptymalizowana pod kątem analizy nie była właściwa dla projektu i odwrotnie. UML jest uniwersalnym sposobem opisu, który ma szeroki zakres zastosowań. Niektóre fragmenty nadają się do analizy, natomiast inne do prezentowania projektu. Dzięki temu język UML może być stosowany zarówno przez analityków, jak i projektantów. W niniejszym dodatku zaprezentujemy notację UML z obu perspektyw. Najpierw zajmiemy się analizą, a następnie przejdziemy do opisu projektu. Opis ten będzie miał formę miniaturowego studium przypadku. Należy pamiętać, że to uszeregowanie — najpierw analiza, a potem projekt — jest sztuczne i nie ma być traktowane jako zalecenie. W istocie w żadnym z pozostałych studiów przypadków w tej książce nie rozgraniczaliśmy analizy i projektu. W tej książce przedstawiłem to w takiej kolejności po to, aby zilustrować sposób wykorzystania UML na różnych poziomach abstrakcji. W rzeczywistym projekcie wszystkie poziomy abstrakcji powstają równocześnie, a nie jeden po drugim. 1

[BOOCH94].

2

[RUMBAUGH91].

3

[WIRFS90].

4

[COAD91A].

474

DODATEK A NOTACJA UML. CZĘŚĆ I: PRZYKŁAD CGI

System rejestrowania kursów: opis problemu Załóżmy, że pracujemy dla firmy, która oferuje profesjonalne szkolenia w zakresie analizy i projektowania obiektowego. Firma potrzebuje systemu, który zarządza prowadzonymi kursami oraz ich uczestnikami. Więcej informacji na ten temat można znaleźć w ramce „System rejestrowania kursów”.

System rejestrowania kursów Użytkownicy muszą mieć możliwość wyświetlenia menu dostępnej oferty kursów i wybrania kursu, na który chcą się zapisać. Po wybraniu kursu powinien wyświetlić się formularz, który pozwoli użytkownikowi wprowadzić następujące informacje:    

nazwisko, numer telefonu, numer faksu, adres e-mail.

Powinna istnieć możliwość wyboru sposobu zapłaty za kurs. Do wyboru powinny być następujące metody płatności:  czek,  przelew,  karta kredytowa.

Jeśli użytkownik chce zapłacić czekiem, to w formularzu powinno wyświetlić się pole do wprowadzania numeru czeku. Jeśli użytkownik chce zapłacić kartą kredytową, to w formularzu powinny wyświetlić się pola do wprowadzania numeru karty kredytowej, daty ważności oraz nazwiska w formie występującej na karcie. Jeśli użytkownik chce zapłacić za pomocą polecenia zapłaty, to w formularzu powinny wyświetlić się pola do wprowadzenia numeru polecenia zapłaty, nazwy firmy oraz nazwiska i numeru telefonu osoby reprezentującej instytucję płatniczą. Po wypełnieniu tych informacji użytkownik klika przycisk Prześlij. W tym momencie powinien wyświetlić się kolejny ekran z podsumowaniem informacji wprowadzonych przez użytkownika. Na tym ekranie powinny znaleźć się instrukcje dla użytkownika polecające wydrukowanie formularza, podpisanie drukowanej kopii i wysłania faksem na numer centrum rekrutacji. Informacje z podsumowaniem powinny być również wysłane e-mailem do pracowników zajmujących się rejestracją oraz do użytkownika. System powinien znać maksymalną liczbę uczestników w każdej grupie i w momencie osiągnięcia limitu automatycznie oznaczać ofertę kursu jako „sprzedano”. Pracownik rejestracji ma możliwość wysłania wiadomości e-mail do wszystkich uczestników zarejestrowanych na danym kursie poprzez wyświetlenie specjalnego formularza i wybranie kursu. Ten formularz pozwoli pracownikowi na wpisanie wiadomości, a następnie naciśnięcie przycisku. Kliknięcie tego przycisku spowoduje wysłanie wiadomości do wszystkich uczestników wybranego kursu. Pracownik rejestracji będzie mógł również wyświetlić formularz z informacjami na temat wszystkich uczestników i zajęć, które już zostały przeprowadzone. Status będzie wskazywał na to, czy uczestnik był obecny oraz czy otrzymano od studenta płatność za kurs. Ten formularz będzie także zapewniał możliwość wyboru kursu. Pracownik rejestracji będzie mógł także zażądać listy wszystkich uczestników kursów, którzy mają nierozliczone salda.

SYSTEM REJESTROWANIA KURSÓW: OPIS PROBLEMU

475

Zidentyfikowanie aktorów i przypadków użycia. Jednym z zadań analizy wymagań jest identyfikacja aktorów i przypadków użycia. Należy zwrócić uwagę, że w rzeczywistym systemie to niekoniecznie muszą być pierwsze dwa zadania, które są wykonywane. Ale dla celów tego rozdziału postanowiłem zacząć od tego miejsca. W praktyce miejsce, od którego zaczynamy, jest mniej istotne od samego faktu rozpoczęcia pracy.

Aktorzy Aktorzy są podmiotami, które oddziałują z systemem, ale są na zewnątrz systemu. Często są to role spełniane przez użytkowników systemu. Czasami jednak mogą je spełniać inne systemy. W poniższym przykładzie wszyscy aktorzy są reprezentowani przez użytkowników-ludzi. Kandydat. Ten aktor rejestruje uczestnika kursu. Komunikuje się z systemem, aby wybrać odpowiedni kurs. Wprowadza informacje na temat uczestnika i sposobu płatności. Kancelista. Ten aktor otrzymuje powiadomienia e-mail dla każdej rejestracji. Wysyła również powiadomienia e-mail do uczestników kursu i otrzymuje raporty dotyczące zapisów i płatności. Uczestnik. Ten aktor otrzymuje e-mail z potwierdzeniem rejestracji oraz e-maile z powiadomieniami od kancelisty. Uczestnik bierze udział w kursach, na które się zapisał.

Przypadki użycia Po określeniu aktorów można opisać interakcje tych podmiotów z systemem. Te specyfikacje są nazywane „przypadkami użycia”. Przypadek użycia opisuje interakcje między aktorem a systemem z punktu widzenia aktora. Nie są w nim szczegółowo opisywane żadne wewnętrzne mechanizmy systemu ani interfejs użytkownika. Przypadek użycia nr 1: Przeglądanie menu kursów. Kandydat żąda listy aktualnie dostępnych kursów w katalogu kursów. System wyświetla listę kursów. Na tej liście są zapisane nazwisko, czas, miejsce i koszt kursu. Lista zawiera także dopuszczalną liczbę uczestników kursu oraz informację o tym, czy kurs jest obecnie wyprzedany. Notacja przypadków użycia. Na rysunku powyżej przedstawiono aktora i przypadek użycia za pomocą diagramu przypadku użycia. Aktor jest reprezentowany przez rysunek ludzika, natomiast przypadek użycia — przez elipsę. Są one ze sobą połączone za pomocą asocjacji, która wskazuje kierunek przepływu danych. Przypadek użycia nr 2: Zapisanie się na kurs. Najpierw kandydat przegląda menu kursów (przypadek użycia nr 1). Następnie wybiera z menu kurs, na który chce się zapisać. System prosi go o podanie nazwiska, numeru telefonu, numeru faksu i adresu e-mail. System pyta również kandydata o preferowany sposób płatności.

Punkt rozszerzenia: wprowadzenie danych o metodzie płatności Kandydat wysyła formularz zgłoszeniowy. Do uczestnika i kancelisty są wysyłane wiadomości e-mail z potwierdzeniem rejestracji. Na ekranie kandydata wyświetla się potwierdzenie rejestracji z monitem o wydrukowanie go, podpisanie i przesłanie pod konkretny numer faksu. Rozszerzanie i korzystanie z przypadków użycia. Przypadek użycia nr 2 zawiera punkt rozszerzenia. Oznacza to, że będzie rozszerzany przez inne przypadki użycia. Przypadki użycia rozszerzeń zaprezentowano poniżej. Są oznaczone numerami 2.1, 2.2 i 2.3. Ich opisy są umieszczone w poprzednim przypadku użycia w punkcie rozszerzenia. Opisują opcjonalne dane, które muszą zostać wprowadzone w zależności od wybranego sposobu płatności.

476

DODATEK A NOTACJA UML. CZĘŚĆ I: PRZYKŁAD CGI

Przypadek użycia nr 2 zawiera również relację «include» z przypadkiem użycia nr 1: „Przeglądanie menu kursów”. Oznacza to, że opis przypadku użycia nr 1 jest umieszczony w odpowiednim miejscu przypadku użycia nr 2. Należy zwrócić uwagę na różnicę między rozszerzaniem a zawieraniem. Gdy przypadek użycia zawiera inny, to odwołuje się do przypadku użycia, który się w nim zawiera. Jeśli jednak przypadek użycia rozszerza inny, to żaden z dwóch przypadków użycia nie odwołuje się do tego drugiego. Zamiast tego rozszerzający przypadek użycia jest wybierany z kontekstu i wstawiany do rozszerzonego przypadku użycia w odpowiednim punkcie. Relacji «include» używamy, gdy chcemy, aby struktura przypadków użycia była bardziej zwięzła. Zwijamy powtarzające się operacje w mniejsze przypadki użycia. Następnie mogą być one współdzielone przez wiele innych przypadków użycia. Celem jest zarządzanie zmianami i wyeliminowanie redundancji. Przeniesienie części wspólnych wielu przypadków użycia do jednego przypadku użycia daje tę korzyść, że gdy zmienią się wymagania tej części wspólnej, to trzeba zmienić tylko ten jeden przypadek użycia, który został zawarty w innych. Relacji «extend» używamy, gdy wiemy, że istnieje wiele alternatywnych rozwiązań lub opcji w ramach przypadku użycia. Oddzielamy niezmienną część przypadku użycia od części zmiennej. Rolę niezmiennej części przejmuje przypadek użycia, który jest rozszerzany, natomiast funkcję części zmiennych przejmują rozszerzające przypadki użycia. Celem, tak jak wcześniej, jest zarządzanie zmianami. Jeśli w prezentowanym przykładzie są dodawane nowe opcje płatności, to trzeba stworzyć nowe, rozszerzające przypadki użycia, ale nie trzeba modyfikować żadnych istniejących przypadków użycia. Notacja relacji «include». Diagram przypadku użycia nr 2 pokazuje, że przypadek użycia „Zapisanie się na kurs” jest powiązany z przypadkiem użycia „Przeglądanie menu kursów” za pomocą linii przerywanej zakończonej strzałką. Grot strzałki wskazuje na zawarty przypadek użycia i jest oznaczony stereotypem «include». Przypadek użycia nr 2.1: Płatność przelewem. System prosi kandydata o podanie numeru polecenia zapłaty, nazwy firmy oraz nazwiska i numeru telefonu osoby reprezentującej dział księgowości. Przypadek użycia nr 2.2: Płatność czekiem. System prosi kandydata o podanie numeru czeku. Przypadek użycia nr 2.3: Płatność kartą kredytową. System prosi kandydata o podanie numeru karty kredytowej, daty ważności oraz nazwiska w formie występującej na karcie. Notacja rozszerzeń przypadków użycia. Przypadki użycia rozszerzeń zaprezentowane powyżej są połączone z rozszerzonym przypadkiem użycia za pomocą relacji «extend». Tę relację rysuje się w formie linii, która łączy dwa przypadki użycia. Tak jak wcześniej linia przerywana jest zakończona grotem. Grot strzałki wskazuje na rozszerzony przypadek użycia i jest oznaczony stereotypem «extend». Przypadek użycia nr 3: Wysyłanie wiadomości e-mail do uczestników. Kancelista wybiera kurs i wprowadza tekst wiadomości. System wysyła wiadomość pod adresy e-mail wszystkich uczestników aktualnie zapisanych na określony kurs.

SYSTEM REJESTROWANIA KURSÓW: OPIS PROBLEMU

477

Przypadek użycia nr 4: Oznaczenie statusu obecności. Kancelista wybiera kurs i uczestnika, który jest obecnie zapisany na ten kurs. System prezentuje dane uczestnika i pokazuje, czy był on obecny na zajęciach kursu oraz czy wpłata tego studenta została odebrana. Kancelista może następnie zmienić status obecności lub płatności. Przypadek użycia nr 5: Pobranie statusu uczestnika. Kancelista wybiera uczestników, którzy go interesują.

Punkt rozszerzenia: „wybranie uczestników” System wyświetla raport zawierający status obecności i płatności wybranych uczestników.

Rozszerzenia Są dwa przypadki użycia, które rozszerzają przypadek użycia „Pobranie statusu uczestników”. Przypadek użycia nr 5.1: Wybranie uczestników kursu. System wyświetla listę wszystkich kursów. Kancelista wybiera kurs. System wybiera wszystkich uczestników tego kursu. Przypadek użycia nr 5.2: Wybranie uczestników z zaległościami w płatnościach. Kancelista zaznacza chęć wybrania wszystkich uczestników, którzy mają zaległości w płatnościach. System wybiera wszystkich uczestników, którzy byli obecni na zajęciach kursu, a których status wskazuje, że płatność nie została odebrana. Przypadki użycia. Podsumowanie. Przypadki użycia, które stworzyliśmy powyżej, opisują, jakiego zachowania systemu oczekują użytkownicy. Zwróćmy uwagę, że przypadki użycia nie mówią nic na temat szczegółów interfejsu użytkownika. Nie ma w nich wzmianki o ikonach, elementach menu, przyciskach czy też listach przewijania. Nawet początkowa specyfikacja mówi więcej o interfejsie użytkownika niż przypadki użycia. To jest celowe. Chcemy, aby przypadki użycia były „lekkie” i łatwe do utrzymania. W tej formie, w jakiej zostały napisane, te przypadki użycia są prawidłowe dla bardzo dużego zbioru możliwych implementacji. Schemat granic systemu. Cały zbiór przypadków użycia można zaprezentować razem na schemacie granic systemu, który pokazano na rysunku A-1. Na tym diagramie pokazano wszystkie przypadki użycia w systemie otoczone prostokątem reprezentującym granice systemu. Aktorzy są poza systemem i są połączeni z przypadkami użycia za pomocą asocjacji, które pokazują kierunek przepływu danych. Do czego używamy tych diagramów? Diagramy przypadków użycia, z diagramami granic systemu włącznie, nie są schematami struktury oprogramowania. Nie dostarczają nam żadnych informacji na temat podziału elementów tworzonego systemu oprogramowania. Schematy te są wykorzystywane w komunikacji ludzkiej — przede wszystkim pomiędzy analitykami a interesariuszami. Pomagają zorganizować funkcjonalność systemu w kontekście różnych rodzajów użytkowników systemu. Ponadto te schematy mogą być bardzo pomocne podczas prezentowania opisu systemu różnego rodzaju użytkownikom. Każdy rodzaj użytkownika jest zainteresowany głównie własnymi przypadkami użycia. Połączenia pomiędzy aktorami a przypadkami użycia pozwalają skupić się użytkownikom poszczególnych rodzajów na tych przypadkach użycia, które będą przez nich wykorzystywane. W bardzo dużych systemach może wystąpić potrzeba zorganizowania schematów granic systemu według rodzaju aktorów. Dzięki temu użytkownicy różnych rodzajów będą mogli przeglądać podzbiór przypadków użycia, który ich dotyczy.

478

DODATEK A NOTACJA UML. CZĘŚĆ I: PRZYKŁAD CGI

Rysunek A.1. Schemat granic systemu

Na koniec przypomnijmy sobie pierwsze prawo dokumentacji Martina: Nie twórz żadnych dokumentów, jeżeli nie są potrzebne natychmiast i nie są znaczące. Diagramy przypadków użycia mogą się przydać, ale często są zbędne. Nie należy uważać ich za konieczne lub niezbędne. Jeśli ktoś poczuje potrzebę, może je narysować. W przeciwnym razie lepiej poczekać, aż potrzeba się pojawi.

Model dziedziny Model dziedziny to zbiór schematów, które pomagają zdefiniować pojęcia występujące w przypadkach użycia. Diagramy te pokazują najważniejsze obiekty występujące w dziedzinie problemu wraz z ich wzajemnymi powiązaniami. Założenie, że ten model może również reprezentować model budowanego oprogramowania, jest źródłem „bólu i cierpień” wielu osób. Zarówno analitycy, jak i projektanci powinni zdawać sobie sprawę, że model dziedziny jest narzędziem opisowym, które ma pomóc ludziom rejestrować swoje decyzje i komunikować się ze sobą. Obiekty w modelu dziedziny mogą być inne niż te, które występują w obiektowym projekcie oprogramowania. Ewentualna zbieżność nie zawsze przynosi korzyść5. 5

[JACOBSON], str. 133, „Nie uważamy, że najlepsze (najbardziej stabilne) systemy są budowane wyłącznie w oparciu o obiekty odpowiadające rzeczywistym podmiotom...”. I także na stronie 167, „W [innych] metodykach ten model [dziedziny] będzie również stanowić podstawę do rzeczywistej implementacji — tzn. podczas implementacji obiekty są bezpośrednio odwzorowane na klasy. Nie stosujemy takiego podejścia w metodyce OOSE [...]. Z naszych doświadczeń ze stosowania takiego podejścia wynika, że nie przynosi ono korzyści. Zamiast tego opracowujemy model analityczny, który jest bardziej elastyczny i łatwiejszy w utrzymaniu w obliczu przyszłych zmian. I to ten model, a nie model dziedziny problemu, ma służyć za podstawę do projektowania i implementacji”. [BOOCH96], str. 108, „... w niedojrzałych projektach istnieje tendencja do stosowania modelu dziedziny otrzymanego w wyniku analizy jako gotowego do kodowania [...] — zatem dalsze projektowanie jest pomijane. W dobrze prowadzonych projektach obowiązuje przekonanie, że jest jeszcze sporo do zrobienia. Trzeba zająć się między innymi takimi zagadnieniami jak współbieżność, serializacja, bezpieczeństwo, dystrybucja. Z tego względu model stosowany w projekcie może ostatecznie różnić się od modelu dziedziny w wielu subtelnościach”.

SYSTEM REJESTROWANIA KURSÓW: OPIS PROBLEMU

479

W [Booch 94] i [OMT] diagramy modelu dziedziny były nie do odróżnienia od schematów, które reprezentowały strukturę i projekt oprogramowania. W najgorszych przypadkach diagramy modelu dziedziny były traktowane jako dokumenty projektowe wysokiego poziomu, a zatem były wykorzystywane do ustanowienia wysokopoziomowej struktury oprogramowania. Aby uniknąć tego rodzaju błędu, można skorzystać z własności języka UML i użyć w modelach dziedziny specjalnego rodzaju encji o nazwie «type». «type» reprezentuje rolę, którą może pełnić obiekt. «type» może mieć operacje i atrybuty, a także asocjacje z innymi encjami «type». «type» nie reprezentuje jednak klasy lub obiektu w sensie projektowania. Nie reprezentuje elementu oprogramowania i nie można go bezpośrednio odwzorować na kod. Reprezentuje raczej pojęciowy podmiot do wykorzystania w opisie problemu. Katalog kursów. Pierwszą abstrakcją dziedziny, którą weźmiemy pod uwagę, jest katalog kursów. Ta abstrakcja reprezentuje listę wszystkich kursów dostępnych w ofercie. W modelu dziedziny (patrz rysunek A.2) dla encji Course Catalog pokazaliśmy to, oznaczając dwie encje reprezentujące abstrakcje w dziedzinie: encję Course Catalog oraz encję Course. Encja CourseCatalog zawiera wiele encji Course.

Rysunek A.2. Model dziedziny dla encji CourseCatalog

Notacja dziedzina-model. W notacji użytej na rysunku A.2 zaprezentowano dwie abstrakcje dziedziny w postaci klas UML ze stereotypem «type» (patrz ramka „Przegląd notacji i semantyki klas UML”). To oznacza, że klasy są elementami koncepcyjnymi dziedziny problemu i nie są bezpośrednio związane z klasami w oprogramowaniu. Zwróćmy uwagę, że encja CourseCatalog zawiera dwie operacje: AddCourse i RemoveCourse. W przypadku encji ze stereotypem «type» operacje odpowiadają obowiązkom encji. Zatem encja CourseCatalog odpowiada za możliwość dodawania i usuwania kursów. Tak jak wspominaliśmy wcześniej — to są koncepcje, a nie specyfikacje funkcji składowych w ramach rzeczywistych klas. Wykorzystujemy je do komunikacji z użytkownikami, a nie do specyfikowania struktury oprogramowania. Na tej samej zasadzie atrybuty pokazane w ramach encji Course także są pojęciami. Wskazują one, że encja Course powinna być odpowiedzialna za pamiętanie opłaty (fee), limitu uczestników (enrollment limit) oraz bieżącej liczby zarejestrowanych uczestników.

Przegląd notacji i semantyki klas UML W notacji UML klasę rysuje się w postaci prostokąta podzielonego na trzy części. W pierwszej części określa się nazwę klasy. W drugiej części są wymienione atrybuty klasy, natomiast w trzeciej — związane z nią operacje. W części nazwy można używać modyfikatorów w postaci stereotypu oraz właściwości. Stereotyp podaje się nad nazwą. Jest on otoczony znakami guillemet («»). Właściwości są wymienione poniżej, z prawej strony nazwy, i są ujęte w nawiasy klamrowe (patrz diagram poniżej).

480

DODATEK A NOTACJA UML. CZĘŚĆ I: PRZYKŁAD CGI

Stereotypy są nazwami, które odnoszą się do „rodzaju” reprezentowanej klasy UML. W notacji UML klasa jest po prostu encją reprezentowaną przez nazwę, posiadającą atrybuty i operacje. Domyślny stereotyp to «implementation class». W tym przypadku klasa UML bezpośrednio odpowiada pojęciu klasy oprogramowania w takich językach jak C++, Java, Smalltalk czy Eiffel. Atrybuty odpowiadają zmiennym składowym, a operacje — funkcjom składowym. Jednak klasa UML oznaczona stereotypem «type» w ogóle nie odpowiada encji języka oprogramowania. Reprezentuje raczej pojęciowy podmiot, który istnieje w dziedzinie problemu. Atrybuty przedstawiają informacje, które logicznie należą do tej jednostki pojęciowej, a operacje odpowiadają obowiązkom tego koncepcyjnego podmiotu. Istnieje kilka innych predefiniowanych stereotypów, które omówimy w dalszej części tego rozdziału. Można również tworzyć własne stereotypy. Stereotyp to jednak coś więcej niż komentarz. Określa on sposób, w jaki powinny być interpretowane wszystkie elementy klasy UML. Jeśli zatem zdecydujemy się na stworzenie nowego stereotypu, powinniśmy zadbać o to, by go dobrze zdefiniować. Właściwości są przede wszystkim strukturalnymi komentarzami. Oznacza się je za pomocą listy elementów rozdzielonych przecinkami wewnątrz nawiasów klamrowych. Każda właściwość jest zapisana w formie pary nazwa = wartość. Jeśli znak równości zostanie pominięty, to przyjmuje się, że właściwość jest wartością logiczną true. W przeciwnym razie wartość jest łańcuchem znaków. Istnieje kilka predefiniowanych właściwości, które będziemy omawiać w dalszej części tego dodatku. Można jednak swobodnie dodawać własne. Na przykład można stworzyć właściwość w następującej postaci: {author=Robert C. Martin, date=12/6/97, SPR=4033}.

Pojęcia a implementacja. Zastosowanie ikon chmur. W niniejszym dodatku wielokrotnie podkreślałem różnicę pomiędzy klasą na poziomie koncepcji (tzn. encją «type») a klasą na poziomie projektu lub implementacji. Uważam, że jest to właściwe ze względu na niebezpieczeństwo błędnego uznania schematów pojęciowych za specyfikację struktury i architektury oprogramowania. Należy pamiętać, że diagramy koncepcyjne mają pomóc w komunikacji pomiędzy interesariuszami, a zatem są pozbawione wszelkich kwestii technicznych struktury oprogramowania. Zastosowanie stereotypów w celu rozróżnienia pomiędzy tymi rodzajami schematów można pominąć. Klasy UML modeli dziedziny wyglądają bardzo podobnie do klas UML wykorzystywanych do projektowania i implementacji. Na szczęście notacja UML pozwala podstawiać różne ikony za różne stereotypy. Z tego powodu w celu lepszego zobrazowania różnicy pomiędzy tymi rodzajami diagramów odtąd będziemy używali ikony chmury do reprezentowania klas «type». To powoduje zmianę modelu dziedziny encji Course Catalog z rysunku A.2 do postaci pokazanej na rysunku A.3.

Rysunek A.3. Model dziedziny dla encji CourseCatalog z wykorzystaniem ikon chmury

Kompletowanie modelu dziedziny. Do tej pory w modelu dziedziny zaprezentowaliśmy katalog kursów zawierający wszystkie oferowane kursy. Jest tu jednak pewien problem. Co rozumiemy przez kurs? Ten sam kurs może być oferowany w wielu różnych terminach i lokalizacjach i może być prowadzony przez różnych instruktorów. Wyraźnie widać, że potrzebujemy dwóch różnych podmiotów. Pierwszemu z nich nadamy nazwę Course. Reprezentuje on kurs sam w sobie, ale nic nie mówi o terminach, lokalizacjach lub instruktorach. Drugiemu nadamy nazwę Session. Reprezentuje on datę, lokalizację oraz instruktora określonego kursu (patrz rysunek A.4).

SYSTEM REJESTROWANIA KURSÓW: OPIS PROBLEMU

481

Rysunek A.4. Kursy i sesje

Notacja. Linie łączące podmioty są nazywane asocjacjami. Wszystkim asocjacjom pokazanym na rysunku A.4 nadano nazwy, ale to nie jest reguła. Zwróćmy uwagę, że nazwy są czasownikami lub zwrotami zawierającymi czasownik. Niewielki czarny trójkąt obok nazwy wskazuje na predykat zdania utworzonego za pomocą dwóch encji i asocjacji. A zatem „Katalog kursów oferuje wiele kursów”, „Harmonogram sesji zawiera wiele sesji” oraz „W sesji kursu bierze udział wielu uczestników”. W zdaniach zaprezentowanych powyżej użyłem słowa „wiele” wszędzie tam, gdzie w relacji występowała ikona 0..*. Jest to jedna z kilku dostępnych ikon liczności, które można umieścić na końcu asocjacji. Oznaczają one liczbę encji, które uczestniczą w asocjacji. Domyślna wartość liczności wynosi 1 (patrz ramka „Liczności”).

Liczności Istnieje szereg ikon liczności, które mogą być wykorzystane do oznaczania asocjacji. Dostępne są następujące liczności:       

0..* * 1..* 0..1 6 3..6 3,5

zero do wielu zero do wielu jeden do wielu zero lub jeden dokładnie sześć pomiędzy trzy a sześć trzy lub pięć

Do określania przedziałów lub elementów zbiorów można stosować dowolne liczby nieujemne.

482

DODATEK A NOTACJA UML. CZĘŚĆ I: PRZYKŁAD CGI

Gdy asocjacje są pozbawione grotów, są traktowane jako dwukierunkowe. Dwukierunkowa asocjacja to taka, w której dwie encje „wiedzą” o sobie wzajemnie. Na przykład nie ulega wątpliwości, że encja CourseCatalog powinna „wiedzieć”, jakie zawiera kursy (encje Course). Wydaje się również uzasadnione, żeby każda encja Course „wiedziała” o katalogu CourseCatalog, w którym ją wymieniono. To samo dotyczy encji SessionSchedule i Session. Obecność grotu pokazuje, że „wiedzę” posiada encja oznaczona przez kierunek. Zatem encja Sessions „wie” o encji Courses, ale encja Courses nic „nie wie” o encji Sessions. Iteracje przypadków użycia. Ten diagram natychmiast mówi nam dwie rzeczy. Po pierwsze, w niektórych miejscach wewnątrz przypadków użycia jest wykorzystywany nieodpowiedni język. Tam, gdzie jest mowa o katalogach kursów i kursach, powinno się mówić o harmonogramach sesji i sesjach. Po drugie, istnieje sporo przypadków użycia, które zostały pominięte. Encje CourseCatalog i SessionSchedule trzeba utrzymywać. Istnieje potrzeba dodawania encji Course do encji CourseCatalog i usuwania jej z niej oraz dodawania i usuwania encji Session do (z) encji SessionSchedule. Zatem poprzez stworzenie modelu dziedziny mamy możliwość lepszego zrozumienia rozwiązywanego problemu. Dzięki temu lepszemu zrozumieniu możemy poprawić i rozszerzyć przypadki użycia. Iteracja pomiędzy modelem dziedziny a przypadkami użycia jest naturalna i niezbędna. Gdybyśmy chcieli doprowadzić niniejsze studium przypadku do końca, zaprezentowalibyśmy zasygnalizowane tutaj zmiany. Ale w celu skutecznego zaprezentowania notacji pominiemy problem iteracji przypadków użycia.

Architektura Teraz możemy zająć się problematyką projektowania oprogramowania. Architektura przedstawia struktury oprogramowania, które tworzą szkielet aplikacji. Klasy i relacje architektury mają ścisłe odwzorowanie w kodzie. Wybór platformy oprogramowania. Zanim jednak zaczniemy, powinniśmy zapoznać się z platformą oprogramowania, na której aplikacja będzie działać. Mamy kilka opcji do wyboru. 1. Webowa aplikacja CGI. Formularz rejestracji oraz inne formularze będą dostępne za pośrednictwem przeglądarki internetowej. Dane będą przechowywane na serwerze w sieci WWW, natomiast skrypty CGI umożliwiające dostęp do danych i ich przetwarzania będą wywoływane przez przeglądarkę internetową. 2. Aplikacja bazodanowa. Możemy zakupić relacyjną bazę danych i skorzystać z pakietu formularzy i języka 4GL do napisania aplikacji. 3. Visual XXX. Możemy zakupić wizualny język programowania. Interfejs użytkownika w takiej aplikacji tworzy się za pomocą wizualnych narzędzi projektowych. Te narzędzia będą wywoływały funkcje oprogramowania potrzebne do przechowywania i pobierania danych oraz wykonywania na nich operacji. Istnieją oczywiście inne możliwości. Moglibyśmy napisać całą aplikację w języku C bez korzystania z pomocy bibliotek lub narzędzi innych niż kompilator. To jednak byłoby głupie. Narzędzia są dostępne i pomagają w pracy. Należy z nich korzystać. Dla potrzeb naszego przykładu przyjmujemy, że stworzymy aplikację webową. Ma to sens, ponieważ wtedy kandydaci mogą pochodzić z każdego miejsca na świecie, a usługa zapisywania się na kursy może być oferowana przez internet. Architektura webowa. Musimy zdecydować o ogólnej architekturze aplikacji webowej. Ile będzie zawierać stron internetowych oraz jakie programy CGI będą one wywoływać? Możliwy sposób specyfikacji architektury przedstawiono na rysunku A.5.

SYSTEM REJESTROWANIA KURSÓW: OPIS PROBLEMU

483

Rysunek A.5. Architektura menu sesji

Notacja. Na rysunku A.5 zaprezentowano diagram komponentów. Ikony przedstawiają fizyczne komponenty oprogramowania. Do określenia rodzaju komponentów użyliśmy stereotypów. Na diagramie pokazano, że menu sesji jest wyświetlane w postaci strony WWW w HTML, która jest generowana przez program CGI o nazwie Session Menu Generator. Linia przerywana zakończona strzałką pomiędzy dwoma komponentami oznacza relację zależności. Relacje zależności określają, które komponenty „mają wiedzę” o innych komponentach. W tym przypadku program Session Menu Generator tworzy stronę WWW Session Menu i dlatego program „wie” o stronie. Z kolei strona WWW Session Menu nic „nie wie” o generatorze. Własne ikony. Istnieją dwa różne rodzaje komponentów na rysunku A.5. Aby je wizualnie od siebie odróżnić, możemy rozszerzyć UML za pomocą dwóch nowych ikon — jednej dla programów CGI i drugiej dla stron HTML. Na rysunku A.6 zamieszczono komponenty wykorzystywane w przypadku użycia nr 2: Zapisanie się na kurs. Strony WWW rysujemy w postaci stron oznaczonych literą „W”. Programy CGI rysujemy w postaci okręgów z napisem „CGI”.

Rysunek A.6. Komponenty systemu rejestracji

Przepływ danych pomiędzy komponentami. Na rysunku A.6 przedstawiono dwie nowe strony WWW i jeden nowy program CGI. Zdecydowaliśmy, że aplikacja powinna rozpocząć się od wyświetlenia strony z jakiegoś rodzaju banerem. Przypuszczalnie na tej stronie znajdą się łącza do różnych rodzajów operacji dostępnych dla użytkowników. Ze strony banera jest wywoływany program Session Menu Generator, który generuje stronę Session Menu. Strona Session Menu zawiera łącza lub przyciski, które pozwalają użytkownikowi zapisać się na kurs. Strona Session Menu wywołuje program Enrollment Form Generator w celu stworzenia formularzy potrzebnych do zapisania się na wybrany kurs. Kiedy użytkownik wypełni formularz, wywoływany jest program CGI Enroll. Program ten waliduje informacje wprowadzone w formularzu i zapisuje je. Jeśli dane wprowadzone w formularzu są nieprawidłowe, generuje stronę Enrollment Error, w przeciwnym razie generuje stronę z potwierdzeniem i wysyła potrzebne wiadomości e-mail (patrz przypadek użycia nr 2).

484

DODATEK A NOTACJA UML. CZĘŚĆ I: PRZYKŁAD CGI

Lepsza elastyczność. Uważni czytelnicy z pewnością zauważyli, że proponowany model komponentów charakteryzuje się brakiem elastyczności. Większość stron WWW jest generowana przez programy CGI. Oznacza to, że tekst HTML stron WWW musi być zawarty w programach CGI. Z tego powodu modyfikowanie stron internetowych wymaga modyfikowania i ponownej kompilacji programów CGI. Zamiast tego wolelibyśmy, aby większa część generowanych stron WWW została stworzona z wykorzystaniem wygodnego edytora HTML. Zatem programy CGI powinny czytać szablony stron internetowych, które mają być wygenerowane. Szablony powinny być oznaczone specjalnymi flagami, przeznaczonymi do zastąpienia przez kod HTML wygenerowany przez programy CGI. Oznacza to, że programy CGI mają pewną wspólną część. Wszystkie czytają pliki szablonów HTML i dodają do nich własne fragmenty kodu6. Wynikowy diagram komponentów pokazano na rysunku A.7. Zwróćmy uwagę, że dodałem ikonę WT. Ikona ta reprezentuje szablon HTML. Jest to plik tekstowy w formacie HTML ze specjalnymi znakami. Te znaki będą wykorzystane przez programy CGI do wygenerowania kodu HTML. Zwróćmy także uwagę na kierunek relacji zależności pomiędzy programami CGI a szablonami HTML. Niektórym czytelnikom ten kierunek może wydawać się odwrotny. Należy jednak pamiętać, że to jest kierunek relacji zależności, a nie przepływu danych. Programy CGI „wiedzą o” szablonach HTML (zależą od nich).

Rysunek A.7. Dodanie szablonów HTML do diagramu komponentów systemu rejestracji na kursy

6

Ten rozdział został napisany na długo przed powstaniem transformacji XSLT. Dziś prawdopodobnie rozwiązalibyśmy problem w ten sposób, że skrypty CGI (lub serwlety) wygenerowałyby XML, a następnie wywołały skrypt XSLT w celu przetłumaczenia kodu XML na HTML. Z drugiej strony, generowanie HTML z wykorzystaniem XSLT nadal nie daje nam możliwości projektowania stron WWW z wykorzystaniem wygodnego edytora WYSIWYG. Czasami uważam, że system szablonów zaprezentowany w tym rozdziale w wielu przypadkach sprawdzi się lepiej.

SYSTEM REJESTROWANIA KURSÓW: OPIS PROBLEMU

485

Dychotomia pomiędzy specyfikacją a egzemplarzem. Nazwy wygenerowanych stron WWW na rysunku A.7 są podkreślone. To dlatego, że te strony istnieją tylko w czasie wykonywania programu. Są one egzemplarzami szablonów HTML. W języku UML obowiązuje konwencja, zgodnie z którą nazwy egzemplarzy oznaczamy podkreśleniem. Egzemplarz jest elementem oprogramowania, który jest generowany na podstawie specyfikacji (dokumentu źródłowego). Więcej informacji na ten temat zamieścimy dalej. Na razie powinniśmy zapamiętać, że elementy, których nazwy nie są podkreślone, reprezentują komponenty. Te komponenty muszą być napisane ręcznie i pełnić rolę specyfikacji. Z kolei elementy, których nazwy są podkreślone, są produktem pewnego procesu generowania na podstawie specyfikacji. Wykorzystanie szablonów HTML. Szablony HTML gwarantują dużą elastyczność architektury tej aplikacji. W jaki sposób one działają? Jak programy CGI umieszczają wygenerowany wynik w odpowiednich miejscach wewnątrz szablonów HTML? Moglibyśmy wprowadzić w plikach szablonów HTML specjalny znacznik HTML. Ten znacznik oznaczałby pozycję wewnątrz generowanego pliku HTML, w której program CGI mógłby wstawić wynik swojego działania. Jednak te wygenerowane strony WWW mogą składać się z kilku sekcji. Każda z nich może wymagać własnego punktu, w którym skrypt CGI wstawi kod HTML. Zatem każdy szablon HTML może zawierać więcej niż jeden znacznik wstawiania, a program CGI musi w jakiś sposób określić, który wynik ma być umieszczony pod określonym znacznikiem. Znacznik mógłby mieć następującą postać: , gdzie „nazwa” jest dowolnym łańcuchem znaków, który identyfikuje punkt wstawiania dla programu CGI. Znacznik postaci pozwoli programowi CGI wprowadzić nazwę header oraz całkowicie zastąpić znacznik wygenerowanym wynikiem. Oczywiście każdy znacznik jest zastępowany ciągiem znaków, zatem każdy znacznik stanowi rodzaj strumienia znaków reprezentowanego przez nazwę. Możemy sobie wyobrazić, że w programie CGI mógłby się znaleźć kod C++ w następującej postaci: HTMLTemplate myPage("mojastrona.htmp"); myPage.insert("header", "

to jest nagłówek

\n"); cout << myPage.Generate();

Powyższy kod wysyła do strumienia cout ciąg HTML wygenerowany na podstawie szablonu mypage.html. W tym szablonie znacznik został zastąpiony ciągiem "

to jest nagłówek

\n". Proponowany projekt klasy HTMLTemplate pokazano na rysunku A.8. Klasa ma atrybut oznaczający nazwę pliku z szablonem. Ma również metody, które pozwalają na wstawianie ciągów zastępczych w punktach wstawiania oznaczonych specjalnymi nazwami. Egzemplarze klasy HTMLTemplate zawierają mapę, która odwzorowuje nazwę punktu wstawiania na zastępczy łańcuch znaków.

Rysunek A.8. Projekt klasy HTMLTemplate

Notacja. Powyżej zaprezentowano pierwszy, prawdziwy diagram klas. Pokazano na nim dwie klasy połączone relacją kompozycji. Ikona użyta do oznaczenia klasy HTMLTemplate oraz klasa map nie są dla nas nowe. Ich znaczenie opisano w ramce zatytułowanej „Przegląd notacji i semantyki klas UML”. Składnię atrybutów i operacji opisano poniżej — w ramce zatytułowanej „Atrybuty i operacje”.

486

DODATEK A NOTACJA UML. CZĘŚĆ I: PRZYKŁAD CGI

Atrybuty i operacje Atrybuty i operacje można opisywać za pomocą następujących specyfikatorów enkapsulacji: + #

publiczne prywatne chronione

Typ atrybutu może być podany w postaci identyfikatora, za którym występuje dwukropek (np. count : int). Tę samą notację można wykorzystać do określenia argumentów funkcji (np. SetName (name : string)). Na koniec notację z dwukropkiem można wykorzystać do określenia typu wyniku funkcji (np. Distance(from : Point) : float).

Grot przy asocjacji łączącej dwie klasy na rysunku A.8 wskazuje, że klasa HTMLTemplate „wie” o klasie map, natomiast klasa map nic „nie wie” o klasie HTMLTemplate. Pełny romb na końcu asocjacji przy klasie HTMLTemplate identyfikuje specjalny rodzaj asocjacji zwany kompozycją (więcej informacji na ten temat można znaleźć w ramce „Asocjacje, agregacje i kompozycje”). Oznacza to, że klasa HTMLTemplate jest odpowiedzialna za istnienie klasy map.

Asocjacje, agregacje i kompozycje Asocjacja oznacza relację pomiędzy dwiema klasami. Asocjacja pozwala egzemplarzom utworzonym na podstawie tych klas przesyłać do siebie wzajemnie komunikaty (tzn. pomiędzy obiektami, których klasy łączą asocjacje, mogą istnieć połączenia). Asocjacje są oznaczane linią łączącą dwie klasy. Asocjacje są najczęściej implementowane za pomocą zmiennych egzemplarza w jednej klasie, wskazujących inne klasy lub odnoszących się do nich. Asocjacja

Kierunek asocjacji można ograniczyć poprzez dodanie grotu. Kiedy na diagramie asocjacji występuje grot, to widoczność obiektów jest określona kierunkiem strzałki. Oznacza to, że klasa, na którą wskazuje grot, „nic nie wie” na temat klasy, która jest z nią połączona za pomocą asocjacji. Asocjacja skierowana

Specjalnym rodzajem asocjacji jest agregacja. Oznacza się ją za pomocą pustego rombu po stronie agregowanej klasy. Agregacja implikuje relację „całość”-„część”. Klasa występująca obok pustego rombu reprezentuje „całość”, natomiast druga klasa wchodząca w skład asocjacji to jej „część”. Relacja „całość”-„część” ma charakter czysto opisowy. Nie istnieje semantyczna różnica pomiędzy agregacją a asocjacją7. 7

Z jednym wyjątkiem. Relacje agregacji zawierające te same obiekty albo relacje cykliczne nie są dozwolone. Oznacza to, że egzemplarze klas nie mogą wchodzić w skład cykli agregacji. Gdyby ta reguła nie obowiązywała, wszystkie egzemplarze należące do cyklu byłyby częścią samych siebie. Oznaczałoby to, że „część” mogłaby zawierać swoją „całość”. Należy pamiętać, że ta zasada nie wyklucza z udziału w cyklach agregacji klas. Jest to ograniczenie wyłącznie dla egzemplarzy.

SYSTEM REJESTROWANIA KURSÓW: OPIS PROBLEMU

487

Agregacja

Specjalnym rodzajem agregacji jest kompozycja. Oznacza się ją za pomocą pełnego rombu. Oznacza ona, że „całość” jest odpowiedzialna za istnienie swojej „części”. Odpowiedzialność ta nie implikuje obowiązku utworzenia ani usunięcia. Oznacza ona raczej, że całość musi jakoś „zadbać” o to, aby część została usunięta. Można to uzyskać poprzez bezpośrednie usunięcie „części” albo poprzez przekazanie obowiązku usunięcia „części” innej encji.

Kompozycja

Warstwa interfejsu z bazą danych. Każdy program CGI musi mieć dostęp do bazy danych, które reprezentują kursy, zajęcia, uczestników itp. Nazwiemy ją bazą danych szkoleń. Na tym etapie nie podejmujemy jeszcze decyzji co do tego, jaka będzie forma tej bazy danych. Może to być relacyjna baza danych albo zbiór plików. Nie chcemy, aby architektura naszej aplikacji zależała od formy, w jakiej są przechowywane dane. Chcemy, aby w przypadku gdy zmieni się forma bazy danych, większa część aplikacji pozostała niezmieniona. W związku z tym będziemy chronić aplikację przed zmianami w bazie danych poprzez nałożenie warstwy interfejsu bazy danych (ang. Database Interface Layer — DIL). Aby warstwa DIL była skuteczna, musi mieć specjalną charakterystykę zależności, którą przedstawiono na rysunku A.9. Warstwa DIL zależy od aplikacji oraz od bazy danych. Aplikacja i baza danych wzajemnie „nic o sobie nie wiedzą”. Dzięki temu można zmieniać bazę danych bez konieczności wprowadzania zmian w aplikacji. Można również zmieniać aplikację bez konieczności zmian w bazie danych. Możemy całkowicie zastąpić format bazy danych lub silnik bazy danych bez wpływu na aplikację.

Rysunek A.9. Charakterystyki zależności warstwy interfejsu od bazy danych

Notacja. Na rysunku A.9 zaprezentowano specjalny rodzaj diagramu klas zwany „diagramem pakietów”. Ikony na rysunku oznaczają pakiety. Ich kształt przypomina folder plików. Pakiet jest kontenerem tak jak folder plików (patrz ramka „Pakiety i podsystemy”). Pakiety z rysunku A.9 zawierają komponenty oprogramowania, takie jak klasy, pliki HTML, główne pliki programów CGI itp. Przerywana linia zakończona strzałką, która łączy pakiety, reprezentuje relację zależności. Grot wskazuje na docelową encję zależności. Zależności pomiędzy pakietami oznaczają, że pakiet zależny nie może być użyty bez pakietu, od którego zależy.

488

DODATEK A NOTACJA UML. CZĘŚĆ I: PRZYKŁAD CGI

Pakiety i podsystemy Pakiety rysuje się w postaci dużych prostokątów z mniejszą, prostokątną „zakładką” nad górną krawędzią po lewej stronie. Zazwyczaj nazwa pakietu jest umieszczona wewnątrz dużego prostokąta.

Pakiety można także rysować w taki sposób, że nazwę pakietu umieszcza się wewnątrz „zakładki”, natomiast treść pakietu jest umieszczona wewnątrz dużego prostokąta. Treścią pakietu mogą być klasy, pliki lub inne pakiety. Nazwę każdego z nich można poprzedzić ikonami enkapsulacji (-, +, #) w celu oznaczenia, że są one prywatne, publiczne lub chronione.

Pakiety mogą być połączone jedną bądź dwoma różnymi relacjami. Zależność oznaczona linią przerywaną ze strzałką to zależność importu. Tę relację zależności oznacza się stereotypem «import». Jest to domyślny stereotyp w przypadku, gdy zależność jest określana dla pakietu. Podstawa strzałki jest dołączona do pakietu importującego, natomiast jej grot dotyka pakietu importowanego. Zależność importu oznacza, że pakiet importujący ma dostęp do wszystkich publicznych elementów importowanego pakietu. Oznacza to, że elementy pakietu importującego mogą używać dowolnych publicznych elementów pakietu importowanego. Pakiety mogą być również łączone relacją uogólnienia. Otwarty trójkątny grot dotyka pakietu ogólnego (abstrakcyjnego), natomiast drugi koniec relacji dotyka pakietu implementującego. Pakiet implementujący ma dostęp do wszystkich elementów publicznych lub chronionych pakietu abstrakcyjnego.

Istnieje kilka predefiniowanych stereotypów dla pakietu. Domyślny to «package», który oznacza kontener bez żadnych specjalnych ograniczeń. Może zawierać wszystko, co może być modelowane za pomocą UML. Zazwyczaj wykorzystuje się go do oznaczenia fizycznego modułu zdolnego do osobnej dystrybucji (ang. releaseable). Taki pakiet występuje w systemie zarządzania konfiguracją oraz w systemie kontroli wersji. Może być reprezentowany przez podkatalogi w systemie plików lub systemie modułów języka (np. pakiety Javy bądź pliki JAR). Pakiety odzwierciedlają podział systemu. Poprawiają możliwości jego rozwoju i dystrybucji.

SYSTEM REJESTROWANIA KURSÓW: OPIS PROBLEMU

489

Stereotyp «subsystem» w odniesieniu do pakietów oznacza logiczną strukturę, która oprócz tego, że zawiera elementy modelu, określa także ich zachowanie. Dla podsystemu można definiować operacje. Operacje te muszą być obsługiwane przez przypadki użycia albo interakcje w ramach pakietu. Podsystemy reprezentują behawioralny podział systemu lub aplikacji.

Wymienione dwa rodzaje pakietów są wzajemnie ortogonalne. Podział, który poprawia możliwości rozwoju i dystrybucji, prawie nigdy nie przypomina podziału, którego podstawą jest zachowanie. Pierwszy z nich jest często wykorzystywany przez inżynierów oprogramowania jako moduł zarządzania konfiguracją i kontroli wersji. Drugi jest częściej stosowany przez analityków w celu opisania systemu w sposób intuicyjny oraz w celu przeprowadzenia analizy wpływu dodawania lub wprowadzania zmian własności.

Interfejs bazy danych. Klasy należące do aplikacji obsługi kursów muszą mieć dostęp do bazy danych. Można to uzyskać za pomocą zbioru interfejsów wewnątrz pakietu aplikacji obsługi kursów (patrz rysunek A.10). Te interfejsy reprezentują typy w modelu dziedziny z rysunku A.4. Są one zaimplementowane za pomocą klas wewnątrz pakietu DIL. Te klasy będą wykorzystane przez inne klasy wewnątrz pakietu aplikacji obsługi kursów w celu uzyskania dostępu do danych w bazie danych. Zwróćmy uwagę, że kierunek zależności z rysunku A.10 odpowiada kierunkowi relacji importu pomiędzy pakietami z rysunku A.9.

Rysunek A.10. Klasy interfejsu do bazy danych w pakiecie aplikacji obsługi kursów

Notacja. Zapisanie nazwy klasy kursywą oznacza, że klasa jest abstrakcyjna8. Ponieważ interfejsy są w pełni abstrakcyjnymi klasami, właściwe jest pisanie ich nazw kursywą. Operacje także są zapisywane kursywą w celu oznaczenia, że są one abstrakcyjne. Klasy w warstwie DIL są powiązane z interfejsami 8

Klasa abstrakcyjna zawiera co najmniej jedną metodę abstrakcyjną.

490

DODATEK A NOTACJA UML. CZĘŚĆ I: PRZYKŁAD CGI

za pomocą relacji realizuje. Relacje te rysuje się za pomocą linii przerywanych z otwartymi trójkątnymi strzałkami wskazującymi interfejsy. Odpowiednikiem tych relacji w Javie są relacje implements. W języku C++ są one reprezentowane przez dziedziczenie. Interfejsy są strukturami fizycznymi. W takich językach jak C++ i Java mają one odpowiedniki w kodzie źródłowym. Z drugiej strony, typy nie są fizyczne i nie reprezentują konstrukcji występujących w kodzie źródłowym. Na rysunku A.10 pokazaliśmy relacje realizuje od interfejsów do typów, które one reprezentują. Nie oznacza to relacji fizycznej ani nie ma odpowiednika w kodzie źródłowym. W tym przypadku relacja realizuje pokazuje zależność pomiędzy encjami fizycznego projektu a encjami modelu dziedziny. To odwzorowanie rzadko jest tak jednoznaczne jak to, które przedstawiono w tym dodatku. Relację importuje pomiędzy pakietami pokazaną na rysunku A.9 na rysunku A.10 zaprezentowano za pomocą podwójnego dwukropka. Klasa DIL::Session to klasa o nazwie Session występująca wewnątrz pakietu DIL i widoczna w pakiecie TrainingApplication (została do niego zaimportowana). Fakt istnienia dwóch klas o nazwie Session jest do przyjęcia, ponieważ należą one do różnych pakietów. Generator menu sesji. Powracając do rysunku A.7, możemy zobaczyć, że pierwszym programem CGI jest program SessionMenuGenerator. Ten program odpowiada pierwszemu przypadkowi użycia ze strony 469. Jak wygląda projekt tego programu CGI? Nie ulega wątpliwości, że powinien on stworzyć reprezentację HTML harmonogramu sesji. W związku z tym potrzebujemy klasy HTMLTemplate, która scali szablon menu sesji z fizycznymi danymi z harmonogramu sesji. Program będzie również korzystał z interfejsu SessionSchedule w celu uzyskania dostępu do egzemplarzy klas Session i Course w bazie danych po to, aby uzyskać nazwiska, godziny, lokalizacje i opłaty. Diagram sekwencji, który opisuje ten proces, przedstawiono na rysunku A.11.

Rysunek A.11. Diagram sekwencji klasy SessionMenuGenerator

SYSTEM REJESTROWANIA KURSÓW: OPIS PROBLEMU

491

Obiekt SessionMenuGenerator jest tworzony w programie głównym. Obiekt ten zarządza całą aplikacją. Tworzy obiekt HTMLTemplate, przekazując do niego nazwę pliku szablonu. Następnie pobiera obiekt iterator9 z interfejsu SessionSchedule. Przetwarza w pętli wszystkie obiekty Session pobrane z iteratora iterator, zadając każdemu obiektowi Session pytanie o jego obiekt Course. Z obiektu Session pobiera godzinę i lokalizację kursu, natomiast nazwę i koszt kursu pobiera z obiektu Course. Ostatnia czynność w pętli polega na pobraniu elementu line zawierającego wszystkie powyższe informacje i wstawieniu go za pomocą operacji Insert do obiektu HTMLTemplate w punkcie wstawiania wewnątrz obiektu Schedule. Po zakończeniu pętli obiekt SessionMenuGenerator wywołuje metodę Destroy obiektu HTMLTemplate i niszczy go. Notacja. Nazwy wewnątrz prostokątów na diagramie sekwencji z rysunku A.11 są podkreślone. Oznacza to, że reprezentują one obiekty, a nie klasy. Nazwy obiektów składają się z dwóch elementów oddzielonych od siebie dwukropkiem. Przed dwukropkiem występuje prosta nazwa obiektu. Za dwukropkiem jest nazwa klasy lub interfejsu, który ten obiekt implementuje. Na rysunku A.11 wszystkie proste nazwy zostały pominięte, dlatego wszystkie nazwy rozpoczynają się od dwukropka. Linie przerywane prowadzące od obiektów to tzw. linie życia (ang. lifelines). Linie te reprezentują czas życia obiektów. Wszystkie obiekty występujące na rysunku A.11 poza obiektami HTMLTemplate i iterator przedstawiają linie życia, które zaczynają się na samej górze i kończą na samym dole. Zgodnie z konwencją oznacza to, że te obiekty istniały przed rozpoczęciem scenariusza i będą istniały, kiedy scenariusz się zakończy. Z kolei obiekt HTMLTemplate jest jawnie tworzony i usuwany przez obiekt SessionMenuGenerator. Wskazuje na to strzałka, która kończy się na obiekcie HTMLTemplate — co oznacza utworzenie obiektu — oraz znak „X” u dołu, który kończy linię życia. Obiekt SessionMenuGenerator niszczy również obiekt Iterator. W tym przypadku nie ma jednak jasności co do tego, który obiekt go tworzy. „Twórca” jest prawdopodobnie obiektem będącym pochodną klasy SessionSchedule. Zatem chociaż na rysunku A.11 nie pokazano jawnie utworzenia obiektu Iterator, to pozycja początku linii życia obiektu implikuje, że został on stworzony mniej więcej w tym czasie, kiedy do obiektu SessionSchedule został przesłany komunikat GetSessionIterator. Strzałki łączące linie życia oznaczają komunikaty. Czas postępuje od góry do dołu, więc diagram przedstawia sekwencję komunikatów przekazywanych między obiektami. Nazwy komunikatów są oznaczone przez etykiety w pobliżu strzałek. Krótkie strzałki z kółkami na końcach są nazywane znacznikami danych (ang. data tokens). Reprezentują elementy danych przekazywane w kontekście komunikatu. Jeśli wskazują w kierunku komunikatu, to są jego parametrami. Jeśli wskazują w kierunku przeciwnym do komunikatu, oznaczają wartości zwracane przez komunikat. Długi, wąski prostokąt na linii życia obiektu SessionMenuGenerator to tzw. aktywacja. Aktywacja reprezentuje czas działania metody lub funkcji. W tym przypadku komunikat, który uruchomił metodę, nie został pokazany. Pozostałe linie życia na rysunku A.11 nie mają aktywacji, ponieważ metody są bardzo krótkie i nie emitują innych komunikatów. Prostokątna, pogrubiona ramka, która otacza niektóre komunikaty na rysunku A.11, definiuje pętlę. Kryterium zakończenia pętli podano w dolnej części ramki. W tym przypadku komunikaty wymienione w ramce będą się powtarzać do czasu przetworzenia wszystkich obiektów Session wewnątrz obiektu iterator. Zwróćmy uwagę, że dwie strzałki komunikatów zostały użyte do oznaczenia więcej niż jednego komunikatu. To jest skrót, którego celem jest zminimalizowanie liczby strzałek. Komunikaty są przesyłane w takiej kolejności, w jakiej je wymieniono. Wyniki są zwracane w tej samej kolejności.

9

Ten rozdział powstał, zanim zaczęto powszechnie stosować bibliotekę STL. W tamtych czasach używałem własnej biblioteki obsługi kontenerów, w której implementowałem iteratory z obsługą szablonów.

492

DODATEK A NOTACJA UML. CZĘŚĆ I: PRZYKŁAD CGI

Klasy abstrakcyjne i interfejsy na diagramach sekwencji Spostrzegawczy czytelnicy z pewnością zauważyli, że egzemplarze niektórych obiektów pokazanych na rysunku A.11 są tworzone na podstawie interfejsów. Na przykład SessionSchedule to jedna z klas interfejsu bazy danych. Może się wydawać, że to naruszenie zasady, zgodnie z którą nie można tworzyć egzemplarzy klas abstrakcyjnych i interfejsów. Nazwa klasy obiektu na diagramie sekwencji nie musi być nazwą faktycznego typu obiektu. Wystarczy, że ten obiekt jest zgodny z interfejsem wymienionej klasy. W językach o statycznych typach, takich jak C++, Java lub Eiffel, obiekt powinien być egzemplarzem klasy wymienionej na diagramie sekwencji albo klasy będącej pochodną klasy lub interfejsu z diagramu sekwencji. W językach dynamicznych, takich jak Smalltalk lub Objective-C, wystarczy, że obiekt jest zgodny z interfejsem wymienionym na diagramie sekwencji10. Tak więc obiekt SessionSchedule przedstawiony na rysunku A.11 odnosi się do obiektu, którego klasa implementuje interfejs SessionSchedule lub jest pochodną klasy implementującej ten interfejs. Statyczny model generatora menu sesji. Z modelu dynamicznego zaprezentowanego na rysunku A.11 wynika model statyczny pokazany na rysunku A.12. Należy zauważyć, że wszystkie relacje albo są zależnościami, albo asocjacjami oznaczonymi za pomocą stereotypów. To dlatego, że żadna z klas przedstawionych na rysunku nie zawiera zmiennych, które odnoszą się do innych obiektów. Wszystkie relacje są przemijające w tym sensie, że nie trwają dłużej niż wykonanie aktywacji na linii życia obiektu SessionMenuGenerator z rysunku A.11.

Rysunek A.12. Statyczny model aplikacji generatora menu sesji

Relacja pomiędzy klasami SessionMenuGenerator i SessionSchedule zasługuje na specjalną uwagę. Zwróćmy uwagę, że dla klasy SessionSchedule podano właściwość {singleton}. To oznacza, że w aplikacji może istnieć tylko jeden obiekt klasy SessionSchedule oraz że jest on dostępny w zasięgu globalnym. (Patrz podrozdział „Singleton” w rozdziale 16.). Zależność pomiędzy klasami SessionMenuGenerator i HTMLTemplate oznaczono stereotypem «creates». To oznacza, że obiekt SessionMenuGenerator tworzy egzemplarze klasy HTMLTemplate. Asocjacje ze stereotypem «parameter» pokazują, że obiekty uzyskują o sobie informacje za pośrednictwem argumentów metod lub zwracanych wyników.

10

Jeśli tego nie rozumiesz, nie martw się. W językach dynamicznych, takich jak Smalltalk i Objective-C, można przesyłać dowolne komunikaty do dowolnych obiektów. Kompilator nie sprawdza, czy obiekt może zaakceptować określony komunikat. Jeżeli w czasie wykonywania programu do obiektu zostanie przesłany komunikat, którego ten obiekt nie rozpoznaje, występuje błąd wykonania. Tak więc istnieje możliwość, aby dwa zupełnie różne i niepowiązane ze sobą obiekty akceptowały te same komunikaty. O takich obiektach mówi się, że są zgodne z tym samym interfejsem.

SYSTEM REJESTROWANIA KURSÓW: OPIS PROBLEMU

493

W jaki sposób obiekt SessionMenuGenerator uzyskuje sterowanie? Prostokąt aktywacji na linii życia obiektu SessionMenuGenerator z rysunku A.11 nie wskazuje na sposób, w jaki obiekt został uruchomiony. Prawdopodobnie jakiś podmiot wyższego poziomu, na przykład procedura main(), wywołał metodę obiektu SessionMenuGenerator. Tę metodę możemy oznaczyć nazwą Run(). To interesujące, ponieważ musimy napisać kilka innych programów CGI. Wszystkie one w jakiś sposób muszą być uruchomione przez procedurę main(). Być może istnieje klasa bazowa lub interfejs o nazwie CGIProgram, który definiuje metodę Run(), i być może klasa SessionMenuGenerator jest jego pochodną. Przekazywanie danych wprowadzanych przez użytkownika do programu CGI. Klasa CGIProgram pomoże nam w rozwiązaniu innego problemu. Programy CGI zazwyczaj są wywoływane przez przeglądarkę po tym, jak użytkownik wypełni formularz na ekranie przeglądarki. Dane wprowadzone przez użytkownika są wówczas przesyłane do funkcji main() programu CGI za pośrednictwem standardowego urządzenia wejściowego. Funkcja main() może przekazać do obiektu CGIProgram referencję do standardowego strumienia wejściowego, a obiekt CGIProgram może z kolei udostępnić dane do swoich pochodnych. Jaką postać mają dane przekazane z przeglądarki do programu CGI? To zbiór par nazwa-wartość. Każde pole w formularzu wypełnione przez użytkownika ma nadaną nazwę. Chcielibyśmy, aby obiekty pochodne klasy CGIProgram mogły zażądać wartości określonego pola za pośrednictwem jego nazwy. Na przykład: string course = GetValue("course");

Tak więc procedura main() tworzy obiekt CGIProgram i dostarcza mu potrzebnych danych, przekazując do jego konstruktora standardowy strumień wejściowy. Następnie funkcja main() wywołuje metodę Run() obiektu CGIProgram, co rozpoczyna jego pracę. Obiekt pochodnej klasy CGIProgram wywołuje metodę GetValue(string) w celu uzyskania dostępu do danych w formularzu. To jednak sprawia, że pozostaje pewien dylemat. Chcielibyśmy, żeby funkcja main() była generyczna, a jednak trzeba stworzyć odpowiednią pochodną klasy CGIProgram, a takich pochodnych jest wiele. Jak można uniknąć konieczności tworzenia wielu funkcji main()? Możemy rozwiązać ten problem, korzystając z mechanizmu polimorfizmu fazy konsolidacji. Polega on na tym, że funkcję main() implementujemy w pliku implementującym klasę CGIProgram (np. cgiProgram.cc). W treści funkcji main() deklarujemy funkcję globalną o nazwie CreateCGI. Nie implementujemy jednak tej funkcji. Zamiast tego funkcję tę implementujemy w pliku z implementację pochodnej klasy CGIProgram (np. sessionMenuGenerator.cc (patrz rysunek A.13).

Rysunek A.13. Architektura programów CGI

494

DODATEK A NOTACJA UML. CZĘŚĆ I: PRZYKŁAD CGI

Autorzy programów CGI nie muszą już pisać funkcji main(). Zamiast tego w każdej pochodnej klasy CGIProgram muszą dostarczyć implementację globalnej funkcji CreateCGI. Ta funkcja zwraca tę pochodną do funkcji main(), gdzie może ona zostać wykorzystana zgodnie z wymaganiami. Na rysunku A.13 pokazano sposób wykorzystania komponentów ze stereotypem «function» do reprezentowania wolnych funkcji globalnych. Na rysunku pokazano również sposób wykorzystania właściwości w celu pokazania, w jakich plikach funkcje są zaimplementowane. Zwróćmy uwagę, że funkcję CreateCGI oznaczono adnotacją właściwości {file=sessionMenuGenerator.cc}.

Podsumowanie W tym rozdziale omówiliśmy dużą część notacji XML w kontekście prostego przykładu. Pokazaliśmy różne konwencje oznaczeń stosowanych w różnych fazach rozwoju oprogramowania. Przedstawiliśmy sposoby przeprowadzania analiz problemów z wykorzystaniem przypadków użycia i typów w celu stworzenia modelu dziedziny aplikacji. Pokazaliśmy, jak należy łączyć ze sobą klasy, obiekty i komponenty na statycznych i dynamicznych diagramach w celu opisania architektury i konstrukcji oprogramowania. Zaprezentowaliśmy notację UML dla każdego z tych pojęć i pokazaliśmy, w jaki sposób można korzystać z tej notacji. Nie mniej ważne było również pokazanie udziału wszystkich tych pojęć i notacji w tworzeniu projektu oprogramowania. Na temat języka UML i projektowania oprogramowania można by napisać znacznie więcej. W następnym rozdziale wykorzystamy inny przykład w celu pokazania dodatkowych elementów UML, a także innego sposobu analizy i nowych kompromisów projektowych.

Bibliografia 1. Grady Booch, Object-Oriented Analysis and Design with Applications, wydanie drugie, Benjamin Cummings, 1994. 2. Rumbaugh, et al., Object Oriented Modeling and Design, Prentice Hall, 1991. 3. Rebecca Wirfs-Brock, et al., Designing Object-Oriented Software, Prentice Hall, 1990. 4. Peter Coad i Ed Yourdon, Object Oriented Analysis, Yourdon Press, 1991. 5. Ivar Jacobson, Object-Oriented Software Engineering, a Use-Case-Driven Approach. Addison-Wesley, 1992. 6. Alistair Cockburn, Structuring Use Cases with Goals, http://members.aol.com/acockburn/papers/usecass.htm. 7. Edward Kennedy, Object Practitioner’s Guide, http://www.zoo.co.uk/~z0001039/PracGuides, 29 listopada 1997. 8. Grady Booch, Object Solutions, Addison-Wesley, 1995. 9. Gamma, et al., Design Patterns, Addison-Wesley, 1995.

D ODATEK B

Notacja UML. Część II: STATMUX W tym rozdziale będziemy kontynuować eksplorację notacji UML. Tym razem skoncentrujemy się na niektórych bardziej szczegółowych aspektach. Za kontekst dla tej eksploracji posłuży analiza problemu multipleksera statystycznego.

Definicja statystycznego multipleksera Multiplekser statystyczny jest urządzeniem, które umożliwia przesłanie wielu szeregowych strumieni danych za pośrednictwem jednej linii telekomunikacyjnej. Dla przykładu rozważmy urządzenie, które zawiera jeden modem 56K i posiada 16 portów szeregowych. Kiedy dwa takie urządzenia zostaną ze sobą połączone za pośrednictwem linii telefonicznej, to znaki wysyłane do portu 1 na jednym urządzeniu są odbierane z portu 1 na drugim urządzeniu. Takie urządzenie może obsługiwać jednocześnie 16 pełnodupleksowych sesji komunikacji za pomocą pojedynczego modemu. Schemat typowej aplikacji dla takiego urządzenia z lat osiemdziesiątych pokazano na rysunku B.1. W Chicago mamy mieszankę terminali ASCII i drukarek, które chcemy podłączyć do komputera VAX w Detroit. Dysponujemy dzierżawioną linią 56 k, która łączy te dwie lokalizacje. Multiplekser statystyczny tworzy pomiędzy tymi dwoma lokalizacjami 16 wirtualnych kanałów szeregowych.

Rysunek B.1. Typowa aplikacja multipleksera statystycznego

Jest oczywiste, że jeśli wszystkie 16 kanałów działa jednocześnie, to przepustowość 56 K zostanie rozdzielona pomiędzy nimi, co odpowiada efektywnej stopie bitowej na poziomie nieco poniżej 3500 bitów na sekundę na jedno urządzenie. Jednak większość terminali i drukarek nie jest zajęta przez 100% czasu. W rzeczywistości cykl roboczy w wielu aplikacjach wynosi grubo poniżej 10%. Tak więc pomimo tego, że linia jest współdzielona, statystycznie każdy użytkownik będzie postrzegał przepustowość bliską 56 K.

496

DODATEK B NOTACJA UML. CZĘŚĆ II: STATMUX

W niniejszym dodatku zajmiemy się problemem oprogramowania wewnątrz multipleksera statystycznego. To oprogramowanie zarządza sprzętem modemu oraz portu szeregowego. Określa również protokół zwielokrotniania używany do współdzielenia linii komunikacyjnych pomiędzy wszystkimi portami szeregowymi.

Środowisko oprogramowania Na rysunku B.2 przedstawiono schemat blokowy1, na którym zaznaczono miejsce oprogramowania w urządzeniu multipleksera statystycznego. Oprogramowanie to działa pomiędzy portami szeregowymi a modemem.

Rysunek B.2. Schemat blokowy systemu Statmux

Każdy port szeregowy generuje dwa przerwania do procesora głównego — jedno kiedy jest gotowy do wysłania znaku i drugie po otrzymaniu znaku. Modem również generuje podobne przerwania. W związku z tym w systemie występują 34 przerwania. Przerwania pochodzące od modemu mają wyższy priorytet niż przerwania od portu szeregowego. Daje to pewność działania modemu przy pełnej prędkości 56 k, nawet jeśli inne porty szeregowe będą musiały być okresowo uśpione. W systemie jest również timer, który generuje przerwanie co jedną milisekundę. Timer umożliwia oprogramowaniu planowanie zdarzeń w określonym czasie.

Ograniczenia czasu rzeczywistego Niewielkie kalkulacje pokażą problemy, z jakimi musi radzić sobie ten system. W każdym momencie 34 źródła przerwań mogą żądać obsługi w liczbie 5600 przerwań na sekundę — plus dodatkowych tysiąc przerwań na sekundę pochodzących od timera. To daje liczbę 191 400 przerwań na sekundę. A zatem oprogramowanie nie może poświęcić na obsługę jednego przerwania więcej niż 5,2 μs. To oznacza bardzo napięte wymagania czasowe. Będziemy potrzebowali stosunkowo szybkiego procesora, aby mieć pewność, że żadne znaki nie zostaną pominięte. Na domiar złego w większości systemów jest więcej zadań do wykonania niż tylko obsługa przerwań. Trzeba również zarządzać protokołem komunikacyjnym w modemie, zbierać przychodzące znaki od portów szeregowych oraz identyfikować znaki, które muszą być wysłane do portu szeregowego. Wszystko to wymaga pewnych obliczeń, których wykonanie musi jakoś zmieścić się pomiędzy przerwaniami.

1

Schematy blokowe są w notacji GML (ang. Galactic Modeling Language) Kenta Becka. Diagramy GML składają się z linii, prostokątów, okręgów, elips oraz innych figur niezbędnych do przedstawienia istoty problemu.

DEFINICJA STATYSTYCZNEGO MULTIPLEKSERA

497

Na szczęście maksymalna stała przepustowość systemu wynosi tylko 11 200 znaków na sekundę (to oznacza liczbę znaków, które mogą być jednocześnie wysyłane i odbierane przez modem). Wynika stąd, że średnio pomiędzy kolejnymi znakami jest odstęp wynoszący prawie 90 μs2. Ponieważ czas wykonywania procedur obsługi przerwań (ang. Interrupt Service Routines — ISR) nie może przekroczyć 5,2 μs, to pomiędzy przerwaniami mamy dostępne co najmniej 94% czasu procesora. Z tego powodu nie musimy zbytnio przejmować się wydajnością na zewnątrz procedur ISR.

Procedury obsługi przerwań wejścia Być może należałoby je napisać w języku asemblera. Głównym celem procedur ISR obsługi wejścia jest pobranie znaku ze sprzętu i zapisanie go w miejscu, z którego będzie mógł być pobrany przez inne oprogramowanie. Typowy sposób obsługi tego problemu polega na wykorzystaniu cyklicznego bufora. Na rysunku B.3 zaprezentowano diagram klas, na którym przedstawiono strukturę procedur ISR obsługi wejścia wraz z cyklicznymi buforami. W celu opisania unikatowych aspektów procedur obsługi przerwań wprowadziliśmy kilka nowych stereotypów i właściwości.

Rysunek B.3. Procedura obsługi przerwań wejścia

Po pierwsze, mamy klasę InputISR. Ta klasa jest oznaczona stereotypem «ISR», który oznacza, że klasa reprezentuje procedurę obsługi przerwania. Takie klasy są napisane w języku asemblera i mają tylko jedną metodę. Metoda ta nie ma nazwy i jest wywoływana tylko wtedy, gdy wystąpi przerwanie. Klasa InputISR jest połączona asocjacją ze swym buforem cyklicznym reprezentowanym przez klasę RingBuffer. Stereotyp «struct», którym oznaczono klasę RingBuffer, oznacza, że to klasa bez metod. Jest to po prostu czysta struktura danych. Klasę tę oznaczyliśmy stereotypem «struct», ponieważ oczekujemy, że będzie ona wywoływana z funkcji w języku asemblera, skąd nie ma dostępu do metod klasy. Funkcję Put(RingBuffer*, char) umieszczono wewnątrz ikony reprezentującej klasę i opisano stereotypem «reentrant». Ten stereotyp wykorzystany w taki sposób reprezentuje funkcję, która jest wolna od przerwań3. Ta funkcja dodaje znaki do cyklicznego bufora. Jest wywoływana przez obiekt klasy InputISR w odpowiedzi na odebranie znaku. Właściwości funkcji wskazują, że ma ona ograniczenie czasu rzeczywistego 2 μs, że powinna być napisana w języku asemblera oraz powinna być zakodowana w trybie inline w miejscu wywołania. Dwie ostatnie właściwości są próbą spełnienia ograniczenia czasowego.

2

To cała wieczność!

3

Zagadnienie wielobieżności (ang. reentrancy) jest złożone. Jego omówienie wykracza poza ramy tej książki. Polecam sięgnięcie do dobrych materiałów dotyczących systemów czasu rzeczywistego i programowania współbieżnego. Jedną z takich pozycji jest książka Douga Lea, Concurrent Programming in Java, Addison-Wesley, 1997.

498

DODATEK B NOTACJA UML. CZĘŚĆ II: STATMUX

ISRRingBuffer to zwykła klasa. Jej metody są wywoływane poza procedurami obsługi przerwań. Klasa wykorzystuje strukturę RingBuffer i dostarcza dla niej fasady. Wszystkie jej metody są zgodne ze stereotypem «reentrant», dlatego są bezpieczne pod względem przerwań. Klasa ISRRingBuffer implementuje interfejs Ring. Interfejs ten pozwala klientom spoza procedur obsługi przerwań uzyskać dostęp do znaków zapisanych w buforach cyklicznych. Ta klasa reprezentuje granice interfejsu pomiędzy przerwaniami a resztą systemu.

Stereotypy na listach Kiedy stereotypy występują w ramkach zawierających listy, mają specjalne znaczenie. Określony stereotyp dotyczy elementów, które znajdują się poniżej niego na liście.

W tym przykładzie dla funkcji f1() nie określono jawnego stereotypu. Natomiast funkcje f2() i f3() są zgodne ze stereotypem «mójstereotyp». Nie ma żadnych ograniczeń co do liczby stereotypów, które mogą pojawić się w takim polu listy. Każdy nowy stereotyp zastępuje poprzedni. Elementy występujące pomiędzy dwoma stereotypami są zgodne ze stereotypem występującym powyżej nich. W środku listy można wykorzystać pusty stereotyp «». Oznacza on, że dla kolejnych elementów nie określono jawnego stereotypu.

Zachowanie bufora cyklicznego. Bufory cykliczne można opisać za pomocą „prostej” maszyny stanów podobnej do tej, którą pokazano na rysunku B.4. Maszyna stanów pokazuje, co się będzie działo, gdy zostaną wywołane metody Get() i Put() obiektów klasy ISRRingBuffer.

Rysunek B.4. Diagram stanów bufora cyklicznego

DEFINICJA STATYSTYCZNEGO MULTIPLEKSERA

499

Na diagramie oznaczono trzy stany, w których może znajdować się bufor cykliczny. Maszyna rozpoczyna działanie w stanie Empty. W stanie Empty w buforze cyklicznym nie ma znaków. W tym stanie wywołanie metody Get() spowoduje niedomiar (ang. underflow). Na tym etapie nie zdecydowaliśmy jeszcze, co się dzieje w warunkach niedomiaru bądź przepełnienia — te decyzje zostaną podjęte w późniejszym czasie. Dwa stany — Empty i Partial — są podstanami nadstanu Puttable. Nadstan Puttable reprezentuje te stany, w których wywołanie metody Put() nie powoduje przepełnienia. Gdy w jednym ze stanów Puttable zostanie wywołana metoda Put(), wchodzące znaki są zapisywane w buforze, a liczniki i indeksy są odpowiednio aktualizowane. Zarówno Partial, jak i Full są podstanami nadstanu Gettable. Nadstan Gettable reprezentuje te stany, w których wywołanie metody Get() nie powoduje niedomiaru. Kiedy w tych stanach zostanie wywołana metoda Get(), z bufora cyklicznego jest usuwany następny znak i jest on zwracany do obiektu wywołującego. Wykonanie tej operacji powoduje odpowiednie skorygowanie liczników i indeksów. Wywołanie metody Put() w stanie Full powoduje przepełnienie. Dwa przejścia ze stanu Partial są zarządzane przez warunki-strażników. Maszyna przechodzi ze stanu Partial do Empty zawsze wtedy, gdy zmienna count osiągnie wartość zero. Podobnie maszyna przechodzi ze stanu Partial do stanu Full zawsze wtedy, gdy zmienna count osiągnie rozmiar bufora (N).

Stany i wewnętrzne przejścia W języku UML stan jest reprezentowany przez prostokąt z zaokrąglonymi narożnikami. Prostokąt ten może być podzielony na dwie części.

W górnym przedziale występuje nazwa stanu. Brak nazwy oznacza, że stan jest anonimowy. Wszystkie anonimowe stany różnią się od siebie. W dolnym przedziale znajduje się lista wewnętrznych przejść dla stanu. Wewnętrzne przejścia są oznaczane w postaci nazwaZdarzenia/akcja. nazwaZdarzenia musi określać nazwę zdarzenia występującego w przypadku, gdy maszyna występuje w określonym stanie. Maszyna odpowiada na to zdarzenie, pozostając w tym stanie i wykonując wskazaną akcję. Istnieją dwa specjalne zdarzenia, które mogą być wykorzystywane dla wewnętrznych przejść. Oznaczono je na powyższym diagramie. Zdarzenie entry występuje przy wejściu do wybranego stanu. Zdarzenie exit występuje przy wyjściu (nawet dla przejść, które natychmiast powracają do tego stanu). Akcja może być nazwą innej maszyny stanów skończonych, która ma oba stany — initial i final. Akcja może być również wyrażeniem proceduralnym zapisanym w języku programowania albo w pseudokodzie. W procedurze mogą być wykorzystane operacje i zmienne obiektu zawierające maszynę stanów. Akcja może mieć również postać ^obiekt.komunikat(arg1, arg2, ...). W takim przypadku akcja powoduje wysłanie komunikatu o podanej nazwie do obiektu o wskazanej nazwie. Na powyższym schemacie występują dwie specjalne ikony reprezentujące pseudostany. Z lewej strony widzimy pełne koło reprezentujące pseudostan initial. Z prawej strony widzimy ikonę „oka byka” reprezentującą pseudostan final. Kiedy maszyna stanów skończonych zostanie wywołana po raz pierwszy, realizuje przejście z pseudostanu initial do stanu, z którym jest połączona. Zatem z pseudostanu initial może istnieć tylko jedno przejście powodujące opuszczenie tego stanu. Kiedy w wyniku zdarzenia nastąpi przejście do pseudostanu final, maszyna stanów kończy działanie i nie obsługuje więcej zdarzeń.

500

DODATEK B NOTACJA UML. CZĘŚĆ II: STATMUX

Przejścia pomiędzy stanami Maszyna stanów skończonych jest siecią stanów połączonych za pomocą przejść. Przejścia są oznaczone strzałkami łączącymi jeden stan z kolejnym. Przejścia są oznaczone etykietami z nazwą zdarzenia, które inicjuje przejście.

Na tym diagramie widzimy dwa stany połączone za pomocą jednego przejścia. Przejście zostanie „wyzwolone”, jeśli maszyna znajdzie się w stanie stan1 i wystąpi zdarzenie. Po „wyzwoleniu” przejścia maszyna stanów wychodzi ze stanu stan1 i wykonuje wskazaną akcję exit. Potem maszyna wykonuje akcję powiązaną z przejściem. Wchodzi do stanu stan2 i wykonuje jego akcję entry. Zdarzenie, które występuje przy przejściu, może być oznaczone za pomocą warunku-strażnika. Przejście zostanie wyzwolone tylko wtedy, kiedy wystąpi zdarzenie i jednocześnie jest spełniony warunek-strażnik (przyjmuje wartość true). Warunki-strażników definiuje się w postaci wyrażeń logicznych umieszczonych w nawiasach prostokątnych za nazwą zdarzenia (np. mojeZdarzenie[mójWarunekStrażnik]). Akcje przy przejściach są analogiczne do akcji przy przejściach wewnętrznych w obrębie stanów (patrz „Stany i wewnętrzne przejścia”).

Stany zagnieżdżone Kiedy ikona jednego stanu w całości obejmuje jeden lub więcej innych stanów, to stany znajdujące się wewnątrz są podstanami (ang. substates) okalającego nadstanu (ang. superstate).

Na powyższym diagramie stany B i C są podstanami nadstanu S. Maszyna stanów rozpoczyna działanie w stanie A, na co wskazuje pseoudostan initial. Jeśli zostanie wyzwolone przejście V, to uaktywnia się podstan C wewnątrz nadstanu S. Powoduje to wywołanie funkcji entry odpowiadających stanom S i C. Jeśli zostanie wyzwolone przejście Y w czasie, gdy maszyna jest w stanie A, następuje wejście do nadstanu S. Przejście do nadstanu musi powodować uaktywnienie jednego z jego podstanów. Jeśli przejście kończy się na krawędzi nadstanu — tak jak w przypadku przejścia Y — to znaczy, że wewnątrz nadstanu istnieje przejście z pseudostanu initial. Zatem Y uaktywnia przejście z pseudostanu S-Initial do podstanu C. Po wyzwoleniu przejścia Y maszyna wchodzi zarówno do nadstanu S, jak i podstanu C. W tym czasie są wywoływane akcje entry dla stanów S i C. Akcje entry nadstanu są wywoływane przed akcjami entry podstanu. Teraz mogą być wyzwolone przejścia W oraz X, które przełączają maszynę pomiędzy podstanami B i C. Akcje exit i entry będą wykonane tak jak zwykle, ale ponieważ nie nastąpiło wyjście z nadstanu S, to jego funkcje exit nie zostaną wywołane.

DEFINICJA STATYSTYCZNEGO MULTIPLEKSERA

501

Na koniec następuje wyzwolenie przejścia Z. Zwróćmy uwagę, że przejście Z powoduje wyjście poza krawędź nadstanu. To oznacza, że niezależnie od tego, czy podstany B i C są aktywne, przejście Z przełącza maszynę do stanu D. Jest to odpowiednik dwóch oddzielnych przejść — jednego ze stanu C do D i drugiego ze stanu B do D. Oba są oznaczone etykietą Z. Kiedy zostanie wyzwolone przejście Z, wykonana będzie właściwa akcja exit podstanu, a następnie akcja exit nadstanu S. Następnie maszyna przechodzi od stanu D i wykonuje powiązaną z nim akcję entry. Zwróćmy uwagę, że przejście Q kończy się na pseudostanie final. Jeśli wyzwoli się przejście Q, to następuje zakończenie nadstanu S. To spowoduje wyzwolenie nieoznaczonego przejścia z nadstanu S do stanu A. Zakończenie nadstanu powoduje również zresetowanie jakichkolwiek informacji historycznych, jak opisano w dalszej części tego dodatku. Przejście T jest zakończone specjalną ikoną wewnątrz nadstanu S. Określa się ją znacznikiem historii. Kiedy zostanie wyzwolone przejście T, ponownie jest uaktywniany podstan, który był ostatnio aktywny wewnątrz nadstanu S. Zatem jeśli przejście Z nastąpiło w czasie, kiedy był aktywny stan C, to przejście T spowoduje ponowne uaktywnienie stanu C. Jeśli przejście T nastąpi w czasie, gdy znacznik historii jest nieaktywny, wówczas wyzwoli się nieoznaczone przejście ze znacznika historii do podstanu B. To oznacza zachowanie domyślne w sytuacji, gdy nie ma dostępnych informacji o historii. Znacznik historii jest nieaktywny, jeśli nigdy nie nastąpiło wejście do nadstanu S lub bezpośrednio po zakończeniu nadstanu S przez przejście Q. Zatem sekwencja zdarzeń Y-Z-T pozostawia maszynę w podstanie C. Z kolei zarówno sekwencja R-T, jak i Y-W-Q-R-T pozostawi maszynę w podstanie B.

Procedury obsługi przerwań wyjścia Przetwarzanie przerwań wyjściowych jest bardzo podobne do przetwarzania przerwań wejściowych. Są jednak pewne różnice. Część oprogramowania poza podsystemem przerwań ładuje wynikowy bufor cykliczny znakami do wysłania. Port szeregowy generuje przerwanie zawsze wtedy, gdy jest gotowy do wysłania następnego znaku. Usługa przerwań przechwytuje następny znak z bufora cyklicznego i przesyła go do portu szeregowego. Jeśli w buforze cyklicznym nie ma znaków w czasie, kiedy port szeregowy osiągnie gotowość, to procedura obsługi przerwań nie ma nic do roboty. Port szeregowy już zasygnalizował gotowość do przyjęcia nowego znaku i zrobi to ponownie dopiero wtedy, gdy otrzyma znak do wysłania i zakończy wysyłkę. Zatem obsługa przerwania zatrzymuje się. Potrzebujemy więc strategii, która pozwoliłaby na restart przerwań wyjściowych w przypadku, gdyby pojawiły się nowe znaki. Strukturę procedury obsługi przerwań wyjścia przedstawiono na rysunku B.5. Podobieństwo tego schematu do procedury obsługi przerwania wejścia z rysunku B.3 jest oczywiste. Zwróćmy jednak uwagę na zależność «calls» skierowaną od klasy ISRRingBuffer do klasy OutputISR. Wskazuje ona na to, że obiekt ISRRingBuffer może spowodować uaktywnienie obiektu OutpuISR, tak jakby zostało odebrane żądanie przerwania.

Rysunek B.5. Procedura obsługi przerwań dla wyjścia

502

DODATEK B NOTACJA UML. CZĘŚĆ II: STATMUX

Na rysunku B.6 pokazano niezbędne modyfikacje wprowadzone w maszynie stanów skończonych obsługującej wyjściowe bufory cykliczne. Spróbujmy porównać ten rysunek z rysunkiem B4. Zwróćmy uwagę na usunięcie nadstanu Puttable oraz na występowanie dwóch przejść Put. Pierwsze przejście Put prowadzi od stanu Empty do stanu Partial. Powoduje ono wykonanie akcji entry nadstanu Gettable, co generuje sztuczne przerwanie do obiektu OutputISR 4. Drugie przejście Put jest wewnętrzne względem stanu Partial.

Rysunek B.6. Maszyna stanów procedury obsługi przerwań dla wyjścia

Protokoły komunikacji Dwa urządzenia statmux komunikują się za pośrednictwem modemów. Każde wysyła pakiety do drugiego za pośrednictwem linii telekomunikacyjnej. Musimy założyć, że łącze jest niedoskonałe i że mogą pojawić się błędy i awarie. Podczas transmisji znaki mogą zostać utracone lub zniekształcone. W wyniku wyładowań elektrycznych lub innych zakłóceń elektromagnetycznych mogą również pojawić się fałszywe znaki. Dlatego też pomiędzy dwoma modemami musi działać protokół komunikacyjny. Protokół ten musi być w stanie sprawdzić, czy pakiety są kompletne i dokładne. Musi również być w stanie ponowić transmisję pakietów, które zostały zniekształcone lub utracone. Diagram aktywności (ang. activity diagram) zaprezentowano na rysunku B.7 (patrz ramka „Diagramy aktywności”). Pokazuje on protokół komunikacji, z którego będą korzystały urządzenia statmux. Ten protokół jest stosunkowo prostą odmianą protokołu okna przesuwnego z obsługą potoku i techniką piggybacking5. Protokół rozpoczyna się w pseudostanie initial. Następuje zainicjowanie pewnych zmiennych, a następnie stworzenie trzech niezależnych wątków. Zmienne zostaną objaśnione w dalszej części, w punktach poświęconych wątkom, które zależą od tych zmiennych. „Wątek czasowy” jest stosowany do ponawiania transmisji pakietów w przypadku, gdy nie zostanie odebrane potwierdzenie w ciągu dozwolonego okresu. Jest on również wykorzystywany po to, aby potwierdzenia prawidłowo odebranych pakietów były wysyłane terminowo. „Wątek wysyłający” jest wykorzystywany do przesyłania pakietów, które umieszczono w kolejce do transmisji. „Wątek odbierający” używany jest do odbierania, walidacji i przetwarzania pakietów. Spróbujmy po kolei opisać każdy z nich. 4

Mechanizm generowania sztucznych przerwań tego rodzaju w dużym stopniu zależy od platformy. Na niektórych z nich możliwe jest wywołanie procedury obsługi przerwania w taki sposób, jakby to była funkcja. Inne do sztucznego wywoływania procedur obsługi przerwań wymagają bardziej skomplikowanych protokołów.

5

Informacje na temat protokołów komunikacyjnych tego rodzaju można znaleźć w książce Computer Networks, wydanie drugie, Tanenbaum, Prentice Hall, 1988, w podrozdziale 4.4.

DEFINICJA STATYSTYCZNEGO MULTIPLEKSERA

503

Rysunek B.7. Diagram aktywności protokołu komunikacyjnego

Wątek wysyłający. Zmienna S zawiera numer seryjny, którym zostanie oznaczony następny pakiet wychodzący. Każdy pakiet jest oznaczany numerem seryjnym w zakresie 0..N. Wątek wysyłający będzie kontynuował wysyłanie pakietów bez oczekiwania na potwierdzenie do czasu, aż pozostanie W niepotwierdzonych pakietów. Zmienna W jest ustawiona na wartość N/2, co oznacza, że nigdy nie jest wykorzystywanych więcej niż połowa numerów seryjnych. Zmienna SendLimit zazwyczaj zawiera numer seryjny pakietu, który znajduje się poza oknem (W). Zatem jest to najmniejszy numer seryjny, który jeszcze nie może być wysłany. W miarę jak wątek wysyłający kontynuuje wysyłanie pakietów, zwiększa zmienną S modulo N. Kiedy zmienna S osiągnie wartość SendingLimit, wątek blokuje się do czasu, aż wątek wysyłający zmieni wartość zmiennej SendingLimit. Jeśli wartość S nie zrówna się z wartością SendingLimit, to nowy pakiet jest pobierany z kolejki za pomocą funkcji ReadQueue(). Pakiet jest umieszczany na pozycji S w tablicy P. Pakiet jest przechowywany w tej tablicy na wypadek, gdyby było potrzebne ponowienie transmisji. Następnie pakiet jest wysyłany razem z numerem seryjnym (S) oraz potwierdzeniem (A). Zmienna A zawiera numer seryjny ostatniego odebranego pakietu. Zmienna jest aktualizowana przez wątek odbierający. Po wysłaniu pakietu rozpoczynamy odliczanie timeout. Jeśli timeout upłynie przed otrzymaniem potwierdzenia pakietu, wówczas wątek czasowy założy, że albo pakiet, albo potwierdzenie jego odebrania zostały utracone, i ponowi jego transmisję.

504

DODATEK B NOTACJA UML. CZĘŚĆ II: STATMUX

W tym momencie następuje zresetowanie timera potwierdzeń. Kiedy timer potwierdzeń osiąga wartość zero, wątek czasowy zakłada, że upłynęło za dużo czasu od ostatniego wysłania potwierdzenia, dlatego wysyła potwierdzenie ostatniego znanego pakietu, który odebrał. Wątek odbierający. Ten wątek zaczyna się od zainicjowania kilku zmiennych. RCVD to tablica flag logicznych indeksowanych za pomocą numeru seryjnego. W miarę odbierania pakietów są one oznaczane w tablicy RCVD flagą true. Po przetworzeniu pakietu pakiet z numerem seryjnym przesuniętym o W wstecz jest oznaczany flagą false. Zmienna E oznacza numer seryjny pakietu, którego oczekujemy i który ma być przetworzony w następnej kolejności. Zmienna ta zawsze będzie miała wartość A+1 modulo N. W ramach inicjalizacji ustawiamy drugą połowę elementów w tablicy RCVD na true w celu zaznaczenia faktu, że te numery seryjne znajdują się poza dozwolonym oknem. Gdyby je odebrano, zostałyby odrzucone jako pakiety zdublowane. Wątek odbierający oczekuje na ramkę. Ramka może być pakietem lub prostym potwierdzeniem. W każdym przypadku będzie ona zawierała potwierdzenie ostatniego dobrego pakietu. Aktualizujemy wartość zmiennej SendingLimit i wyzwalamy wątek wysyłający. Zwróćmy uwagę, że wartość zmiennej SendingLimit jest ustawiana na wartość oddaloną o W od ostatnio potwierdzonej ramki. Tak więc nadawca może wykorzystać tylko połowę przestrzeni numerów seryjnych, począwszy od ostatniego potwierdzonego pakietu. W ten sposób nadawca i odbiorca ustalili, która połowa przestrzeni numerów seryjnych jest aktualnie prawidłowa. Jeśli ramka zawiera pakiet, to pobieramy numer seryjny tego pakietu i sprawdzamy w tablicy RCVD, czy już odebraliśmy pakiet z takim numerem seryjnym. Jeśli tak, to odrzucamy go jako duplikat. W przeciwnym razie aktualizujemy tablicę RCVD, aby pokazać, że pakiet został odebrany, i zapisujemy pakiet w tablicy R. Mimo że pakiety są wysyłane według numerów seryjnych, mogą być odbierane nie po kolei. Dzieje się tak, ponieważ pakiety mogą zostać po prostu zagubione, a ich transmisja może być ponawiana. W związku z tym pomimo że właśnie odebraliśmy pakiet PS, może to nie być ten pakiet, którego oczekiwaliśmy (E). Jeśli to nie jest ten pakiet, to po prostu czekamy, aż pakiet E zostanie odebrany. Jeśli jednak PS == E, to inicjujemy osobny wątek w celu przetwarzania pakietu. Dodatkowo przesuwamy okno numeru seryjnego poprzez ustawienie pozycji E+W tablicy RCVD na false. Na koniec ustawiamy A na wartość E w celu zaznaczenia, że E był ostatnim dobrym odebranym numerem seryjnym, po czym inkrementujemy E. Wątek czasowy. Timer po prostu czeka na zdarzenie. Mogą wystąpić dwa rodzaje zdarzeń. Zdarzenie Timeout(K) oznacza, że wątek wysyłający wysłał pakiet, ale nigdy nie odebrano potwierdzenia. W związku z tym wątek czasowy ponawia transmisję pakietu K i restartuje timer. Zdarzenie AckTime jest generowane przez powtarzalny timer z możliwością wyzwalania. Ten timer wysyła zdarzenie AckTime co X milisekund. Można go jednak wyzwolić w dowolnym momencie, aby

rozpoczął odliczanie od X. Wątek wysyłający wyzwala ten timer za każdym razem, gdy wyśle pakiet. Jest to właściwe, ponieważ z każdym pakietem jest przesyłane potwierdzenie. Jeśli w ciągu X milisekund nie został przesłany pakiet, to występuje zdarzenie AckTime, a wątek czasowy wysyła ramkę z potwierdzeniem. Uff! Być może niektórym czytelnikom przebrnięcie przez powyższy opis sprawiło pewną trudność. Wyobraźmy sobie jednak, co by było, gdybym nie umieścił tego objaśniającego tekstu. Być może diagram wyraża mój zamiar, ale z całą pewnością dodatkowy opis się przydaje. Diagramy rzadko są wystarczającym opisem. Skąd wiadomo, czy diagram jest prawidłowy? Nie wiemy tego! Wcale bym się nie zdziwił, gdyby kilku czytelników znalazło w nim błąd. Diagramów zazwyczaj nie da się testować bezpośrednio, tak jak można testować kod. Aby zatem sprawdzić, czy algorytm jest prawidłowy, trzeba poczekać na kod. Z powodu występowania tych dwóch problemów użyteczność takich schematów staje się wątpliwa. Mogą one pełnić rolę dobrych narzędzi edukacyjnych, ale nie należy uważać ich za wystarczająco ekspresywne i dokładne do tego, by mogły być uznane za jedyną specyfikację projektu. Opis, kod i testy również są potrzebne.

DEFINICJA STATYSTYCZNEGO MULTIPLEKSERA

Diagramy aktywności Diagramy aktywności są hybrydą diagramów przejść pomiędzy stanami, schematów blokowych i sieci Petriego. Diagramy te najbardziej nadają się do opisywania algorytmów wielowątkowych sterowanych zdarzeniami. Diagram aktywności jest diagramem stanów. Nadal jest to wykres stanów połączonych za pomocą przejść. Jednak diagramy aktywności zawierają specjalne rodzaje stanów i przejść. Stan akcji

Stan akcji rysuje się w postaci bloku z okrągłymi bokami i płaskimi krawędziami górną i dolną. Ikona ta różni się od ikony reprezentującej zwykły stan tym, że narożniki tej drugiej są ostre, natomiast ikona stanu ma narożniki zaokrąglone (patrz „Stany i wewnętrzne przejścia”). Wewnątrz ikony stanu akcji wymieniona jest jedna lub kilka instrukcji proceduralnych reprezentujących ich akcje entry (analogicznie do ramki procesu na schemacie blokowym). Po wejściu do stanu akcji jego akcje entry są wykonywane natychmiast. Po wykonaniu tych akcji następuje wyjście ze stanu. Przejście wychodzące nie może mieć etykiety zdarzenia, ponieważ rolę „zdarzenia” spełnia samo wykonanie akcji entry. Może jednak istnieć kilka przejść wychodzących — każde opatrzone wzajemnie wykluczającymi się warunkami-strażnikami. Unia wszystkich warunków-strażników musi zawsze mieć wartość true (tzn. nie ma możliwości „utknięcia” w stanie akcji). Decyzje

Dzięki temu, że ze stanu akcji może prowadzić wiele przejść strzeżonych warunkami, może on spełniać rolę etapu podejmowania decyzji. Jednak decyzje powinny być raczej oznaczane jawnie — za pomocą tradycyjnego symbolu rombu. Przejście wchodzi do rombu, a opuszcza go N przejść strzeżonych warunkami. Jak wspominałem wcześniej, unia logiczna wszystkich wychodzących warunków-strażników musi zwracać wartość true. Na rysunku B.7 wykorzystano odmianę ikony rombu, która bardziej przypomina schemat blokowy. Wewnątrz rombu sformułowano warunek logiczny, a dwa przejścia wyjściowe oznaczono etykietami Tak i Nie. Przejścia złożone

505

506

DODATEK B NOTACJA UML. CZĘŚĆ II: STATMUX

Przejścia złożone pokazują dzielenie i łączenie wielu wątków sterowania. Oznacza się je za pomocą czarnej kreski zwanej paskiem asynchronizacji. Stany są połączone z paskiem synchronizacji za pomocą strzałek. Stany skierowane do paska asynchronizacji są nazywane źródłowymi, natomiast te, które są skierowane od paska na zewnątrz, to stany docelowe. Cała grupa strzałek prowadzących do paska i od paska tworzy pojedyncze przejście. Strzałki nie są oznaczone ani etykietami zdarzeń, ani warunkami-strażnikami. Przejścia są wyzwalane w chwili, gdy wszystkie stany źródłowe są zajęte (tzn. gdy trzy niezależne wątki znajdują się w odpowiednich stanach). Ponadto stany źródłowe muszą być stanami rzeczywistymi, a nie stanami akcji (tzn. muszą mieć możliwość oczekiwania). Po wyzwoleniu następuje wyjście ze wszystkich stanów źródłowych i wejście do wszystkich stanów docelowych. Jeśli jest więcej stanów docelowych niż źródłowych, następuje rozwidlenie nowych wątków sterowania. Jeśli jest więcej stanów źródłowych, to znaczy, że niektóre wątki zostały połączone. Każde wejście do stanu źródłowego powoduje zwiększenie wartości licznika. Każdorazowe wyzwolenie złożonego przejścia powoduje zmniejszenie wartości liczników jego stanów źródłowych. Stan źródłowy jest uważany za zajęty tak długo, jak długo jego licznik ma niezerową wartość. Dla wygody notacji w roli źródła dla paska asynchronizacji może wystąpić rzeczywiste przejście lub stan akcji (patrz rysunek B.7). W takim przypadku zakłada się, że przejście kończy się w bezimiennym rzeczywistym stanie, który jest stanem źródłowym dla paska asynchronizacji.

Struktura oprogramowania protokołów komunikacyjnych. Trzy wątki sterowania współdzielą te same zmienne. W związku z tym funkcje wywoływane przez te wątki powinny prawdopodobnie być metodami tej samej klasy. Jednak w większości współczesnych systemów obsługi wątków wątki są utożsamiane z obiektami. Oznacza to, że z każdym wątkiem jest związany obiekt, który tym wątkiem zarządza. W języku UML nazywa się je obiektami aktywnymi (patrz punkt „Obiekty aktywne”). Tak więc klasa, która zawiera metody protokołu, będzie również musiała stworzyć aktywne obiekty, które sterują wątkami. Wątek czasowy będzie przydatny w miejscach niezwiązanych z obsługą protokołu, dlatego ten wątek powinien być utworzony w innej części systemu. Zatem obiektowi protokołu pozostaje utworzenie wątku nadawczego i odbiorczego. Na rysunku B.8 zaprezentowano diagram obiektów (patrz punkt „Diagramy obiektów”), który przedstawia sytuację bezpośrednio po zainicjowaniu obiektu CommunicationsProtocol. Obiekt Communications Protocol utworzył dwa obiekty Thread i przejął odpowiedzialność za ich istnienie. Wewnątrz obiektu Thread wykorzystano wzorzec projektowy Polecenie6 w celu uruchomienia nowo utworzonego wątku wykonania. Każdy obiekt Thread zawiera egzemplarz obiektu implementującego interfejs Runnable (patrz punkt „Notacja lizaka”). Wykorzystano również wzorzec projektowy Adapter7 w celu powiązania obiektów Thread z odpowiednimi metodami obiektu CommunicationsProtocol. Podobny układ można zaobserwować pomiędzy obiektami Timer i CommunicationsProtocol. Jednak w tym przypadku istnienie obiektu Timer nie jest zarządzane przez obiekt CommunicationsProtocol. 6

Patrz rozdział 13.

7

Patrz rozdział 25.

DEFINICJA STATYSTYCZNEGO MULTIPLEKSERA

507

Rysunek B.8. Diagram obiektów: bezpośrednio po zainicjowaniu obiektu protokołu

Relacja «friend» została użyta dlatego, ponieważ chcemy, aby metody wywoływane przez adaptery były prywatne dla obiektu CommunicationsProtocol. Nie chcemy, aby były wywoływane przez obiekty inne niż adaptery8.

Diagramy obiektów Diagramy obiektów przedstawiają statyczne relacje istniejące pomiędzy zbiorem obiektów w konkretnym czasie. Diagramy te różnią się od diagramów klas na dwa sposoby. Po pierwsze, przedstawiają obiekty, a nie klasy oraz połączenia pomiędzy obiektami zamiast relacji pomiędzy klasami. Po drugie, diagramy klas pokazują relacje i zależności na poziomie kodu źródłowego, natomiast diagramy obiektów pokazują tylko relacje i zależności czasu wykonywania, które istnieją w chwili określonej przez diagram obiektów. Zatem diagram obiektów pokazuje obiekty i połączenia, które istnieją, gdy system znajduje się w określonym stanie.

8

Istnieje kilka innych sposobów osiągnięcia tego celu. W Javie można wykorzystać klasy wewnętrzne.

508

DODATEK B NOTACJA UML. CZĘŚĆ II: STATMUX

Na poprzednim rysunku pokazano diagram klas i diagram obiektów, które reprezentują jeden z możliwych stanów obiektów i powiązań, wywodzących się z klas i relacji na diagramie klas. Zwróćmy uwagę, że obiekty zostały narysowane w taki sam sposób jak na diagramie sekwencji. Są reprezentowane przez prostokąty z podkreślonymi nazwami złożonymi z dwóch komponentów. Zwróćmy także uwagę, że relacje na diagramie obiektów są narysowane w taki sam sposób jak na diagramie klas. Relacja pomiędzy dwoma obiektami nazywa się połączeniem. Połączenie pozwala na przesyłanie komunikatów w odpowiednim kierunku. W tym przypadku komunikaty mogą być przesyłane z obiektu egzC do obiektu egzD. To połączenie istnieje, ponieważ istnieje relacja kompozycji pomiędzy klasą A a klasą D oraz dlatego, że klasa C jest pochodną klasy A. Zatem egzemplarz klasy C może mieć połączenia wywodzące się z jej klas bazowych. Zauważmy także, że relacja pomiędzy klasą A i klasą E nie jest reprezentowana na diagramie obiektów. To dlatego, że diagram obiektów przedstawia określony stan systemu, w którym obiekty C nie są powiązane z obiektami E.

Obiekty aktywne Obiekty aktywne są obiektami, które są odpowiedzialne za jeden wątek wykonania. Wątek wykonania nie musi być uruchomiony wewnątrz metod aktywnego obiektu. Obiekt aktywny zazwyczaj odwołuje się do innych obiektów. Obiekt aktywny jest po prostu obiektem, z którego pochodzi wątek wykonania. Jest to również obiekt, który udostępnia interfejsy zarządzania wątkami, takie jak Terminate i Suspend oraz ChangePriority.

Obiekty aktywne są rysowane tak jak zwykłe obiekty, ale z pogrubionym konturem. Jeśli aktywny obiekt posiada również inne obiekty, które działają w ramach jego wątku sterowania, można narysować te obiekty wewnątrz granic obiektu aktywnego.

Notacja lizaka Interfejsy mogą być zaprezentowane w postaci klas, ze stereotypem «interface», albo można je zaprezentować z wykorzystaniem specjalnej ikony w postaci lizaka (ang. lollipop).

Oba diagramy w tej ramce mają dokładnie takie samo znaczenie. Egzemplarze klasy Klient korzystają z interfejsu Serwer. Klasa ImplSerwera implementuje interfejs Server.

DEFINICJA STATYSTYCZNEGO MULTIPLEKSERA

509

Każdą z dwóch relacji połączonych z „lizakiem” można pominąć, jak pokazano na poniższym diagramie:

Proces inicjalizacji. Poszczególne etapy przetwarzania wykorzystywane do zainicjowania obiektu CommunicationsProtocol pokazano na rysunku B.9. Jest to diagram kolaboracji (zobacz punkt „Diagramy

kolaboracji”).

Rysunek B.9. Diagram kolaboracji: Inicjowanie obiektu CommunicationsProtocol

Proces inicjalizacji rozpoczyna się od komunikatu numer 1. Obiekt CommunicationsProtocol odbiera komunikat Initialize z pewnego nieznanego źródła. Obiekt ten odpowiada komunikatami 1.1 i 1.2 poprzez stworzenie obiektu SendingThread oraz powiązanego z nim obiektu SenderRunAdapter. Następnie za pomocą komunikatów 1.3 i 1.4 wiąże adapter z wątkiem i uruchamia wątek. Zwróćmy uwagę, że komunikat 1.4 jest asynchroniczny, zatem proces inicjalizacji jest kontynuowany za pomocą komunikatów od 1.5 do 1.8, które powtarzają procedurę tworzenia obiektu ReceivingThread. W międzyczasie komunikat 1.4.1a rozpoczyna osobny wątek wykonania. Wątek ten wywołuje metodę Run obiektu SenderRunAdapter. W efekcie adapter przesyła komunikat 1.4.1.1a:RunSendingThread do obiektu CommunicationsProtocol. To uruchamia przetwarzanie wątku wysyłającego. Podobny łańcuch zdarzeń uruchamia wątek odbiorczy. Na koniec komunikaty od 1.9 do 1.12 tworzą adaptery czasowe i rejestrują je z timerem.

510

DODATEK B NOTACJA UML. CZĘŚĆ II: STATMUX

Diagramy kolaboracji Diagramy kolaboracji są podobne do diagramów obiektów z tą różnicą, że pokazują, w jaki sposób stan obiektu zmienia się w czasie. Komunikaty przesyłane pomiędzy obiektami są zaprezentowane razem z ich argumentami i zwracanymi wartościami. Każdy komunikat jest oznaczony numerem porządkowym w celu pokazania kolejności względem innych komunikatów.

Komunikaty są rysowane w postaci niewielkich strzałek umieszczonych w pobliżu połączenia pomiędzy dwoma obiektami. Strzałka wskazuje na obiekt, który odbiera komunikat. Komunikat jest oznaczony nazwą oraz numerem porządkowym. Numer porządkowy jest oddzielony od nazwy komunikatu dwukropkiem. Za nazwą komunikatu występują nawiasy zawierające rozdzielaną przecinkami listę argumentów komunikatu. Numer porządkowy jest rozdzielaną kropkami listą liczb, za którymi występuje opcjonalny identyfikator wątku. Liczby wchodzące w skład numeru porządkowego oznaczają zarówno kolejność komunikatu, jak i jego głębokość w hierarchii wywoływania. Komunikat numer 1 jest pierwszym, który powinien zostać wysłany. Jeśli procedura wywołana przez komunikat 1 wywoła dwa inne komunikaty, to będą one oznaczone odpowiednio 1.1 i 1.2. Kiedy komunikaty te zwrócą sterowanie i przetwarzanie komunikatu numer 1 zakończy się, kolejnemu komunikatowi zostanie nadany numer 2. Dzięki zastosowaniu tego systemu kropek możliwe jest kompletne opisanie zarówno kolejności, jak i sposobu zagnieżdżania komunikatów. Identyfikator wątku oznacza nazwę wątku, w którym działa komunikat. Jeżeli identyfikator wątku zostanie pominięty, oznacza to, że komunikat wykonuje się w wątku bez nazwy. Jeśli komunikat o numerze 1.2 zainicjuje nowy wątek o nazwie t, to pierwszemu komunikatowi tego nowego wątku zostanie nadana nazwa 1.2.1t. Zwracane wartości i argumenty mogą być pokazane z wykorzystaniem symbolu znacznika danych (niewielka strzałka zakończona kółkiem). Alternatywnie zwracane wartości mogą być pokazane z wykorzystaniem składni przypisania w nazwie komunikatu w następujący sposób: 1.2.3 : c:=message(a,b)

W tym przypadku wartość zwracana przez funkcję message będzie zapisana w zmiennej c.

Komunikat oznaczony strzałką z pełnym grotem — jak pokazano z lewej strony — reprezentuje synchroniczne wywołanie funkcji. Taki komunikat nie zwraca sterowania, dopóki nie zakończą działania inne synchroniczne komunikaty wywołane z procedury obsługi tego komunikatu. Jest to standardowy rodzaj komunikatu w takich językach jak C++, Smalltalk, Eiffel i Java.

Grot w postaci kresek — jak pokazano po lewej stronie — reprezentuje komunikat asynchroniczny. Taki komunikat inicjuje nowy wątek sterowania w celu uruchomienia wywołanej metody, a następnie natychmiast zwraca sterowanie. Zatem komunikat zwraca sterowanie przed wykonaniem metody. Komunikaty wysłane przez metodę powinny być oznaczone identyfikatorem wątku, ponieważ wykonują się w wątku, który różni się od wątku wywołania.

DEFINICJA STATYSTYCZNEGO MULTIPLEKSERA

511

Sytuacje wyścigu w ramach protokołu. W protokole opisanym na rysunku B.7 występuje szereg interesujących sytuacji wyścigu. Wyścig występuje w przypadku, gdy nie można przewidzieć kolejności dwóch odrębnych zdarzeń, a ta kolejność ma znaczenie dla stanu systemu. Stan systemu zależy następnie od tego, które zdarzenie „wygrało” wyścig. Programista próbuje zadbać o to, aby system działał poprawnie, bez względu na kolejność zdarzeń. Sytuacje wyścigu są jednak trudne do zidentyfikowania. Niewykryte sytuacje wyścigu mogą prowadzić do trudnych do zdiagnozowania błędów. Jako przykład sytuacji wyścigu rozważmy ciąg zdarzeń występujących podczas wysyłania pakietu (patrz rysunek B.10). Taki rodzaj diagramu określa się nazwą wykres sekwencji komunikatów (zobacz punkt „Wykresy sekwencji komunikatów”). Lokalny nadawca wysyła pakiet S i rozpoczyna odliczanie limitu czasu. Zdalny odbiorca odbiera pakiet i powiadamia nadawcę, że pakiet S został odebrany bez problemu. Zdalny nadawca albo wysyła oddzielny pakiet ACK, albo umieszcza potwierdzenie ACK w następnym pakiecie. Lokalny odbiorca odbiera pakiet ACK i przerywa odliczanie timeout.

Rysunek B.10. Potwierdzenia pakietu: stan normalny

Czasami potwierdzenie ACK nie trafia do nadawcy. W takim przypadku upływa timeout, a nadawca ponawia transmisję pakietu. Taką sytuację przedstawiono na rysunku B.11.

Rysunek B.11. Brak potwierdzenia pakietu; ponowienie transmisji

Wyścig występuje pomiędzy tymi dwoma warunkami ekstremalnymi. Istnieje możliwość, że timer przerywa zliczanie czasu bezpośrednio po wysłaniu pakietu ACK. Taki scenariusz pokazano na rysunku B.12. Zwróćmy uwagę na przecinające się linie. One reprezentują wyścig. Pakiet S został wysłany i prawidłowo odebrany. Co więcej, pakiet z potwierdzeniem ACK został odesłany. Jednak potwierdzenie ACK dotarło już po upływie timeout. W związku z tym transmisja pakietu będzie ponowiona pomimo otrzymania potwierdzenia ACK.

512

DODATEK B NOTACJA UML. CZĘŚĆ II: STATMUX

Rysunek B.12. Wyścig ACK; ponowienie transmisji

Logika zaprezentowana na rysunku B.7 właściwie radzi sobie z wyścigiem tego rodzaju. Zdalny odbiorca odkryje, że drugi odebrany pakiet S jest duplikatem i odrzuci go.

Wykresy sekwencji komunikatów Wykresy sekwencji komunikatów są specjalną formą diagramów sekwencji. Podstawową różnicą jest to, że strzałki komunikatów są skierowane w dół, pod kątem. To pokazuje, że pomiędzy wysłaniem i odebraniem komunikatu może upłynąć pewien czas. Poza tym na wykresie sekwencji komunikatów mogą się znaleźć wszystkie pozostałe elementy diagramu sekwencji, z aktywacjami i numerami porządkowymi włącznie. Głównym zastosowaniem wykresów sekwencji komunikatów jest wykrywanie i dokumentowanie sytuacji wyścigu. Te wykresy bardzo dobrze pokazują względne czasy pewnych zdarzeń. Pokazują także, że dwa niezależne procesy mogą w inny sposób postrzegać kolejność zdarzeń. Rozważmy rysunek B.12. Z punktu widzenia obiektu Timer zdarzenie Timeout nastąpiło przed zdarzeniem PrzerwanieTimeoutu. Natomiast z punktu widzenia obiektu lokalnyNadawca wygląda, jakby te dwa zdarzenia zachodziły w odwrotnej kolejności. Ta różnica w postrzeganiu kolejności zdarzeń może prowadzić do wad logiki — sytuacji, które są bardzo wrażliwe na czas i bardzo trudne do odtworzenia i zdiagnozowania. Wykresy sekwencji komunikatów są bardzo wygodnym narzędziem do wykrywania takich sytuacji, zanim spowodują problemy.

Wniosek W tym dodatku zaprezentowaliśmy większość dynamicznych technik modelowania UML. Pokazaliśmy maszyny stanów, diagramy aktywności, kolaboracji oraz wykresy sekwencji komunikatów. Pokazaliśmy też, jak te diagramy rozwiązują problemy typowe dla jednego i wielu wątków sterowania.

Bibliografia 1. Gamma, et al., Design Patterns, Reading, MA: Addison-Wesley, 1995.

D ODATEK C

Satyra na dwa przedsiębiorstwa Mam świetny pomysł, jak wstąpić do klubu najlepszych producentów oprogramowania i rzucić świat na kolana! — Rufus T. Firefly

Rufus! Inc. Project Kickoff

Rupert Industries Projekt Alpha

Masz na imię Bogdan. Jest 3 stycznia 2001 roku. Wciąż boli Cię głowa po balu, na którym witałeś nadejście nowego milenium. Siedzisz w pokoju konferencyjnym w towarzystwie kilku menedżerów i grupy kolegów. Jesteś liderem zespołu projektowego. Na spotkaniu jest Twój szef, który zaprosił liderów wszystkich zespołów. Spotkanie zorganizował jego przełożony. — Musimy zrealizować nowy projekt — powiedział szef Twojego szefa. Nazwijmy go Superszefem. Superszef zebrał już tyle „punktów”1, że zaczyna chodzić z głową w chmurach. Twój bezpośredni szef dopiero zaczął zbierać punkty, ale już nie może się doczekać, kiedy wreszcie zostawi ślady swojej brylantyny na suficie. Superszef opisuje istotę właśnie zidentyfikowanego rynku oraz projekt, który ma umożliwić firmie zdobycie tego rynku. — Musimy zakończyć ten projekt do początku czwartego kwartału, do 1 października — zażądał Superszef. — Żaden projekt nie ma wyższego priorytetu, więc wstrzymujemy wszystkie bieżące projekty. Uczestnicy spotkania zareagowali na te słowa głuchą ciszą. Oznacza to, że efekt miesięcy prac trzeba będzie wyrzucić do kosza. Po chwili nad stołem konferencyjnym zaczyna się unosić szmer niezadowolenia. Punkty na głowie Superszefa zaczynają się jarzyć diabelską, zieloną poświatą. Kiedy lustruje wzrokiem kolejnych uczestników spotkania, jego oczy spotykają

Masz na imię Robert. Jest 3 stycznia 2001 roku. Po Świętach spokojnie spędzonych w towarzystwie najbliższej rodziny wracasz do pracy odświeżony, z nowymi siłami do pracy. Siedzisz w pokoju konferencyjnym ze swoim zespołem specjalistów. Spotkanie zwołał szef Twojego działu. — Mamy kilka pomysłów związanych z nowym projektem — powiedział menedżer działu. Ma na imię Roman. Jest dynamicznym facetem, który ma więcej energii niż reaktor jądrowy. Jest bardzo ambitny i zmotywowany, ale rozumie wartość pracy zespołowej. Roman opisuje istotę nowego rynku zidentyfikowanego przez Waszą firmę i prowadzi Cię do Jerzego, menedżera działu marketingu odpowiedzialnego za definiowanie produktów, które powinny umożliwić podbój tego rynku. Jerzy zwraca się do Ciebie słowami: — Chcielibyśmy możliwie szybko przystąpić do definiowania pierwszej oferty przyszłego produktu. Kiedy możesz zorganizować moje spotkanie z Twoim zespołem? Odpowiadasz: — Bieżącą iterację naszego projektu zakończymy w ten piątek. Do tego czasu możemy znaleźć kilka godzin na spotkanie w sprawie nowego projektu. Po spotkaniu wybiorę kilku członków zespołu, którzy będą odpowiedzialni wyłącznie za nowy projekt. Zaraz potem zaczniemy

1

Autor pisze o „punktach”, które są reprezentowane przez długość włosów. Kiedy ktoś „otrzyma punkt”, wydłużają mu się włosy, analogicznie do nosa Pinokia, gdy ten skłamał — przyp. tłum.

514

DODATEK C SATYRA NA DWA PRZEDSIĘBIORSTWA

się kolejno ze zmieszanymi spojrzeniami podwładnych, powodując u nich odruchowe drgawki. Nie ulega wątpliwości, że decyzja Superszefa nie będzie podlegała dyskusji. Po przywróceniu bezwzględnej ciszy Superszef powiedział: — Prace trzeba rozpocząć natychmiast. Ile czasu zajmie wam przeprowadzenie niezbędnych analiz? Podnosisz rękę. Twój szef próbuje Cię powstrzymać, ale nie zauważasz jego sygnałów i nadal domagasz się głosu. — Proszę pana, nie możemy stwierdzić, jak długo potrwa analiza, skoro nie dysponujemy żadnymi wymaganiami. — Dokument opisujący wymagania będzie gotowy w ciągu trzech, czterech tygodni — odpowiada Superszef. Punkty na jego głowie zaczynają wibrować. Jest sfrustrowany. — Przyjmijmy, że macie już wymagania. Ile czasu zajmie wam ich analiza? Wszyscy wstrzymują oddech. Uczestnicy spotkania zaczynają uważnie obserwować się nawzajem w poszukiwaniu kogoś, kto ma jakiś pomysł. — Jeśli nie zdążymy z analizą do 1 kwietnia, będziemy mieli poważny problem. Potraficie skończyć analizę do tego czasu? Twój szef wyraźnie nabiera odwagi: — Cóż, możemy spróbować. Jego punkty właśnie urosły o 3 mm, a Twój ból głowy zmusił Cię do połknięcia dwóch tabletek przeciwbólowych. — Dobrze! — Superszef uśmiechnął się. — W takim razie ile czasu zajmie wam opracowanie projektu? — Proszę pana — mówisz, a Twój szef blednie. Najwyraźniej obawia się, że jego 3-milimetrowe punkty są zagrożone. — Bez przeprowadzenia analizy nie możemy stwierdzić, jak długo potrwa opracowanie projektu. Oblicze Superszefa staje się coraz bardziej surowe. — UDAWAJCIE, że już przeprowadziliście tę analizę — mówi, wpatrując się w Ciebie swoimi małymi oczkami. — Ile czasu zajmie wam opracowanie tego projektu? Wygląda na to, że dwie tabletki na ból głowy nie pomogą. Twój szef próbuje desperacko ratować swoje ostatnio zdobyte punkty: — Panie dyrektorze, skoro całe przedsięwzięcie nie może trwać dłużej niż sześć miesięcy, projekt powinniśmy mieć najpóźniej w ciągu trzech miesięcy.

przyjmować do zespołu ich następców, sukcesywnie przenosząc do nowego projektu kolejnych ludzi. — To świetnie! — mówi Roman. — Chciałbym tylko, żebyś miał świadomość, iż nowy projekt ma najwyższy priorytet, ponieważ wstępne efekty prac chcielibyśmy przedstawić już na lipcowych targach. Gdybyśmy do tego czasu nie opracowali żadnej działającej wersji, stracilibyśmy świetną okazję promocji naszego nowego produktu. — Rozumiem — odpowiadasz. — Nie wiem jeszcze, o jaki system chodzi, ale jestem pewien, że do lipca uda nam się zrobić coś działającego. Na razie jednak nie mogę powiedzieć, czym będzie to „coś”. Tak czy inaczej, pan i Jerzy będziecie mieli pełną wiedzę o postępach prac. Możecie być spokojni o stan systemu do lipcowych targów. Roman z zadowoleniem kiwa głową. Doskonale wie, jak przebiega cały proces. Twój zespół zawsze dzielił się z nim swoimi spostrzeżeniami, jednocześnie akceptując jego decyzje. Jest pewny, iż Twój zespół w pierwszej kolejności zajmie się tym, co najważniejsze, i że jakość produktu końcowego nie będzie budziła najmniejszych wątpliwości. *** — Dobra, Robert — powiedział Jerzy na pierwszym spotkaniu — jak Twój zespół zareagował na propozycję podziału? — Na pewno będziemy tęsknić do wspólnych projektów — odpowiadasz — ale część z nas była już trochę zmęczona ostatnim projektem i sama szukała zmian. Powiedz mi tylko, czym będziecie się zajmowali. Jerzy ożywia się: — Wiesz, z iloma problemami muszą się mierzyć nasi obecni klienci... Przez kolejne pół godziny opisuje Ci interesujący go problem wraz z możliwymi rozwiązaniami. — No dobrze, ale zaczekaj chwilę — odpowiadasz. — Muszę mieć pełną wiedzę na temat tego projektu. Po tej uwadze prowadzisz z Jerzym długą rozmowę o przyszłym kształcie planowanego systemu. Niektóre jego pomysły wydają się jeszcze nieukształtowane. Sugerujesz możliwe rozwiązania. Jerzy przyjmuje część z nich z zadowoleniem. Kontynuujecie dyskusję. W czasie wspólnych rozważań formułujecie nowe aspekty, a Jerzy skrupulatnie zapisuje odpowiednie karty historyjek użytkowników. Każda taka karta reprezentuje jakąś operację, którą

SATYRA NA DWA PRZEDSIĘBIORSTWA

— Dobrze, że się zgadzamy, Smithers — odrzekł rozpromieniony Superszef. Twój szef lekko się rozluźnia. Wie, że jego punkty są bezpieczne. Po chwili już nawet słyszy, jak we włosach „szumi” mu brylantyna. Superszef mówi dalej: — Skoro analiza będzie gotowa do 1 kwietnia, projekt powinien być gotów przed 1 lipca. Zatem na implementację pozostaną trzy miesiące. Nasze spotkanie jest doskonałym przykładem tego, jak dobrze sprawdza się nowa polityka dochodzenia do konsensusu. Idźcie i bierzcie się do pracy. Chciałbym, aby plany TQM i QIT znalazły się na moim biurku w przyszłym tygodniu. A! I nie zapomnijcie o spotkaniach zespołów i raportach w związku z miesięcznym audytem jakościowym. — Tabletki na ból głowy chyba nie pomogą — myślisz po powrocie do swojego pokoju. — Potrzebuję mocnego bourbona. Nagle do pokoju wchodzi Twój rozpromieniony szef i mówi: —To było naprawdę świetne spotkanie. Myślę, że nasz projekt wreszcie rzuci świat na kolana. Ze zrozumieniem kiwasz głową — jesteś tak zażenowany, że nie potrafisz się zdobyć na żaden inny gest. — Ach — mówi dalej Twój szef — prawie bym zapomniał. Przekazuje Ci 30-stronicowy dokument. — Pamiętaj, że w przyszłym tygodniu mamy wizytę audytorów SEI. Masz tutaj instrukcję. Musisz ją przeczytać, zapamiętać i zniszczyć. Znajdziesz tu odpowiedzi na wszelkie pytania, które mogą Ci zadać. Jest tutaj napisane także, do których części budynku możesz ich zaprowadzić, a których obszarów powinieneś unikać. Chcemy wejść na trzeci poziom CMM już w czerwcu!

*** Wraz ze swoimi współpracownikami (innymi liderami zespołów) przystępujesz do analizy nowego projektu. Zadanie jest trudne, ponieważ nie dysponujesz żadnymi wymaganiami. Z drugiej strony, po 10-minutowym wprowadzeniu wygłoszonym przez Superszefa pamiętnego poranka masz jakieś pojęcie, co produkt powinien robić. Ze względu na obowiązujące procedury korporacyjne najpierw musisz utworzyć dokument z przypadkami użycia. Wraz ze swoim zespołem identyfikujesz kolejne przypadki użycia i nanosisz odpowiednie owale i ludziki na diagramy. Filozoficzne rozważania doprowadziły do pewnych podziałów wśród członków Twojego zespołu.

515

nowy system powinien realizować. Karty zaczynają wypełniać stół. Zarówno Ty, jak i Jerzy wybieracie interesujące Was karty i nanosicie na nie notatki zgodnie z prowadzoną dyskusją. Karty historyjek użytkowników skutecznie reprezentują złożone koncepcje w dość prostej formie. Na końcu spotkania mówisz do Jerzego: — Dobrze, mam już ogólne pojęcie o twoich zamierzeniach. Porozmawiam o tym ze swoim zespołem. Podejrzewam, że będą chcieli przeprowadzić kilka eksperymentów na rozmaitych strukturach baz danych i z różnymi formatami prezentacji. Na następne spotkanie przyjdę już z grupą programistów, zatem będziemy mogli przystąpić do identyfikacji szczegółowych funkcji systemu. Tydzień później odbywa się spotkanie powstającego zespołu z Jerzym. Rozkładasz na stole istniejące karty historyjek użytkownika i przystępujecie do omawiania szczegółów systemu. Spotkanie ma bardzo dynamiczny przebieg. Jerzy prezentuje historyjki użytkowników w kolejności zgodnej z ich znaczeniem. Każda historyjka jest szczegółowo omawiana. Programiści dążą do utrzymania na tyle niewielkich rozmiarów poszczególnych historyjek, aby można było w miarę łatwo oszacować koszt ich implementacji i aby zachować możliwość skutecznego testowania tych implementacji. Stale proszą Jerzego o podział największych historyjek na kilka mniejszych. Jerzy zwraca szczególną uwagę na spójność historyjek użytkowników z wartościami i priorytetami czysto biznesowymi, zatem stara się zachować rozsądek podczas dokonywania podziału. Historyjki zajmują już cały stół. Za ich zapisywanie odpowiada Jerzy, ale część programistów sporządza własne notatki. Nikt nie próbuje narzucić swojego zdania pozostałym uczestnikom spotkania, a na kartach są zapisywane tylko najważniejsze punkty, które mają przypominać o przebiegu dyskusji. Kiedy programiści zapoznali się z historyjkami użytkowników i zaakceptowali je, przystępują do szacowania kosztów ich realizacji. Wstępne szacunki są dość powierzchowne, ale sugerują Jerzemu, jaki będzie względny koszt realizacji poszczególnych historyjek. Na końcu spotkania wszyscy mają świadomość, że dla nowego projektu można by sformułować jeszcze szereg innych historyjek użytkowników. Nikt nie ma też wątpliwości, iż najważniejsze

516

DODATEK C SATYRA NA DWA PRZEDSIĘBIORSTWA

Doszło do sporu w kwestii łączenia poszczególnych przypadków użycia relacjami «extends» lub «includes». Powstały dwa konkurencyjne modele, a mimo to nikt nie potrafi oszacować kosztu realizacji tak sformułowanych planów. Dyskusje ciągną się bez końca i nie przynoszą żadnego postępu. Po tygodniu ktoś odkrył witrynę internetową iceberg.com, na której zaleca się rezygnację ze stereotypów «extends» i «includes» na rzecz stereotypów «precedes» i «uses». Dostępne w tej witrynie dokumenty autorstwa Dona Sengroiux opisują metodę nazwaną analizą Stalwart. Zgodnie z nią przypadki użycia należy sukcesywnie tłumaczyć na diagramy projektu. Bardziej wymagające modele przypadków użycia są tworzone z zastosowaniem tego nowego schematu, co jednak nie rozwiązuje problemu uzyskania zgody w kwestii szacowania kosztów. Chaos trwa nadal. Na kolejnych spotkaniach poświęconych przypadkom użycia emocjonalna atmosfera bierze górę nad chłodną kalkulacją techniczną. Gdyby nie brak wymagań, brak obserwowanego postępu mógłby Cię zapędzić w poważne zakłopotanie. Dokument wymagań dociera do firmy dopiero 15 lutego. Ponadto 20 i 25 lutego i w każdym kolejnym tygodniu otrzymujesz kolejne wersje tego dokumentu. Każda nowa wersja jest sprzeczna z poprzednią. Najwyraźniej specjaliści od marketingu, którzy są autorami tych dokumentów, nie mogą dojść do kompromisu. W tym samym czasie różni członkowie Twojego zespołu proponują wiele nowych konkurencyjnych szablonów przypadków użycia. Każdy taki szablon dzięki swojemu nowatorstwu przekłada się na dalsze opóźnienie prac. Ożywione dyskusje trwają bez końca. 1 marca Prudence Putrigence, pełnomocniczka odpowiedzialna za cały proces, ogłosiła, że udało jej się zintegrować wszystkie konkurencyjne sposoby wyrażania przypadków użycia i szablonów w ramach jednej spójnej metodyki. Sama specyfikacja tej metodyki zajmuje 15 stron. Zdecydowała się uwzględnić wszystkie elementy zawarte w poszczególnych szablonach. Dodatkowo zaprezentowała dokument liczący 159 stron i opisujący zalecaną formę tworzenia przypadków użycia. Zespół musi teraz przebudować wszystkie przypadki użycia zgodnie z nową metodyką. Trochę się zdziwiłeś, kiedy zdałeś sobie sprawę z tego, że musisz odpowiedzieć na pytania zadane na 15 stronach tylko po to, by znaleźć rozwiązania

historyjki zostały zidentyfikowane i że ich implementacja zajmie kilka miesięcy. Jerzy kończy spotkanie, zabierając ze sobą wszystkie zapisane karty i obietnicę otrzymania propozycji pierwszej wersji dystrybucyjnej następnego dnia rano. *** Następnego ranka ponownie zwołujesz spotkanie. Jerzy wybrał pięć kart z historyjkami użytkowników i umieścił je na tablicy. — Zgodnie z waszymi szacunkami tych pięć kart reprezentuje nakład pracy oszacowany na około pięćdziesiąt punktów. W ostatniej iteracji poprzedniego projektu pięćdziesiąt punktów udało się zrealizować w trzy tygodnie. Jeśli uda nam się zaimplementować te pięć historyjek użytkownika w trzy tygodnie, będziemy mogli zademonstrować efekt swojej pracy Romanowi. To utwierdzi go w przekonaniu, że projekt postępuje zgodnie z założonym planem. Jerzy próbuje mnie przekonać do swojej teorii. Wystarczy jednak spojrzeć na jego twarz, aby rozpoznać, że nie jest do końca pewny tego, co przed chwilą powiedział. Po chwili odpowiadasz: — Jerzy, pomyśl, to jest przecież zupełnie nowy zespół, który ma się zająć nowym projektem. Oczekiwanie, byśmy od razu osiągnęli tę samą efektywność co poprzedni zespół, jest trochę zbyt optymistyczne. Wczoraj po południu spotkałem się jednak z zespołem i ustaliliśmy, że będziemy dążyć do realizacji pięćdziesięciu punktów co trzy tygodnie. Myślę, że możesz na nas liczyć. — Pamiętaj jednak — mówisz dalej — że ocena kosztów poszczególnych historyjek i szacunkowa efektywność zespołu na tym etapie mają wstępny charakter. Bardziej precyzyjnie będziemy mogli ocenić swoje możliwości dopiero po szczegółowym zaplanowaniu tej iteracji; nasze szacunki będą jeszcze lepsze, kiedy zakończymy implementację. Jerzy spogląda na Ciebie zza okularów, jakby chciał powiedzieć: — Nie zapominaj, kto tu jest szefem. Po chwili uśmiecha się jednak i mówi: — No dobrze, niczym się nie przejmuj. Zdaję sobie sprawę z problemów, na które zwracasz uwagę. Jerzy kładzie na stole 15 kolejnych kart historyjek użytkownika i mówi: — Jeśli uda nam się zaimplementować te historyjki do końca marca,

SATYRA NA DWA PRZEDSIĘBIORSTWA

najbardziej prozaicznych problemów, na przykład: co powinien zrobić system, kiedy użytkownik naciśnie klawisz Enter? Proces korporacyjny (autorstwa L.E. Otta, słynnego autora artykułu pt. Analiza holistyczna — dialektyka progresywna inżynierów oprogramowania) wymaga od Ciebie, byś sformułował ze swoim zespołem wszystkie główne przypadki użycia, 87% przypadków drugoplanowych oraz 36,274% przypadków trzecioplanowych przed zakończeniem analizy i przejściem do fazy projektowania. W tym momencie nie masz pojęcia, czym są trzecioplanowe przypadki użycia. Chcąc spełnić to oczekiwanie, starasz się przekazać dokument przypadków użycia do przejrzenia do działu marketingu. Masz nadzieję, że przynajmniej pracownicy tego działu wiedzą, co znaczą trzecioplanowe przypadki użycia. Pracownicy działu marketingu są jednak zbyt zajęci sprawami handlowymi, aby z Tobą rozmawiać. Ponieważ projekt został już zainicjowany, nie masz możliwości zwołania nawet jednego spotkania z pracownikami działu marketingu. Jedyne, co mogą Ci zaoferować, to formułowanie ciągle zmieniających się i sprzecznych ze sobą dokumentów wymagań. W czasie gdy jeden zespół bez końca głowi się nad dokumentem z przypadkami użycia, inny zespół pracuje nad modelem dziedziny. Drugi z zespołów tworzy różne wersje dokumentów UML. Model zmienia się co tydzień. Członkowie tego zespołu nie potrafią zdecydować, czy powinni w swoim modelu stosować stereotyp «interface», czy «type». Najwięcej kontrowersji budzi dobór składni języka OCL. Pozostali członkowie tego zespołu, którzy właśnie wrócili z pięciodniowych wykładów poświęconych katabolizmowi, upierają się, że konstruowane diagramy powinny obejmować wszystkie, nawet najdrobniejsze szczegóły. Takie diagramy byłyby oczywiście niezrozumiałe dla wszystkich poza ich autorami. 27 marca, na tydzień przed terminem zakończenia analizy, dysponujesz niezliczonymi dokumentami i diagramami, ale nie jesteś ani trochę dalej z analizą problemu, niż byłeś 3 stycznia.

*** I nagle wydarzył się cud.

*** W sobotę 1 kwietnia sprawdzasz firmową skrzynkę poczty elektronicznej w domu. Otrzymałeś kopię wiadomości wysłanej przez Twojego szefa do Superszefa.

517

będziemy mogli przekazać wersję beta naszego systemu klientom. Dzięki temu uzyskamy od nich cenne uwagi, co powinniśmy poprawić, a co dodać do tego produktu. Po chwili odpowiadasz: — Dobrze, udało nam się zdefiniować pierwszą iterację i zidentyfikować historyjki użytkownika dla trzech kolejnych. Przyjmijmy, że te cztery iteracje będą się składały na naszą pierwszą wersję dystrybucyjną. — A więc jesteście w stanie zrealizować te pięć historyjek użytkownika w ciągu trzech tygodni? — zapytał Jerzy. — Nie mogę tego powiedzieć na pewno — odparłem. — Spróbujmy podzielić te historyjki na mniejsze zadania i sprawdźmy, co powiedzą programiści. Zgodnie z tymi ustaleniami Jerzy, Ty i Twój zespół spędzacie kilka następnych godzin na analizie każdej z wybranych przez Jerzego pięciu historyjek i próbach ich dzielenia na mniejsze zadania. Programiści szybko stwierdzają, że część spośród tych zadań może się składać na realizację więcej niż jednej historyjki, a niektóre są na tyle podobne, że będzie można wielokrotnie wykorzystywać gotowe rozwiązania. Łatwo zauważyć, że właśnie teraz w głowach programistów rodzą się potencjalne projekty przyszłego systemu. Od czasu do czasu zaczynają ze sobą dyskutować i bazgrać diagramy UML na niektórych kartach historyjek. Tablica ścienna szybko wypełnia się zadaniami, których realizacja doprowadzi do zakończenia procesu implementacji pięciu historyjek planowanej iteracji. W tej sytuacji inicjujesz proces podziału zadań pomiędzy programistów, ogłaszając: — Dobra, kto chce realizować te zadania? — Chętnie wezmę na siebie zadanie generowania wstępnej wersji bazy danych — zgłosił się Piotr. — Za podobne zadanie odpowiadałem w ostatnim projekcie; wygląda na to, że tym razem poradzę sobie z tym problemem dość szybko. Wydaje mi się, że zajmie mi to dwa pełne dni robocze. — Dobra, w takim razie zajmę się ekranem logowania — powiedział Janusz. — Niech będzie! — wykrzyknął Edek, jeden z najmłodszych uczestników spotkania. — Nigdy

518

DODATEK C SATYRA NA DWA PRZEDSIĘBIORSTWA

Z listu wynika jednoznacznie, że zakończyłeś już analizę! Natychmiast dzwonisz do swojego szefa i narzekasz: — Jak mogłeś powiedzieć Superszefowi, że zakończyliśmy już nasze analizy? — Zaglądałeś do kalendarza? — odparł. — Jest 1 kwietnia! Ironia tej daty nie ma dla Ciebie najmniejszego znaczenia. Mówisz więc dalej: — Przecież mamy jeszcze mnóstwo do zrobienia. Zostało wiele elementów do przeanalizowania! Nie zdecydowaliśmy nawet, czy będziemy stosować stereotyp «extends», czy «precedes». — Masz jakieś dowody na to, że analiza nie jest jeszcze skończona? — zapytał zniecierpliwiony szef. — Myślę, że... Twój szef przerwał Ci, zanim zdążyłeś cokolwiek powiedzieć: — Taka analiza mogłaby trwać bez końca, a kiedyś musi się wreszcie skończyć. Skoro na dzisiaj planowano jej zakończenie, dzisiaj przerywamy prace. Chciałbym, abyś w poniedziałek zebrał wszystkie materiały opracowane w czasie analiz i umieścił je w folderze publicznym. Przekaż ten folder Prudence, aby mogła go umieścić w systemie CM do południa w poniedziałek. A potem zajmij się przygotowaniem projektu. Po odłożeniu słuchawki zaczynasz się zastanawiać, jaki sens ma dalsze trzymanie butelki bourbona w dolnej szufladzie biurka.

*** Szefostwo firmy zorganizowało imprezę z okazji terminowego zakończenia fazy analiz. Superszef wygłosił poruszające przemówienie poświęcone ostatnim sukcesom. Twój szef (wyższy o 3 mm) pogratulował całemu zespołowi zgrania i owocnej współpracy. Na koniec głos zabrał dyrektor naczelny, który poinformował zebranych o bardzo pomyślnych wnioskach z audytu SEI i podziękował wszystkim za uważne przestudiowanie przekazanych instrukcji. Wygląda na to, że już w czerwcu uda się wejść na wymarzony trzeci poziom. (Menedżerowie na poziomie Superszefa i wyższym mają otrzymać wysokie premie w momencie zaakceptowania przez SEI przejścia na poziom trzeci). W ciągu kolejnych tygodni pracujesz ze swoim zespołem nad projektem systemu. Oczywiście szybko odkrywacie, że analiza, na której konstruowany projekt ma bazować, jest niedoskonała; nie, jest bezużyteczna; nie, jest gorsza niż bezużyteczna. Kiedy jednak

nie pracowałem nad GUI, więc chyba warto spróbować. — Ach ci młodzi... zawsze są tacy niecierpliwi — szepnął Janusz, porozumiewawczo mrugając okiem w Twoim kierunku, po czym dużo głośniej zwrócił się do Edka: — Możesz mi pomagać, mój młody rycerzu Jedi. Następnie zwrócił się do Jerzego: — Myślę, że zajmie mi to trzy pełne dni robocze. Programiści jeden po drugim zgłaszają się do realizacji poszczególnych zadań i szacują ich koszt liczony w pełnych dniach roboczych. Zarówno Jerzy, jak i Ty zdajecie sobie sprawę z tego, że umożliwienie programistom dobrowolnego wyboru zadań jest dużo lepszym rozwiązaniem niż ich odgórny przydział. Zdajesz sobie też sprawę, że na tym etapie nie powinieneś narzucać programistom własnych szacunków. Znasz swoich współpracowników i darzysz ich zaufaniem. Jesteś pewien, że dadzą z siebie wszystko podczas prac nad projektem. Programiści doskonale wiedzą, że nie mogą pracować nad zadaniami, których koszt (liczony w pełnych dniach roboczych) przekroczy koszt zadań zrealizowanych w ostatniej iteracji. Po wyczerpaniu limitu dni roboczych wszystkich programistów w ramach danej iteracji kończy się proces podziału zadań. Wreszcie wszyscy programiści dysponują kompletem zadań na najbliższą iterację. Na tablicy ściennej wciąż znajdują się jednak karty reprezentujące zadania. — Właśnie tego się obawiałem — mówisz i zwracasz się do Jerzego: — Trudno, pozostaje nam tylko jedno rozwiązanie. Skoro wybraliśmy zbyt wiele zadań dla pierwszej iteracji, musimy zdecydować o rezygnacji z części historyjek lub zadań. Jerzy ciężko wzdycha. Zdaje sobie sprawę, że nie ma innej możliwości. Decyzja o nadgodzinach już na początku projektu byłaby szaleństwem i w żadnym dotychczasowym projekcie prowadzonym przez Jerzego podobna decyzja nie przyniosła niczego dobrego. W tej sytuacji Jerzy przystępuje do usuwania najmniej istotnej funkcjonalności. — Cóż, tak naprawdę nie potrzebujemy na tym etapie ekranu logowania. Wystarczy, że nasz system będzie się automatycznie uruchamiał po zalogowaniu użytkownika.

SATYRA NA DWA PRZEDSIĘBIORSTWA

mówisz swojemu szefowi, że musisz wrócić do analizy, aby wyeliminować jej najsłabsze punkty, ciągle słyszysz odpowiedź: — Faza analizy już się skończyła. Powinieneś się teraz koncentrować wyłącznie na projekcie. Wracaj do pracy. W tej sytuacji robisz ze swoim zespołem co w Twojej mocy, mimo że nie masz pewności, czy realizowane wymagania zostały poddane prawidłowej analizie. Właściwie nie ma to większego znaczenia, ponieważ dokument opisujący wymagania zmienia się niemal co tydzień, a pracownicy działu marketingu nadal nie mają czasu, by się z Tobą spotkać. Projekt idzie koszmarnie. Twój szef opacznie zrozumiał ostatnio przeczytaną książkę The Finish Line, której autor, Mark DeThomaso, beztrosko zasugerował, że dokumenty projektu powinny opisywać wszystkie szczegóły zawarte w kodzie źródłowym. — Skoro mamy pracować na tym poziomie szczegółowości — pytasz — to dlaczego od razu nie przystąpimy do pisania kodu? — Ponieważ wówczas nie projektowałbyś tego systemu. Przypominam, że w tej fazie masz się koncentrować wyłącznie na projekcie. — Poza tym — mówi dalej szef — właśnie zakupiliśmy dla całej firmy licencję systemu Dandelion! Za pomocą tego doskonałego narzędzia będziemy mogli realizować metodykę Round the Horn. Trzeba przenieść wszystkie diagramy do tego narzędzia, a ono wygeneruje cały niezbędny kod źródłowy! Co więcej, Dandelion zadba również o synchronizację diagramów z kodem. Szef przekazuje Ci atrakcyjne, kolorowe pudełko z wersją instalacyjną Dandeliona. Bierzesz je bez słowa i udajesz się do swojego pokoju. Po dwunastu godzinach, ośmiu zawieszeniach systemu, jednym formatowaniu dysku i ośmiu szklaneczkach Baccardi wreszcie udało Ci się zainstalować to narzędzie na serwerze. Podejrzewasz, że opanowanie obsługi Dandeliona zajmie członkom Twojego zespołu blisko tydzień. Uśmiechasz się i myślisz: — Każdy tydzień beze mnie to dobry tydzień. Twój zespół tworzy kolejne diagramy projektu. Okazało się, że Dandelion bardzo utrudnia proces ich rysowania. Jego użytkownicy muszą się przekopywać przez dziesiątki wielokrotnie zagnieżdżonych okien dialogowych pełnych dziwacznych pól tekstowych i pól wyboru, których wypełnianie i zaznaczanie nie zawsze jest intuicyjne. A jest jeszcze problem przenoszenia klas pomiędzy pakietami.

519

— A niech to! — westchnął Edek. — Tak bardzo zależało mi na tym zadaniu. — Cierpliwości — powiedział Janusz, po czym dodał: — ci, którzy poczekają, aż pszczoły opuszczą ul, uchronią się od żądeł i zdołają zakosztować słodyczy miodu. Edek zmieszał się. Wszyscy wyglądają na zmieszanych. — A więc... — kontynuuje Jerzy — myślę, że moglibyśmy usunąć jeszcze to... I tak wspólnymi siłami skrócono listę zadań. Programiści, którym odebrano przyznane wcześniej zadania, wybierają sobie kolejne. Negocjacje nie przebiegają bezproblemowo. Jerzy kilkakrotnie dał wyraz swojej frustracji i braku cierpliwości. Za każdym razem, gdy atmosfera stawała się trudna do zniesienia, Edek zgłaszał się na ochotnika: — Spróbuję tak się sprężyć, aby nadrobić brakujące godziny. Już chciałeś ostudzić jego zapał, gdy nagle z pomocą przyszedł Janusz, który spojrzał mu w oczy i powiedział: — Kiedy raz przejdziesz ciemną ścieżką, wybrana droga na zawsze zdominuje Twoje przeznaczenie. Wreszcie udało się osiągnąć iteracje w formie możliwej do zaakceptowania przez Jerzego. Plan pierwszej iteracji nie był oczywiście w pełni zgodny z jego oczekiwaniami. W rzeczywistości osiągnięty kompromis był dużo skromniejszy od początkowych założeń. Jednak wreszcie dysponujesz planem, który w opinii zespołu jest możliwy do zrealizowania w ciągu trzech tygodni. Co więcej, pierwsza iteracja obejmuje najważniejsze elementy funkcjonalności wskazane przez Jerzego. — Dobra, Jerzy — mówisz, kiedy emocje wydają się opanowane — kiedy możemy się spodziewać Twoich testów akceptacyjnych? Jerzy wzdycha. Problem, na który zwróciłeś uwagę, stanowi drugą stronę medalu. Dla każdej historyjki użytkownika implementowanej przez Twój zespół Jerzy musi opracować pakiet testów akceptacyjnych, które umożliwią weryfikację ich zgodności z oczekiwaniami. Zespół musi dysponować tymi testami na długo przed zakończeniem danej iteracji, ponieważ tylko one mogą wyeliminować rozbieżności w wyobrażeniu systemu przez Jerzego i programistów.

520

DODATEK C SATYRA NA DWA PRZEDSIĘBIORSTWA

Początkowo konstruowaliście swoje diagramy na podstawie przypadków użycia. Jednak wymagania zmieniają się tak często, że przypadki użycia błyskawicznie się dezaktualizują. Trwają dyskusje, czy zastosować wzorzec projektowy Wizytator, czy Dekorator. Jeden z programistów kategorycznie odmówił stosowania wzorca Wizytator w jakiejkolwiek formie, twierdząc, że taka konstrukcja jest niezgodna z zasadami projektowania obiektowego. Inny deweloper odmówił stosowania mechanizmu wielodziedziczenia jako siedliska samego diabła. Spotkania, które w założeniu miały polegać na przeglądzie dotychczasowych osiągnięć, szybko przerodziły się w bezproduktywne dyskusje o znaczeniu stosowania technik obiektowych, definicji fazy analizy i różnicy w stosunku do fazy projektu oraz warunkach stosowania relacji agregacji i asocjacji. W połowie tego cyklu projektowania pracownicy działu marketingu oświadczyli, że przemyśleli wszystko raz jeszcze i zmienili swoje poglądy na system. Ich nowy dokument definiujący wymagania został całkowicie przebudowany. Zrezygnowali z wielu istotnych obszarów funkcjonalności i zastąpili je takimi, które na tym etapie wydały im się właściwsze. Powiedziałeś swojemu szefowi, że ostatnie zmiany wiążą się z koniecznością przeprowadzenia ponownej analizy i zaprojektowania znacznej części systemu. Usłyszałeś jednak: — Faza analizy dawno się skończyła. Teraz możemy pracować wyłącznie nad projektem. Wracaj do pracy. Zasugerowałeś, że łatwiej byłoby stworzyć prosty prototyp, który można by zaprezentować pracownikom działu marketingu, a być może także potencjalnym klientom. Twój szef odpowiedział jednak: — Faza analizy dawno się skończyła. Skup się na projekcie. Wracaj do pracy. Pozostało zastosowanie hacków. Próbujesz opracować jakiś dokument projektowy, który będzie uwzględniał treść nowego dokumentu z wymaganiami. Okazuje się jednak, że nawet ostatnia rewolucja w wymaganiach nie doprowadziła do przerwania ciągłego wprowadzania modyfikacji. Co więcej, zmienność wymagań wydaje się teraz jeszcze częstsza i coraz głębsza. Próbujesz mozolnie radzić sobie z tym problemem. 15 czerwca baza danych systemu Dandelion uległa uszkodzeniu. Wszystko wskazuje na to, że niespójność w jednej części bazy danych rozszerza się

— Spróbuję opracować kilka przykładowych skryptów testowych jeszcze dzisiaj — obiecuje Jerzy. — Będę dodawał kolejne codziennie. Kompletnym pakietem testów będziecie dysponowali w połowie tej iteracji. *** Iteracja rozpoczyna się w poniedziałkowy poranek i obejmuje sesje podziału klas, odpowiedzialności i współpracy. Po kilku godzinach wszyscy programiści mają już swoje pary i przystępują do kodowania. — A teraz, mój młody asystencie — Janusz zwraca się do Edka — uzyskasz tajemną wiedzę o projektowaniu sterowanym testami. — Super, brzmi naprawdę świetnie — odpowiada Edek. — Jak to robicie? Janusz jest rozpromieniony. Nie ulega wątpliwości, że bezbłędnie przewidział reakcję. — A zatem mój kawalerze, co teraz robi kod? — Co? — odpowiada zdziwiony Edek. — Przecież nie mam jeszcze żadnego kodu. — W takim razie rozważmy nasze pierwsze zadanie. Potrafisz powiedzieć, co Twój przyszły kod powinien robić? — No pewnie — odpowiada Edek z pewnością właściwą dla jego młodego wieku. — Nasz kod w pierwszej kolejności powinien nawiązywać połączenie z bazą danych. — W takim razie czego będziemy potrzebowali do nawiązania połączenia z bazą danych? — Zadajesz dziwne pytania — odpowiedział, śmiejąc się, Edek. — Myślę, że będziemy musieli uzyskać obiekt bazy danych z jakiegoś rejestru i wywołać metodę Connect(). — Ach, ty przebiegły młody człowieku! Rzeczywiście będziemy potrzebowali obiektu, w ramach którego będziemy mogli zbuforować obiekt bazy danych. — Zbuforować? Czy to odpowiednie słowo? — Skoro go używam, to znaczy, że odpowiednie! Czy możemy napisać test, który będzie przechodził na rejestrze bazy danych? Edek ciężko wzdycha. Wie, że musi grać dalej: — Powinniśmy mieć możliwość utworzenia obiektu bazy danych i przekazania go do rejestru za pośrednictwem metody Store(). Powinniśmy wówczas mieć możliwość odczytania tego obiektu z rejestru za pomocą metody Get()

SATYRA NA DWA PRZEDSIĘBIORSTWA

na pozostałe tabele. Drobne niedociągnięcia w bazie danych doprowadziły w ciągu kilku miesięcy do poważnych błędów. W końcu narzędzie CASE po prostu odmówiło posłuszeństwa. Oczywiście te trudne do uchwycenia błędy występują we wszystkich kopiach zapasowych. Prośby o wsparcie techniczne ze strony producenta narzędzia Dandelion od wielu dni pozostają bez odpowiedzi. Wreszcie otrzymujesz krótką wiadomość od twórców Dandeliona, z której wynika, że jedynym rozwiązaniem tego znanego błędu jest zakup nowej wersji, która ma być gotowa w następnym kwartale. Przejście na nową wersję będzie wymagało ręcznego przerysowania wszystkich istniejących diagramów.

*** 1 lipca wydarzył się drugi cud! Niespodziewanie zakończyła się faza projektowania! Nie idziesz z tym do szefa, by narzekać. Od razu sięgasz do środkowej szuflady biurka po wódkę.

*** Szefostwo zorganizowało kolejną imprezę na cześć terminowego zakończenia fazy projektowania i kolejnego kroku w kierunku trzeciego poziomu CMM. Tym razem przemówienie Superszefa było jeszcze bardziej wzruszające niż wcześniej. Niemal na wszystkich ścianach w biurze Twojej firmy pojawiły się nowe banery i plakietki. Widać na nich orły i alpinistów rozmawiających o pracy zespołowej i potencjale drzemiącym w dobrze zgranej grupie. Interpretacja treści tych banerów wydaje się dużo łatwiejsza dopiero po kilku szklaneczkach szkockiej. Dochodzisz do wniosku, że konieczne jest opróżnienie jednej z szafek, aby przygotować miejsce dla brandy. Wraz ze swoim zespołem przystępujesz do właściwego kodowania. Nagle odkrywasz jednak, że w projekcie brakuje kilku istotnych obszarów. Właściwie projekt w tej formie okazuje się zupełnie bezużyteczny. Zwołujesz sesję projektową w jednym z pomieszczeń konferencyjnych w celu wyeliminowania chociaż kilku problemów, które uniemożliwiają dalsze postępy. Nagle na spotkaniu pojawia się Twój szef i od razu stwierdza: — Etap projektowania mamy już za sobą. Skupcie się tylko na kodowaniu. Wracajcie do pracy. Kod wygenerowany przez narzędzie Dandelion jest wyjątkowo odrażający. Okazuje się, że Ty i Twój zespół w niewłaściwy sposób korzystaliście z asocjacji

521

i sprawdzenia, czy oba obiekty (zapisany i odczytany) są identyczne. — Cóż, dobrze powiedziane, mój młody kolego. — Jasne. — Spróbujmy teraz napisać funkcję testową, która dowiedzie, że twoja propozycja ma sens. — A czy nie powinniśmy zacząć od napisania obiektów bazy danych i rejestru? — Ach, musisz się jeszcze sporo nauczyć. Jesteś bardzo niecierpliwy. Po prostu najpierw napisz test. — Ale przecież kod tego testu nawet się nie skompiluje! — Jesteś pewien? A co będzie, jeśli się jednak skompiluje? — Hm... — Edek, po prostu napisz ten test. Zaufaj mi. W tym momencie Janusz, Edek i pozostali członkowie zespołu przystąpili do kodowania swoich zadań, po jednym przypadku testowym w każdym cyklu. Pokój, w którym pracowali, wypełnił się szumem rozmów prowadzonych w ramach poszczególnych par. Szum był od czasu do czasu przerywany głośniejszym okrzykiem, kiedy któraś z par kończyła realizację bieżącego zadania lub trudnego przypadku testowego. Wraz z postępem prac programiści zmieniają partnerów raz lub dwa razy dziennie. Taki model pracy powoduje, że każdy programista orientuje się w zadaniach realizowanych przez pozostałych członków zespołu. W ten sposób wiedza o tworzonym kodzie sukcesywnie rozchodzi się w całym zespole. Za każdym razem, gdy któraś z par kończy realizację jakiegoś istotnego elementu (całego lub tylko ważnej części zadania), natychmiast podejmuje próbę integracji swojego kodu z pozostałymi składnikami systemu. Oznacza to, że baza kodowa rośnie z dnia na dzień, a ewentualne trudności związane z integracją są minimalizowane. Programiści codziennie konsultują się z Jerzym. Zwracają się do niego z prośbą o dodatkowe wyjaśnienia za każdym razem, gdy mają jakieś wątpliwości dotyczące funkcjonalności systemu bądź interpretacji przypadku testu akceptacyjnego. Jerzy zgodnie z obietnicą dostarcza zespołowi stały strumień skryptów testów akceptacyjnych. Członkowie zespołu uważnie zapoznają się z tymi testami, aby lepiej zrozumieć oczekiwania Jerzego dotyczące budowanego systemu.

522

DODATEK C SATYRA NA DWA PRZEDSIĘBIORSTWA

i agregacji. Cały wygenerowany kod wymaga edycji w celu wyeliminowania błędów powstałych wskutek tego niedopatrzenia. Edycja kodu jest wyjątkowo trudna, ponieważ system Dandelion „wzbogacił” go o dziwaczne komentarze zawierające specjalne konstrukcje składniowe wymagane do synchronizacji kodu z diagramami. Jeśli przypadkowo zmodyfikujemy któryś z tych komentarzy, diagramy będą ponownie generowane w niewłaściwy sposób. Okazuje się, że stosowanie metodyki Round the Horn wymaga ogromnego wysiłku. Im więcej pracy wkładacie w utrzymanie zgodności kodu z narzędziem Dandelion, tym większa jest liczba błędów generowanych przez ten system. Wreszcie się poddajesz i decydujesz, że ręcznie dostosujecie diagramy do bieżącego stanu kodu. Chwilę później dochodzisz do wniosku, że utrzymywanie aktualnych diagramów w ogóle mija się z celem. Poza tym kto ma na to czas? Twój szef zatrudnił konsultanta, którego zadaniem będzie budowa narzędzi zliczających wiersze kodu tworzonego przez Ciebie i Twój zespół. Zawiesił na ścianie wielki wykres w kształcie termometru z wartością 1 000 000 na szczycie. Każdego dnia wydłuża czerwoną linię reprezentującą łączną sumę dotychczas napisanych wierszy. Trzy dni po zawieszeniu na ścianie tego wykresu Twój szef zaczepił Cię na korytarzu i oznajmił: — Wykres nie rośnie w takim tempie, jakiego oczekiwałem. Musimy dysponować milionem wierszy do 1 października. — Nie wie-e-e-m na-a-awet, czy ten pro-ojekt będzie wymagał mi-liona wierszy — wykrztusiłeś. — Musimy mieć milion wierszy do 1 października — powtórzył z naciskiem Twój szef. Jego włosy wydłużyły się o kolejne punkty. Skomplikowany, grecki wzór, który szef wykorzystuje do obliczania punktów, stworzył aurę autorytetu i kompetencji. — Jesteś pewien, że stosowane bloki komentarzy są wystarczająco obszerne? Po chwili, korzystając z przebłysku kierowniczej inteligencji, dodał: — Mam! Chcę, żebyś narzucił swoim inżynierom nową politykę. Żaden wiersz kodu nie może mieć więcej niż 20 znaków. Każdy taki wiersz należy dzielić na dwa lub (najlepiej) więcej wierszy. Cały istniejący kod musicie przebudować zgodnie z tym standardem. W ten sposób błyskawicznie zwiększymy liczbę wierszy. Zdecydowałeś, że nie powiesz szefowi, iż przebudowa istniejącego kodu zajęłaby dwa pełne miesiące.

Na początku drugiego tygodnia pierwszej iteracji system ma już tyle funkcjonalności, że można je pokazać Jerzemu. Jerzy z ogromnym zainteresowaniem ogląda, jak prezentowany kod przechodzi kolejne przypadki testowe. — To jest naprawdę świetne — powiedział Jerzy po zakończeniu prezentacji. — Ale to nie wygląda na jedną trzecią wszystkich zadań zakwalifikowanych do tej iteracji. Czy pracujecie wolniej, niż przewidywaliśmy? Nie potrafisz ukryć grymasu na twarzy. Czekałeś na dobry moment, aby poinformować Jerzego o tym problemie, ale w tej sytuacji musisz znaleźć właściwe wytłumaczenie natychmiast. — Tak, rzeczywiście pracujemy nieco wolniej, niż zakładaliśmy. Okazuje się, że konfiguracja naszego nowego serwera aplikacji wymaga dużo więcej czasu. Co więcej, jego ponowne uruchamianie trwa całe wieki, a musimy tę procedurę powtarzać za każdym razem, gdy wprowadzamy choćby najdrobniejszą zmianę w konfiguracji. Jerzy spogląda na Ciebie podejrzliwie. Wciąż nie udało się rozładować napięcia, które narosło jeszcze w czasie poniedziałkowych negocjacji. Po chwili pyta: — Co to oznacza dla harmonogramu? Nie możemy już dokonywać żadnych przesunięć. Nie możemy! Roman się wścieknie! Zamknie nas wszystkich w drewnianej szopie i poszuka sobie innych ludzi. Spoglądasz Jerzemu prosto w oczy. Tego, co chcesz powiedzieć, nie da się wyrazić w uprzejmy sposób. W tej sytuacji wyrzucasz z siebie: — Słuchaj, jeśli pójdzie tak jak do tej pory, nie uda nam się ukończyć prac do następnego piątku. Możemy najwyżej spróbować znaleźć sposób przyspieszenia prac. Szczerze mówiąc, nie liczyłbym jednak na cud. Powinieneś poszukać jednego lub dwóch zadań, z których moglibyśmy zrezygnować w tej iteracji, nie modyfikując dotychczasowych planów dotyczących prezentacji przed Romanem. Cokolwiek to będzie, piątkowa prezentacja musi się odbyć. Chyba nie chciałbyś, aby decyzja o wyborze zadań do odrzucenia należała do nas. — A niech was wszystkich... — Jerzy zdecydował się zachować ostatnie słowa dla siebie i szybkim krokiem udał się do swojego pokoju, kiwając lekko głową.

SATYRA NA DWA PRZEDSIĘBIORSTWA

Doszedłeś do wniosku, że nie będziesz się do niego zwracał w żadnej sprawie. Wydaje się, że jedynym rozwiązaniem jest dożylne podanie czystego etanolu. Powoli zaczynasz organizować odpowiedni zabieg. Hacki, hacki i jeszcze raz hacki. Wraz ze swoim zespołem osiągnąłeś szaleńcze tempo produkcji kolejnych wierszy kodu. 1 sierpnia Twój szef z niezadowoleniem stwierdził, że wskaźnik na „termometrze” nie podnosi się w oczekiwanym tempie i zarządził 50-godzinny tydzień pracy. Hacki, hacki, hacki. 1 września wskazania „termometru” przekroczyły 1,2 miliona wierszy, Twój szef zażądał raportu wyjaśniającego powody przekroczenia budżetu kodowania o ponad 20%. Zarządził obowiązek pracy we wszystkie soboty i nakazał przywrócenie projektu do stanu, w którym kod nie będzie obejmował więcej niż milion wierszy. W tej sytuacji pozostaje Ci tylko ponowne scalanie dzielonych wcześniej wierszy. Hacki, hacki, hacki. Nastroje są fatalne, coraz więcej pracowników opuszcza zespół. Dział zapewniania jakości zarzuca Cię raportami o błędach. Klienci domagają się podręczników instalacji i instrukcji użytkownika. Sprzedawcy żądają specjalnych demonstracji dla wybranych klientów. Dokument opisujący wymagania ciągle się zmienia; pracownicy działu marketingu skarżą się na niezgodności produktu z ich specyfikacją, a lokalny sklep monopolowy przestał akceptować Twoją kartę kredytową. To musi się kiedyś skończyć. 15 września Superszef zwołuje spotkanie. W chwili, gdy wchodzi do pokoju, punkty na jego głowie generują obłoki pary. Kiedy przemawia, bas jego głosu doprowadza Cię do problemów żołądkowych. — Menedżer odpowiedzialny za zapewnianie jakości poinformował mnie, że do tej pory zaimplementowano mniej niż połowę żądanych funkcjonalności. Powiedział też, że system nieustannie ulega awariom, generuje błędne wyniki i jest zadziwiająco nieefektywny. Skarżył się także, że nie radzi sobie z publikacjami wersji dystrybucyjnych, z których każda jest bardziej awaryjna od poprzedniej. Wstrzymał przemowę na kilka sekund, w ciągu których starał się opanować nerwy. — Menedżer QA ocenia, że w tym tempie nie będziemy w stanie wydać gotowego produktu do grudnia. Wprawdzie uważasz, że najwcześniej projekt będzie gotowy w marcu, ale nie odzywasz się. — Do grudnia! — Superszef huknął tak głośno, że pozostali uczestnicy spotkania schowali głowy, jakby mierzył do nich z karabinu. — Grudzień zupełnie

523

Nie po raz pierwszy mówisz do siebie: — Nikt mi nigdy nie obiecywał, że zarządzanie projektem będzie łatwe. Jesteś pewien, że jeszcze wielokrotnie będziesz dochodził do podobnych wniosków. *** W praktyce projekt przebiega nieznacznie lepiej, niż zakładałeś. Zespół musiał zrezygnować z jednego zadania w ramach iteracji, jednak wybór dokonany przez Jerzego był na tyle przemyślany, że demonstracja systemu przed Romanem przebiegła w doskonałej atmosferze. Roman nie był zachwycony postępami, ale też nie wydawał się zaniepokojony. Powiedział tylko: — Całkiem nieźle. Pamiętajcie tylko, że musimy być gotowi z prezentacją tego systemu już na lipcowych targach, a nie wydaje mi się, byśmy mieli zbyt wiele do pokazania, pracując w tym tempie. Jerzy, którego pewność siebie znacznie wzrosła w momencie zakończenia pierwszej iteracji, odpowiedział Romanowi: — Roman, zespół pracuje naprawdę ciężko i radzi sobie całkiem nieźle. Jestem przekonany, że w lipcu będziemy mieli co pokazać. Nie będzie to oczywiście kompletny system, a pewne jego fragmenty mogą być niedostępne, ale coś na pewno pokażemy. Mimo kłopotów obserwowanych w trakcie ostatniej iteracji udało się dostroić wartości reprezentujące wydajność zespołu. Kolejna iteracja przebiegła dużo lepiej. Nie wynikało to wcale z większej liczby zrealizowanych zadań, tylko z tego, że tym razem w czasie iteracji nie trzeba było eliminować żadnych zadań ani historyjek. Na początku czwartej iteracji osiągnięto naturalny rytm pracy. Wszystkie strony, a więc Jerzy, Ty i Twój zespół, doskonale znacie wzajemne oczekiwania. Zespół pracuje ciężko, ale udaje się utrzymywać stałe tempo. Jesteś pewien, że jest w stanie utrzymać to tempo przez co najmniej rok. Liczba niespodzianek odkrywanych na bieżąco w harmonogramie spadła niemal do zera. Z drugiej strony, liczba nowych elementów specyfikacji wcale nie maleje. Jerzy i Roman regularnie monitorują stan systemu i formułują nowe zalecenia w kwestii zmian w istniejącej funkcjonalności. Wszystkie strony zdają sobie jednak sprawę z tego, że każda tego rodzaju zmiana wymaga czasu i musi być uwzględniona w harmonogramie.

524

DODATEK C SATYRA NA DWA PRZEDSIĘBIORSTWA

nie wchodzi w grę. Oczekuję od liderów zespołów nowych szacunków na piśmie do jutra rana. Do czasu zakończenia tego projektu zarządzam pracę w trybie 65-godzinnych tygodni. Lepiej dla was, żeby prace zakończyły się do 1 listopada. Kiedy opuszcza pokój konferencyjny, słychać jak mamrocze do siebie: „To ma być odpowiedzialność”.

*** Twój bezpośredni szef całkowicie wyłysiał. Punkty z jego głowy znalazły się na ścianie w gabinecie Superszefa. Dziwne, fluorescencyjne światła na jego obliczu niemal całkowicie Cię oślepiają. — Masz coś do picia? — zapytał niespodziewanie. Ponieważ właśnie skończyłeś butelkę wina Boone’s Farm, sięgasz do szafki po butelkę Thunderbirda i nalewasz wino do kubka po kawie. — Co musiałoby się stać, aby ten projekt zakończył się powodzeniem? — zapytał. — Musimy wreszcie zamrozić wymagania, dokonać ich analizy, zaprojektować je, by w końcu przystąpić do ich implementacji — odpowiadasz chłodno. — Do 1 listopada? — wykrzyknął z niedowierzaniem. — Nie ma mowy! Wracaj do kodowania tego cholernego systemu — zagrzmiał, drapiąc się w łysinę. Kilka dni później odkryłeś, że Twojego bezpośredniego przełożonego przeniesiono do działu badań. Wszystko potoczyło się błyskawicznie. Klienci, których w ostatniej chwili poinformowano o braku możliwości terminowej realizacji ich zamówień, zaczęli wycofywać swoje oferty. Dział marketingu ponownie podjął próbę oceny, czy ten produkt w ogóle mieści się w ogólnych celach przedsiębiorstwa. Po całej firmie krążą pisma, „lecą głowy”, zmieniają się strategie, całość wydaje się dość ponura. I wreszcie w marcu, po wielu 65-godzinnych tygodniach pracy ukończono bardzo niestabilną wersję oprogramowania. Na tym etapie wskaźniki liczby wykrywanych błędów wciąż utrzymują się na bardzo wysokim poziomie, a zespół wsparcia technicznego nie nadąża z przetwarzaniem skarg i żądań formułowanych przez zirytowanych klientów. Nikt nie jest zadowolony z tego stanu rzeczy. W kwietniu Superszef zdecydował się na diametralną zmianę swojego podejścia do tego problemu i zakup produktu stworzonego przez firmę Rupert Industries oraz ograniczenie się do redystrybucji. Klienci powoli miękną, pracownicy działu marketingu wydają się sympatyczniejsi, a Ty musisz sobie poszukać nowej pracy.

Zmiany nie powodują więc naruszenia czyichkolwiek oczekiwań. W marcu dokonujesz dużej prezentacji systemu zarządowi przedsiębiorstwa. Funkcjonalność oprogramowania jest jeszcze dość ograniczona, a forma na razie wyklucza możliwość publicznej prezentacji, jednak postęp ma stały charakter i budzi podziw wśród członków zarządu. Prace nad drugą wersją dystrybucyjną przebiegały jeszcze lepiej niż nad pierwszą. Zespół znalazł już sposób automatyzacji wykonywania skryptów akceptacyjnych przygotowywanych przez Jerzego. Dokonał też takiej refaktoryzacji projektu systemu, aby dodawanie nowych i modyfikowanie istniejących elementów funkcjonalności było naprawdę proste. Prace nad drugą wersją dystrybucyjną zakończyły się wraz z końcem czerwca. Ta publikacja została zaakceptowana z myślą o prezentacji na lipcowych targach. Drugie wydanie nie obejmowało wszystkich elementów, których życzyliby sobie Jerzy i Roman, ale skutecznie demonstrowało najważniejsze funkcje przyszłego systemu. Mimo że klienci uczestniczący w pokazie zwracali uwagę na brak pewnych rozwiązań, byli pod wrażeniem ogólnej koncepcji przedstawionego oprogramowania. Ty, Roman i Jerzy wróciliście z tych targów z szerokimi uśmiechami na twarzach. Wszyscy czujecie, że osiągnęliście zamierzony cel. Wiele miesięcy później skontaktował się z Tobą przedstawiciel firmy Rufus Inc. Wspomniana firma pracowała nad bardzo podobnym systemem z myślą o wewnętrznych zastosowaniach. Firma Rufus Inc., która zarzuciła prace nad systemem po ostatecznym fiasku własnego projektu, negocjuje warunki umowy licencyjnej dla Twojej technologii z myślą o stosowaniu jej we własnym środowisku. Wszystko idzie we właściwym kierunku!

D ODATEK D

Kod źródłowy jest projektem Wciąż pamiętam sytuację, która doprowadziła do napisania tego artykułu. Latem 1986 roku pracowałem tymczasowo jako konsultant w Centrum Uzbrojenia Marynarki Wojennej China Lake w Kalifornii. Miałem wtedy okazję uczestniczyć w dyskusji panelowej poświęconej językowi Ada. W pewnym momencie któryś ze słuchaczy zadał dość typowe pytanie: Czy programiści są inżynierami? Nie pamiętam już, jaka była dokładna odpowiedź, ale przypominam sobie, że nie rozwiewała wątpliwości. W tej sytuacji usiadłem i zacząłem się zastanawiać, jak sam odpowiedziałbym na tak postawione pytanie. Nie byłem pewien odpowiedzi, jednak któraś z wypowiedzi w ramach dalszej dyskusji spowodowała, że przypomniałem sobie artykuł, który przeczytałem w magazynie „Datamation” niemal dziesięć lat wcześniej. Wspomniany artykuł w dość przekonujący sposób uzasadniał, dlaczego inżynierowie muszą umieć dokumentować swoją pracę (myślę, że artykuł był właśnie o tym — nie zaglądałem do niego od bardzo dawna). Kluczowe spostrzeżenie autora tej publikacji dotyczyło efektu końcowego procesu inżynieryjnego, którym powinien być dokument. Innymi słowy, autor dowodził, że inżynierowie tworzą dokumenty, a nie fizyczne konstrukcje. Dokumenty opracowane przez inżynierów są wykorzystywane przez innych uczestników procesu do tworzenia właściwych produktów. Zacząłem sobie wtedy zadawać pytanie: Czy wśród dokumentacji generowanej w ramach projektów programistycznych znajduje się coś, co można by uznać za prawdziwy dokument inżynierski? Odpowiedź była następująca: Tak. Istnieje dokładnie jeden taki dokument — kod źródłowy. Postrzeganie kodu źródłowego jako dokumentu inżynierskiego — projektu — całkowicie zmieniło moje podejście do własnej profesji. Zmieniło moje podejście do wszystkiego. Co więcej, im częściej o tym myślałem, tym bardziej byłem przekonany, że właśnie dotychczasowe, niewłaściwe podejście wyjaśnia mnóstwo typowych problemów związanych z wytwarzaniem oprogramowania. Mówiąc precyzyjniej, miałem wrażenie, że faktycznym źródłem problemów jest niezrozumienie lub wręcz aktywne odrzucanie przez wielu programistów takiego spojrzenia na kod źródłowy. Minęło wiele lat, zanim nadarzyła się okazja publicznej prezentacji moich argumentów. Artykuł o projektowaniu oprogramowania opublikowany w magazynie „The C ++ Journal” skłonił mnie do napisania listu do wydawcy tego czasopisma. Po wymianie kilku listów Livleen Singh, redaktor naczelna, zgodziła się na publikację moich przemyśleń na temat tego artykułu. Treść mojej publikacji przedstawiono poniżej. — Jack Reeves, 22 grudnia 2001

Czym jest projekt oprogramowania? © Jack W. Reeves, 1992 Wydaje się, że techniki programowania obiektowego, szczególnie mechanizmy dostępne w języku C++, wprowadziły burzę w świecie oprogramowania. Powstało mnóstwo artykułów i książek opisujących, jak należy stosować te techniki w praktyce. Ogólnie rzecz biorąc, wątpliwości dotyczące faktycznej wartości technik obiektowych z czasem zostały zastąpione pytaniami o sposoby najbardziej efektywnego ich wykorzystywania możliwie niewielkim kosztem. Mimo że techniki obiektowe są znane już od jakiegoś czasu, ta eksplozja popularności wydaje się niezwykła. Skąd to nagłe zainteresowanie? Pojawiają się różne wyjaśnienia. Istnienie jednego decydującego powodu tego stanu rzeczy jest mało prawdopodobne. Wiele

526

DODATEK D KOD ŹRÓDŁOWY JEST PROJEKTEM

wskazuje na to, że o przekroczeniu masy krytycznej zdecydowało wiele czynników. Mimo to można przyjąć, że sam język programowania C++ stanowi jeden z najistotniejszych czynników w ostatniej fazie rewolucji w świecie oprogramowania. Także w tym przypadku można by wskazać kilka przyczyn tego zjawiska, jednak chciałbym zasugerować odpowiedź z nieco innej perspektywy. Język C++ zyskał ogromną popularność, ponieważ ułatwia jednoczesne projektowanie i implementowanie oprogramowania. Jeśli to wyjaśnienie wydaje się komuś dziwne, chciałbym podkreślić, że jest to celowe. Ten artykuł ma zwrócić uwagę na relację łączącą programowanie z projektowaniem oprogramowania. W ciągu niemal dziesięciu lat miałem nieodparte wrażenie, że producenci oprogramowania nie dostrzegają drobnej różnicy pomiędzy procesem opracowywania projektu oprogramowania a tym, czym projekt oprogramowania jest w istocie. Myślę, że rosnąca popularność języka C++ wynika po części z tego, że wszyscy szukamy sposobów stania się lepszymi inżynierami oprogramowania. Z czasem zdaliśmy sobie sprawę z tego, że programowanie nie polega na budowaniu oprogramowania, tylko na jego projektowaniu. Wiele lat temu uczestniczyłem w seminarium, na którym zadano pytanie, czy wytwarzanie oprogramowania jest dyscypliną inżynierską. Chociaż nie pamiętam szczegółów dyskusji na ten temat, przypominam sobie, jak owe rozważania skłoniły mnie do własnych przemyśleń dotyczących ówczesnej kondycji firm programistycznych, które szukały fałszywych analogii łączących świat inżynierii tworzenia sprzętu ze światem inżynierii oprogramowania, ignorując wiele faktycznych podobieństw. Ostatecznie doszedłem do przekonania, że nie jesteśmy inżynierami oprogramowania, ponieważ nie potrafimy nawet stwierdzić, czym jest projekt oprogramowania. Dzisiaj jestem tego bardziej pewien niż podczas tamtego seminarium. Ostatecznym celem każdej aktywności inżynierskiej jest jakiś rodzaj dokumentacji. Kiedy kończą się prace nad projektem, powinno nastąpić przekazanie dokumentacji tego projektu do zespołu odpowiedzialnego za produkcję. Powinna to być zupełnie inna grupa dysponująca zupełnie innymi umiejętnościami niż zespół projektowy. Jeśli dokumenty powstałe na etapie projektu rzeczywiście reprezentują kompletny projekt, zespół odpowiedzialny za właściwe prace nad produktem nie powinien mieć żadnych problemów z realizacją tego zadania. W praktyce taki zespół mógłby budować bardzo wiele różnych produktów bez jakiejkolwiek interwencji ze strony projektantów. Po dokonaniu przeglądu cyklu życia oprogramowania w sposób, w jaki go postrzegałem, doszedłem do przekonania, że jedyną dokumentacją, która faktycznie spełnia kryterium projektu inżynierskiego, są listingi kodu źródłowego. Prawdopodobnie istnieje wiele argumentów (starczyłoby ich na kilka osobnych artykułów) zarówno za, jak i przeciw temu założeniu. W tym artykule przyjmuję, że finalna wersja kodu źródłowego jest faktycznym projektem oprogramowania, a następnie dokonuję analizy konsekwencji tego założenia. Być może nie będę potrafił dowieść swojej tezy, ale mam nadzieję, że uda mi się zwrócić uwagę na kilka zjawisk zaobserwowanych w świecie wytwarzania oprogramowania, z popularnością języka C++ włącznie. Istnieje jedna konsekwencja postrzegania kodu jako projektu oprogramowania, której znaczenie jest o wiele większe od pozostałych. Jest na tyle istotna i tak oczywista, że większość organizacji zajmujących się wytwarzaniem oprogramowania zupełnie o niej zapomina. Otóż budowanie oprogramowania jest wyjątkowo tanie. Nie twierdzę, że koszty są niskie — są bardzo niskie, prawie ich nie ma. Skoro kod źródłowy jest projektem oprogramowania, za właściwą budowę oprogramowania odpowiadają kompilatory i programy konsolidujące (tzw. linkery). Proces kompilacji i scalania oprogramowania bywa nawet określany „budowaniem”. Koszty inwestycji w infrastrukturę niezbędną do tworzenia oprogramowania są bardzo niskie — ograniczają się do zakupu komputera, edytora, kompilatora i linkera. Kiedy już dysponujemy środowiskiem wytwarzania oprogramowania, sama budowa zajmuje bardzo niewiele czasu. Chociaż większość programistów narzeka, że czas kompilacji programu języka C++ obejmującego 50 000 wierszy kodu jest długi, czas trwania tej operacji jest nieporównanie krótszy od czasu potrzebnego do budowy rozwiązań fizycznych, których projekt odpowiada swoją złożonością 50 000 wierszom kodu C++. Innym skutkiem postrzegania kodu źródłowego jako projektu oprogramowania jest wniosek o stosunkowo łatwym tworzeniu projektu oprogramowania (przynajmniej w wymiarze mechanicznym). Pisanie (tj. projektowanie) typowego modułu oprogramowania złożonego z od 50 do 100 wierszy kodu

CZYM JEST PROJEKT OPROGRAMOWANIA?

527

z reguły zajmuje zaledwie część dnia roboczego. (Kompletna weryfikacja i usuwanie błędów to już inna historia, ale tym problemem zajmiemy się później). Warto w tej sytuacji zadać sobie pytanie, czy istnieje choć jedna dziedzina inżynierii, w której można konstruować równie złożone projekty w tak krótkim czasie. Zanim przystąpimy do odpowiednich rozważań, powinniśmy precyzyjnie określić sposób mierzenia i porównywania złożoności projektów. Tak czy inaczej, nie ulega wątpliwości, że nawet bardzo duże projekty oprogramowania powstają stosunkowo szybko. Skoro projekty oprogramowania są dość łatwe w tworzeniu i gwarantują możliwość budowy niemal bez żadnych kosztów, trudno się dziwić, że charakteryzują się wprost niewiarygodną złożonością i rozmiarami. Mimo że przyczyny tego stanu są dość oczywiste, wspomniany problem często jest ignorowany. Nawet projekty realizowane przez uczniów i studentów często obejmują wiele tysięcy wierszy kodu. Z drugiej strony, wiele gotowych produktów powstaje na podstawie projektów liczących zaledwie 10 000 wierszy. Dawno minęły czasy, kiedy największym uznaniem cieszyło się proste oprogramowanie. Typowe produkty komercyjne cechują się projektami złożonymi z setek tysięcy wierszy kodu. Liczbę wierszy wielu współczesnych projektów oprogramowania liczymy w milionach. Co więcej, projekty oprogramowania niemal cały czas ewoluują. Nawet jeśli bieżący projekt składa się z zaledwie kilku tysięcy wierszy kodu, musimy pamiętać, że ten stosunkowo niewielki projekt mógł być pisany wielokrotnie w czasie życia produktu. Mimo że istnieją przykłady projektów konstrukcji fizycznych, których złożoność wcale nie jest niższa niż w przypadku projektów oprogramowania, musimy pamiętać o dwóch istotnych cechach współczesnych projektów tradycyjnej inżynierii. Po pierwsze, krytycy oprogramowania często zapominają, że także efekt pracy inżynierów nad złożonymi problemami konwencjonalnymi nie zawsze jest wolny od błędów. Historia zna wiele przypadków konstruowania mikroprocesorów z błędami w logice, uszkodzonych mostów, nieszczelnych tam wodnych, spadających samolotów, tysięcy samochodów i innych produktów, które trzeba było wycofywać z rynku wskutek błędów popełnionych na etapie projektowania. Po drugie, realizacja złożonych projektów inżynierskich z reguły wymaga równie złożonych i kosztownych faz właściwej budowy. W efekcie niezdolność do produkcji tego rodzaju konstrukcji w naturalny sposób ogranicza liczbę przedsiębiorstw, które podejmują próby projektowania naprawdę złożonych rozwiązań fizycznych. Podobne ograniczenia nie występują w świecie oprogramowania. Istnieją setki firm informatycznych i tysiące bardzo złożonych produktów zaliczanych do oprogramowania. Zarówno liczba tych produktów, jak i poziom złożoności rośnie niemal z dnia na dzień. Oznacza to, że rozwiązania problemów przemysłu informatycznego nie należy szukać w świecie tradycyjnej inżynierii. Skoro systemy CAD i CAM ułatwiają pracę projektantom konstrukcji fizycznych dążących do tworzenia coraz bardziej złożonych rozwiązań, można przyjąć, że to inżynieria tradycyjna coraz bardziej upodabnia się do procesów wytwarzania oprogramowania. Projektowanie oprogramowania jest prawdziwym sprawdzianem umiejętności zarządzania złożonością. Złożoność występuje nie tylko w samym projekcie oprogramowania, ale też w organizacji firmy wytwarzającej oprogramowanie oraz w całej gałęzi przemysłu. Projekt oprogramowania pod wieloma względami przypomina projekty innych systemów. Może bazować na wielu technologiach, a często wymaga angażowania specjalistów z różnych dziedzin. Specyfikacje oprogramowania z reguły są dość zmienne i jako takie są narażone na gruntowne i częste modyfikacje (zwykle w czasie trwania procesu projektowania). Także zespoły wytwarzające oprogramowanie często się zmieniają (podobnie najczęściej zmiany mają miejsce w trakcie procesu projektowania). Oprogramowanie bardziej przypomina złożone systemy społeczne lub organiczne niż konstrukcje fizyczne. Te podobieństwa sprawiają, że projektowanie oprogramowania jest trudne, a efekt końcowy narażony na poważne błędy. Nie twierdzę, że moje spostrzeżenia są oryginalne; warto jednak pamiętać o tym, że niemal trzydzieści lat po początku rewolucji w świecie inżynierii oprogramowania procesy wytwarzania systemów informatycznych wciąż sprawiają wrażenie dość przypadkowych w porównaniu z pozostałymi obszarami inżynierii. Nie ma wątpliwości co do tego, że kiedy „prawdziwi” inżynierowie przekazują wykonawcy gotowy projekt, to niezależnie od jego złożoności są przekonani o możliwości realizacji zawartych w nim założeń. Ponadto mogą być pewni, że produkt docelowy można zbudować z wykorzystaniem zaproponowanych

528

DODATEK D KOD ŹRÓDŁOWY JEST PROJEKTEM

technik konstrukcyjnych. Warunkiem tego stanu rzeczy jest poświęcanie przez inżynierów znacznej ilości czasu na weryfikację i udoskonalanie swoich projektów. Dla przykładu przeanalizujmy projekt mostu. Zanim wykonawca przystąpi do budowy mostu, inżynierowie dokonują analizy strukturalnej, budują modele komputerowe, które poddają rozmaitym symulacjom, oraz konstruują modele testowane między innymi w tunelach aerodynamicznych. Krótko mówiąc, projektanci podejmują wszelkie kroki, aby upewnić się o słuszności przyjętych założeń jeszcze przed przystąpieniem do realizacji inwestycji. Jeszcze większych nakładów wymaga konstruowanie samolotów liniowych — w ich przypadku konieczne jest tworzenie prototypów w pełnej skali i przeprowadzanie lotów testowych potwierdzających przewidywania projektantów lub przeczących im. Większość z nas nie ma wątpliwości, że projekty oprogramowania nie przechodzą równie rygorystycznych badań inżynierskich co projekty konstrukcji fizycznych. Jeśli jednak przyjmiemy, że funkcję projektu pełni kod źródłowy, będziemy musieli przyznać, iż także projektanci oprogramowania poświęcają sporo uwagi weryfikacji i udoskonalaniu swoich projektów. Nie określają oni tych działań mianem inżynierii — wolą je nazywać testowaniem i diagnozowaniem budowanych systemów. Mało kto (przynajmniej w świecie oprogramowania) traktuje testowanie i diagnozowanie systemów informatycznych jak „prawdziwą inżynierię”. Powodem takiego podejścia jest przede wszystkim niechęć tej gałęzi przemysłu do postrzegania kodu jako projektów. W żadnej innej dziedzinie inżynierii podobne obiekcje nie mają miejsca. Modele pełnowymiarowe czy prototypy stanowią powszechnie akceptowane elementy innych dyscyplin inżynierii. Projektanci oprogramowania nie dysponują bardziej formalnymi metodami weryfikacji swoich projektów lub nie stosują ich wyłącznie wskutek ograniczeń budżetowych cykli budowy systemów. Odkrycie drugie: same procesy budowy i testowania projektu są tańsze i prostsze od wszelkich innych czynności. Niezależnie od tego, na ile kompilacji się zdecydujemy, koszty tych operacji są bliskie zeru w wymiarze czasu, a wszystkie niezbędne zasoby mają charakter odnawialny i można je odzyskać w razie rezygnacji z danej wersji. Warto pamiętać o tym, że testowanie nie ogranicza się do weryfikacji poprawności bieżącego projektu — jest nieodłącznym elementem szerszego procesu udoskonalania projektu. Tradycyjni inżynierowie pracujący nad skomplikowanymi konstrukcjami często budują modele (lub przynajmniej wizualizacje komputerowe). Takie podejście umożliwia im intuicyjną ocenę projektu, która nie jest możliwa wyłącznie na podstawie dokumentacji. W przypadku oprogramowania konstruowanie podobnych modeli jest nie tylko niemożliwe, ale też całkowicie zbędne. Koncentrujemy się na samym projekcie. Nawet jeśli testy formalne działają w sposób równie zautomatyzowany jak kompilator, nie możemy zrezygnować z cykli budowy i testowania. Właśnie dlatego testy formalne nigdy nie cieszyły się zainteresowaniem wśród inżynierów oprogramowania. Taka jest rzeczywistość procesów wytwarzania oprogramowania w dzisiejszym świecie. Coraz bardziej złożone projekty oprogramowania są tworzone przez coraz większą liczbę programistów i organizacji. Gotowe projekty są następnie kodowane w tym czy innym języku programowania oraz poddawane procesom weryfikacji i udoskonalania w ramach cykli budowa-test. Opisany proces nie eliminuje ryzyka powstawania błędów, ale też nie nakłada rygorystycznych ograniczeń na początkujących uczestników. To, iż zdecydowana większość programistów nie chce uwierzyć, że właśnie tak przebiega proces tworzenia systemów informatycznych, dodatkowo pogarsza sytuację. W ramach większości współczesnych procesów wytwarzania oprogramowania podejmuje się próby dzielenia poszczególnych etapów projektowania na odrębne składowe. Prace nad projektem najwyższego poziomu muszą się zakończyć, a sam projekt musi zostać zamrożony przed przystąpieniem do pisania jakiegokolwiek kodu. Na tym etapie testowanie i diagnostyka ma na celu tylko wychwycenie niedociągnięć w konstrukcji. W całym tym procesie uczestniczą programiści, czyli pracownicy budowlani świata oprogramowania. Wiele osób sądzi, że gdyby tylko udało się zmusić programistów do popełniania mniejszej liczby błędów poprzez bezkrytyczne konstruowanie oprogramowania według otrzymywanych projektów, procesy wytwarzania oprogramowania mogłyby wreszcie zyskać dojrzałość znaną z innych dyscyplin inżynierskich. Taka metamorfoza jest jednak mało realistyczna, przynajmniej dopóki przemysł informatyczny ignoruje uwarunkowania inżynierskie i ekonomiczne.

CZYM JEST PROJEKT OPROGRAMOWANIA?

529

W żadnej innej gałęzi przemysłu stosunek przebudowanego projektu do całości na poziomie 100% (już na etapie wytwarzania) nie miałby szans na akceptację. Pracownik, który nie potrafi natychmiast przystąpić do realizacji otrzymanego projektu, zwykle traci pracę. W świecie oprogramowania nawet najmniejszy fragment kodu może zostać nieznacznie zmieniony lub całkowicie przebudowany na etapie testów i diagnostyki. Tradycyjna inżynieria dopuszcza podobne udoskonalenia w trakcie procesu twórczego, na przykład podczas projektowania — nigdy w ramach procesu właściwego wytwarzania. Nikt nie oczekuje od inżyniera, że jego projekt będzie doskonały już w pierwszej odsłonie. Nawet jeśli taki idealny scenariusz uda się zrealizować, projekt musi przejść przez proces udoskonalania choćby po to, by dowieść swojej doskonałości. Jeśli nie jesteśmy w stanie przejąć czegokolwiek innego z japońskich technik zarządzania, powinniśmy przynajmniej zapamiętać, że obwinianie pracowników o błędy w procesach jest sprzeczne z dążeniem do poprawy produktywności. Zamiast zmuszać programistów do sztywnego przestrzegania błędnych ustaleń poprzedniej fazy projektu, musimy te ustalenia rewidować, a nie iść dalej w niewłaściwym kierunku. Zdolność do zmian jest swoistym papierkiem lakmusowym czegoś, co nazywamy „inżynierią oprogramowania”. Inżynieria to sposób realizacji procesu, a nie to, czy realizacja ostatecznych zapisów dokumentacji wymaga narzędzia CAD, czy nie. Największym problemem wytwarzania oprogramowania jest to, że wszystkie działania wchodzą w skład procesu projektowania. Kodowanie jest częścią projektowania, testowanie i diagnozowanie jest częścią projektu. Co więcej, także to, co zwykle określamy mianem projektowania oprogramowania, wchodzi w skład szerszego procesu projektowania. O ile oprogramowanie jest tanie w budowie, charakteryzuje się niewiarygodnie wysokimi kosztami projektowania. Oprogramowanie jest na tyle skomplikowane, że istnieje mnóstwo różnych aspektów projektowania i sposobów postrzegania procesów projektowych. Problem w tym, że wszystkie te aspekty są wzajemnie powiązane (podobnie jak w świecie inżynierii tradycyjnej). Byłoby wspaniałe, gdyby projektanci najwyższego poziomu mogli ignorować szczegółowe rozwiązania i algorytmy w ramach poszczególnych modułów. Podobnie nasze życie byłoby dużo łatwiejsze, gdyby programiści nie musieli się martwić o problemy projektu wysokiego poziomu podczas projektowania wewnętrznych algorytmów dla tworzonego modułu. Okazuje się jednak, że pewne aspekty jednej warstwy projektu zawsze mają wpływ na pozostałe warstwy. Wybór algorytmów dla danego modułu może się okazać nie mniej ważny dla powodzenia całego przedsięwzięcia niż dowolne aspekty projektu wyższego poziomu. Nie istnieje hierarchia, według której można by różnicować wagę poszczególnych aspektów projektu oprogramowania. Błędny projekt na najniższym poziomie może być równie fatalny w skutkach co niedopatrzenie na najwyższym poziomie. Projekt oprogramowania musi być kompletny i prawidłowy we wszystkich swoich aspektach — w przeciwnym razie oprogramowanie budowane na jego podstawie będzie błędne. Z myślą o ograniczaniu skutków dużej złożoności oprogramowanie projektuje się w warstwach. Nawet jeśli jeden programista martwi się tylko o szczegółowy projekt jednego modułu, musimy pamiętać o tym, że prawdopodobnie istnieją setki innych modułów i tysiące innych szczegółów, których jeden programista zapewne nie mógłby objąć swoim umysłem. Istnieją istotne aspekty projektu oprogramowania, których nie można zakwalifikować do takich kategorii jak na przykład struktury danych i algorytmy. W idealnym świecie programiści w ogóle nie powinni się martwić o inne aspekty projektu niż te, nad którymi aktualnie pracują. Praktyka pokazuje jednak, że osiągnięcie tego ideału jest niemożliwe z powodów, które wydają się uzasadnione. Projekt oprogramowania nie jest kompletny, dopóki nie zostanie zakodowany i przetestowany. Testowanie jest podstawowym elementem procesów weryfikacji i udoskonalania projektu. Strukturalny projekt wysokiego poziomu nie stanowi kompletnego projektu oprogramowania, a jedynie strukturalny szkielet dla projektu szczegółowego. Możliwości rygorystycznej weryfikacji projektu wysokiego poziomu z natury rzeczy są bardzo ograniczone. Projekt szczegółowy ma (a przynajmniej powinien mieć) co najmniej taki wpływ na ostateczny kształt projektu wysokiego poziomu jak pozostałe czynniki. Udoskonalanie wszystkich aspektów projektu powinno mieć charakter procesu trwającego przez cały cykl projektowania. Jeśli któryś z aspektów zostanie zamrożony i wyłączony z procesu udoskonalania, ostateczna wersja całego projektu prawdopodobnie będzie kiepska lub wręcz bezużyteczna.

530

DODATEK D KOD ŹRÓDŁOWY JEST PROJEKTEM

Gdyby dało się wymusić taką formę projektowania oprogramowania na wysokim poziomie, aby spełniało ono warunki rygorystycznego procesu inżynierskiego, byłoby wspaniale. Z drugiej strony, w świecie systemów informatycznych w ogóle nie powinniśmy liczyć na rygorystyczne procesy inżynierskie. Oprogramowanie jest po prostu zbyt skomplikowane i uzależnione od zbyt wielu czynników. Zdarza się, że sprzęt nie działa tak, jak tego oczekują projektanci. Nierzadko także funkcje oferowane przez biblioteki wprowadzają nieudokumentowane ograniczenia. Przed tymi i podobnymi problemami prędzej czy później staje każde przedsięwzięcie informatyczne. Ponadto istnieje szereg problemów wykrywanych dopiero w fazie testów (pod warunkiem że nie zaniedbamy tego elementu) tylko dlatego, iż ich wcześniejsze odkrywanie jest po prostu niemożliwe. Odnajdywanie tych problemów często wymusza zmiany w projekcie. Przy odrobinie szczęścia takie zmiany mają charakter lokalny. W większości przypadków modyfikacje dotyczą jednak istotnej części całego projektu oprogramowania (zgodnie z prawem Murphy’ego). Kiedy okazuje się, że któraś z części projektu z jakiegoś powodu nie może zostać zmieniona, musimy poszukać sposobu odpowiedniego przebudowania pozostałych jego elementów. Jest to jedna z tych czynności, które menedżerowie określają mianem „hakowania”, jednak właśnie na tym polega prawdziwe wytwarzanie oprogramowania. Na przykład ostatnio pracowałem nad projektem, w ramach którego odkryto zależność czasową pomiędzy szczegółowymi rozwiązaniami w ramach modułów A i B. Okazało się jednak, że wewnętrzne mechanizmy modułu A zostały ukryte za abstrakcją, która uniemożliwiała obsługę prawidłowych sekwencji wywołań generowanych przez moduł B. W chwili odkrycia tego problemu było oczywiście za późno, by próbować zmienić abstrakcję modułu A. Zgodnie z najczarniejszymi scenariuszami trzeba było wprowadzić cały pakiet wyjątkowo złożonych „poprawek” do projektu tego modułu. Zanim zakończyliśmy proces instalacji pierwszej wersji systemu, już mieliśmy wrażenie, że opracowaliśmy produkt według błędnego projektu. Każda nowa poprawka zdawała się eliminować skutki poprzedniej. Było to dość typowe przedsięwzięcie polegające na tworzeniu oprogramowania. Ostatecznie moi koledzy i ja zażądaliśmy wprowadzenia zmiany w projekcie — szczęśliwie udało nam się znaleźć ochotnika, który zgodził się negocjować w tej sprawie z zarządem. Możemy być pewni, że podobne problemy wystąpią w każdym projekcie informatycznym typowych rozmiarów. Mimo wszelkich prób eliminowania tego rodzaju zdarzeń musimy się liczyć z ryzykiem przeoczenia przynajmniej części istotnych szczegółów. Właśnie na tym polega różnica pomiędzy rzemiosłem a inżynierią. Rzemiosło charakteryzuje się tym, że o ile doświadczenie może nas prowadzić we właściwym kierunku, to i tak cały czas stąpamy po niepewnym, nieznanym gruncie. Następnie przychodzi czas na inżynierię, czyli kontrolowany proces udoskonalania tego, od czego zaczęliśmy naszą pracę. Wszyscy programiści wiedzą, że pisanie dokumentów projektu oprogramowania już po opracowaniu kodu źródłowego (zamiast przed) pozwala tworzyć znacznie bardziej precyzyjną dokumentację. Powody tego stanu rzeczy są dość oczywiste. Tylko ostateczny projekt (w formie finalnej wersji kodu źródłowego) przeszedł pełny proces udoskonalania w ramach cykli budowa-test. Prawdopodobieństwo braku zmian w początkowym projekcie w trakcie tych cykli jest odwrotnie proporcjonalne do liczby modułów i programistów zaangażowanych w dane przedsięwzięcie. Prawdopodobieństwo to bardzo szybko maleje, by wreszcie osiągnąć wartość bliską zeru. W świecie inżynierii oprogramowania rozpaczliwie potrzebujemy dobrych projektów na wszystkich poziomach. W szczególności zaś potrzebujemy dobrego projektu najwyższego poziomu. Im lepszy jest wstępny projekt, tym łatwiejsze jest konstruowanie projektów szczegółowych. Projektanci powinni korzystać ze wszelkich narzędzi, które mogą im ułatwić to zadanie. Niezależnie od tego, czy mają postać diagramów struktur, diagramów Boocha, tabel stanów, czy PDL, jeśli tylko pomagają w pracy, powinniśmy ich używać. Musimy jednak pamiętać o tym, że ani narzędzia, ani notacje same nie stanowią projektu oprogramowania. Prędzej czy później musimy opracować prawdziwy projekt zapisany w wybranym języku programowania. Nie powinniśmy się więc obawiać kodowania naszych projektów na bieżąco — równolegle z korzystaniem z narzędzi pomocniczych. Musimy tylko zachowywać stałą gotowość do ich udoskonalania.

CZYM JEST PROJEKT OPROGRAMOWANIA?

531

Do tej pory nie powstała jedna notacja, która nadawałaby się równie dobrze do wspierania procesów projektowania najwyższego poziomu i projektowania szczegółowych rozwiązań. Ostatecznie projekt musi zostać zakodowany w którymś z języków programowania. Oznacza to, że notacje projektu najwyższego poziomu muszą być tłumaczone na zapisy docelowego języka programowania przed przystąpieniem do implementacji szczegółowego projektu. Proces tłumaczenia wymaga czasu i prowadzi do powstawania błędów. Zamiast ograniczać się do tłumaczenia notacji, która nie zawsze ma proste przełożenie na zapisy wybranego języka programowania, programiści często decydują się na powrót do wymagań i przebudowę projektu najwyższego poziomu, by na bieżąco je zakodować. Jest to nieodłączny element wytwarzania oprogramowania. Prawdopodobnie lepszym wyjściem byłoby umożliwienie samym projektantom pisania oryginalnego kodu, zamiast dopuszczać do sytuacji, w której inni programiści próbują tłumaczyć ten projekt na wskazany język programowania. Pewnym rozwiązaniem byłoby wdrożenie zunifikowanej notacji projektowej pasującej w równym stopniu do wszystkich poziomów. Innymi słowy, potrzebujemy języka programowania, który będzie dodatkowo umożliwiał wyrażanie koncepcji projektowych wysokiego poziomu. Warto w tym momencie zwrócić uwagę na język C++. Jest on nie tylko językiem programowania zdającym egzamin w rzeczywistych projektach, ale też jednym z najlepszych języków wyrażania decyzji projektowych. Język C++ umożliwia bezpośrednie wyrażanie wysokopoziomowych informacji o komponentach projektowych. Taka możliwość ułatwia nam zarówno konstruowanie, jak i późniejsze udoskonalanie projektów. Ścisła kontrola typów znacznie upraszcza proces wykrywania błędów w projekcie i tym samym umożliwia tworzenie bardziej niezawodnych projektów oraz zbliża cały proces do tradycyjnych procesów inżynierskich. Projekt oprogramowania ostatecznie musi być reprezentowany w jakimś języku programowania, by następnie można go było poddać weryfikacji i udoskonalaniu w ramach cyklu budowa-test. Rezygnacja z tego modelu byłaby bardzo nierozsądna. Warto zwrócić uwagę na rodzaj narzędzi i technik programistycznych, które zyskały szczególną popularność. Programowanie strukturalne w swoim czasie było uważane za wielki przełom. Spopularyzował je język Pascal, który z czasem sam zyskał spore uznanie w środowisku programistów. Kolejną rewolucją było zaistnienie programowania obiektowego z jego flagowym narzędziem: językiem C++. Skoro wiemy już, jakie technologie i narzędzia osiągnęły sukces, warto przeanalizować rozwiązania, które nie zdały egzaminu. Narzędzia CASE? Są popularne, ale nie są uniwersalne. Diagramy struktur? Popularne, ale mało uniwersalne. To samo można powiedzieć o diagramach Wamer-Oir, diagramach Boocha, diagramach obiektów itd. Wszystkie te notacje mają swoje plusy i jedną zasadniczą słabość: nie mają wiele wspólnego z projektowaniem oprogramowania. Okazuje się, że jedyną powszechnie stosowaną notacją projektów oprogramowania jest język PDL. Uczestnicy procesów wytwarzania oprogramowania podświadomie czują, że doskonalenie technik programowania i — w szczególności — rzeczywistych języków programowania jest nieporównanie ważniejsze od jakichkolwiek innych aspektów tej gałęzi przemysłu. Współcześni programiści muszą być zaangażowani i zainteresowani projektami. Twórcy oprogramowania z wyjątkową otwartością przyjmą wszelkie języki programowania, które będą oferowały większe możliwości wyrażania projektów. Warto przy tej okazji zwrócić uwagę na sposób, w jaki zmieniają się procesy wytwarzania oprogramowania. W pewnym momencie powstała koncepcja tzw. procesu kaskadowego. Obecnie większą popularnością cieszą się metodyki spirali (ang. spiral development) oraz błyskawicznego prototypowania. O ile zwolennicy przytoczonych technik często dowodzą, że ich stosowanie „ogranicza ryzyko” i „skraca czas dostarczania produktów”, faktycznym celem tych metodyk jest poszukiwanie uzasadnienia dla rozpoczynania kodowania w możliwie wczesnych fazach cyklu życia. Takie podejście zawsze jest pożądane, ponieważ umożliwia wczesne rozpoczynanie cyklu budowania i testowania w celu weryfikacji i udoskonalania projektu. Opisywane metodyki dodatkowo zwiększają prawdopodobieństwo udziału projektantów oprogramowania, którzy opracowali projekt najwyższego poziomu, w pracach nad projektem szczegółowym. Jak już wspomniano, inżynieria w większym stopniu dotyczy sposobu realizacji procesu niż ostatecznego kształtu produktu. Uczestnicy przedsięwzięć w świecie oprogramowania pod wieloma względami przypominają tradycyjnych inżynierów, ale nigdy nie powinni całkowicie rezygnować z istniejących różnic.

532

DODATEK D KOD ŹRÓDŁOWY JEST PROJEKTEM

Programowanie oraz cykle budowa-test są centralnymi elementami procesów w świecie inżynierii oprogramowania i jako takie wymagają właściwego zarządzania. Ekonomia cyklu budowa-test oraz fakt, iż system informatyczny może reprezentować niemal dowolne rozwiązania, powodują, że znalezienie jednej, uniwersalnej metody weryfikacji poprawności projektu jest bardzo mało prawdopodobne. Możemy ten proces usprawnić, ale nie możemy przed nim uciec. Warto poświęcić jeszcze trochę uwagi ostatniemu ważnemu wnioskowi: celem każdego projektu inżynierskiego jest opracowanie jakiejś dokumentacji. Nie ma wątpliwości, że chociaż właściwe dokumenty projektu są najważniejsze, tworzona dokumentacja nigdy nie ogranicza się tylko do nich. Budowane oprogramowanie w końcu będzie przez kogoś wykorzystywane. Wielce prawdopodobna jest także konieczność modyfikowania i rozbudowy systemu w przyszłości. Oznacza to, że dokumentacja zewnętrzna jest nie mniej ważna dla powodzenia całego przedsięwzięcia informatycznego niż w przypadku projektów tradycyjnej inżynierii. Nawet jeśli we wczesnych fazach ignorujemy potrzebę opracowywania podręczników użytkownika, przewodników instalacji i innych dokumentów, które nie są bezpośrednio związane z procesem projektowania, musimy mieć na uwadze dwa ważne zastosowania zewnętrznych dokumentów projektowych. Pierwszym zastosowaniem dokumentacji zewnętrznej jest gromadzenie ważnych informacji z przestrzeni problemów, których nie udało się zawrzeć bezpośrednio w projekcie. Opracowywanie projektu oprogramowania z reguły wiąże się z koniecznością wynajdywania właściwych koncepcji modelowych w ramach przestrzeni problemu. Opisywany proces wymaga oczywiście dogłębnego rozumienia pojęć z dziedziny rozwiązywanego problemu. Chociaż te dodatkowe informacje zwykle nie są bezpośrednio modelowane w przestrzeni oprogramowania, bez nich projektant prawdopodobnie nie byłby w stanie zidentyfikować kluczowych pojęć i znaleźć sposobu ich modelowania. Odpowiednie dane powinny zostać gdzieś utrwalone na wypadek, gdyby w przyszłości gotowy model wymagał modyfikacji. Drugim ważnym zastosowaniem dokumentacji zewnętrznej jest opisywanie tych aspektów projektu, których zawarcie bezpośrednio w projekcie byłoby trudne. Mogą to być zarówno aspekty wysokiego poziomu, jak i aspekty niskiego poziomu. W wielu przypadkach najlepszym sposobem wyrażania tych aspektów jest forma graficzna. Takie rozwiązanie oczywiście uniemożliwia ich zawieranie w komentarzach osadzanych w kodzie źródłowym. W żadnym razie nie należy tego traktować jako argumentu na rzecz graficznych notacji projektów oprogramowania kosztem języków programowania. Mamy tutaj raczej do czynienia z sytuacją występującą także w tradycyjnych dziedzinach inżynierii, gdzie graficzne dokumenty projektowe współistnieją z opisami tekstowymi. Musimy pamiętać o tym, że nie dokumentacja zewnętrzna, a właśnie kod źródłowy określa faktyczny kształt projektu. Idealnym rozwiązaniem byłoby korzystanie z narzędzi przetwarzających gotowy kod źródłowy i na tej podstawie generujących dokumentację zewnętrzną. Trudno jednak oczekiwać od życia tak wiele. Innym wielkim ułatwieniem byłoby istnienie narzędzi umożliwiających programistom (lub autorom dokumentacji technicznej) wyodrębnianie z kodu źródłowego interesujących ich informacji, które można by później dokumentować w innej formie. Niewątpliwie ręczne aktualizowanie tego rodzaju dokumentów jest dość trudne. Jest to jeszcze jeden powód, dla którego programiści poszukują możliwie wyrazistych języków programowania. Z tego samego powodu warto ograniczać ilość dokumentacji zewnętrznej do minimum i dążyć do jej możliwie nieformalnego charakteru tak długo, jak to tylko możliwe. Także w tym przypadku możemy albo podejmować próby stosowania zaawansowanych narzędzi pomocniczych, albo liczyć na pióra, papier i tablice ścienne. Podsumowując:  Prawdziwe oprogramowanie pracuje na komputerach. Program ma postać sekwencji zer i jedynek

składowanych na jakimś nośniku magnetycznym, a nie listingu programu zapisanego w C++ ani innym języku programowania.  Listing kodu źródłowego programu jest dokumentem reprezentującym projekt oprogramowania. Za budowę projektów odpowiadają kompilatory i programy łączące.

CZYM JEST PROJEKT OPROGRAMOWANIA?

533

 Prawdziwe oprogramowanie jest niewiarygodnie tanie w budowie. Koszt budowy cały czas spada

w miarę wzrostu wydajności komputerów.  Prawdziwe oprogramowanie jest niewiarygodnie drogie w projektowaniu. Wynika to z faktu, że





















oprogramowanie jest wyjątkowo złożone oraz że praktycznie wszystkie kroki przedsięwzięcia polegającego na jego tworzeniu wchodzą w skład procesu projektowania. Programowanie jest jedną z czynności projektowych — w ramach dobrego procesu projektowania oprogramowania nikt nie waha się podjąć decyzji o kodowaniu, jeśli tylko taki krok na danym etapie ma sens. Decyzja o przystąpieniu do kodowania znajduje uzasadnienie dużo częściej, niż sądzi wielu programistów. Proces wyrażania projektu w formie kodu źródłowego często pozwala odkryć pewne przeoczenia i konieczność poprawy wstępnego projektu. Im wcześniej to nastąpi, tym lepszy będzie ostateczny projekt. Ponieważ oprogramowanie jest wyjątkowo tanie w budowie, w świecie wytwarzania systemów informatycznych stosowanie formalnych metod weryfikacji nie znajduje uzasadnienia. Budowa i testowanie projektu jest rozwiązaniem dużo prostszym i tańszym niż formalne dowodzenie jego poprawności. Testowanie i diagnozowanie oprogramowania należą do procesu projektowania — są w świecie oprogramowania odpowiednikiem procesów weryfikacji i udoskonalania projektów z innych dyscyplin inżynierii. We właściwie zarządzanych procesach projektowania oprogramowania przytoczona zasada jest przestrzegana i nikt nie podejmuje prób skracania ani eliminowania niezbędnych kroków. Istnieją jeszcze inne czynności projektowe związane z tworzeniem projektu najwyższego poziomu, projektu modułów, projektu strukturalnego, projektu architektury itp. Dobry proces projektowania oprogramowania uwzględnia wszystkie te kroki. Wszystkie czynności projektowe są ze sobą w ten czy inny sposób związane. W dobrym procesie projektowania oprogramowania należy to brać pod uwagę i stwarzać możliwość modyfikowania (czasem radykalnego) projektu w reakcji na ujawnienie takiej konieczności w poszczególnych krokach. Istnieje wiele potencjalnie przydatnych notacji projektów oprogramowania — część upraszcza proces sporządzania dokumentacji zewnętrznej, inne wspierają właściwy proces projektowania. Dokumenty generowane za ich pomocą nie stanowią jednak projektu oprogramowania. Wytwarzanie oprogramowania wciąż bardziej przypomina rzemiosło niż dziedzinę inżynierii. Wynika to przede wszystkim z braku rygorystycznych kryteriów przebiegu procesów weryfikacji i doskonalenia projektów. I wreszcie rzeczywiste postępy w świecie wytwarzania oprogramowania zależą od postępów w wymiarze technik programowania, czyli de facto rozwoju języków programowania, a jednym z języków, które zrewolucjonizowały techniki wytwarzania oprogramowania, jest C++. Ogromna popularność języka C++ wynika przede wszystkim z tego, że oferuje bezpośrednie wsparcie dla tworzenia lepszych projektów oprogramowania. C++ jest krokiem we właściwym kierunku, co nie oznacza, że dalszy postęp nie jest konieczny.

Posłowie Kiedy wracam do swojego artykułu po dziesięciu latach, szczególnie uderza mnie kilka zawartych tam wniosków. Po pierwsze (i najważniejsze z perspektywy czytelnika tej książki), dzisiaj jestem jeszcze bardziej niż wówczas przekonany o słuszności głównych tez tej publikacji. Moja pewność wynika z liczby popularnych metodyk i narzędzi wytwarzania oprogramowania, które pojawiły się w tym dziesięcioleciu i potwierdziły słuszność przedstawionych przeze mnie założeń. Najbardziej oczywistym przykładem (i być może najmniej istotnym) jest popularność obiektowych języków programowania. Istnieje obecnie wiele obiektowych języków programowania (oprócz języka C++). Co więcej, istnieją też takie notacje projektowania obiektowego jak język UML. Ogromna popularność obiektowych języków programowania niewątpliwie wynika z dążenia do bezpośredniego wyrażania projektów w kodzie źródłowym.

534

DODATEK D KOD ŹRÓDŁOWY JEST PROJEKTEM

Koncepcja refaktoryzacji, czyli przebudowy bazy kodu w celu poprawy jego niezawodności, możliwości wielokrotnego stosowania itd., także potwierdzi moje przekonanie o tym, że wszystkie aspekty projektu powinny być na tyle elastyczne, aby można je było modyfikować z uwzględnieniem wniosków z weryfikacji. Refaktoryzacja jest w istocie procesem i zbiorem wskazówek opisujących techniki doskonalenia projektu, w którym wykryto pewne niedociągnięcia. I wreszcie warto przeanalizować ideę zwinnego wytwarzania oprogramowania. O ile najbardziej rozpowszechnioną formą takiego wytwarzania oprogramowania jest tzw. programowanie ekstremalne (ang. eXtreme Programming — XP), istnieje szereg innych metodyk, których wspólną cechą jest traktowanie kodu źródłowego jako najważniejszego produktu procesu wytwarzania. Z drugiej strony, istnieje wiele argumentów, o których zaledwie wspomniałem w powyższym artykule i których znaczenie w ostatnich latach pokaźnie wzrosło. Jednym z nich jest waga architektury, czyli projektu najwyższego poziomu. W powyższym artykule stwierdziłem, że architektura jest w istocie jednym z elementów projektu i jako taka musi zapewniać należytą elastyczność w trakcie cykli budowa-test weryfikujących cały projekt. Ogólnie rzecz biorąc, przytoczone zdanie wciąż jest prawdziwe, jednak po głębszych przemyśleniach dochodzę do przekonania o swojej naiwności. Chociaż cykl budowa-test rzeczywiście może ujawnić pewne problemy w architekturze, musimy pamiętać o tym, że nieporównanie większa liczba problemów z reguły wynika wprost ze zmiany wymagań. Projektowanie oprogramowania na wysokim poziomie jest trudne i ani nowe języki programowania (jak Java czy C++), ani notacje graficzne (jak UML) nie ułatwiają tego zadania osobom, które nie do końca wiedzą, jak należy do tego rodzaju problemów właściwie podchodzić. Co więcej, kiedy już zbudujemy sporą ilość kodu wokół istniejącej architektury, istotna zmiana tej architektury zwykle wiąże się z koniecznością całkowitej przebudowy projektu lub wręcz powrotu do punktu wyjścia. Nawet organizacje, które rozumieją koncepcję refaktoryzacji, często muszą się borykać z problemem kompletnej przebudowy istniejącego kodu. Oznacza to, że opracowanie prawidłowego projektu najwyższego poziomu (architektury) już w pierwszej próbie jest bardzo ważne i zyskuje na znaczeniu w miarę rozbudowy projektu. Istnieją na szczęście obszary, w których odpowiednie wzorce projektowe skutecznie wspierają projektantów w eliminowaniu przytoczonych problemów. Innym obszarem, który — jak się wydaje — wymaga więcej uwagi, jest dokumentacja zewnętrzna, w szczególności dokumentacja architektury. Mimo że kod źródłowy można postrzegać jako projekt, określanie architektury na jego podstawie bywa bardzo trudne. W artykule sprzed dziesięciu lat wyraziłem nadzieję, że być może powstaną narzędzia ułatwiające programistom automatyczną synchronizację dokumentacji zewnętrznej z kodem źródłowym. Z czasem niemal całkowicie zapomniałem o tej koncepcji. Dobrą architekturę obiektową zwykle można opisać w formie zaledwie kilku diagramów i kilkudziesięciu stron tekstu. Takie diagramy (i tekst) muszą się jednak koncentrować na kluczowych klasach i relacjach w ramach reprezentowanego projektu. Tracę już nadzieję na powstanie na tyle inteligentnych narzędzi programowych, aby można było wyodrębniać najważniejsze aspekty z dużo obszerniejszej masy kodu źródłowego. Oznacza to, że projektanci muszą sami pisać i utrzymywać tego rodzaju dokumentację. Ciągle uważam, że pisanie dokumentacji już po opracowaniu kodu źródłowego lub przynajmniej jednocześnie z tworzeniem kodu jest lepszym rozwiązaniem niż podejmowanie prób uprzedniego pisania kodu. I wreszcie na końcu artykułu zauważyłem, iż pojawienie się języka C++ było sporym postępem w świecie programowania i — tym samym — projektowania systemów i że wciąż środowisko programistów oczekuje kolejnych, podobnych kroków. Ponieważ obserwuję kompletny brak postępów w świecie języków programowania, które mogłyby się równać popularnością z językiem C++, wydaje się, że tamto spostrzeżenie jest dzisiaj jeszcze bardziej aktualne niż wtedy, gdy publikowałem tamten artykuł. — Jack Reeves, 1 stycznia 2002

Skorowidz A abstrakcja, 118, 124, 145, 214 abstrakcja harmonogramu, 214 abstrakcje stabilne, 276 abstrakcyjna fabryka, 388 abstrakcyjność, 297 abstrakcyjny interfejs, 381 acykliczne zależności, 267 Acykliczny wizytator, 403, 404 Adapter, 333, 337 ADP, Acyclic Dependencies Principle, 267 ADP, Adaptive Software Development, 39 agile, 23 Agile Alliance, 24 agregacje, 486 aktorzy, 475 aktualizacja obiektu, 313 Aktywny obiekt, 169 algorytm termostatu, 146 algorytmy HiLo, 384 analiza, 206 analiza przypadku stacja pogodowa, 367 API, 375 API utrwalania, 382 aplikacja koszyk na zakupy, 345 multipleksera statystycznego, 495 obsługi kursów, 489 Payroll, 48 płacowa, 295, 298 Shape, 119 stacji pogodowej, 382 zdawania, 463 architektura, 482 menedżera zadań, 469, 471 programów CGI, 493 systemu pomiaru, 370 webowa, 482 artefakt, 362 asocjacje, 486 atrybuty, 486 automat stanów skończonych, 427, 428

B baza danych, 167, 219, 257 błąd w strukturze transakcji, 207, 209 błędy transakcji, 211 BOM, Bill of Material, 418

brak mobilności, immobility, 101 brzydkie zapachy kodu, 101 budowanie systemów wielowątkowych, 172

C CCP, Common-Closure Principle, 266 CGI, 473 charakterystyki zależności, 487 ciąg główny, 277 ciągła integracja, 34 ciśnienie atmosferyczne, 371 cykle, 270 cykle zależności, 268, 283

D DAG, Directed Acyclic Graph, 269 DBC, design by contract, 132 decyzje, 505 decyzje biznesowe, 246 Dekorator, 365, 413, 414 delegacja, 175, 323 delegowanie obserwatora, 323 diagram aktywności, 503, 505 czujnika temperatury, 375 klas, 212, 378 kolaboracji, 509 komponentów systemu, 484 obiektów, 507 pakietów, 269, 290, 382 przypadków użycia, 477 sekwencji, 371, 490, 492 stanów, 498 diagramy STD, 428 UML, 217, 230 DIP, Dependency Inversion Principle, 141 DM, Dependency Management, 263 dodawanie do modelu obiektowego, 342 do modelu relacyjnego, 343 pracowników, 218 dokumenty planowania oprogramowania, 369 domknięcie, 124, 125 dostęp do bazy danych, 345 dynamiczna struktura abstrakcji, 216 struktura programu głównego, 302

dynamiczny model abstrakcji, 215 programu, 257 scenariusza, 245 transakcji, 221, 228, 233, 235, 239 wzorca, 345 działanie wzorca Pełnomocnik, 344 dziedziczenie, 129, 137, 175, 222, 321 wielokrotne, 153 wirtualne, 362

E elastyczność, 484 eliminowanie cykli zależności, 268 sprzężeń, 48, 372 ETS, Educational Testing Service, 397, 449 ewolucja kodu do wzorca, 311

F Fabryka, 161, 281, 287, 388 fabryki obiektów, 301 wymienne, 284, 285 Fasada, Facade, 161, 187, 366 fasada bazy danych, 366 firma Chmura, 367 framework do zdawania, 463 ETS informacje o projekcie, 449 projekt, 454 strategia, 452 wyniki, 453 wyznaczania ocen, 456 FSM, finite state machine, 427 funkcja DoEval, 458 GeneratePrimes, 55 testMove, 46 funkcje zdegenerowane, 140

G generator menu sesji, 490 raportów, 407

536

SKOROWIDZ

generowanie liczb pierwszych, 54 gra w kręgle, 66–98 w planowanie, 35 graf acykliczny, 268 zależności, 269 granice systemu, 478 grupowanie klientów, 158 GUI, 439

interpretacja tabeli przejść, 432 ISP, Interface Segregation Principle, 149 iteracje przypadków użycia, 482 izolacja testu, 47

J jawne domknięcie, 124 język PDL, 531 Smalltalk, 133

H hermetyzacja, 294 heurystyki, 139 hierarchia cech testu, 455 klas, 135, 208 klas Modem, 400 pakietów, 292 typu Modem, 338 wizytatora, 403 historia 24-godzinna, 383, 392 historyjki użytkowników, 32

I imitowanie, spoofing, 285 fabryki, 286 klasy, 285 implementacja algorytmów HiLo, 384 klasy Turnstile, 441 wzorca, 192, 195 wzorca Pełnomocnik, 345, 387 wzorca Polecenie, 224 inicjalizacja interfejsu, 157 inicjowanie fabryk, 302 instrukcje switch-case, 429, 432 interakcja z GUI, 440 interfejs, 149, 150 API, 341, 357, 375 bazy danych, 489 GUI, 439 klasy ModemImplementation, 115 Modem, 334 rozdzielony użytkownika, 155 StationToolkit, 376 TimedDoor, 152 TimerClient, 150 TimeSink, 320 Transaction, 217 TurnstileLockedState, 434 TurnstileState, 434 użytkownika, 153, 372 WeatherStation, 381 znacznikowy, marker interface, 418 interfejsy klas, 152 obiektów, 152

K kanoniczna postać modelu, 327 klasa ActiveObjectEngine, 170 AddEmployeeTransaction, 221, 222 AddSalariedEmployee, 222, 223 AlarmClock, 374, 378 Application, 177 ApplicationRunner, 182 Assembly, 408, 422 BubbleSorter, 179–183 ChangeAffiliationTransaction, 241 ChangeClassificationTransaction, 237 ChangeEmployeeTransaction, 234 ChangeHourlyTransaction, 238 ChangeMemberTransaction, 242 ChangeNameTransaction, 235 ChangeUnaffiliatedTransaction, 243 Clock, 312 ClockDriverTest, 313, 317, 318 CompositeCommand, 309 CompositeShape, 307, 308 CSVPiecePartExtension, 424 DB, 347, 352, 355 DBTest, 352, 355 DedicatedHayesModem, 338 DelayedTyper, 172 DeleteEmployeeTransaction, 224 DoubleBubbleSorter, 181 Employee, 255 Evaluator, 457 FSMError, 446 ftocStrategy, 182 HayesModem, 415 HiLoDataImp, 384 HourlyClassification, 250 HTMLTemplate, 485 IntBubbleSorter, 180 IntSortHandle, 184 ItemData, 355 LinearObject, 138, 139 LoudDialModem, 414, 415, 418 NullEmployee, 202 MockTimeSink, 315, 317, 325 MockTimeSource, 314, 319–325 ModemDecorator, 417

ModemDecoratorTest, 416 MonthlySchedule, 247 ObservableClock, 321 ObserverTest, 324 OrderData, 351 OrderImp, 352 OrderProxy, 354 Part, 421 PartCountVisitor, 410 PaymentSchedule, 252 PayrollDatabase, 219 PersistentAssembly, 364 PersistentObject, 360, 362 PersistentProduct, 363 PiecePart, 409, 422 PrimeGenerator, 56–61 Product, 349 ProductData, 346 ProductImp, 349 productPersistenceTestCase, 360 ProductProxy, 349 ProxyTest, 348, 351 QuickBubbleSorter, 185 QuickEntryMediator, 188, 190 SalesReceiptTransaction, 296 Scheduler, 371–373 ServiceChargeTransaction, 230, 231 SessionMenuGenerator, 490 SleepCommand, 171 SMCTurnstileTest, 446 SortHandle, 184 StationToolkit, 376 Subject, 324 TemperatureHiLo, 383 TemperatureSensor, 377 TestBOMReport, 410 TestBOMXML, 419 TestGeneratePrimes, 55 TestModemVisitor, 402, 406 TestSleepCommand, 170 TimeCard, 226 TimeCardTransaction, 225, 227, 296 TimeSource, 316, 320, 321 TimeSourceImplementation, 322 Turnstile, 197–200, 441–443 TurnstileFSM, 437 UserDatabaseSource, 194 WeatherStation, 377–380 WeeklySchedule, 251 XMLAssemblyExtension, 424 XMLPiecePartException, 423 klasy abstrakcyjne, 134, 492 aplikacji płacowej, 298, 304 testowe, 370 klient, 32, 150 kod źródłowy, 525 kompilator maszyny stanów, 436 SMC, 438, 443, 468

SKOROWIDZ

komponenty systemu rejestracji, 483 kompozycje, 486 Kompozyt, Composite, 307 komunikacja, 502 konfiguracja pakietów, 274 konwencje, 139 konwersja stopni, 176 krótkie cykle, 32 kruchość, fragility, 101

L lepkość, viscosity, 101 liczności, 481 LSP, Liskov Substitution Principle, 127

M macierz dodawania, 456, 458 funkcji, 403 rzadka, 407 manifest Agile Alliance, 24 maszyna FSM, 428, 438 stanów, 436, 439, 469 rysowanie prostokąta, 440 Mediator, 188 menedżer zadań, 469, 471 metafora, 37 metoda CalculateDeductions(), 253 metoda configureForUnix, 400 Execute, 224, 247 Undo, 169 Metoda szablonowa, Template method, 119, 161, 175–181, 220, 459, 462 metodologia Adaptive Software Development, 29 Crystal, 29 Feature Driven Development, 29 SCRUM, 29 metryki, 296 D, 279 stabilności, 273 zarządzania zależnościami, 280 mierzenie abstrakcji, 276 model dodawania pracownika, 221 dostarczania karty, 226 dziedziny, 478 obiektowy, 342 procesora zdarzeń, 465 programu głównego, 257 transakcji AddEmployeeTransaction, 218 DeleteEmployee, 223 SalesReceiptTransaction, 228

wzorca Pełnomocnik, 345 zależności klas, 144 modyfikacja klasy, 296 klasy Scheduler, 373 monady, 158 Monostate, 194 Most, Bridge, 338 multiplekser, 495

N naruszanie stabilności, 275 zasady DIP, 282 zasady LSP, 128, 129, 136 zasady OCP, 120, 130 zasady SRP, 116 zasady SDP, 275 narzędzia klas Scope, 390 niepotrzebne powielenia, 101 nieprawidłowy format transakcji, 210 nieprzezroczystość, opacity, 101 niestabilność, 297 nieznany identyfikator, 208 notacja UML agregacje, 486 aktorzy, 475 asocjacje, 486 atrybuty, 486 decyzje, 505 diagramy aktywności, 503, 505 diagramy kolaboracji, 510 diagramy obiektów, 507 diagramy stanów, 498 kompozycje, 486 liczności, 481 model dziedziny, 478 notacja lizaka, 508 obiekty aktywne, 508 operacje, 486 pakiety, 488 podsystemy, 488 przejścia pomiędzy stanami, 500 przejścia wewnętrzne, 499 przejścia złożone, 505 przykład CGI, 473 przypadki użycia, 475 schemat blokowy, 496 semantyka klas, 479 stany, 499 stany zagnieżdżone, 500 STATMUX, 495 wykresy sekwencji komunikatów, 512

O Obiekt Null, 201 Obiekt rozszerzenia, Extension Object, 365, 418

537

obiekty aktywne, 508 obliczanie wynagrodzenia, 213, 214 Obserwator, Observer, 311, 326, 327 obserwatory ciśnienia atmosferycznego, 373 obsługa baz danych, 357 GUI, 439 kolejności, 124 przerwań wejścia, 497 przerwań wyjścia, 501 wyjątków, 178 zdarzenia, 467 zdarzenia standardowego, 466 ochrona prywatności klasy, 296 OCP, Open-Closed Principle, 117 odchylenia, 270 oddziaływania klientów, 151 odległość od ciągu głównego, 278, 297 znormalizowana, 298 odpowiedzialność, 114, 115 pojedyncza, 113 sprzężona, 115 odpytywanie obiektów, 159 odwracanie własności, 142 zależności, 141, 147, 271, 281, 359 ograniczenia czasu rzeczywistego, 496 okresowe pomiary, 370 okresy rozliczeniowe, 251 opakowanie obiektów, 157 operacje, 486 oprogramowanie, 525, 532 oprogramowanie middleware, 357, 359 oprogramowanie Nimbus-LC, 391 oprogramowanie protokołów komunikacyjnych, 506 oprogramowanie WMS-LC, 369 otwarta przestrzeń robocza, 35 ozdobniki, adornments, 294

P pakiet Classifications, 295 TransactionImplementation, 301 pakiety, 263, 488 nieodpowiedzialne, irresponsible, 291 odpowiedzialne, responsible, 291 z metrykami, 300 Pełnomocnik, 342, 356, 387 pełnomocnik dla relacji, 350 pętle, 460 plan publikacji wersji dystrybucyjnych, 394 planowanie, 39 iteracji, 41 wersji dystrybucyjnych, 41 zadań, 41 podstawianie typów, 127 podsystemy, 488

538

SKOROWIDZ

podział klas na pakiety, 379 kodu czasowy, 168 fizyczny, 168 na warstwy, 142 polecenia, Command, 161 kompozytowe, 308 proste, 166 sterowane przez czujnik, 166 Polecenie, 165, 224 poliady, 158 polimorfizm statyczny, 147 poprawność modelu, 132 porządkowanie typów, 125 potwierdzenie pakietu, 511 praktyki agile, 23 problem modemu, 334–339 projektowy, 251 dotyczący tworzenia, 376 procedura obsługi przerwań wejścia, 497 wyjścia, 501 proces inicjalizacji, 509 procesor zdarzeń, 464, 469 program Furnace, 146 główny, 257, 302 testowy, 343 programowanie, 65 ekstremalne, 29, 31 parami, 33 sterowane testami, 34, 45 zabezpieczanie przed zmianami, 123 projekt agile, 101 Alpha, 513 dzielnie na pakiety, 261 frameworka, 454, 463 góra-dół, 271 Kickoff, 513 modelu zdarzeń, 465 oprogramowania, 525 według kontraktu, DBC, 132 projektowanie pakietów, 263 według kontraktu, 132 prosty projekt, 36 protokoły komunikacyjne, 502, 506 przebieg iteracji, 42 przejścia pomiędzy stanami, 500 złożone, 505 przerywanie cykli, 270 zależności, 315 przetwarzanie rozproszone, 441 zdarzenia, 466, 467

przypadek testowy, 226, 240, 246–254 przypadek użycia, 206, 475 dodawanie pracownika, 162, 207 dostarczenie informacji, 164, 210 dostarczenie karty pracy, 163, 209 dostarczenie raportu sprzedaży, 163, 209 systemu Nimbus-LC, 393 usuwanie pracownika, 163, 208 generowanie listy płac, 164, 212 zmiana danych pracownika, 164, 210 pusty obiekt, Null object, 161

R realizacja wypłat, 244, 246, 248 redundancja, 150 refaktoryzacja, 37, 53 rejestrowanie kursów, 474 relacja IS-A, 132 relacje, 476 relacyjny model danych, 342 rozdzielone odpowiedzialności, 114 interfejs, 155 rozszerzanie klasy, 332 rozwiązanie problemu modemu, 335–339 równomierne tempo, 35 RTC, run-to-completion, 172

S scenariusze, 245 schemat blokowy systemu, 496 granic systemu, 478 Schody do nieba, Stairway to heaven, 359 segregacja interfejsów, 149 semantyka klas UML, 479 separacja przez delegację, 152 przez wielokrotne dziedziczenie, 153 utrwalania od strategii, 386 Serwer abstrakcyjny, 332 silnik przejść, 432 Singleton 161, 192, 193 skrypt depend.sh, 297 SMC, 436 sortowanie, 183 sortowanie bąbelkowe, 179 specyfikacja systemu płacowego, 162 specyfikowanie kontraktów, 133 spójność, cohesion, 113, 302 pakietów, 266 projektu, 130, 131 relacyjna, 297 sprzężenia, 47, 294, 374 przychodzące, 297 wychodzące, 297 sprzężony podsystem utrwalania, 116

SRP, Single Responsibility Principle, 113 stabilne abstrakcje, 276 zależności, 272 stabilność, 272 stacja pogodowa, 305, 367 Stan, 427, 433, 436 stany zagnieżdżone, 500 STATMUX, 495 statyczna struktura klasy, 219, 225 statyczny model programu, 257, 492 model transakcji, 218, 228–232, 244 multiplekser, 495 stereotypy na listach, 498 stosowanie klas-pełnomocników, 359 wzorca Monostate, 196 wzorca Singleton, 193 Strategia, Strategy, 119, 161, 175, 181, 386, 435, 462 strategia obsługi GUI, 439 struktura czujnika, 374 danych planu piętra, 459 generatora raportów, 407 klas, 462 klasy BubbleSorter, 180 klasy TemperatureHiLo, 383 klasy TimeCardTransaction, 225 pakietów, 290, 380, 389 pakietów aplikacji płacowej, 303 programu głównego, 302 wzorca, 462 zależności, 273 studium przypadku ETS, 397 stacja pogodowa, 305 system płacowy, 161, 205, 217 symptomy złego projektu, 101 system Nimbus-LC, 369 system płacowy, 161, 258, 289 implementacja, 217 pierwsza iteracja, 205 podział 8na pakiety, 261 system rejestrowania kursów, 474 system Statmux, 496 systemy wielowątkowe, 172 szablony HTML, 484, 485 sztywność, rigidity, 101

T tabela przejść, 432, 433, 441 TDD, test-driven development, 34 techniki implementacji, 429 test jednostkowy, 55, 133, 284, 430 testowanie, 45 akcji, 432 obiektu DigitalClock, 312 testy akceptacyjne, 33, 49, 51

SKOROWIDZ

transakcja, 167 AddEmployee, 168 AddSalariedTransaction, 219 ChangeAffiliationTransaction, 240 ChangeClassificationTransaction, 235 ChangeCommissionedTransaction, 236 ChangeEmployeeTransaction, 232, 233 ChangeMethodTransaction, 239 PaydayTransaction, 244 SalariedTransaction, 236 SalesReceiptTransaction, 228 ServiceChargeTransaction, 229 TimeCardTransaction, 226 tworzenie fabryki, 389 macierzy dla dodawania, 458 obiektów trwałych, 286 pełnomocników, 350 prototypów, 40 zestawów testowych, 284

U, W uniwersalny regulator, 147 usuwanie pracowników, 223 utrwalanie, 382, 386 warstwa, 142 adaptera klasy, 134 middleware, 358 pośrednia, 358 wątek czasowy, 504 odbierający, 504 wysyłający, 503 wersje dystrybucyjne systemu, 394 wewnętrzne przejścia, 499 wiele dekoratorów, 416 wielokrotne dziedziczenie, 321 wykorzystanie kodu, 264, 292 wykorzystywanie maszyny stanów, 468 wielokrotność, 309 wielokrotny zbiorowy użytek, 265 Wizytator, Visitor, 365, 399–401, 426 właściciel interfejsu, 333 wskaźnik A, 297 Ca, 297 Ce, 297 D, 297 D', 298 H, 297 I, 297 wskaźniki dla pakietów, 300, 305 globalne, 157 wspólna własność, 34 wybór języka, 369 platformy oprogramowania, 482

wydzielanie, 137 wyjątek FSMError, 446 wyjątki, 140 wykorzystanie diagramów, 327 wzorca Fabryka, 284 wykres czasowy, 279 punktowy, 279 wykresy sekwencji komunikatów, 512 wymagania administracyjne, 392 dla aplikacji oceniających, 454 dla aplikacji zdawania, 463 dla Nimbus-LC, 391 użytkowe, 391 wyszukiwanie abstrakcji, 145, 214 wyścig, 511 wyścig ACK, 512 wyświetlanie parametrów pogody, 370 wyznaczanie ocen, 456 wzorce projektowe, 161, 165 wzorzec Acykliczny wizytator, 403, 404 Adapter, 333, 334, 337 Aktywny obiekt, 169 Dekorator, 365, 413, 414 Fabryka, 281, 287 Fasada, 187, 366 Kompozyt, 307 Mediator, 188 Metoda szablonowa, 119, 161, 175–181, 220, 459, 462 Monostate, 194 Most, 338 Obiekt Null, 201 Obiekt rozszerzenia, 365, 418, 419 Obserwator, 311, 326, 327 Pełnomocnik, 342, 356, 387 Polecenie, 165, 224 Schody do nieba, 359 Serwer abstrakcyjny, 332 Singleton, 192, 193 Stan, 427, 433, 436 Strategia, 119, 161, 175, 181, 386, 435, 462 Wizytator, 365, 399–401, 426

Z zachowanie zgodności z OCP, 121, 123 zadanie MeasureTask, 469 RTC, 172 zależności acykliczne, 267 między pakietami, 269 modułów, 141 niewłaściwe, 275 pomiędzy pakietami, 267

539

stabilne, 272 zależność od abstrakcji, 143 zarządzanie kolejnością, 124 zależnościami, DM, 263 zasadami projektu, 328 zasada, 27, 101 ADP, acyklicznych zależności, 267 CCP, zbiorowego zamykania, 266, 291 CRP, zbiorowego wielokrotnego użytku, 265 DIP, odwracania zależności, 141, 281, 332 ISP, segregacji interfejsów, 149, 151 LSP, podstawiania Liskov, 127, 334 OCP, otwarte-zamknięte, 117, 328 REP, 264, 292 SAP, stabilnych abstrakcji, 276 SDP, stabilnych zależności, 272 SRP, pojedynczej odpowiedzialności, 113, 333 zasady projektowania pakietów, 263 spójności pakietów, 264 sprzęgania pakietów, 267 zasięg zmiennej stanu, 431 zastosowanie delegacji, 323 wskaźników, 298 wzorca Fabryka, 282 wzorca Kompozyt, 308 wzorca Metoda szablonowa, 178, 220, 459 wzorca Obserwator, 372 wzorca Schody do nieba, 360 wzorca Strategia, 181 wzorca Wizytator, 412 zasady CCP, 291 zasady REP, 292 zbiorowe domykanie, 266, 291 zbytnia złożoność, 101 zdarzenie Erase, 464 Measure, 466 ScreenCursor, 464 Sketch, 465 specyficzne dla winiety, 467 thirdBadPassword, 439 zegar cyfrowy, 311 zestawienia materiałów, 418 zgodność z zasadą LSP, 137 zgodność z zasadą OCP, 121 ziarnistość, 264 złożoność, 150 zmiana danych pracowników, 231 klasyfikacji, 235 zmienne globalne, 225 zwinne wytwarzanie oprogramowania, 29

540

SKOROWIDZ

Manifest zwinnego wytwarzania oprogramowania Odkrywamy lepsze sposoby rozwijania oprogramowania, rozwijając je i pomagając robić to innym. Dzięki tej pracy ukształtował się następujący system wartości:

Ludzie i interakcje ważniejsze niż procesy i narzędzia. Działające oprogramowanie ważniejsze niż kompleksowa dokumentacja.  Współpraca z klientem ważniejsza niż negocjacje kontraktu.  Reagowanie na zmiany ważniejsze niż przestrzeganie planu. 



Oznacza to, że podczas gdy istnieje wartość w pozycjach po prawej, to bardziej cenimy pozycje po lewej stronie. Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler

James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick

Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

Zasady wynikające z Manifestu Agile Alliance Postępujemy zgodnie z następującymi zasadami: 

Naszym najwyższym priorytetem jest osiągnięcie zadowolenia klienta poprzez ciągłe dostarczanie wartościowego oprogramowania.



Zmieniające się wymagania są mile widziane nawet w późnej fazie rozwoju. Procesy agile uwzględniają zmiany uzasadnione dążeniem klienta do uzyskania przewagi nad swoimi konkurentami na rynku.



Dostarczamy działające oprogramowanie często — od kilku tygodni do kilku miesięcy — z preferencją do krótszej skali czasowej.



Ludzie biznesu i deweloperzy muszą współpracować codziennie w trakcie trwania całego projektu.



Projekty należy budować wokół zmotywowanych osób. Należy zapewnić im środowisko i wsparcie, którego potrzebują, oraz zaufać, że wykonają zadanie.



Najbardziej wydajnym i skutecznym sposobem przekazywania informacji zespołowi projektowemu oraz wewnątrz zespołu jest bezpośrednia rozmowa.



Podstawowym miernikiem postępu jest działające oprogramowanie.



Procesy agile promują zrównoważony rozwój. Sponsorzy, deweloperzy i użytkownicy powinni mieć możliwość utrzymania stałego tempa przez czas nieokreślony.



Ciągła dbałość o doskonałość techniczną i dobry projekt zwiększa zwinność.



Prostota — sztuka maksymalizacji ilości wykonanej pracy — ma znaczenie kluczowe.



Najlepsze architektury, wymagania i projekty powstają w samoorganizujących się zespołach.



W regularnych odstępach czasu zespół zastanawia się, jak stać się bardziej wydajnym, a następnie odpowiednio dostosowuje swoje działania.

Praktyki programowania ekstremalnego Cały zespół Wszyscy uczestnicy projektu EP — deweloperzy, analitycy biznesowi, testerzy itd.— pracują razem w otwartej przestrzeni. Są członkami tego samego zespołu. Na ścianach w takim pokoju jest pełno dużych, widocznych wykresów i innych dowodów potwierdzających postępy prac.

Gra planistyczna Planowanie jest procesem ciągłym i progresywnym. Powinno odbywać się co dwa tygodnie i dotyczyć okresu następnych dwóch tygodni. Deweloperzy szacują koszt funkcji, nad którymi mają zamiar pracować, a klienci wybierają funkcjonalności do zaimplementowania na podstawie kosztów i wartości biznesowej.

Testy przygotowywane przez klientów W ramach wyboru każdej pożądanej funkcjonalności klienci definiują automatyczne testy akceptacyjne, których celem jest pokazanie, że funkcja działa.

Prosty projekt Zespół stara się utrzymać projekt w postaci dostosowanej do bieżącej funkcjonalności systemu. Projekt przechodzi wszystkie testy, nie zawiera zdublowanego kodu, wyraża wszystko to, co autorzy chcieli wyrazić, i zawiera minimalną konieczną ilość kodu potrzebnego do zaimplementowania wszystkich funkcjonalności.

Programowanie parami Cały kod jest tworzony przez dwóch programistów pracujących obok siebie przy tym samym komputerze.

Programowanie sterowane testami Programiści pracują w bardzo krótkich cyklach. Dodają test, który nie przechodzi, a następnie dążą do tego, by zaczął przechodzić.

Usprawnianie projektu Nie należy tolerować złego kodu. Należy dążyć do tego, by kod był tak czysty, jak to możliwe, i tak ekspresywny, jak to możliwe.

Ciągła integracja Zespół przez cały czas dąży do tego, aby system był w pełni zintegrowany.

Wspólna własność kodu Każda para programistów w każdej chwili może usprawniać kod.

Standardy kodowania Cały kod w systemie wygląda tak, jakby napisał go jeden programista o bardzo wysokich kwalifikacjach.

Metafora Zespół pracuje nas wspólną wizją sposobu, w jaki działa program.

Równomierne tempo Zespół potrafi utrzymać równomierne tempo kodowania przez długi czas. Jego członkowie ciężko pracują w tempie, które może być zachowane na stałym poziomie w nieskończoność. Programiści zachowują energię, traktując projekt tak, jakby to był maraton, a nie sprint.

Zasady projektowania obiektowego SRP

zasada pojedynczej odpowiedzialności Powód modyfikacji klasy powinien być tylko jeden.

OCP

zasada otwarte-zamknięte Encje oprogramowania (klasy, moduły, funkcje itp.) powinny być otwarte na rozbudowę, ale zamknięte dla modyfikacji.

LSP

zasada podstawiania Liskov Musi być możliwość podstawienia typów pochodnych za ich typy bazowe.

DIP

zasada odwracania zależności Abstrakcje nie powinny zależeć od szczegółów. To szczegóły powinny zależeć od abstrakcji.

ISP

zasada segregacji interfejsów Klienty nie powinny być zmuszone do zależności od metod, których nie używają. Interfejsy należą do klientów, a nie do hierarchii klas pochodnych.

REP

zasada równoważności wielokrotnego wykorzystania kodu i dystrybucji Ziarnistość wielokrotnego wykorzystywania kodu jest równoważna ziarnistości wydań wersji dystrybucyjnych.

CCP

zasada zbiorowego domykania Klasy należące do pakietu powinny być wspólnie zamknięte dla tego samego rodzaju zmian. Zmiana, która dotyczy zamkniętego pakietu, dotyczy wszystkich klas w tym pakiecie i nie ma wpływu na żadne inne pakiety.

CRP

zasada zbiorowego wielokrotnego użytku Klasy należące do pakietu są wykorzystywane wielokrotnie razem. Jeśli korzystamy z jednej klasy z pakietu, to korzystamy ze wszystkich klas należących do tego pakietu.

ADP

zasada acyklicznych zależności Graf zależności pomiędzy pakietami nie może zawierać cykli.

SDP

zasada stabilnych zależności Zależności powinny być zgodne z kierunkiem stabilności.

SAP

zasada stabilnych abstrakcji Pakiet powinien być abstrakcyjny w stopniu odpowiadającym jego stabilności.

Robert-C-Martin-zwinne_wytwarzanie_oprogramowania_najlepsze_zasady_wzorce_i_praktyki

to jest nagłówek

to jest nagłówek

Recommend Documents