Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00281 007777 11009264 na godz. na dobę w sumie
Projektowanie obiektowe. Role, odpowiedzialność i współpraca - książka
Projektowanie obiektowe. Role, odpowiedzialność i współpraca - książka
Autor: , Liczba stron: 352
Wydawca: Helion Język publikacji: polski
ISBN: 83-246-0046-9 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> techniki programowania
Porównaj ceny (książka, ebook, audiobook).

Projektowanie i programowanie obiektowe to dziś standard w produkcji oprogramowania. Język UML, powszechnie stosowane narzędzie opisu projektów i architektury oprogramowania, systematyzuje i upraszcza proces projektowania. Projektowanie systemów w oparciu o przypadki użycia oraz role, odpowiedzialność i współpracę obiektów, pozwala na skoncentrowanie się na tym, jak powinien działać system, bez zbyt wczesnego zagłębiania się w szczegóły implementacyjne. Dopiero po opracowaniu prawidłowego projektu można zacząć zastanawiać się, jak zaimplementować projekt przy użyciu klas, interfejsów i hierarchii dziedziczenia.

Książka 'Projektowanie obiektowe. Role, odpowiedzialność i współpraca' przedstawia metodykę projektowania obiektowego noszącą nazwę 'Projektowania Sterowanego Odpowiedzialnością'. Przedstawia praktyczne zasady projektowania obiektów będących integralnymi elementami systemu, w którym każdy obiekt ma specyficzną rolę i zakres odpowiedzialności. Autorzy prezentują najnowsze praktyki i techniki 'Projektowania Sterowanego Odpowiedzialnością', a także przedstawiają sposoby ich stosowania w rozwoju nowoczesnych aplikacji obiektowych. Książka przedstawia strategie znajdowania kandydatów na obiekty i zawiera praktyczne przykłady oraz porady, dzięki którym bez problemu wykorzystasz opisywane w niej metody.

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

IDZ DO IDZ DO PRZYK£ADOWY ROZDZIA£ PRZYK£ADOWY ROZDZIA£ SPIS TREŒCI SPIS TREŒCI KATALOG KSI¥¯EK KATALOG KSI¥¯EK KATALOG ONLINE KATALOG ONLINE ZAMÓW DRUKOWANY KATALOG ZAMÓW DRUKOWANY KATALOG TWÓJ KOSZYK TWÓJ KOSZYK DODAJ DO KOSZYKA DODAJ DO KOSZYKA CENNIK I INFORMACJE CENNIK I INFORMACJE ZAMÓW INFORMACJE ZAMÓW INFORMACJE O NOWOŒCIACH O NOWOŒCIACH ZAMÓW CENNIK ZAMÓW CENNIK CZYTELNIA CZYTELNIA FRAGMENTY KSI¥¯EK ONLINE FRAGMENTY KSI¥¯EK ONLINE Wydawnictwo Helion ul. Chopina 6 44-100 Gliwice tel. (32)230-98-63 e-mail: helion@helion.pl Projektowanie obiektowe. Role, odpowiedzialnoœæ i wspó³praca Autorzy: Rebecca Wirfs-Brock, Alan McKean T³umaczenie: Przemys³aw Kowalczyk ISBN: 83-246-0046-9 Tytu³ orygina³u: Object Design: Roles, Responsibilities, and Collaborations Format: B5, stron: 352 Projektowanie i programowanie obiektowe to dziœ standard w produkcji oprogramowania. Jêzyk UML, powszechnie stosowane narzêdzie opisu projektów i architektury oprogramowania, systematyzuje i upraszcza proces projektowania. Projektowanie systemów w oparciu o przypadki u¿ycia oraz role, odpowiedzialnoœæ i wspó³pracê obiektów, pozwala na skoncentrowanie siê na tym, jak powinien dzia³aæ system, bez zbyt wczesnego zag³êbiania siê w szczegó³y implementacyjne. Dopiero po opracowaniu prawid³owego projektu mo¿na zacz¹æ zastanawiaæ siê, jak zaimplementowaæ projekt przy u¿yciu klas, interfejsów i hierarchii dziedziczenia. Ksi¹¿ka „Projektowanie obiektowe. Role, odpowiedzialnoœæ i wspó³praca” przedstawia metodykê projektowania obiektowego nosz¹c¹ nazwê „Projektowania Sterowanego Odpowiedzialnoœci¹”. Przedstawia praktyczne zasady projektowania obiektów bêd¹cych integralnymi elementami systemu, w którym ka¿dy obiekt ma specyficzn¹ rolê i zakres odpowiedzialnoœci. Autorzy prezentuj¹ najnowsze praktyki i techniki „Projektowania Sterowanego Odpowiedzialnoœci¹”, a tak¿e przedstawiaj¹ sposoby ich stosowania w rozwoju nowoczesnych aplikacji obiektowych. Ksi¹¿ka przedstawia strategie znajdowania kandydatów na obiekty i zawiera praktyczne przyk³ady oraz porady, dziêki którym bez problemu wykorzystasz opisywane w niej metody. (cid:129) Stereotypy ról obiektów (cid:129) Analiza opisu systemu (cid:129) Model biznesowy systemu (cid:129) Wyszukiwanie kandydatów na obiekty (cid:129) Przydzielanie odpowiedzialnoœci obiektom (cid:129) Definiowanie wspó³pracy pomiêdzy obiektami (cid:129) Przekazywanie sterowania w obiektach i systemie Spis treści Przedsłowie autorstwa Ivara Jacobsona....................................................9 Przedsłowie autorstwa Johna Vlissidesa .................................................11 Przedmowa ...........................................................................................13 Rozdział 1. Pojęcia używane w projektowaniu .........................................................17 Maszyneria obiektowa ........................................................................................................... 17 Role ........................................................................................................................................ 19 Stereotypy ról obiektów ......................................................................................................... 20 Rola, odpowiedzialność i współpraca .................................................................................... 21 Kontrakty obiektów ................................................................................................................ 23 Gwarancje warunków użycia i następstw ........................................................................ 23 Obiekty dziedzinowe .............................................................................................................. 24 Obiekty specyficzne dla aplikacji ........................................................................................... 25 Interfejsy ................................................................................................................................ 27 Klasy ...................................................................................................................................... 28 Dwie role ......................................................................................................................... 28 Złożenie ................................................................................................................................. 30 Dziedziczenie ......................................................................................................................... 31 Organizacje obiektów ............................................................................................................ 32 Komponenty ........................................................................................................................... 33 Wzorce ................................................................................................................................... 33 Zastosowanie wzorca podwójnego rozdziału ................................................................... 34 Rzeczywiste korzyści z używania wzorców .................................................................... 38 Schematy, sp. z o.o. ................................................................................................................ 38 Architektura ........................................................................................................................... 40 Style architektoniczne ............................................................................................................ 41 Sterowanie scentralizowane ............................................................................................. 43 Sterowanie rozproszone — brak centrów ........................................................................ 43 Sterowanie delegowane ................................................................................................... 44 Badanie interakcji — przykład architektury warstwowej ................................................ 44 Umieszczanie obiektów w warstwach ............................................................................. 46 Opis projektu .......................................................................................................................... 47 Podsumowanie ....................................................................................................................... 48 Zalecane lektury ..................................................................................................................... 48 4 Projektowanie obiektowe. Role, odpowiedzialność i współpraca Rozdział 2. Projektowanie sterowane odpowiedzialnością ........................................51 Proces widzenia, opisywania i projektowania ........................................................................ 52 Uruchamianie produkcji — definicja i planowanie .......................................................... 55 Przygotowanie sceny — wstępny opis ............................................................................. 55 Przystępujemy do produkcji — projekt ........................................................................... 57 „Widzenie” z wielu perspektyw ....................................................................................... 59 Pisanie scenariusza — analiza opisów ................................................................................... 59 Opisy użytkowania .......................................................................................................... 60 Inne specyfikacje ............................................................................................................. 67 Słowniki ........................................................................................................................... 67 Obiekty konceptualne ...................................................................................................... 68 Obsadzanie ról — projektowanie badawcze .......................................................................... 69 Karty CRC ....................................................................................................................... 70 Rozwiązania — używanie wzorców ................................................................................ 72 Poszukiwanie rozwiązania ............................................................................................... 75 Przeskakiwanie od pomysłów do szczegółów .................................................................. 76 Przed premierą — dopracowywanie projektu ........................................................................ 77 Projektowanie a elastyczność i rozszerzalność ................................................................ 79 Projektowanie a niezawodność ........................................................................................ 80 Tworzenie przewidywalnych, spójnych i zrozumiałych projektów ................................. 80 Podsumowanie ....................................................................................................................... 81 Zalecane lektury ..................................................................................................................... 82 Rozdział 3. Szukanie obiektów ...............................................................................85 Strategia odkrywania .............................................................................................................. 86 Szukanie obiektów i ról, a następnie klas ............................................................................... 87 Po co opis projektu? ............................................................................................................... 88 Strategie poszukiwań ............................................................................................................. 91 Czymże jest nazwa? ............................................................................................................... 93 Opisywanie kandydatów ........................................................................................................ 98 Charakteryzowanie kandydatów .......................................................................................... 102 Łączenie kandydatów ........................................................................................................... 103 Poszukiwanie wspólnych cech ............................................................................................. 105 Obrona kandydatów ............................................................................................................. 107 Podsumowanie ..................................................................................................................... 109 Zalecana lektura ................................................................................................................... 109 Rozdział 4. Odpowiedzialność ...............................................................................111 Czym jest odpowiedzialność? .............................................................................................. 111 Skąd bierze się odpowiedzialność? ...................................................................................... 113 Strategie przydzielania odpowiedzialności .......................................................................... 124 Zapisywanie odpowiedzialności .................................................................................... 125 Wstępne przypisywanie odpowiedzialności ................................................................... 127 Wychodzenie z kłopotów ............................................................................................... 136 Implementacja obiektów i odpowiedzialności ..................................................................... 138 Obiekt może grać wiele ról ............................................................................................ 138 Projektowanie metod obsługujących odpowiedzialność ................................................ 140 Testowanie jakości kandydatów ........................................................................................... 141 Podsumowanie ..................................................................................................................... 142 Zalecane lektury ................................................................................................................... 143 Rozdział 5. Współpraca ........................................................................................145 Czym jest współpraca między obiektami? ........................................................................... 145 Przygotowanie do współpracy ....................................................................................... 146 Opisywanie współpracy kandydatów ............................................................................. 146 Spis treści 5 Opis projektu aplikacji „Mów za mnie” ............................................................................... 147 Warianty współpracy ........................................................................................................... 148 Kto steruje? .................................................................................................................... 149 Na ile obiekty mogą sobie ufać? .................................................................................... 150 Strategie identyfikacji współpracy ....................................................................................... 152 Badanie roli każdego obiektu — stereotypy implikują współpracę ............................... 153 Zakresy odpowiedzialności implikują współpracę ......................................................... 159 Projektowanie szczegółów złożonego zakresu odpowiedzialności ................................ 160 Projektowanie współpracy dla konkretnych zadań ........................................................ 162 Identyfikowanie pasujących wzorców projektowych .................................................... 162 Jak architektura wpływa na współpracę? ....................................................................... 164 Rozwiązywanie problemów we współpracy .................................................................. 164 Symulacja współpracy ......................................................................................................... 167 Planowanie symulacji .................................................................................................... 168 Przeprowadzanie symulacji ........................................................................................... 170 Projektowanie dobrej współpracy ........................................................................................ 173 Prawo Demeter — studium przypadku .......................................................................... 174 Umożliwianie współpracy .................................................................................................... 176 Wskazówki dotyczące nawiązywania połączeń ............................................................. 177 Projektowanie niezawodnej współpracy ........................................................................ 178 Kiedy możemy uznać, że skończyliśmy? ............................................................................. 179 Podsumowanie ..................................................................................................................... 180 Zalecane lektury ................................................................................................................... 181 Rozdział 6. Styl sterowania ..................................................................................183 Czym jest styl sterowania? ................................................................................................... 183 Warianty stylów sterowania ................................................................................................. 184 Kompromisy ........................................................................................................................ 185 Centralizowanie sterowania ........................................................................................... 186 Delegowanie sterowania ................................................................................................ 187 Ograniczenia decyzji sterujących ................................................................................... 188 Tworzenie centrów sterowania ............................................................................................. 191 Studium przypadku — styl sterowania dla zdarzeń użytkownika ........................................ 192 Centralizowanie sterowania w BudowniczymKomunikatu ........................................... 195 Przenoszenie podejmowania decyzji do metod stanu w BudowniczymKomunikatu ..... 203 Abstrahowanie od decyzji .............................................................................................. 204 Delegowanie kolejnych zakresów odpowiedzialności ................................................... 206 Projektowanie stylu sterowania dla sąsiedztwa Podpowiadacza .................................... 208 Projektowanie podobnego centrum sterowania — jak zachować spójność? .................. 211 Podsumowanie ..................................................................................................................... 217 Rozdział 7. Opisywanie współpracy .......................................................................219 Opowiadanie o współpracy .................................................................................................. 219 Strategia tworzenia historii o współpracy ............................................................................ 220 Ustalanie zakresu, poziomu i tonu historii ........................................................................... 221 Lista opisywanych aspektów ................................................................................................ 222 Określenie poziomu szczegółowości .................................................................................... 223 Widok z lotu ptaka ......................................................................................................... 223 Uczestnicy przypadku współpracy ................................................................................. 225 Sekwencja interakcji pomiędzy współpracownikami .................................................... 227 Widok szczegółowy ....................................................................................................... 229 Widok skoncentrowany na interakcji ............................................................................. 230 Widok implementacyjny ................................................................................................ 231 Widok ilustrujący adaptację współpracy ........................................................................ 232 Gdy nie wystarczają diagramy sekwencji ...................................................................... 234 6 Projektowanie obiektowe. Role, odpowiedzialność i współpraca Wybór odpowiedniej formy ................................................................................................. 237 Opowiedzmy, narysujmy, opiszmy — wskazówki .............................................................. 239 Organizowanie pracy ........................................................................................................... 244 Wyróżnianie ................................................................................................................... 244 Odsłanianie historii ........................................................................................................ 245 Przekazywanie podstawowych informacji ..................................................................... 246 Składanie wszystkiego w całość .................................................................................... 247 Konserwacja historii ............................................................................................................ 247 Podsumowanie ..................................................................................................................... 248 Zalecane lektury ................................................................................................................... 249 Rozdział 8. Niezawodna współpraca ......................................................................251 Zrozumienie konsekwencji awarii ........................................................................................ 251 Zwiększanie niezawodności systemu ................................................................................... 253 Określanie zaufanych współpracowników ........................................................................... 254 Współpraca zaufana i niepewna ..................................................................................... 254 Konsekwencje zaufania ................................................................................................. 257 Gdzie zwiększać niezawodność? ......................................................................................... 258 Co wynika z przypadków użycia ................................................................................... 258 Rozróżnianie wyjątków i błędów ................................................................................... 259 Wyjątki obiektowe a wyjątki z przypadków użycia ....................................................... 260 Podstawy wyjątków obiektowych .................................................................................. 260 Strategie obsługi wyjątków i błędów ............................................................................. 265 Określanie obiektu odpowiedzialnego za podjęcie działań ............................................ 267 Projektowanie rozwiązania .................................................................................................. 269 Burza mózgów na temat wyjątków ................................................................................ 270 Ograniczmy zakres ........................................................................................................ 271 Opisywanie strategii obsługi wyjątków ......................................................................... 273 Dokumentowanie projektu obsługi wyjątków ...................................................................... 273 Określanie formalnych kontraktów ................................................................................ 277 Przegląd projektu ................................................................................................................. 279 Podsumowanie ..................................................................................................................... 281 Zalecane lektury ................................................................................................................... 281 Rozdział 9. Elastyczność ......................................................................................283 Co oznacza „bycie elastycznym”? ....................................................................................... 283 Stopnie elastyczności ........................................................................................................... 285 Konsekwencje elastycznego rozwiązania ............................................................................. 286 Określanie wymagań elastyczności ...................................................................................... 287 Opisywanie zmienności ....................................................................................................... 291 Warianty i ich realizacja ....................................................................................................... 293 Identyfikacja wpływu zmienności ................................................................................. 294 Badanie strategii realizacji elastyczności ....................................................................... 294 Użycie szablonów i punktów zaczepienia do zapewnienia elastyczności ...................... 295 Rola wzorców w elastycznych projektach ........................................................................... 302 Zmiana działania obiektu — wzorzec Strategii ............................................................. 302 Ukrycie współpracujących obiektów — wzorzec Mediatora ......................................... 303 Dopasowywanie istniejących obiektów — wzorzec Adaptera ....................................... 303 W jaki sposób wzorce zwiększają elastyczność? ........................................................... 305 Jak dokumentować elastyczność projektu? .......................................................................... 305 Pamiętajmy o czytelnikach ............................................................................................ 309 Opisywanie sposobu wprowadzania zmian .................................................................... 310 Zmiana projektu działającego systemu ................................................................................ 312 Podsumowanie ..................................................................................................................... 314 Zalecane lektury ................................................................................................................... 314 Spis treści 7 Rozdział 10. O projektowaniu .................................................................................317 Natura projektowania oprogramowania ............................................................................... 317 Rozwiązywanie problemów dotyczących jądra ................................................................... 318 Określmy ramy problemu .................................................................................................... 319 Rozwiązywanie problemów odkrywczych ........................................................................... 322 Historia o zarządzaniu dzieloną informacją ................................................................... 322 Historia o złożoności problemu komunikacji ................................................................. 324 Historia o problemie projektowym, którego nie dało się uprościć ................................. 325 Czy problemy odkrywcze mogą być złośliwe? .............................................................. 326 Strategie rozwiązywania problemów odkrywczych ............................................................. 327 Przeformułowanie problemu .......................................................................................... 328 Syntezowanie rozwiązania ............................................................................................. 329 Praca nad resztą problemów ................................................................................................. 330 Projektowanie odpowiedzialne ............................................................................................ 331 Zalecane lektury ................................................................................................................... 334 Dodatek A Bibliografia .........................................................................................335 Skorowidz ..........................................................................................341 Rozdział 2. Projektowanie sterowane odpowiedzialnością Betty Edwards, autorka książki Rysowanie a wewnętrzny artysta, przekonuje, że wielu tak zwanych „kreatywnych” talentów można się nauczyć. Proponuje doskonały ekspe- ryment myślowy: „Czego trzeba, aby nauczyć dziecko czytać? Co by było, gdybyśmy uważali, że tylko niektórzy, szczęśliwie obdarowani przez naturę, posiadają «kreatywną» zdolność czytania? Gdyby nauczyciele byli przekonani, że najlepszym sposobem nauki jest zarzucić dziec- ko dużą ilością materiałów, poczekać i przekonać się, czy posiadło wrodzony talent do czytania? Gdyby strach przed zduszeniem kreatywnego procesu czytania powstrzymy- wał wszelkie próby pomocy nowym czytelnikom? Gdyby dziecko zapytało, na czym polega czytanie, a nauczyciel odpowiedział: «Spróbuj dowolnej metody, która ci przyj- dzie do głowy. Ciesz się tym, badaj różne możliwości, czytanie to taka frajda!»? Być może okazałoby się, że jedno lub dwoje dzieci w każdej klasie posiada taki rzadki talent i samo potrafi nauczyć się czytać. Ale, oczywiście, taka metoda nauki jest absurdalna! Czytania można się nauczyć. Podobnie jak rysowania”. Książka Betty Edwards zawiera argumenty przeciwko poglą- dowi, że umiejętność rysowania wymaga rzadkiego, „artystycz- nego” talentu oraz że sformalizowana nauka podstawowych technik rysowania hamuje kreatywność. Owych podstawowych technik, podobnie jak technik czytania, można się nauczyć. Nic dziwnego, że wielu z nas nie umie rysować! Nauka ryso- wania polega po prostu na poznaniu podstawowych umiejętności percepcyjnych — nabyciu odpowiedniego sposobu widzenia przedmiotów, który jest wymagany do zrobienia porządnego rysunku. Niniejszy rozdział przedstawia podstawowe czynności związane z projektowaniem sterowanym odpowiedzialnością, a także prezentuje przykłady pracy projektowej. Ponieważ projektowanie obiektowe jest procesem wymagającym wysokiej kreatywności, projektanci powinni wiedzieć, kiedy należy zastosować odpowiednie narzędzia pomagające przedstawić problem konceptualnie lub wymyślić rozwiązanie. Projektowanie obiektowe nie wymaga żadnego rzadkiego, ani specjalnego talentu „projektowego”. Chociaż jest czynnością wymagającą dużej kreatywności, jego podstaw można się łatwo nauczyć. Każdy może stać się adeptem projektowania obiektowego. Wystarczy trochę praktyki i doświadczenia, aby nabyć zdolności widzenia natury problemu projektowego i nauczyć się podstawowych strategii tworzenia akceptowalnych rozwiązań. 52 Projektowanie obiektowe. Role, odpowiedzialność i współpraca W tym rozdziale przedstawimy podstawowe kroki rozwoju aplikacji obiektowych przy użyciu metodologii zwanej projektowaniem sterowanym odpowiedzialnością. Najpierw opisujemy akcje i czynności, za które nasze oprogramowanie powinno być „odpowie- dzialne”. Odpowiedzialność określamy pojęciami, które rozumieją zarówno twórcy, jak i użytkownicy aplikacji. Potem przenosimy naszą uwagę na zaprojektowanie obiektów programistycznych, które implementują wymaganą odpowiedzialność. Proces widzenia, opisywania i projektowania Posiadanie talentu projektowania obiektowego oznacza, że dzięki doświadczeniu, wyrobionej intuicji albo wrodzonej zdolności łatwo potrafimy „wpaść” na rozwiązania, które wymagają od innych wiele wysiłku lub nauki. Szybko udaje nam się dojść do samego sedna problemu i znaleźć sposoby zaprojektowania akceptowalnego rozwiązania. Na początek chcielibyśmy jasno powiedzieć jedną rzecz: chociaż nasza książka przedstawia czynności związane z tworzeniem projektów obiek- towych w sposób liniowy, w praktyce projektowanie bardzo rzadko od- bywa się w określonej z góry kolejności. Procesy związane z tworzeniem projektu są bardzo płynne i zależne od pojawiających się w ich trakcie problemów i pytań; niezależnie od tego, że końcowe rezultaty projekto- wania są bardzo sztywno osadzone w kodzie wynikowym. Nasze moż- liwości opisania tych burzliwych często czynności są ograniczone przez właściwości słowa drukowanego. Projektowanie sterowane odpowiedzialnością jest metodologią nieformalną. Składa się z wielu technik, które wspomagają nasz sposób myślenia o tym, w jaki sposób rozdzielić odpowiedzialność aplikacji pomiędzy obiekty i jak sterować ich zachowaniem. Naszym podstawowym narzędziem jest zdolność abstrahowania — tworzenia obiektów, które reprezentują istotę działającej aplikacji. Nazwa naszej metody projektowej podkreśla znaczenie wątku, który przewija się w każdej czynności: naszego skupienia na odpowiedzialności oprogramowania. Opisuje ona, co nasze obiekty muszą robić, aby spełnić cel swojego istnienia. Nasza praca rozpoczyna się od zebrania wymagań, potem zajmujemy się przybliżonym naszkicowaniem pomy- słów, które następnie uszczegóławiamy, opisujemy i przekształcamy w modele progra- mistyczne. Co zaskakujące, na początku projektowania nie skupiamy się na obiektach. Zamiast nich najważniejsze jest ujęcie w opisie przyszłego systemu różnorodnych punktów widzenia zleceniodawców i użytkowników. W naszych rozwiązaniach musimy wziąć pod uwagę wiele różnych perspektyw. Projektowanie sterowane odpowiedzialnością jest procesem wyjaśniania. Przechodzimy od początkowych wymagań do wstępnych opisów i modeli; od ogólnych opisów do bardziej szczegółowych modeli obiektów; od kandydatów na obiekty do precyzyjnych modeli ich odpowiedzialności i wzorców współpracy. Podczas pracy nigdy nie posuwamy się prostą ścieżką, którą przedstawia rysunek 2.1. Zamiast tego, jak widać na rysunku 2.2, nasza podróż przez projektowanie wypełniona jest zakrętami, nawrotami i wypadami w bok. Kiedy próbujemy stworzyć rozwiązanie projektowe, przechodzimy często pomiędzy różnymi czynnościami, odkrywając różne aspekty problemu. Podchodzimy do niego oportunistycznie — próbujemy wykorzystać nadarzające się okazje. Używamy różnorodnych narzędzi, które pozwalają nam uzyskać Rozdział 2. (cid:139) Projektowanie sterowane odpowiedzialnością 53 Rysunek 2.1. Sztywno i dokładnie zaplanowana praca często kończy się porażką Rysunek 2.2. Ścieżka projektowania sterowanego odpowiedzialnością jest bardzo elastyczna odpowiednią perspektywę, odkryć informacje oraz ukształtować rozwiązania. Nasza praca jest elastyczna i przybiera różne formy. Kolejność naszych czynności oraz przedmiot, na którym się skupiamy, będą się z konieczności wciąż zmieniać (zobacz rysunek 2.3). Planowanie, dodawanie nowych możliwości, określanie celów, charakteryzowanie aplikacji przez prototy- py, tworzenie modelu obiektowego, identyfikowanie trudnych problemów — to tylko niektóre z naszych zadań. Różnią się one swoimi celami, rygorem, przedmiotem, naciskiem, kon- tekstem oraz narzędziami, które do nich stosujemy. Nasza prezentacja czynności projektowych jest liniowa, ponieważ ograniczają nas ramy drukowanych, numerowanych stron. Czytając niniejszą książkę, należy zadawać sobie pytania: „Gdzie mogę wykorzystać tę technikę w pracy nad moim projektem? Jakie narzędzie myślowe byłoby w obecnej chwili najbardziej przydatne?”. Trzeba wykorzystywać okazje! Rysunek 2.3. Wciąż przenosimy naszą uwagę z jednego obszaru projektu na inny, przekształcając nasze wizje i odkrywając nowe szczegóły 54 Projektowanie obiektowe. Role, odpowiedzialność i współpraca Nawet przy stosunkowo prostych projektach programistycznych nie możemy przewi- dzieć wszystkich problemów, pojawiających się w trakcie. Przy takiej złożoności pro- jektów nie wszystkie nasze decyzje będą optymalne. Nasze postępy nie będą jednostajne. W czasie pracy odkrywamy nowe informacje i ograniczenia. Musimy poświecić trochę czasu, aby cofnąć się i „wygładzić” narastające niespójności. Marvin Minsky powiada, że ludzka inteligencja sprowadza się do zdolności negocjowania rozwiązań i rozstrzygania konfliktów pomiędzy sprzecznymi celami. Jeżeli jedna część naszego umysłu proponuje rozwiązanie, a inna twierdzi, że nie jest ono akceptowalne, zwykle potrafimy znaleźć inny sposób. Jeżeli nie możemy dostrzec rozwiązania, po prostu szukamy lepszej perspektywy. Aby skompensować niedostatki naszej zdolności przewidywania pro- blemów i zagrożeń, planujemy przerwy na ponowne przeglądanie, po- prawianie i dostosowywanie naszego projektu do zmieniającego się zbioru warunków i ograniczeń. Pozwala nam to użyć naszej rosnącej wiedzy i pogłębiającego się zrozumienia problemu do poprawienia efektów wcze- śniejszych stadiów rozwoju projektu. Jak wynika z rysunku 2.4, nasz proces jest iteracyjny i przyrostowy. Podczas rozwoju projektu przeno- simy nacisk ze zbierania wymagań i tworzenia specyfikacji na analizę, projektowanie, testowanie i kodowanie. Zawsze możemy jednak powró- cić do poprzednich czynności, aby odkryć nowe aspekty napotkanego problemu. Rysunek 2.4. Odkrywanie nowych aspektów obejmuje powstanie pomysłu, przedstawienie go zleceniodawcy w celu uzyskania sprzężenia zwrotnego oraz wprowadzanie zmian i nowych informacji do poprawionego modelu Rozdział 2. (cid:139) Projektowanie sterowane odpowiedzialnością 55 Jako projektanci mamy naturalne przekonanie, że obiekty stanowią centrum programi- stycznego wszechświata. Jednakże nasza „obiektowość” nie może przesłaniać nam faktu, że w wymyślaniu, projektowaniu i konstruowaniu udanej aplikacji biorą udział również inni uczestnicy i perspektywy. Podobnie jak na przykład przedstawienie w teatrze, pro- dukcja oprogramowania wymaga znacznie więcej, niż widać w końcowym efekcie. I chociaż w naszej pracy obiekty mogą odgrywać główną rolę, ważne jest również, aby brać pod uwagę wpływ innych perspektyw i czynności na nasz projekt. Uruchamianie produkcji — definicja i planowanie Zastosujemy tradycyjne podejście do opisywania procesu projektowania obiektowego. Zacznijmy od początku. Zanim skoczymy na głęboką wodę, należy najpierw zdefinio- wać cele projektu, skonstruować plan ich osiągnięcia oraz zapewnić dla nich akceptację zleceniodawcy. W długich lub złożonych projektach musimy przedyskutować i udokumentować wyma- gania użytkowników oraz zademonstrować, jak nasz system będzie służył tym, którzy za niego zapłacą. Musimy pamiętać, że nasz sukces lub porażka najmocniej odbiją się na naszych zleceniodawcach. Nawet przy niewielkich projektach trochę planowania nigdy nie zaszkodzi. Dzięki niemu uzyskujemy zwarte przedstawienie projektu, które składa się z określenia zamiarów, ogólnego opisu rozwiązania oraz definicji celów i korzyści. Planowanie projektu przygotowuje scenę dla rozwoju naszych pomysłów. Jest scenariu- szem naszego działania. Musimy pamiętać, że naszym głównym celem jest zadowolenie użytkowników i zleceniodawców. Plan projektu zawiera opis następujących zagadnień: (cid:141) Jak będziemy tworzyć oprogramowanie? (cid:141) Wartości, które są ważne dla projektu i ludzi weń zaangażowanych. (cid:141) Ludzie, ich role, procesy i oczekiwane wyniki. (cid:141) Oczekiwana postać końcowa produktu. Planowanie i definiowanie projektu są fundamentalnymi czyn- nościami, ale nie są przedmiotem tej książki. Mając plan czyn- ności, możemy zająć się strukturami i procesami. Naszym celem jest zrozumienie, co powinno robić nasze oprogramo- wanie oraz jak będzie wspomagać swoich użytkowników. Przygotowanie sceny — wstępny opis „Jest to w dużym stopniu kwestia artystyczna. Twórca projektu działa podobnie jak starożytny bard, którego epickie poematy nie były zapisywane, lecz recytowane z pamięci. Musi wybierać struktury, które łatwo zapamiętać, dzięki czemu publiczność nie zgubi głównego wątku opowieści”. Michael Jackson Początkowo staramy się zawęzić pole działania i uszczegółowić nasze opisy. Zaczynamy od niedokładnych szkiców, oszukujemy w obszarach wymagających szczegółów, których nie potrafimy jeszcze określić. Powtarzamy cykle odkrywania, refleksji i opisywania. Krok po kroku dodajemy szczegóły, wyjaśniamy nieścisłości i rozstrzygamy sprzeczności między wymaganiami. Początkowo nasze opisy nie mówią nic o obiektach. Perspektywę obiektową dodajemy dopiero po ogólnym opisaniu całego systemu. Pojęcia obiektowe 56 Projektowanie obiektowe. Role, odpowiedzialność i współpraca będą stanowić jądro modelu wewnętrznych składników naszego systemu. Naszą receptę na analizę systemu stanowi tabela 2.1. Tabela 2.1. Analiza zawiera definicję systemu, jego opis oraz czynności związane z analizą obiektową Analiza sterowana odpowiedzialnością Faza Definicja systemu Czynność Tworzenie wysokopoziomowej architektury systemu Identyfikacja początkowych pojęć w systemie Identyfikacja odpowiedzialności systemu Szczegółowy opis Specyfikacja środowiska rozwojowego Tworzenie tekstowych opisów sposobów, w jakie użytkownicy chcieliby wykonywać swoje zadania Analiza specjalnych wymagań, które mają wpływ na projekt Dokumentacja dynamiki systemu Ukazanie ekranów aplikacji i interakcji z perspektywy użytkownika Identyfikowanie obiektów dziedzinowych oraz ich intuicyjnych zakresów odpowiedzialności Dokumentowanie dodatkowych pojęć i terminów Analiza obiektowa Rezultaty Diagram granic systemu Diagramy wysokiego poziomu architektury technicznej Opisy i diagramy pojęć w systemie Słownik pojęć Perspektywa i funkcje systemu Charakterystyki użytkowania Ogólne ograniczenia, założenia i zależności Dokumentacja istniejących schematów rozwojowych, programów zewnętrznych, API oraz narzędzi komputerowych Lista aktorów — różnych typów użytkowników oraz systemów zewnętrznych, które mają kontakt z naszym systemem Opisy przypadków użycia — niesformalizowane, tekstowe opisy zadań użytkowników Scenariusze i konwersacje — bardziej szczegółowe i formalne opisy konkretnych przykładów użycia Strategie zwiększania wydajności, korzystania z danych wcześniejszych systemów, planowanie obsługi rozproszonych danych i przetwarzania, odporności na błędy, niezawodności Diagramy aktywności pokazujące ograniczenia pomiędzy przypadkami użycia Specyfikacje ekranów Model nawigacji Karty CRC, opisujące role i odpowiedzialność obiektów Wstępny model obiektowy Słowniki definiujące koncepcje, opisy zachowania i reguły biznesowe Oczywiście, w każdym projekcie rezultaty mogą być trochę inne. W zależności od spe- cyfiki systemu niektóre dokumenty mogą nie być zbyt przydatne. Na przykład jeżeli tworzymy aplikację, która nie obsługuje pracy interaktywnej z użytkownikami, możemy pominąć projekty ekranów. Aby zaprojektować odpowiedzialność, skupiamy się na tych opisach, które dają nam wartościowe perspektywy. Niektóre wymagania odkrywamy już podczas dyskusji ze zleceniodawcami. Odpowiadają one z grubsza wymaganiom Rozdział 2. (cid:139) Projektowanie sterowane odpowiedzialnością 57 użytkowników, ale obejmują również pewną liczbę wymagań klienckich oraz admini- stracyjnych: (cid:141) Użyteczność (cid:141) Wydajność (cid:141) Konfigurowalność (cid:141) Autoryzacja użytkowników (cid:141) Współbieżność (cid:141) Skalowalność (cid:141) Bezpieczeństwo (cid:141) Niezawodność Czasem tego typu wymagania wychodzą na jaw dopiero podczas rozwoju lub nawet wstępnego użytkowania systemu przez programistów, testerów i użytkowników wersji beta. Wiele wymagań i aspektów często nakłada się na siebie, ale różni zleceniodawcy przedstawiają je w różnej formie. Bezpieczeństwo może stanowić najważniejszy aspekt aplikacji dla użytkowników, którzy nie chcą, by „dane o kartach kredytowych wycie- kały do Internetu”, ale nie są to wymagania równie szczegółowe, jak te, które przedstawia ekspertowi od bezpieczeństwa internetowego administrator serwisu WWW. Oprócz tych oczywistych wymagań, które mają mierzalny i bezpośredni wpływ na pro- jekt, dodatkowe wymagania elastyczności, łatwości konserwowania, rozszerzania czy ponownego używania komponentów mogą ograniczać akceptowalne rozwiązania, cho- ciaż nie widać ich zwykle z perspektywy interakcji użytkownika z aplikacją. W wielu przypadkach jednak to właśnie te cechy, jeżeli będziemy je ignorować, mogą prowadzić do niepowodzenia projektu. Jako projektanci powinniśmy ze zbioru wymagań stworzyć projekt, który jest z nimi zgodny. Jednak musimy być przygotowani na to, że niezależnie od naszych starań, i tak nie uda nam się od razu zidentyfikować wszystkich wymagań. Przystępujemy do produkcji — projekt Projektując, konstruujemy model pracy naszego systemu. Proces projektowania obiek- towego możemy rozbić na dwie główne fazy: tworzenie początkowego projektu (praca badawcza opisana w tabeli 2.2), a następnie konstruowanie bardziej szczegółowych rozwiązań (uściślanie pokazane w tabeli 2.3). Tabela 2.2. Projektowanie badawcze koncentruje się na stworzeniu początkowego modelu obiektowego systemu Projektowanie badawcze Czynność Połączenie obiektów dziedzinowych ze sterującymi Przypisanie zakresów odpowiedzialności do obiektów Rozwój początkowego modelu współpracy Rezultaty Zbiór kart CRC modelujących obiekty, role, odpowiedzialność i współpracę Diagramy sekwencji lub współpracy Opisy odpowiedzialności i współpracy podsystemów Początkowe definicje klas Działające prototypy 58 Projektowanie obiektowe. Role, odpowiedzialność i współpraca Tabela 2.3. Uściślanie projektu obejmuje czynności, dzięki którym projekt staje się bardziej przewidywalny, spójny, elastyczny i zrozumiały Uściślanie projektu Czynność Uzasadnianie kompromisów Rozłożenie sterowania aplikacją Określenie statycznej i dynamicznej relacji widzialności pomiędzy obiektami Poprawianie modelu w celu ułatwienia konserwacji, zwiększenia elastyczności i spójności Jasne udokumentowanie projektu Formalizacja projektu Rezultaty Dokumentacja decyzji projektowych Zidentyfikowane style sterowania Łatwe do zrozumienia wzorce podejmowania decyzji i delegowania zadań w modelu obiektowym Poprawione definicje i diagramy klas Stworzenie nowych abstrakcji obiektowych Poprawione role obiektów, obejmujące mieszanki stereotypów Uproszczone, spójne interfejsy i wzorce współpracy Specyfikacje klas implementujących poszczególne role Zastosowanie wzorców projektowych Diagramy UML opisujące pakiety, komponenty, podsystemy, klasy, sekwencje interakcji, współpracę, interfejsy Kod Kontrakty pomiędzy komponentami systemu oraz kluczowymi klasami Ilość czasu, który poświęcamy na badanie alternatyw oraz poprawianie projektu, a także objętość dokumentacji, którą możemy stworzyć, zależy w dużym stopniu od problemu. Radzimy skupić się na tych czynnościach, które wnoszą wymierny wkład do projektu. Nie musimy koniecznie wykonać każdej z wymienianych tutaj czynności. Także produkowanie stosów dokumentów projektowych nie jest gwarancją sukcesu. Przedstawione tutaj czynności oraz uzyskiwane rezultaty należy traktować jako ogólny przewodnik i dostosować je do własnych potrzeb. W pewnym momencie dochodzimy do punktu, w którym gotowy jest początkowy projekt badawczy i chcielibyśmy zakończyć projektowanie, a rozpocząć programowanie. Może się tak zdarzyć nawet po stosunkowo krótkim czasie, szczególnie gdy projekt jest prosty i wiemy, jak go wy- konać. Czasem chcemy dowieść poprawności jakiejś jego części przez implementację prototypu, zanim zainwestujemy czas i energię w pro- jektowanie pozostałych podsystemów, które zależą od tego, czy nasze rozwiązanie się sprawdzi. Może być i odwrotnie, zanim zaczniemy im- plementację, zechcemy wprowadzić poprawki do naszego projektu. Nie- zależnie od tego, czy poświęcimy więcej czasu na doskonalenie projektu, czy też będziemy go poprawiać równolegle z implementowaniem, nasze początkowe pomysły projektowe z pewnością się zmienią. Większość aplikacji jest zbyt złożona, aby za pierwszym razem stworzyć „prawi- dłowy” projekt. Tak więc tworzenie działającego rozwiązania oznacza częste powracanie do początkowych założeń, aby upewnić się, że system kształtuje się zgodnie z oczekiwaniami zleceniodawców. Może też ozna- czać, że potrzebujemy dodatkowego czasu na zaprojektowanie elastycznego rozwiąza- nia albo wprowadzenie obsługi warunków wyjątkowych. Czynności projektowe — od początkowych badań po szczegółowe uściślenia — stanowią główny temat tej książki. Ale zanim zagłębimy się w projektowanie, wyjaśnijmy, co powinniśmy „wyraźnie widzieć”, aby stworzyć odpowiedni projekt. Rozdział 2. (cid:139) Projektowanie sterowane odpowiedzialnością 59 „Widzenie” z wielu perspektyw Każdy zleceniodawca i użytkownik w naszym procesie pro- jektowym ma różne potrzeby i priorytety. Każda osoba będzie patrzeć na nasze postępy i powstającą aplikację z własnej, unikalnej perspektywy. Ponieważ większość zleceniodawców nie mówi naszym ojczystym, „obiektowym” językiem, przed projektantami stają dwa wyzwania: (cid:141) Jak poprawnie zinterpretować wymagania zleceniodawców i ich priorytety? (cid:141) Jak przedstawiać nasze projekty w sposób zrozumiały dla osób bez wykształcenia informatycznego? „Fakty są dla naukowców jak powietrze. Bez niego nie potrafią latać”. Iwan Pawłow Każdy uczestnik procesu produkcji oprogramowania ma inne kryteria oceniania naszych osiągnięć. Różne punkty widzenia wpływają na zróżnicowanie priorytetów i aspektów, które są istotne dla różnych osób. Na przykład przyszli użytkownicy chcą zobaczyć, czy aplikacja ułatwi im wykonywanie swoich zadań. Chcą, by sterowanie i przetwarzanie aplikacji było spójne i „naturalne”. Analityk biznesowy będzie wolał upewnić się, że zespół rozwojowy prawidłowo rozu- mie i potrafi zaimplementować wszystkie reguły i procesy logiki biznesowej. Tester chce sprawdzić, czy aplikacja spełnia wszystkie wymagania oraz, między innymi, zakładane cele wydajnościowe. Niektórzy zleceniodawcy interesują się czasem szczegółami i jakością naszego projektu, ale większość zwykle tego nie robi. Wszyscy będą żądali zapewnień, że nasz projekt odpowiada ich potrzebom i priorytetom. Zróbmy zatem szybki przegląd całego procesu, aby zobaczyć, jak stworzyć projekt odpowiadający specyficznym potrze- bom naszych zleceniodawców. Pisanie scenariusza — analiza opisów W początkowej fazie procesu naszym podstawowym celem jest zrozumieć najważniejsze wymagania i dać temu wyraz. Prze- kształcamy mgliste, twórcze pomysły w specyfikacje tego, co mamy zbudować. Błędy w specyfikacji produktu są najbardziej kosztowne, bo rzutują na wszystkie późniejsze czynności. Jest więc bardzo ważne, aby komunikować charakterystyki naszego oprogramowania przy użyciu prostego, jednoznacznego języka tym osobom, które będą go używać oraz kon- serwować. Aby zrozumieć, jak nasz system dopasowuje się do bezpośredniego środowiska, w którym będzie uruchamiany, a także jak komunikuje się z nieco szerszym sąsiedztwem zewnętrznych urządzeń, baz danych czy innych programów, używamy różnych perspek- tyw, które ilustruje rysunek 2.5. „Nie ma sensu mówić o czymś precyzyjnie, jeżeli nawet nie wiemy, o czym mówimy”. John von Neumann 60 Projektowanie obiektowe. Role, odpowiedzialność i współpraca Rysunek 2.5. Zleceniodawcy widzą i opisują system ze swoich unikalnych punktów widzenia „Opisy są widocznym medium przekazywania myśli”. Michael Jackson Jakim językiem powinniśmy opisywać nasz system? Nie istnieje jeden język, wspólny dla użytkowników, klientów, analityków danych, pro- jektantów, programistów i menedżerów, którym moglibyśmy odpo- wiednio opisać nasze oprogramowanie. Zbieramy cały wachlarz opisów, używając różnych języków i notacji. Naszym celem jest wyjaśnienie tego, co niejasne oraz zebranie i opisanie jednym głosem tego, za co ma być odpowiedzialne nasze opro- gramowanie. Gromadzimy różne opisy i wprowadzamy uwidocznione w nich aspekty do naszych specyfikacji. Staramy się zrozumieć, gdzie nasz system powinien się „koń- czyć”, gdzie „zaczyna” się jego środowisko zewnętrzne oraz jakie funkcje powinien wykonywać. Kiedy już nakreślimy te granice, skupiamy się na wewnętrznych szczegó- łach naszego oprogramowania oraz sposobach jego komunikacji ze środowiskiem. Rozwijamy spójny, wspólny słownik pojęć i używamy go konsekwentnie do opisywa- nia zleceniodawcom przedmiotów, które mają związek z naszym systemem, procesów, które wspiera oraz zakresów odpowiedzialności, które implementuje. Opisy użytkowania Ponieważ wiele wymagań do aplikacji pochodzi od jej przyszłych użytkowników, muszą oni prawidłowo je rozumieć. Z punktu widzenia użytkownika istnieje wokół naszego systemu granica, która oddziela nasze oprogramowanie od świata ze- wnętrznego. Użytkownicy postrzegają system głównie w aspekcie wspie- rania przezeń ich pracy. Takie zadaniowe spojrzenie może być opisane przez zbiór przypadków użycia. Są one częścią modelu w języku UML. Rozbijamy specyfikację wielkiej aplikacji na przypadki użycia, które w zwarty sposób opisują oddzielne „kawałki” funkcjonalności z zewnętrz- nej perspektywy. Przypadki użycia oraz zorientowanie projektu na potrzeby użytkownika są ważne, ale nie obejmują całego systemu. Model jest zbiorem powiązanych opisów. Istnieją różne typy modeli — użytkowania, danych, obiektów, stanów, procesów i wiele innych. Rozdział 2. (cid:139) Projektowanie sterowane odpowiedzialnością 61 Aktorzy i ich spojrzenie na nasz system Język UML definiuje aktora jako kogoś lub coś, co jest na zewnątrz systemu i wchodzi w interakcje z nim. Aktorów możemy podzielić na trzy najważniejsze grupy: (cid:141) użytkowników, (cid:141) administratorów, (cid:141) programy i urządzenia zewnętrzne. Wszyscy aktorzy ma dwie wspólne cechy: (cid:141) są na zewnątrz aplikacji, (cid:141) mają inicjatywę, powodują zdarzenia lub wchodzą w interakcje z naszym systemem. Organizując opisy użytkowania wokół aktorów, sprawiamy, że zakresy odpowiedzialności naszego oprogramowania zorien- towane są na punkty widzenia każdego aktora. W później- szych krokach będziemy rozwijać projekt na podstawie tych opisów oraz mając na uwadze pożądane cechy systemu. Ale w obecnym stadium rozwoju potrzebujemy innych, bardziej abstrakcyjnych opisów, aby stworzyć pojedynczy, spójny model obiektowy. Potrzebujemy opisów bogatych w szczegóły, intencje, implikacje i cele. Model obiektowy jedynie proponuje rozwią- zanie problemu. Przemilcza ono codzienne potrzeby, intencje i priorytety zleceniodawców i użytkowników. Obiekty najlepiej opisują pojęcia i przedmioty, ich charakterystyki, odpowiedzialności i interakcje. Jeżeli oczekujemy od naszego oprogramowania jakiejś cechy, nasze potrzeby muszą być udokumentowane w którymś z opisów. Pożądane cechy nie pojawiają się „same z siebie”. Bogate i szczegółowe opisy, których potrzebujemy, powinny przedstawiać funkcjonalność, punkty zmienności i konfiguracji oraz podstawy architektury systemu. Identyfikujemy grupy ludzi oraz programy i urządzenia zewnętrzne, z którymi komunikuje się nasza aplikacja i opisujemy sposoby tych interakcji. Notujemy, gdzie są obszary wymagające elastyczności oraz na jaką zmienność warunków powinna być przygotowana aplikacja. Najlepiej, jak potrafimy, staramy się, by nasza dokumentacja była zrozumiała dla tych, którzy potrzebują tej wiedzy. Jeżeli na tym etapie budujemy jakieś modele obiektowe albo prototypy kodu, to tylko by pogłębić własne zrozumienie niektórych wymagań. Stworzone teraz prototypy są zwykle później porzucane. Przypadki użycia Przypadki użycia, opisane w 1992 roku przez Ivara Jacobsona, są częścią języka UML. Wiele osób używa ich jako narzędzia opisu, jak będzie użytkowany przyszły system. Innym „do szczęścia” wystarcza hierarchiczna lista funkcji systemu, proste historie użytkowników lub długie dokumenty specyfikacyjne. Przypadki użycia są szczególnie cenne, ponieważ pozwalają uchwycić działanie aplikacji z zewnętrznej perspektywy użytkownika. Używamy trzech form opisów przypadków użycia: proste teksty, zwane narracjami (ang. narrative), scenariusze (ang. scenario) składające się z numerowanych kroków oraz konwersacje (ang. conversation) eksponujące dialog między użytkownikiem a systemem. Każda forma opisu przypadków użycia kładzie nacisk na inny ich aspekt. Przypadek użycia to „powiązana zachowaniem sekwencja transakcji w dialogu z systemem”. Ivar Jacobson 62 Projektowanie obiektowe. Role, odpowiedzialność i współpraca Przypadki użycia mogą różnić się poziomem szczegółowości, w zależności od tego, dla kogo są przeznaczone. Możemy rozpocząć od bardzo ogólnego opisu, a następnie wzbogać go w szczegóły i opisywać sekwencje czynności i interakcji pomiędzy użytkownikiem a systemem. Forma, którą wybierzemy, zależy od tego, co próbujemy przekazać. Możemy też połączyć więcej niż jedną formę w opisie przypadku użycia w zależności od potrzeb naszych odbiorców. Zwykle zaczynamy od opisu narracyjnego, który prezentuje ogólny przegląd przypadku użycia. Następnie, w razie potrzeby, możemy go wzbogacić w dowolną liczbę scenariuszy i konwersacji, które uszczegółowią ogólny obraz. Przykład edytora tekstu Rozważmy przypadki użycia, które potrzebne nam były do napisania niniejszego roz- działu. Pisanie książek nie jest główną funkcją edytora tekstu, którego używamy. Jest to ogólne narzędzie do przygotowywania dokumentów. Korzystając z niego, musimy do- stosowywać nasze czynności do zadań, które wspomaga: wprowadzania i poprawiania tekstu. Brakuje mu innych funkcji, które przydatne byłyby przy pisaniu książki: prowa- dzenie badań, burze mózgów, tworzenie streszczeń i schematów. Zadania, które można znaleźć wśród funkcjonalności edytora tekstu, to otwieranie dokumentu, pisanie i reda- gowanie tekstu. Naszym celem jest przedstawienie zadań użytkowników jak najbardziej opisowo. Funkcje systemu, które w ogólnym opisie mogą się wydawać bardzo proste, stają się często długą serią decyzji i czynności, podejmowanych przez użytkownika. Pisanie to czynność dość swobodna. Łączymy i mieszamy zadania pisar- skie w nieprzewidywalnej kolejności. Ponieważ edytor tekstu ma wspo- magać szeroką gamę stylów pisania, jego funkcje najlepiej opisać za pomocą niewielkich przypadków użycia, które mogą być wykonywane w dowolnej kolejności. Ale zadania przydatne podczas pisania książki są większe; składają się z wielu podzadań. Formatowanie strony jest serią zmian marginesów, wcięć, nagłówków, stopek i tak dalej. Reorganizo- wanie sekwencji akapitów jest serią operacji „wytnij” i „wklej”. Nada- jemy nazwy przypadkom użycia i opisujemy je z punktu widzenia użyt- kownika — na przykład „Redaguj tekst”, „Zapisz dokument do pliku” czy „Wyszukaj w pomocy kontekstowej”. Zauważmy, że w naszych przykładach nazwy przyjmują zwykle formę „Wykonaj czynność na obiekcie”. Oto narracyjne przedstawienie przypad- ku użycia, który dotyczy zapisywania dokumentu: Dokumenty można zapisywać w różnych formatach plików. Kiedy zapisujemy nowy dokument, używany jest domyślny format pliku, chyba że użytkownik wybierze inny. Po zakończeniu operacji „Zapisz dokument” plik reprezentuje dokument dokładnie w takiej formie, w jakiej był przedstawiony użytkownikowi w momencie wykonania operacji. Punkt widzenia systemu ważny jest zwykle tylko dla twórców aplikacji. Użytkownikom mówi niewiele. Pisząc przypadki użycia, powinniśmy trzymać się perspektywy użytkownika. Inną alternatywą jest nazywanie i opisywanie przypadków z punktu wi- dzenia naszego edytora tekstu. Operacja „Otwórz dokument” mogłaby zostać opisana jako „Otwórz plik i wczytaj go do bufora tekstowego”. Nie zalecamy jednak przyjmowania perspektywy systemowej. Nie jest ona naturalna dla użytkowników i powoduje dziwne wrażenie, jakby to system patrzył na użytkownika z wnętrza komputera i opisywał, co za- mierza zrobić. Rozdział 2. (cid:139) Projektowanie sterowane odpowiedzialnością 63 Przypadki użycia dla naszego edytora tekstu opisują raczej niewielkie fragmenty funkcjo- nalności. Praktyczna zasada jest taka, że przypadki użycia powinny obejmować takie zakresy, jakie najbardziej odpowiadają użytkownikowi. Poziom szczegółowości również może się zmieniać. Użytkownicy mogą zadowolić się kilkoma ogólnymi zdaniami albo wymagać opisania najdrobniejszych szczegółów, zależy to również od tego, jaka jest ich znajomość opisywanego procesu i jak bardzo jest on złożony. Mimo tych wszyst- kich różnic w poziomie abstrakcji i szczegółowości, narracyjne przypadki użycia mają jedną wspólną cechę: opisują ogólne możliwości aplikacji w jednym lub dwóch akapitach, posługując się przy tym zwykłym językiem. Scenariusze Przedstawione wcześniej narracyjne przypadki użycia opisują ogólne możliwości apli- kacji, natomiast scenariusze prezentują konkretne ścieżki, które prowadzą użytkownika do wykonania zadania. Pojedynczy przypadek użycia może zostać wykonany na bardzo wiele sposobów. Poniższy scenariusz, „Zapisz dokument do pliku HTML” pokazuje, czym różni się ta operacja od swojego „rodzica”, narracyjnego przypadku użycia „Za- pisz dokument do pliku”: Scenariusz: Zapisz dokument do pliku HTML 1. Użytkownik wydaje polecenie zapisu do pliku. 2. Program wyświetla okno dialogowe „Zapis pliku”, gdzie użytkownik może oglądać i modyfikować katalog, nazwę pliku i typ dokumentu. 3. Jeżeli plik jest zapisywany po raz pierwszy i użytkownik nie nadał mu nazwy, jest ona konstruowana na podstawie pierwszego wiersza tekstu w dokumencie oraz domyślnego rozszerzenia pliku. 4. Użytkownik wybiera typ dokumentu HTML w opcjach okna dialogowego, co powoduje zmianę rozszerzenia pliku na „.htm” w razie potrzeby. 5. Użytkownik może zmienić nazwę pliku i katalog. 6. Użytkownik wydaje programowi polecenie zakończenia zapisu do pliku. 7. Program wyświetla ostrzeżenie, że zapis do pliku w formacie HTML może spowodować utratę części informacji o formatowaniu tekstu. Użytkownik może wybrać porzucenie lub kontynuowanie operacji zapisu. 8. Użytkownik wybiera kontynuację zapisywania dokumentu w formacie HTML. 9. Program zapisuje dokument i wyświetla tekst przeformatowany na nowo. Niektóre informacje o formatowaniu tekstu, na przykład wyliczenia, wcięcia, użyte czcionki, mogą zostać zmienione w stosunku do stanu przed zapisem. Jeżeli potrzebujemy bardziej konkretnego i szczegółowego wyjaśnienia, jak powinna być wykonywana dana funkcja, tworzymy scenariusze opisujące czynności i informacje dotyczące specyficznych sytuacji. Jeszcze większy poziom szczegółowości oraz nacisk na interakcje między użytkownikiem a systemem pozwalają ująć nam konwersacje. 64 Projektowanie obiektowe. Role, odpowiedzialność i współpraca Konwersacje Konwersacje przedstawiają interakcje pomiędzy użytkownikiem a systemem w formie dialogu. Ich celem jest określenie zakresu odpowiedzialności obu stron: użytkownika, który inicjuje dialog, oraz programu, który monitoruje i odpowiada na czynności wyko- nywane przez użytkownika. Bardzo szczegółowa forma konwersacji pozwala nam jasno przedstawić odpowiedzi aplikacji na czynności użytkownika. Każda konwersacja składa się z dwóch oddzielnych części: kolumny zawierającej czyn- ności użytkownika i wprowadzane przez nieg
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Projektowanie obiektowe. Role, odpowiedzialność i współpraca
Autor:
,

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: