Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00519 006705 13590103 na godz. na dobę w sumie
Analiza i projektowanie obiektowe. Rusz głową! - książka
Analiza i projektowanie obiektowe. Rusz głową! - książka
Autor: , , Liczba stron: 624
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-2802-5 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> techniki programowania
Porównaj ceny (książka, ebook, audiobook).

Współczesne systemy informatyczne mają niewiele wspólnego z tymi sprzed kilkunastu lat. Są skomplikowane, nafaszerowane wieloma technologiami, bywa też, że mają (zbyt) wielu autorów. Jak zapanować nad tym wszystkim? Jak projektować systemy szybko oraz bezbłędnie? Czujesz się zagubiony? Nic się nie martw! Po prostu...

Otwórz swój umysł! Teraz dzięki nowatorskim metodom nauczania możesz błyskawicznie opanować wszystkie elementy projektowania obiektowego. Charakterystyczna dla serii 'Rusz głową!' cecha to wymieszana w odpowiednich proporcjach wiedza, humor oraz wszystko wyjaśniające grafiki. Informacje zawarte w książce obejmują pełny zakres tematyki związanej z analizą i projektowaniem obiektowym. Tylko kilkaset stron dzieli Cię od opanowania metod zbierania wymagań, tworzenia przypadków użycia czy też projektowania diagramów klas. A to tylko początek - sprawdź spis treści i przekonaj się, jak szeroki materiał zawiera ta książka.

Naprzód, głowo!

Nikt ci tego nie potrafił wytłumaczyć? Wydaje Ci się, że to problem nie na Twoją głowę? Nie potrzebujesz elektrowstrząsów, żeby pobudzić swój mózg do aktywnego działania. Tylko żadnych gwałtownych gestów! Usiądź wygodnie, otwórz książkę, dopiero teraz się zacznie. Na początek - rusz głową!

Precz z nudnymi wykładami i zakuwaniem bez zrozumienia!

Nauka to znacznie więcej niż tylko czytanie suchego tekstu. Twój mózg jest niczym głodny rekin, cały czas prący naprzód w poszukiwaniu nowej, apetycznej przekąski.

Jak karmimy Twój wygłodniały umysł?

Używamy rysunków, bo obraz wart jest 1024 słów. Stosujemy powtórzenia, by zakodować na stałe dane w Twojej chłonnej głowie. Oddziałujemy na emocje, jesteśmy nieprzewidywalni, zaskakujący i zabawni. Stawiamy przed Tobą wyzwania i zadajemy pytania, które angażują Cię w proces studiowania przedstawianych zagadnień. Cały czas pobudzamy Twój umysł do aktywnego działania, zmuszamy go do posłuszeństwa... a za ciężką pracę nagrodzimy go smakowitym ciasteczkiem w postaci wiedzy - wisienka gratis!

Rozgryź to sam!

Książka należy serii 'Rusz głową!', która jest kontynuacją serii 'Head First'. Książki z tej serii zdobyły uznanie czytelników dzięki swemu unikalnemu i nowatorskiemu podejściu do przekazywania wiedzy. Sprawdź na półce, może znajdziesz obok inne książki z tej serii. Dzięki nim nawet najbardziej skomplikowane dziedziny wiedzy stają się przystępne, przyjazne i prostsze.

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

Darmowy fragment publikacji:

Idź do • Spis treści • Przykładowy rozdział Katalog książek • Katalog online • Zamów drukowany katalog Twój koszyk • Dodaj do koszyka Cennik i informacje • Zamów informacje o nowościach • Zamów cennik Czytelnia • Fragmenty książek online Kontakt Helion SA ul. Kościuszki 1c 44-100 Gliwice tel. 32 230 98 63 e-mail: helion@helion.pl © Helion 1991–2010 Analiza i projektowanie obiektowe. Rusz głową! Autorzy: Brett D. McLaughlin, Gary Pollice, Dave West Tłumaczenie: Piotr Rajca ISBN: 978-83-246-2802-5 Tytuł oryginału: Head First Object-Oriented Analysis and Design Format: 200×230, stron: 624 Współczesne systemy informatyczne mają niewiele wspólnego z tymi sprzed kilkunastu lat. Są skomplikowane, nafaszerowane wieloma technologiami, bywa też, że mają (zbyt) wielu autorów. Jak zapanować nad tym wszystkim? Jak projektować systemy szybko oraz bezbłędnie? Czujesz się zagubiony? Nic się nie martw! Po prostu… Otwórz swój umysł! Teraz dzięki nowatorskim metodom nauczania możesz błyskawicznie opanować wszystkie elementy projektowania obiektowego. Charakterystyczna dla serii „Rusz głową!” cecha to wymieszana w odpowiednich proporcjach wiedza, humor oraz wszystko wyjaśniające grafiki. Informacje zawarte w książce obejmują pełny zakres tematyki związanej z analizą i projektowaniem obiektowym. Tylko kilkaset stron dzieli Cię od opanowania metod zbierania wymagań, tworzenia przypadków użycia czy też projektowania diagramów klas. A to tylko początek – sprawdź spis treści i przekonaj się, jak szeroki materiał zawiera ta książka. Naprzód, głowo! Nikt ci tego nie potrafił wytłumaczyć? Wydaje Ci się, że to problem nie na Twoją głowę? Nie potrzebujesz elektrowstrząsów, żeby pobudzić swój mózg do aktywnego działania. Tylko żadnych gwałtownych gestów! Usiądź wygodnie, otwórz książkę, dopiero teraz się zacznie. Na początek – rusz głową! Precz z nudnymi wykładami i zakuwaniem bez zrozumienia! Nauka to znacznie więcej niż tylko czytanie suchego tekstu. Twój mózg jest niczym głodny rekin, cały czas prący naprzód w poszukiwaniu nowej, apetycznej przekąski. Jak karmimy Twój wygłodniały umysł? Używamy rysunków, bo obraz wart jest 1024 słów. Stosujemy powtórzenia, by zakodować na stałe dane w Twojej chłonnej głowie. Oddziałujemy na emocje, jesteśmy nieprzewidywalni, zaskakujący i zabawni. Stawiamy przed Tobą wyzwania i zadajemy pytania, które angażują Cię w proces studiowania przedstawianych zagadnień. Cały czas pobudzamy Twój umysł do aktywnego działania, zmuszamy go do posłuszeństwa… a za ciężką pracę nagrodzimy go smakowitym ciasteczkiem w postaci wiedzy – wisienka gratis! Rozgryź to sam! • Zasady i cele projektowania obiektowego • Metody zbierania wymagań • Przypadki użycia i ich analiza • Graficzna prezentacja systemu i zasad jego działania – diagramy UML • Wzorce projektowe – sprawy skomplikowane stają się proste, a proste jeszcze prostsze • Projektowanie architektury systemu • Testowanie Spis treści Spis treści (skrócony) 1 Dobrze zaprojektowane aplikacje są super. Tu zaczyna się wspaniałe oprogramowanie 2 Gromadzenie wymagań. Daj im to, czego chcą 3 Wymagania ulegają zmianom. Kocham cię, jesteś doskonały… A teraz — zmień się 4 Analiza. Zaczynamy używać naszych aplikacji w rzeczywistym świecie 5 Część 1. Dobry projekt = elastyczne oprogramowanie. Nic nie pozostaje wiecznie takie samo Przerywnik. Obiektowa katastrofa Część 2. Dobry projekt = elastyczne oprogramowanie. Zabierz swoje oprogramowanie na 30-minutowy trening 6 Rozwiązywanie naprawdę dużych problemów. „Nazywam się Art Vandelay... jestem Architektem” Powtarzanie i testowanie. Oprogramowanie jest wciąż przeznaczone dla klienta 7 Architektura. Porządkowanie chaosu 8 Zasady projektowania. Oryginalność jest przereklamowana 9 10 Proces projektowania i analizy obiektowej. Scalając to wszystko w jedno A Pozostałości B Witamy w Obiektowie Skorowidz 31 83 137 169 221 245 257 301 343 395 441 499 571 589 603 W Spis treści (z prawdziwego zdarzenia) Wprowadzenie Twój mózg koncentruje się na analizie i projektowaniu obiektowym. Podczas gdy Ty starasz się czegoś nauczyć, Twój mózg robi Ci przysługę i dba o to, abyś przez przypadek nie zapamiętał zdobywanych informacji. Myśli sobie: „Lepiej zostawić trochę miejsca na bardziej istotne sprawy, na przykład jakich zwierząt unikać albo czy jazda na snowboardzie nago jest dobrym pomysłem”. W jaki zatem sposób możesz oszukać swój mózg i przekonać go, że Twoje życie zależy od znajomości analizy i projektowania obiektowego? Dla kogo jest ta książka? Wiemy, co sobie myślisz Metapoznanie: myślenie o myśleniu Zmuś swój mózg do posłuszeństwa Ważne uwagi Zespół techniczny Podziękowania 20 21 23 25 26 28 29 5 Spis treści 1 Dobrze zaprojektowane aplikacje są super Tu zaczyna się wspaniałe oprogramowanie A zatem, w jaki sposób w praktyce pisze się wspaniałe oprogramowanie? Zawsze bardzo trudno jest określić, od czego należy zacząć. Czy aplikacja faktycznie robi to, co powinna robić i czego od niej oczekujemy? A co z takimi problemami jak powtarzający się kod — przecież to nie może być dobre ani właściwe rozwiązanie, prawda? Zazwyczaj trudno jest określić, które z wielu problemów należy rozwikłać w pierwszej kolejności, a jednocześnie mieć pewność, że podczas wprowadzania poprawek nie popsujemy innych fragmentów aplikacji. Bez obaw. Po zakończeniu lektury tego rozdziału będziesz już dokładnie wiedział, jak pisać doskonałe oprogramowanie, i pewnie podążał w kierunku trwałego poprawienia sposobu tworzenia programów. I w końcu zrozumiesz, dlaczego OOA D to czteroliterowy skrót (pochodzący od angielskich słów: Object-Oriented Analysis and Design, analiza i projektowanie obiektowe), który Twoja matka chciałaby, byś poznał. Niby skąd mam wiedzieć, od czego należy zacząć? Mam wrażenie, że ilekroć zaczynam pracę nad nowym projektem, każdy ma inne zdanie odnośnie tego, co należy zrobić w pierwszej kolejności. Czasami zrobię coś dobrze, lecz czasami kończy się na tym, że muszę przerobić całą aplikację od początku, bo zacząłem w złym miejscu. A ja chcę jedynie pisać świetne oprogramowanie! A zatem, od czego powinienem zacząć pisanie aplikacji dla Ryśka? Rock-and-roll jest wieczny! Nowa elegancka aplikacja Ryśka… Co przede wszystkim zmieniłbyś w aplikacji Ryśka? Doskonałe oprogramowanie… ma więcej niż jedną z wymienionych już cech Wspaniałe oprogramowanie w trzech prostych krokach W pierwszej kolejności skoncentruj się na funkcjonalności Test Szukamy problemów Analiza metody search() Stosuj proste zasady projektowania obiektowego Projekt po raz pierwszy, projekt po raz drugi Jak łatwo można wprowadzać zmiany w Twojej aplikacji? Poddawaj hermetyzacji to, co się zmienia Delegowanie Nareszcie doskonałe oprogramowanie (jak na razie) OOA D ma na celu tworzenie wspaniałego oprogramowania, a nie dodanie Ci papierkowej roboty Celne spostrzeżenia 32 33 38 42 43 48 53 55 56 61 66 68 71 73 76 79 80 6 Spis treści 2 Gromadzenie wymagań Daj im to, czego chcą Każdy lubi zadowolonych klientów. Już wiesz, że pierwszy krok w pisaniu doskonałego oprogramowania polega na upewnieniu się, czego chce klient. Ale jak się dowiedzieć, czego klient oczekuje? Co więcej — skąd mieć pewność, że klient w ogóle wie, czego tak naprawdę chce? Właśnie wówczas na arenę wkraczają „dobre wymagania”. W tym rozdziale dowiesz się, w jaki sposób zadowolić klientów, upewniając się, że dostarczysz im właśnie to, czego chcą. Kiedy skończysz lekturę, wszystkie swoje projekty będziesz mógł opatrzyć etykietą „Satysfakcja gwarantowana” i posuniesz się o kolejny krok na drodze do tworzenia doskonałego oprogramowania… i to za każdym razem. Nadszedł czas na kolejny pokaz Twych programistycznych umiejętności Test programu Nieprawidłowe zastosowanie (coś w tym stylu) Czym jest wymaganie? Tworzenie listy wymagań Zaplanuj, co może się popsuć w systemie Problemy w działaniu systemu są obsługiwane przez ścieżki alternatywne (Ponowne) przedstawienie przypadku użycia Jeden przypadek użycia, trzy części Porównaj wymagania z przypadkami użycia Twój system musi działać w praktyce Poznajemy Szczęśliwą Ścieżkę Przybornik projektanta 84 87 89 90 92 96 98 100 102 106 113 120 134 Drzwiczki dla psa oraz pilot stanowią elementy systemu, bądź też znajdują się wewnątrz niego. System 7 Spis treści 3 Wymagania ulegają zmianom Kocham cię, jesteś doskonały… A teraz — zmień się Sądzisz, że dowiedziałeś się już wszystkiego o tym, czego chciał klient? Nie tak szybko… A zatem przeprowadziłeś rozmowy z klientem, zgromadziłeś wymagania, napisałeś przypadki użycia, napisałeś i dostarczyłeś klientowi odlotową aplikację. W końcu nadszedł czas na miłego, relaksującego drinka, nieprawdaż? Pewnie… aż do momentu gdy klient uzna, że tak naprawdę chce czegoś innego niż to, co Ci powiedział. Bardzo podoba mu się to, co zrobiłeś — poważnie! — jednak obecnie nie jest już w pełni usatysfakcjonowany. W rzeczywistym świecie wymagania zawsze się zmieniają; to Ty musisz sobie z tymi zmianami poradzić i pomimo nich zadbać o zadowolenie klienta. Jesteś bohaterem! Jesteś patałachem! Jedyny pewnik analizy i projektowania obiektowego Ścieżka oryginalna? Ścieżka alternatywna? Kto to wie? Przypadki użycia muszą być zrozumiałe przede wszystkim dla Ciebie Od startu do mety: jeden scenariusz Wyznanie Ścieżki Alternatywnej Uzupełnienie listy wymagań Powielanie kodu jest bardzo złym pomysłem Ostateczny test drzwiczek Napisz swoją własną zasadę projektową! Przybornik projektanta 138 139 141 146 148 150 152 156 164 166 167 168 public void pressButton() { System.out.println(”Naciśnięto przycisk na pilocie...”); if (door.isOpen()) { door.close(); } else { door.open(); final Timer timer = new Timer(); timer.schedule(new TimerTask() { public void run() { door.close(); timer.cancel(); } }, 5000); } class Remote { press- Button() } Remote.java 8 Spis treści 4 Analiza Zaczynamy używać naszych aplikacji w rzeczywistym świecie Czas zdać ostatnie egzaminy i zacząć stosować nasze aplikacje w rzeczywistym świecie. Twoje aplikacje muszą robić nieco więcej, niż jedynie działać prawidłowo na komputerze, którego używasz do ich tworzenia — komputerze o dużej mocy i doskonale skonfigurowanym; Twoje aplikacje muszą działać w takich warunkach, w jakich rzeczywiści klienci będą ich używali. W tym rozdziale zastanowimy się, jak zyskać pewność, że nasze aplikacje będą działać w rzeczywistym kontekście. Dowiesz się w nim, w jaki sposób analiza tekstowa może przekształcić stworzony wcześniej przypadek użycia w klasy i metody, które na pewno będą działać zgodnie z oczekiwaniami klienta. A kiedy skończysz lekturę tego rozdziału, także i Ty będziesz mógł powiedzieć: „Dokonałem tego! Moje oprogramowanie jest gotowe do zastosowania w rzeczywistym świecie!”. Kiedy już określiłam, jakich klas i operacji będę potrzebować, odpowiednio zaktualizowałam diagram klas. Jeden pies, dwa psy, trzy psy, cztery… Twoje oprogramowanie ma kontekst Określ przyczynę problemu Zaplanuj rozwiązanie Opowieść o dwóch programistach Delegowanie w kodzie Szymka — analiza szczegółowa Potęga aplikacji, których elementy są ze sobą luźno powiązane Zwracaj uwagę na rzeczowniki występujące w przypadku użycia Od dobrej analizy do dobrych klas… Diagramy klas bez tajemnic Diagramy klas to nie wszystko Celne spostrzeżenia 170 171 172 173 180 184 186 191 204 206 211 215 W tym kontekście rzeczy przybierają zły obrót znacznie częściej. class DogDoor { open() } DogDoor.java Rzeczywisty Świat W rzeczywistym świecie spotykamy inne psy, koty, gryzonie oraz całą masę innych problemów; a wszystkie te czynniki mają tylko jeden cel — doprowadzić do awarii naszego oprogramowania. 9 Spis treści 5 (część 1.) Dobry projekt = elastyczne oprogramowanie Nic nie pozostaje wiecznie takie samo Zmiany są nieuniknione. Niezależnie od tego, jak bardzo podoba Ci się Twoje oprogramowanie w jego obecnej postaci, to najprawdopodobniej jutro zostanie ono zmodyfikowane. A im bardziej utrudnisz wprowadzanie modyfikacji w aplikacji, tym trudniej będzie Ci w przyszłości reagować na zmiany potrzeb klienta. W tym rozdziale mamy zamiar odwiedzić naszego starego znajomego oraz spróbować poprawić projekt istniejącego oprogramowania. Na tym przykładzie przekonamy się, jak niewielkie zmiany mogą doprowadzić do poważnych problemów. Prawdę mówiąc, jak się okaże, odkryte przez nas kłopoty będą tak poważne, że ich rozwiązanie będzie wymagało rozdziału składającego się aż z DWÓCH części! 5(przerywnik) Firma Instrumenty Strunowe Ryśka rozwija się Klasy abstrakcyjne Diagramy klas bez tajemnic (ponownie) Ściągawka z UML-a Porady dotyczące problemów projektowych Trzy kroki tworzenia wspaniałego oprogramowania (po raz kolejny) 222 225 230 231 237 239 Spis treści Obiektowa Katastrofa! Najbardziej popularny quiz w Obiektowie Unikanie ryzyka Sławni projektanci Konstrukcje używane w kodzie Utrzymanie i wielokrotne użycie Nerwica oprogramowania $100 $100 $100 $100 $100 $200 $200 $200 $200 $200 $300 $300 $300 $300 $300 $400 $400 $400 $400 $400 10 13 Spis treści 5(część 2.) Dobry projekt = elastyczne oprogramowanie Zabierz swoje oprogramowanie na 30-minutowy trening Czy kiedykolwiek marzyłeś o tym, by być nieco bardziej elastycznym w działaniu? Jeśli kiedykolwiek wpadłeś w kłopoty podczas prób wprowadzania zmian w aplikacji, to zazwyczaj oznacza to, że Twoje oprogramowanie powinno być nieco bardziej elastyczne i odporne. Aby pomóc swojej aplikacji, będziesz musiał przeprowadzić odpowiednią analizę, zastanowić się nad niezbędnymi zmianami w projekcie i dowiedzieć się, w jaki sposób rozluźnić zależności pomiędzy jej elementami. I w końcu, w wielkim finale, przekonasz się, że większa spójność może pomóc w rozwiązaniu problemu powiązań. Brzmi interesująco? A zatem przewróć kartkę — przystępujemy do poprawiania nieelastycznej aplikacji. Wróćmy do aplikacji wyszukiwawczej Ryśka Dokładniejsza analiza metody search() Korzyści, jakie dała nam analiza Dokładniejsza analiza klas instrumentów Śmierć projektu (decyzja) Zmieńmy złe decyzje projektowe na dobre Zastosowanie „podwójnej hermetyzacji” w aplikacji Ryśka Nigdy nie obawiaj się wprowadzania zmian Elastyczna aplikacja Ryśka Testowanie dobrze zaprojektowanej aplikacji Ryśka Jak łatwo można zmodyfikować aplikację Ryśka? Wielki konkurs łatwości modyfikacji Spójna klasa realizuje jedną operację naprawdę dobrze Przegląd zmian wprowadzanych w oprogramowaniu dla Ryśka Doskonałe oprogramowanie to zazwyczaj takie, które jest „wystarczająco dobre” Przybornik projektanta 258 261 262 265 270 271 273 279 282 285 289 290 293 296 298 300 11 Spis treści 6 Rozwiązywanie naprawdę dużych problemów „Nazywam się Art Vandelay… jestem Architektem” Nadszedł czas, by zbudować coś NAPRAWDĘ DUŻEGO. Czy jesteś gotów? Zdobyłeś już wiele narzędzi do swojego projektanckiego przybornika, jednak w jaki sposób z nich skorzystasz, kiedy będziesz musiał napisać coś naprawdę dużego? Cóż, może jeszcze nie zdajesz sobie z tego sprawy, ale dysponujesz wszystkimi narzędziami, jakie mogą być potrzebne do skutecznego rozwiązywania poważnych problemów. Niebawem poznasz kilka nowych narzędzi, takich jak analiza dziedziny oraz diagramy przypadków użycia, jednak nawet one bazują na wiadomościach, które już zdobyłeś, takich jak uważne słuchanie klienta oraz dokładne zrozumienie, co trzeba napisać, zanim jeszcze przystąpimy do faktycznego pisania kodu. Przygotuj się… nadszedł czas, byś sprawdził, jak sobie radzisz w roli architekta. Rozwiązywanie dużych problemów Wszystko zależy od sposobu spojrzenia na duży problem Wymagania i przypadki użycia to dobry punkt wyjściowy… Potrzebujemy znacznie więcej informacji Określanie możliwości Możliwość czy wymaganie Przypadki użycia nie zawsze pomagają ujrzeć ogólny obraz tworzonego oprogramowania Diagramy przypadków użycia Mały aktor Aktorzy to także ludzie (no dobrze… nie zawsze) A zatem zabawmy się w analizę dziedziny! Dziel i rządź Nie zapominaj, kim tak naprawdę jest klient Czym jest wzorzec projektowy? Potęga OOA D (i trochę zdrowego rozsądku) Przybornik projektanta Spis treści 302 303 308 309 312 314 316 318 323 324 329 331 335 337 340 342 12 Spis treści 7 Architektura Porządkowanie chaosu Gdzieś musisz zacząć, jednak uważaj, żeby wybrać właściwe „gdzieś ”! Już wiesz, jak podzielić swoją aplikację na wiele małych problemów, jednak oznacza to tylko i wyłącznie tyle, iż obecnie nie masz jednego dużego, lecz WIELE małych problemów. W tym rozdziale spróbujemy pomóc Ci w określeniu, gdzie należy zacząć, i upewnimy się, że nie będziesz marnował czasu na zajmowanie się nie tym, co trzeba. Nadeszła pora, by pozbierać te wszystkie drobne kawałki na Twoim biurku i zastanowić się, jak można je przekształcić w uporządkowaną i dobrze zaprojektowaną aplikację. W tym czasie poznasz niesłychanie ważne „trzy P dotyczące architektury” i dowiesz się, że Risk to znacznie więcej niż jedynie słynna gra wojenna z lat 80. Czy czujesz się nieco przytłoczony? Potrzebujemy architektury Zacznijmy od funkcjonalności Co ma znaczenie dla architektury Trzy „P” dotyczące architektury Wszystko sprowadza się do problemu ryzyka Scenariusze pomagają zredukować ryzyko Koncentruj się na jednej możliwości w danej chwili Architektura jest strukturą Twojego projektu Podobieństwa po raz kolejny Analiza podobieństw: ścieżka do elastycznego oprogramowania Co to znaczy? Zapytaj klienta Zmniejszanie ryzyka pomaga pisać wspaniałe oprogramowanie Celne spostrzeżenia 344 346 349 351 352 358 361 369 371 375 381 386 391 392 Najmniejszych szans na zdążenie w terminie. Jeden procent szans, by system działał prawidłowo. Jedynie kilka rzeczy może poważnie nawalić. Tak blisko ideału, jak tylko oprogramowanie może być! 13 class Tile { ge- { ge- tUnit() tUnit() } } Tile.java Tile.java Tile.java Board.java Unit type: String properties: Map setType(String) getType(): String setProperty(String, Object) getProperty(String): Object class Unit { Unit { Unit() Unit() } } class Board { ge- Unit.java Unit.java Unit.java tUnit() } r r t t e e m m - - o o k k y y z z y y R R i i k k l l e e i i W W Spis treści Zasada otwarte- -zamknięte Zasada jednej odpowiedzialności 14 8 Zasady projektowania Oryginalność jest przereklamowana Powielanie jest najlepszą formą unikania głupoty. Nic chyba nie daje większej satysfakcji niż opracowanie całkowicie nowego i oryginalnego rozwiązania problemu, który męczy nas od wielu dni… aż do czasu gdy okaże się, że ktoś rozwikłał ten sam problem już wcześniej, a co gorsza — zrobił to znacznie lepiej niż my. W tym rozdziale przyjrzymy się kilku zasadom projektowania, które udało się sformułować podczas tych wszystkich lat stosowania komputerów, i dowiemy się, w jaki sposób mogą one sprawić, że staniesz się lepszym programistą. Porzuć ambitne myśli o „zrobieniu tego lepiej” — lektura tego rozdziału udowodni Ci, jak pisać programy sprytniej i szybciej. Zasada projektowania — w skrócie Zasada otwarte-zamknięte OCP, krok po kroku Zasada nie powtarzaj się Zasada DRY dotyczy obsługi jednego wymagania w jednym miejscu Zasada jednej odpowiedzialności Wykrywanie wielu odpowiedzialności Przechodzenie od wielu do jednej odpowiedzialności Zasada podstawienia Liskov Studium błędnego sposobu korzystania z dziedziczenia LSP ujawnia ukryte problemy związane ze strukturą dziedziczenia Musi istnieć możliwość zastąpienia typu bazowego jego typem pochodnym Naruszenia LSP sprawiają, że powstający kod staje się mylący Deleguj funkcjonalność do innej klasy Użyj kompozycji, by zebrać niezbędne zachowania z kilku innych klas Agregacja — kompozycja bez nagłego zakończenia Agregacja a kompozycja Dziedziczenie jest jedynie jedną z możliwości Celne spostrzeżenia Przybornik projektanta 396 397 399 402 404 410 412 415 420 421 422 423 424 426 428 432 433 434 437 438 Zasada nie powtarzaj się Zasada podstawienia Liskov Spis treści 9 Powtarzanie i testowanie Oprogramowanie jest wciąż przeznaczone dla klienta Czas pokazać klientowi, jak bardzo Ci na nim zależy. Nękają Cię szefowie? Klienci są zmartwieni? Udziałowcy wciąż zadają pytanie: „Czy wszystko będzie zrobione na czas?”. Żadna ilość nawet wspaniale zaprojektowanego kodu nie zadowoli Twoich klientów; musisz pokazać im coś działającego. Teraz, kiedy dysponujesz już solidnym przybornikiem z narzędziami do programowania obiektowego, nadszedł czas, byś udowodnił swoim klientom, że pisane przez Ciebie oprogramowanie naprawdę działa. W tym rozdziale poznasz dwa sposoby pracy nad implementacją możliwości funkcjonalnych tworzonego oprogramowania — dzięki nim Twoi klienci poczują błogie ciepło, które sprawi, że powiedzą o Tobie: „O tak, nie ma co do tego wątpliwości, jest właściwą osobą do napisania naszej aplikacji!”. Rozwiązanie nr 1: Koncentrujemy się na podobieństwach Unit type: String properties: Map id: int name: String weapons: Weapon * setType(String) getType(): String setProperty(String, Object) getProperty(String): Object getId(): int setName(String) getName(): String addWeapon(Weapon) getWeapons(): Weapons * Wszystkie właściwości, które są wspólne dla wszystkich jednostek, zostały przedstawione w klasie Unit w formie odrębnych zmiennych. Szymek doszedł do wniosku, że identyfikator jednostki będzie określany w konstruktorze klasy Unit, a zatem nie ma potrzeby definiowania odrębnej metody setId(). Dla każdej z nowych właściwości klasy Szymek zdefiniował odpowiednią parę metod. Twój przybornik narzędziowy powoli się wypełnia Wspaniałe oprogramowanie tworzy się iteracyjnie Schodzenie w głąb: dwie proste opcje Programowanie w oparciu o możliwości Programowanie w oparciu o przypadki użycia Dwa podejścia do tworzenia oprogramowania Analiza możliwości Pisanie scenariuszy testowych Programowanie w oparciu o testy Podobieństwa po raz wtóry Kładziemy nacisk na podobieństwa Hermetyzujemy wszystko Dopasuj testy do projektu Testy bez tajemnic… Udowodnij klientowi, że wszystko idzie dobrze Jak dotąd używaliśmy programowania w oparciu o kontrakt Tak naprawdę programowanie w oparciu o kontrakt dotyczy zaufania Programowanie defensywne Podziel swoją aplikację na mniejsze fragmenty funkcjonalności Celne spostrzeżenia Przybornik projektanta 442 444 445 446 447 448 452 455 458 460 464 466 470 472 478 480 481 482 491 493 496 464 Rozdział 9. 15 Spis treści 10 Proces projektowania i analizy obiektowej Scalając to wszystko w jedno Czy dotarliśmy już do celu? Poświęciliśmy sporo czasu i wysiłku, by poznać wiele różnych sposobów pozwalających poprawić jakość tworzonego oprogramowania; teraz jednak nadeszła pora, by połączyć i podsumować wszystkie zdobyte informacje. Na to właśnie czekałeś: mamy zamiar zebrać wszystko, czego się nauczyłeś, i pokazać Ci, że wszystkie te informacje stanowią części jednego procesu, którego możesz wielokrotnie używać, by tworzyć wspaniałe oprogramowanie. Spis treści Tworzenie oprogramowania w stylu obiektowym Trans-Obiektów Mapa metra w Obiektowie Lista możliwości Przypadki użycia odpowiadają zastosowaniu, możliwości odpowiadają funkcjonalności A teraz zacznij powtarzać te same czynności Dokładniejsza analiza sposobu reprezentacji sieci metra Używać klasy Line czy też nie używać... oto jest pytanie Najważniejsze sprawy związane z klasą Subway Ochrona własnych klas Czas na przerwę Wróćmy znowu do etapu określania wymagań Koncentruj się na kodzie, a potem na klientach Powtarzanie sprawia, że problemy stają się łatwiejsze Jak wygląda trasa? Samemu sprawdź Przewodnik Komunikacyjny po Obiektowie Ktoś chętny na trzeci cykl prac? Podróż jeszcze nie dobiegła końca… 500 504 506 509 515 519 521 530 536 539 547 549 551 555 560 564 567 569 Rozmowa z klientem Lista Lista możliwości możliwości możliwości możliwości możliwości możliwości Diagramy Diagramy Diagramy przypadków użycia przypadków użycia przypadków użycia przypadków użycia Lista kluczowych możliwości Lista kluczowych możliwości Lista kluczowych możliwości Zewnętrzny czynnik Zewnętrzny czynnik Zewnętrzny czynnik Zewnętrzny czynnik Zewnętrzny czynnik Zewnętrzny czynnik Analiza Analiza Analiza Analiza Architektura Architektura Architektura Architektura Podział problemu Podział problemu Podział problemu Podział problemu Podział problemu Podział problemu Podział problemu Podział problemu Podział problemu Podział problemu Podział problemu Wymagania Wymagania Wymagania Wymagania Wymagania Wymagania Wymagania Wymagania Wymagania Wymagania Wymagania Wymagania Wymagania Wymagania Wymagania Wymagania Wymagania Wymagania Podział problemu Wymagania Podobieństwa Podobieństwa Podobieństwa Podobieństwa Podobieństwa Podobieństwa Podobieństwa Hermetyzacja Hermetyzacja Ścieżka alternatywna Ścieżka alternatywna Ścieżka alternatywna Z e w n ę t r z n y c z y n n i k i n i c j u j ą c y L i s t a k l u c z o w y c h m o ż l i w o ś c i L i s t a k l u c z o w y c h m o ż l i w o ś c i L i s t a k l u c z o w y c h m o ż l i w o ś c i L i s t a k l u c z o w y c h m o ż l i w o ś c i L i s t a k l u c z o w y c h m o ż l i w o ś c i L i s t a k l u c z o w y c h m o ż l i w o ś c i L i s t a k l u c z o w y c h m o ż l i w o ś c i L i s t a k l u c z o w y c h m o ż l i w o ś c i L i s t a k l u c z o w y c h m o ż l i w o ś c i L i s t a k l u c z o w y c h m o ż l i w o ś c i L i s t a k l u c z o w y c h m o ż l i w o ś c i L i s t a k l u c z o w y c h m o ż l i w o ś c i L i s t a k l u c z o w y c h m o ż l i w o ś c i L i s t a k l u c z o w y c h m o ż l i w o ś c i L i s t a k l u c z o w y c h m o ż l i w o ś c i L i s t a k l u c z o w y c h m o ż l i w o ś c i L i s t a k l u c z o w y c h m o ż l i w o ś c i L i s t a k l u c z o w y c h m o ż l i w o ś c i L i s t a k l u c z o w y c h m o ż l i w o ś c i Wzorzec projektowy Wzorzec projektowy Wzorzec projektowy Wzorzec projektowy Wzorzec projektowy Wzorzec projektowy Wzorzec projektowy Wzorzec projektowy Wzorzec projektowy Scenariusz Scenariusz P o w t ó r z e n i eAnaliza dziedziny Analiza dziedziny Analiza dziedziny Analiza dziedziny Analiza dziedziny Analiza dziedziny Analiza dziedziny Analiza dziedziny Analiza dziedziny Analiza dziedziny Analiza dziedziny Analiza dziedziny Analiza dziedziny Analiza dziedziny Analiza dziedziny Analiza dziedziny Analiza dziedziny Analiza dziedziny Analiza dziedziny Analiza dziedziny Analiza dziedziny Analiza dziedziny Analiza dziedziny Projekt wstępny Projekt wstępny Projekt wstępny Projekt wstępny Projekt wstępny Projekt wstępny Projekt wstępny Projekt wstępny Projekt wstępny Projekt wstępny Projekt wstępny Projekt wstępny Projekt wstępny Projekt wstępny Projekt wstępny Projekt wstępny Projekt wstępny Projekt wstępny Projekt wstępny Projekt wstępny Analiza dziedziny P o w t ó r z e n i e P o w t ó r z e n i e P o w t ó r z e n i e P o w t ó r z e n i e P o w t ó r z e n i e P o w t ó r z e n i e P o w t ó r z e n i e Rozmowa z klientem Rozmowa z klientem Rozmowa z klientem Rozmowa z klientem Rozmowa z klientem Rozmowa z klientem P o w t ó r z e n i e P o w t ó r z e n i e P o w t ó r z e n i e Ścieżka alternatywna Ścieżka alternatywna Ścieżka alternatywna Ścieżka alternatywna Ścieżka alternatywna Ścieżka alternatywna Ścieżka alternatywna Ścieżka alternatywna Ścieżka alternatywna Ścieżka alternatywna Ścieżka alternatywna Ścieżka alternatywna Ścieżka alternatywna Ścieżka alternatywna Ścieżka alternatywna Ścieżka alternatywna Analiza tekstowa Lista wymagańAnaliza tekstowa Lista wymagańAnaliza tekstowa Analiza tekstowa Analiza tekstowa Analiza tekstowa Analiza tekstowa Analiza tekstowa Analiza tekstowa Analiza tekstowa Analiza tekstowa Lista wymagań Lista wymagań Lista wymagań Lista wymagań Lista wymagań Lista wymagań Lista wymagań Lista wymagań Spójność Spójność Spójność Spójność Spójność Spójność Spójność Spójność P o w t ó r z e n i e P o w t ó r z e n i e P o w t ó r z e n i e P o w t ó r z e n i e P o w t ó r z e n i e P o w t ó r z e n i e Architektura Architektura Zasady projektowe Zasady projektowe Zasady projektowe Zasady projektowe Zasady projektowe Różnice Różnice Delegowanie Delegowanie Delegowanie Delegowanie Delegowanie Delegowanie Delegowanie Delegowanie Delegowanie Delegowanie Z a s a d y p r o j e k t o w a n i a o b i e k t o w e g o Z a s a d y p r o j e k t o w a n i a o b i e k t o w e g o Z a s a d y p r o j e k t o w a n i a o b i e k t o w e g o Dostarczenie Dostarczenie Dostarczenie Dostarczenie Dostarczenie Dostarczenie Dostarczenie Dostarczenie Dostarczenie Dostarczenie Dostarczenie Dostarczenie Dostarczenie Dostarczenie Dostarczenie Wzorzec projektowy Wzorzec projektowy Zasady projektowe Zasady projektowe Zasady projektowe Implementacja Implementacja Implementacja Implementacja Implementacja Implementacja Implementacja Implementacja Implementacja Implementacja Implementacja Implementacja Implementacja Implementacja Implementacja Implementacja Implementacja Implementacja Implementacja Implementacja P r o g r a m o w a n i e w o p a r c i u o m o ż l i w o ś c i P r o g r a m o w a n i e w o p a r c i u o m o ż l i w o ś c i P r o g r a m o w a n i e w o p a r c i u o m o ż l i w o ś c i Hermetyzacja Hermetyzacja Hermetyzacja Programowanie w oparciu o testy Programowanie w oparciu o testy Programowanie w oparciu o testy Programowanie w oparciu o testy Programowanie w oparciu o testy Programowanie w oparciu o testy P o w t ó r z e n i e P o w t ó r z e n i e Scenariusz 16 Spis treści A Pozostałości Dziesięć najważniejszych tematów (których nie poruszyliśmy) Możesz nam wierzyć albo i nie, ale to jeszcze nie jest koniec. Owszem, wyobraź sobie, że nawet po przeczytaniu tych 600 stron wciąż możesz jeszcze znaleźć tematy, o których nawet nie wspomnieliśmy. Choć dziesięć zagadnień, jakie mamy zamiar przedstawić w tym dodatku, nie zasługuje na wiele więcej niż krótką wzmiankę, to jednak nie chcieliśmy, byś opuszczał Obiektów bez informacji na ich temat. Teraz będziesz miał nieco więcej tematów do rozmów podczas firmowej imprezy z okazji wygrania telewizyjnego quizu Obiektowa Katastrofa… poza tym któż, od czasu do czasu, nie kocha stymulujących rozmów o analizie i projektowaniu? Kiedy już skończymy, pozostanie jeszcze… następny dodatek… no i oczywiście indeks, i może kilka reklam… ale później dotrzesz wreszcie do końca książki. Obiecujemy. Nr 1. JEST i MA Nr 2. Sposoby zapisu przypadków użycia Nr 3. Antywzorce Nr 4. Karty CRC Nr 5. Metryki Nr 6. Diagramy sekwencji Nr 7. Diagramy stanu Nr 8. Testowania jednostkowe Nr 9. Standardy kodowania i czytelny kod Nr 10. Refaktoryzacja Antywzorce Antywzorce są przeciwieństwem wzorców projektowych: stanowią one często stosowane ZŁE rozwiązania pewnych problemów. Powinniśmy być w stanie rozpoznawać te niebezpieczne pułapki i unikać ich. Spis treści Klasa: DogDoor Opis: Reprezentuje faktyczne drzwiczki dla psa. Stanowi interfejs zapewniający możliwość korzystania z urządzeń sprzętowych kontrolujących działanie drzwiczek dla psa. Odpowiedzialności: Nazwa Otworzenie drzwiczek Zamknięcie drzwiczek Zwróć uwagę, by zapisać tu zarówno operacje, które dana klasa realizuje samodzielnie, jak i te, które wykonuje przy użyciu innych klas. Współpracownik Do wykonania tych czynności nie są używane żadne inne obiekty. 572 574 577 578 580 581 582 584 586 588 17 Spis treści 20 Spis treści B Witamy w Obiektowie Stosowanie języka obiektowego Przygotuj się na zagraniczną wycieczkę. Czas odwiedzić Obiektów — miejsce, gdzie obiekty robią to, co powinny, aplikacje są dobrze hermetyzowane (już wkrótce dowiesz się, co to znaczy), a projekty oprogramowania pozwalają na ich wielokrotne stosowanie i rozbudowę. Musisz jeszcze poznać kilka dodatkowych zagadnień i poszerzyć swoje umiejętności językowe. Nie przejmuj się jednak, nie zajmie Ci to wiele czasu i zanim się obejrzysz, już będziesz rozmawiał w języku obiektowym, jakbyś mieszkał w Obiektowie od wielu lat. Witamy w Obiektowie UML i diagramy klas Dziedziczenie Polimorfizm Hermetyzacja Celne spostrzeżenia Airplane speed: int getSpeed(): int setSpeed(int) 591 593 595 596 600 To jest nazwa klasy. Zawsze jest umieszczana na samej górze diagramu i zapisywana pogrubioną czcionką. Ta linia oddziela zmienne składowe klasy od jej metod. Diagram klasy pozwala wyobrazić sobie ogólną postać klasy: bez trudu, na pierwszy rzut oka, można powiedzieć, co dana klasa robi. W razie potrzeby w diagramie można nawet pominąć fragment zawierający zmienne składowe lub metody, jeśli to pomoże w przekazaniu niezbędnych informacji. Oto jak przedstawiamy klasy na tak zwanym diagramie klas. To właśnie w taki sposób UML pozwala na przedstawianie szczegółowych informacji o klasach tworzących aplikację. To są zmienne składowe klasy. Każda ma pewną nazwę, a po dwukropku określony jest jej typ. To są metody klasy. Każda metoda ma nazwę, za nią w nawiasach podawane są parametry metody, a następnie, po dwukropku, typ wartości wynikowej. Skorowidz 603 S 18 jesteś tutaj  591 3. Wymagania ulegają zmianom Kocham cię, jesteś doskonały… A teraz — zmień się Cóż ja na Boga w nim widziałam? Właśnie się dowiedziałam, że on nawet nie interesuje się wyścigami NASCAR. Sądzisz, że dowiedziałeś się już wszystkiego o tym, czego chciał klient? Nie tak szybko… A zatem przeprowadziłeś rozmowy z klientem, zgromadziłeś wymagania, napisałeś przypadki użycia, napisałeś i dostarczyłeś klientowi odlotową aplikację. W końcu nadszedł czas na miłego, relaksującego drinka, nieprawdaż? Pewnie… aż do momentu gdy klient uzna, że tak naprawdę chce czegoś innego niż to, co Ci powiedział. Bardzo podoba mu się to, co zrobiłeś — poważnie! — jednak obecnie nie jest już w pełni usatysfakcjonowany. W rzeczywistym świecie wymagania zawsze się zmieniają; to Ty musisz sobie z tymi zmianami poradzić i pomimo nich zadbać o zadowolenie klienta. to jest nowy rozdział  137 Witamy w raju Jesteś bohaterem! Pyszna pina colada do picia, słońce przyjemnie ogrzewające Twoje ciało, zwitek studolarowych banknotów wciśnięty za kąpielówki… właśnie tak wygląda życie studolarowych banknotów wciśnięty za kąpielówki… właśnie tak wygląda życie programisty, który sprawił, że interesy firmy PsieOdrzwia kwitną. Drzwiczki, programisty, który sprawił, że interesy firmy PsieOdrzwia kwitną. Drzwiczki, które stworzyliście dla Tadka i Janki, okazały się niesamowitym sukcesem i obecnie Darek sprzedaje je klientom na całym świecie. Darek zarabia na Twoim kodzie naprawdę duże pieniądze. Lecz wtem dzwoni telefon… Cześć, słuchaj… Wasze drzwiczki dla psa działają rewelacyjnie, ale chcielibyśmy, żebyście jeszcze trochę nad nimi popracowali… Jesteś zmęczony zachowaniem Twojego pupilka? Czy jesteś gotów wynająć osobę do wyprowadzania Twojego ulubieńca? Czy jesteś gotów wynająć osobę do wyprowadzania Twojego ulubieńca? Masz dosyć drzwiczek dla psów, które zacinają się za każdym razem, gdy je otworzysz? Masz dosyć drzwiczek dla psów, które zacinają się za każdym razem, gdy je otworzysz? Sprzedano już ponad 10 000 sztuk! Nadszedł czas by zadzwonić do firmy Nadszedł czas by zadzwonić do firmy Psieodrzwia Psieodrzwia  Profesjonalny montaż wykonywany u klienta przez naszych ekspertów.  Opatentowana stalowa konstrukcja.  Możliwość wyboru koloru i napisów.  Możliwość dostosowania wielkości. Zadzwoń do nas już dziś: 0-800-998 9989 Ty: O rany, czy coś jest nie tak z drzwiczkami? Tadek i Janka: Nie, absolutnie nie. Drzwiczki działają dokładnie tak, jak opisałeś. Ty: No, ale musi być jakiś problem, prawda? Może drzwiczki nie zamykają się odpowiednio szybko? A może nie działa przycisk na pilocie? Tadek i Janka: Nie, co ty… Wszystko działa równie dobrze jak tego dnia, kiedy zainstalowałeś cały system i pokazałeś nam, jak wszystko funkcjonuje. Ty: No to może Azor przestał szczekać, żebyście go wypuścili na zewnątrz? A… a sprawdziliście baterie w pilocie? Tadek i Janka: Słuchaj, naprawdę z drzwiczkami jest wszystko w porządku. Po prostu mamy kilka pomysłów na modyfikacje, które chcielibyśmy wprowadzić… Ty: Ale skoro wszystko dobrze działa, to w czym problem? Tadek i Janka, którzy beztrosko przerywają Twoje wakacje. 138 Rozdział 3. Męczy nas ciągła konieczność nasłuchiwania, czy Azor szczeka… Czasami nawet go nie słyszymy i Azor załatwia swoje potrzeby w kuchni… Wymagania ulegają zmianom No i ciągle się nam gubi pilot do drzwiczek albo zostawiamy go w innym pokoju. Męczy mnie już to ciągłe naciskanie przycisku, by otworzyć drzwiczki. Drzwiczki dla psa, dla Tadka i Janki, wersja 2.0 Jak (obecnie) działają drzwiczki 1. Azor szczeka, by właściciele wypuścili go na spacer. 2. Tadek lub Janka słyszą, że Azor szczeka. 3. Tadek lub Janka naciskają przycisk na pilocie. 4. Drzwiczki dla psa otwierają się. 5. Azor wychodzi na zewnątrz. 6. Azor załatwia swoje potrzeby. 6.1 Drzwi zamykają się automatycznie. 6.2. Azor szczeka, by właściciele wpuścili go do domu. 6.3. Tadek lub Janka słyszą szczekanie Azora (znowu). 6.4. Tadek lub Janka naciskają przycisk na pilocie. 6.5. Drzwiczki dla psa otwierają się (znowu). 7. Azor wraca z powrotem. 8. Drzwi automatycznie się zamykają. Czy nie dałoby się zrobić tak, żeby drzwiczki otwierały się automatycznie, kiedy Azor zaszczeka? W takim przypadku nie musielibyśmy w ogóle niczego robić, żeby go wypuścić. Rozmawialiśmy na ten temat i oboje uważamy, że to jest DOSKONAŁY pomysł! jesteś tutaj  139 Klient ma rację No i wracamy do tablicy A zatem nadszedł czas, by zabrać się do pracy nad poprawieniem drzwiczek dla psa zamówionych przez Tadka i Jankę. Musimy określić, w jaki sposób należy otwierać drzwiczki za każdym razem, gdy Azor zaszczeka. Zacznijmy od… Zaraz, chwileczkę… To jest totalnie do bani… Przecież już zrobiliśmy dla nich działające drzwiczki i powiedzieli, że są w porządku. A teraz okazuje się, że jeszcze coś mamy w nich poprawiać i to tylko dlatego, że akurat mieli taki pomysł? Klient ma zawsze rację Nawet jeśli wymagania ulegną zmianie, musisz być przygotowany do zaktualizowania aplikacji i zadbania o to, by działała zgodnie z oczekiwaniami klienta. Kiedy klient wymyśli nową funkcję, Twoim zadaniem będzie zmienić aplikację i spełnić potrzeby klienta. Darek uwielbia takie sytuacje, gdyż może zainkasować od Tadka i Janki nową sumkę za zmiany w aplikacji, które Ty wprowadzisz. WYSIl SzarE komórkI Właśnie poznałeś jedyny pewnik występujący w analizie i projektowaniu obiektowym. Jak myślisz, co nim jest? 140 Rozdział 3. Wymagania ulegają zmianom Jedyny pewnik analizy i projektowania obiektowego* W porządku, zatem co jest tym jedynym pewnikiem, na który zawsze możesz liczyć, pisząc oprogramowanie? Niezależnie od tego, gdzie pracujesz, jakie oprogramowanie tworzysz oraz jakiego języka programowania używasz, jaka jest jedyna stała, która zawsze będzie Ci towarzyszyć? ZMIANA (użyj lusterka, by odczytać odpowiedź) Niezależnie od tego, jak dobrze zaprojektujesz swoją aplikację, to wraz z upływem czasu zawsze będzie się ona rozwijać i zmieniać. Poznasz nowe rozwiązania występujących w niej problemów, używane języki programowania będą ewoluować, Twoi mili klienci wymyślą nowe, zwariowane wymagania, które Ty będziesz musiał „poprawiać”. Zaostrz ołówek Zaostrz ołówek Wymagania cały czas ulegają zmianom… czasami w połowie realizacji projektu, a czasami w chwili, gdy sądziłeś, że wszystko już jest gotowe. Poniżej zapisz kilka potencjalnych przyczyn, dla których mogą ulec zmianie wymagania w aktualnie pisanej przez Ciebie aplikacji. Mój klient zdecydował, że chciałby, by aplikacja działała w inny sposób. Mój szef uznał, że aplikacja spisywałaby się lepiej, gdyby została napisana jako aplikacja internetowa, a nie tradycyjna. Wymagania zawsze ulegają zmianom. Jeśli jednak stworzyłeś dobre przypadki użycia, to zazwyczaj będziesz w stanie szybko zmodyfikować aplikację i dostosować ją do nowych wymagań. * Jeśli czytałeś książkę Wzorce projektowe. Rusz głową!, to zapewne ta strona będzie wyglądała znajomo. Autorzy tej książki w tak doskonały sposób opisali modyfikacje, że postanowiliśmy „pożyczyć” ich pomysły i jedynie ZMIENIĆ kilka słów tu i ówdzie. Dziękujemy wam, Beth i Ericu! jesteś tutaj  141 Dodanie ścieżki alternatywnej ćwiczenie Rozszerzyć możliwości drzwiczek Tadka i Janki o rozpoznawanie szczekania. Zaktualizuj diagram i dodaj do niego ścieżkę alternatywną przedstawiającą sytuację, w której Azor zaczyna szczekać. Nowy system rozpoznawania dźwięków, oferowany przez Darka, rozpoznaje szczekanie i drzwiczki otwierają się automatycznie. Pilot do drzwiczek wciąż powinien funkcjonować, dlatego z diagramu nie powinieneś niczego usuwać; po prostu dodaj do niego nową ścieżkę prezentującą, jak system działa w przypadku rozpoznania szczekania Azora. Janka, otwórz drzwiczki dla Azora, bo ten pies inaczej nie przestanie szczekać! Hau, hauu 1 Azor szczeka, by właściciele wypuścili go na spacer. 2 Tadek lub Janka słyszą, że Azor szczeka. Tadek lub Janka naciskają przycisk na 3 pilocie. 8 Drzwi zamykają się automatycznie. 7 Azor wchodzi do środka. 142 Rozdział 3. Wymagania ulegają zmianom 6.1 Drzwiczki zamykają się automatycznie. Hau! Hau! 6.2 Azor szczeka, by właściciele wpuścili go do śrdodka Znowu szczeka… Niechże ktoś wpuści tego psa do środka. 4 Drzwiczki otwierają się. 5 Azor wychodzi na zewnątrz. Teraz czuję się znacznie lepiej! 6 Azor załatwia swoje potrzeby. 6.3 Tadek lub Janka słyszą (ponownie) szczekanie Azora. 6.4 Tadek lub Janka naciskają przycisk na pilocie jesteś tutaj  143 6.5 Drzwiczki zamykają się automatycznie. Aby sprostać potrzebom Azora Rozszerzyć możliwości drzwiczek Tadka i Janki o rozpoznawanie szczekania. Zaktualizuj diagram i dodaj do niego ścieżkę alternatywną przedstawiającą sytuację, w której Azor zaczyna szczekać. Nowy system rozpoznawania dźwięków, oferowany przez Darka, rozpoznaje szczekanie i drzwiczki otwierają się automatycznie. Pilot do drzwiczek wciąż powinien funkcjonować, dlatego z diagramu nie powinieneś niczego usuwać; po prostu dodaj do niego nową ścieżkę prezentującą, jak system działa w przypadku rozpoznania szczekania Azora. rozwiązania ćwiczeń Janka, otwórz drzwiczki dla Azora, bo ten pies inaczej nie przestanie szczekać! Hau, hauu Hau, hauu 2 Tadek lub Janka słyszą, że Azor szczeka. 3 Tadek lub Janka naciskają przycisk na pilocie. 1 Azor szczeka, by właściciele wypuścili go na spacer. Do drzwiczek dla psa musimy dodać cudowny system rozpoznawania szczekania. Większość diagramu pozostaje taka sama… Potrzebujemy jedynie tych dwóch dodatkowych kroków. 2.1 System rozpoznawania dźwięków „słyszy” szczekanie. 3.1 System rozpoznawania dźwięków wysyła żądanie otworzenia drzwiczek. Podobnie jak w przypadku pierwszej ścieżki alternatywnej, także i teraz możemy zastosować podpunkty, by zaznaczyć, że jest to ścieżka alternatywna. 8 Drzwi zamykają się automatycznie. 7 Azor wchodzi do środka. 144 Rozdział 3. Wymagania ulegają zmianom Hau! Hau! 6.1 Drzwiczki zamykają się automatycznie. Teraz czuję się Teraz czuję się znacznie lepiej! znacznie lepiej! Ta k ż e t u t a j p o t r z e b u j e m y k i l k u d o d a t k o w y c h k r o k ó w . Azor szczeka, by właściciele 6.2 Azor szczeka, by właściciele Azor szczeka, by właściciele wpuścili go do środka wpuścili go do środka 4 Drzwiczki otwierają się. 5 Azor wychodzi na zewnątrz. 6 Azor załatwia swoje potrzeby. Ponieważ te kroki już znajdują się na ścieżce alternatywnej, zatem będziemy potrzebowali kolejnego poziomu — dlatego też krok na nowej ścieżce alternatywnej oznaczyliśmy za pomocą aż dwóch cyfr. 6.3.1 System rozpoznawania dźwięku „słyszy” szczekanie Azora (ponownie). 6.4.1 System rozpoznawania dźwięku wysyła żądanie otworzenia drzwiczek. Znowu szczeka… Znowu szczeka… Znowu szczeka… Niechże ktoś wpuści tego Niechże ktoś wpuści tego Niechże ktoś wpuści tego psa do środka. psa do środka. psa do środka. psa do środka. 6.3 Tadek lub Janka słyszą Tadek lub Janka słyszą (ponownie) szczekanie (ponownie) szczekanie Azora. 6.46.46.4 Tadek lub Janka naciskają Tadek lub Janka naciskają przycisk na pilocie przycisk na pilocie 6.5 Drzwiczki zamykają się automatycznie. jesteś tutaj  145 Jaką ścieżką mam podążać? Ścieżką oryginalną? Ścieżką alternatywną? Kto to wie? Ale teraz mój przypadek użycia jest totalnie pogmatwany i trudny do zrozumienia. Wszystkie te ścieżki alternatywne sprawiają, że określenie, co się właściwie dzieje, przysparza poważnych problemów. Drzwiczki dla psa, dla Tadka i Janki, wersja 2.1 Jak (obecnie) działają drzwiczki 1. Azor szczeka, by właściciele wypuścili go na spacer. 2. Tadek lub Janka słyszą, że Azor szczeka. 2.1. System rozpoznawania dźwięków „słyszy” szczekanie Azora. 3. Tadek lub Janka naciskają przycisk na pilocie. 3.1. System rozpoznawania dźwięków wysyła żądanie otworzenia drzwiczek. Teraz pojawiły się alternatywne kroki dla oryginalnych kroków numer 2. i 3. 4. Drzwiczki dla psa otwierają się. 5. Azor wychodzi na zewnątrz. 6. Azor załatwia swoje potrzeby. 6.1 Drzwi zamykają się automatycznie. 6.2. Azor szczeka, by właściciele wpuścili go do domu. 6.3. Tadek lub Janka słyszą szczekanie Azora (znowu). 6.3.1. System rozpoznawania dźwięków „słyszy” szczekanie Azora (ponownie). 6.4. Tadek lub Janka naciskają przycisk na pilocie. 6.4.1. System rozpoznawania dźwięków wysyła żądanie otworzenia drzwiczek. 6.5. Drzwiczki dla psa otwierają się (znowu). 7. Azor wraca z powrotem. 8. Drzwi automatycznie się zamykają. Teraz mamy już nawet kroki alternatywne do wcześniejszych kroków alternatywnych. 146 Rozdział 3. Przedstawiliśmy je jako podpunkty listy, trzeba jednak pamiętać, że w rzeczywistości stanowią one zupełnie nową ścieżkę alternatywną. Te podpunkty stanowią dodatkowy zestaw kroków, które mogą być wykonane… …a te podpunkty, stanowią w rzeczywistości zupełnie inną ścieżkę przejścia przez przypadek użycia. Wymagania ulegają zmianom Ciągle uważam, że ten przypadek użycia jest trudny do zrozumienia i nieczytelny. Wygląda na to, że Tadek i Janka zawsze słyszą, kiedy Azor szczeka, Tadek i Janka ale urządzenie do rozpoznawana dźwięków słyszy go tylko czasami. Ale to nie jest to, czego by chcieli Tadek i Janka. Czy rozumiesz, o czym mówi Gerard? Pomysł Tadka i Janki polegał na tym, by już więcej nie musieli nasłuchiwać, czy Azor szczeka, czy nie. Przedstawiliśmy podpunkty listy, w rzeczywistości Drzwiczki dla psa, dla Tadka i Janki, wersja 2.1 W rzeczywistości w nowym przypadku użycia chodzi nam o to, by pokazać, że może być wykonany krok 2. lub krok 2.1… …a następnie krok 3. lub krok 3.1. Jak (obecnie) działają drzwiczki 1. Azor szczeka, by właściciele wypuścili go na spacer. 2. Tadek lub Janka słyszą, że Azor szczeka. 2.1. System rozpoznawania dźwięków „słyszy” szczekanie Azora. 3. Tadek lub Janka naciskają przycisk na pilocie. 3.1. System rozpoznawania dźwięków wysyła żądanie otworzenia drzwiczek. 4. Drzwiczki dla psa otwierają się. 5. Azor wychodzi na zewnątrz. 6. Azor załatwia swoje potrzeby. 6.1 Drzwi zamykają się automatycznie. 6.2. Azor szczeka, by właściciele wpuścili go do domu. 6.3. Tadek lub Janka słyszą szczekanie Azora (znowu). 6.3.1. System rozpoznawania dźwięków „słyszy” szczekanie Azora (ponownie). 6.4. Tadek lub Janka naciskają przycisk na pilocie. 6.4.1. System rozpoznawania dźwięków wysyła żądanie otworzenia drzwiczek. 6.5. Drzwiczki dla psa otwierają się (znowu). 7. Azor wraca z powrotem. 8. Drzwi automatycznie się zamykają. Tutaj może być wykonany krok 6.3 lub krok 6.3.1… … a t u k r o k 6 . 4 l u b 6 . 4 . 1 . jesteś tutaj  147 Zapisz to w dowolnej postaci Przypadki użycia muszą być zrozumiałe i użyteczne przede wszystkim dla Ciebie Jeśli masz problemy ze zrozumieniem przygotowanego przypadku użycia, to po prostu zapisz go w jakiś inny sposób. Istnieją setki różnych sposobów zapisywania przypadków użycia, jednak najważniejsze jest to, by był on pojmowalny dla Ciebie, Twojego zespołu oraz osób, którym musisz go wytłumaczyć. Spróbujmy zatem zapisać przypadek użycia ze strony 147 w bardziej przejrzysty i zrozumiały sposób. Wszystkie kroki, które mogą zostać wykonane zamiast jakichś kroków ścieżki głównej, umieściliśmy z prawej strony. Drzwiczki dla psa, dla Tadka i Janki, wersja 2.2 Jak działają drzwiczki Ścieżka główna 1. Azor szczeka, by właściciele wypuścili go na spacer. 2. Tadek lub Janka słyszą, że Azor szczeka. 3. Tadek lub Janka naciskają przycisk na pilocie. 4. Drzwiczki dla psa otwierają się. 5. Azor wychodzi na zewnątrz. 6. Azor załatwia swoje potrzeby. Ścieżki alternatywne 2.1. System rozpoznawania dźwięków „słyszy” szczekanie Azora. 3.1. System rozpoznawania dźwięków wysyła żądanie otworzenia drzwiczek. Ten sposób zapisu jest nieco bardziej przejrzysty i zrozumiały: możemy wykonać krok 2. LUB krok 2.1; a następnie krok 3. LUB krok 3.1. 6.1 Drzwi zamykają się automatycznie. 6.2. Azor szczeka, by właściciele wpuścili go do domu. Teraz dodaliśmy nagłówek informujący, że wszystkie kroki umieszczone w lewej kolumnie należą do ścieżki głównej. Jeśli istnieje tylko jeden krok, to podczas realizacji sekwencji czynności opisanych przez przypadek użycia krok ten zawsze zostanie wykonany. Kroki podrzędne są opcjonalne… Możesz ich użyć, choć nie jest to wcale wymagane. Pomimo to umieściliśmy je w lewej kolumnie, gdyż nie stanowią one zamienników dla innych kroków ścieżki głównej. Niezależnie od tego, w jaki sposób zostanie wykonany przypadek użycia, zawsze jego realizacja zakończy się na kroku 8. należącym do ścieżki głównej. 148 Rozdział 3. 6.3. Tadek lub Janka słyszą szczekanie Azora (znowu). 6.4. Tadek lub Janka naciskają przycisk na pilocie. 6.5. Drzwiczki dla psa otwierają się (znowu). 7. Azor wraca z powrotem. 8. Drzwi automatycznie się zamykają. 6.3.1. System rozpoznawania dźwięków „słyszy” szczekanie Azora (ponownie). 6.4.1. System rozpoznawania dźwięków wysyła żądanie otworzenia drzwiczek. Kroki przedstawione z prawej strony mogą zastąpić krok 6.3 oraz 6.4. Podczas realizacji procesu opisywanego przez przypadek użycia można wykonać tylko jeden z wariantów: krok zapisany z lewej LUB krok zapisany z prawej strony. Jeśli naprawdę możemy tworzyć przypadki użycia w dowolny sposób, to czy możemy zmodyfikować je w taki sposób, by system rozpoznawania szczekania stał się elementem głównej ścieżki? Bo przecież chcemy, by w większości przypadków system działał właśnie w taki sposób, nieprawdaż? Wymagania ulegają zmianom mogą zostać wykonane kroków ścieżki głównej, Doskonały pomysł! Ścieżka główna reprezentuje ten sposób działania systemu, jaki ma być realizowany w większości przypadków. Tadek i Janka zapewne życzyliby sobie, by system rozpoznawania dźwięku otwierał drzwiczki dla Azora częściej niż oni przy użyciu pilota, dlatego też takie zmodyfikowanie ścieżki głównej jest dobrym rozwiązaniem: Drzwiczki dla psa, dla Tadka i Janki, wersja 2.3 Jak działają drzwiczki Teraz kroki związane z wykorzystaniem systemu rozpoznawania dźwięku zostały usunięte ze ścieżki alternatywnej i dołączone do ścieżki głównej. Ścieżka główna Ścieżka główna 1. Azor szczeka, by właściciele wypuścili go na spacer. „słyszy” szczekanie Azora. 2. System rozpoznawania dźwięków 3. System rozpoznawania dźwięków wysyła żądanie otworzenia drzwiczek. 4. Drzwiczki dla psa otwierają się. 5. Azor wychodzi na zewnątrz. 6. Azor załatwia swoje potrzeby. Ścieżki alternatywne 2.1. Tadek lub Janka słyszą, 3.1. Tadek lub Janka naciskają przycisk na pilocie. że Azor szczeka. Obecnie Tadek i Janka będą używali pilota raczej sporadycznie, dlatego umieszczenie wszystkich kroków związanych z pilotem w ścieżkach alternatywnych będzie prawidłowym rozwiązaniem. wpuścili go do domu. 6.1. Drzwi zamykają się automatycznie. 6.2. Azor szczeka, by właściciele 6.3. System rozpoznawania 6.4. System rozpoznawania dźwięków 6.4.1. Tadek lub Janka naciskają 6.5. Drzwiczki dla psa otwierają się (znowu). 6.3.1. Tadek lub Janka słyszą dźwięków „słyszy” szczekanie Azora (ponownie). wysyła żądanie otworzenia drzwiczek. przycisk na pilocie. szczekanie Azora (znowu). 7. Azor wraca z powrotem. 8. Drzwi automatycznie się zamykają. jesteś tutaj  149 Docieramy do celu Od startu do mety: jeden scenariusz Uwzględniając wszystkie ścieżki alternatywne zamieszczone w nowym przypadku użycia, istnieje wiele sposobów na wypuszczenie Azora na spacer i późniejsze wpuszczenie go do domu. Poniżej przedstawiliśmy jeden z możliwych scenariuszy. Wykorzystajmy tę ścieżkę alternatywną i pozwólmy Tadkowi i Jance otworzyć drzwiczki przy użyciu pilota. Drzwiczki dla psa, dla Tadka i Janki, wersja 2.3 Jak działają drzwiczki Wszystkie możliwe ścieżki realizacji tego przypadku użycia rozpoczynają się od kroku 1. Ścieżka główna 1. Azor szczeka, by właściciele wypuścili go na spacer. „słyszy” szczekanie Azora. 2. System rozpoznawania dźwięków 3. System rozpoznawania dźwięków wysyła żądanie otworzenia drzwiczek 4. Drzwiczki dla psa otwierają się. 5. Azor wychodzi na zewnątrz. 6. Azor załatwia swoje potrzeby. 6.1. Drzwi zamykają się automatycznie. 6.2. Azor szczeka, by właściciele wpuścili go do domu. 6.3. System rozpoznawania 6.4. System rozpoznawania 6.5. Drzwiczki dla psa otwierają się (znowu). dźwięków „słyszy” szczekanie Azora (ponownie). dźwięków wysyła żądanie otworzenia drzwiczek. 7. Azor wraca z powrotem. 8. Drzwi automatycznie się zamykają. Poruszanie się zgodnie z kolejnością wyznaczaną przez strzałki pozwala na przejście danego przypadku użycia konkretną ścieżką. Taka ścieżka jest nazywana scenariuszem. W jednym przypadku użycia można zazwyczaj wyróżnić kilka scenariuszy. 150 Rozdział 3. Ścieżki alternatywne 2.1. Tadek lub Janka słyszą, że Azor szczeka. 3.1. Tadek lub Janka naciskają przycisk na pilocie. W tym przypadku zastosujemy tę oto ścieżkę, reprezentującą sytuację, w której Azor pozostaje na zewnątrz po automatycznym zamknięciu drzwiczek. 6.3.1. Tadek lub Janka słyszą szczekanie Azora (znowu). 6.4.1. Tadek lub Janka naciskają przycisk na pilocie. Także teraz zastosujemy ścieżkę alternatywną, w której Tadek i Janka otwierają drzwiczki pilotem. Realizacja przypadku użycia zawsze zakończy się na kroku 8. — Azor zawsze bezpiecznie wróci do domu. Nie istnieją głupie pytania P: Rozumiem ścieżkę główną naszego przypadku użycia, ale czy możecie mi jeszcze raz wytłumaczyć, czym jest ścieżka alternatywna? O: Ścieżka alternatywna to jeden lub kilka kroków, które mogą, lecz nie muszą, zostać wykonane lub które tworzą alternatywny sposób przejścia przez przypadek użycia. Ścieżki alternatywne mogą zawierać dodatkowe kroki dołączane do ścieżki głównej bądź też kroki pozwalające na dotarcie do celu w sposób całkowicie odmienny niż ten, jaki zapewnia ścieżka główna. P: A zatem, kiedy Azor wyjdzie na zewnątrz i utknie tam, będzie to element ścieżki alternatywnej? O: Owszem. W naszym przypadku użycia kroki 6.1, 6.2, 6.3, 6.4 oraz 6.5 tworzą ścieżkę alternatywną. Są to kroki dodatkowe, które system może wykonać; są one potrzebne wyłącznie w przypadku, gdy Azor zostanie na zewnątrz po automatycznym zamknięciu się drzwiczek. Jednak jest to ścieżka alternatywna, gdyż Azor nie zawsze załatwia swoje potrzeby aż tak długo — system może przejść bezpośrednio z kroku 6. do kroku 7. P: I do tego celu używamy kroków podrzędnych, oznaczonych jako 6.1 i 6.2? O: Dokładnie. Dzieje się tak, gdyż ścieżka alternatywna zawierająca kroki dodatkowe jest po prostu zbiorem czynności, które mogą zostać wykonane jako fragmenty innego kroku ścieżki głównej. Kiedy Azor zostaje na zewnątrz zbyt długo, to na ścieżce głównej zostają wykonane kroki 6. i 7., dlatego też ścieżka alternatywna zaczyna się od kroku o numerze 6.1 i kończy krokiem 6.5. Wszystkie one są opcjonalnymi elementami kroku 6. Wymagania ulegają zmianom P: Czy w jednym przypadku użycia może być więcej niż jedna ścieżka alternatywna? O: Oczywiście. W jednym przypadku użycia może być kilka ścieżek alternatywnych udostępniających dodatkowe kroki oraz wiele różnych ścieżek od warunku rozpoczęcia do warunku zakończenia. Może także istnieć ścieżka alternatywna prowadząca do szybszego zakończenia przypadku użycia… Jednak w przypadku drzwiczek dla psa zamówionych przez Tadka i Jankę nie musimy uciekać się aż do tak złożonych rozwiązań. P: A zatem jak nazwać sytuację, w której będą istnieć aż dwie różne ścieżki prowadzące przez pewien fragment przypadku użycia? O: Cóż, tak naprawdę to jest to tylko inny rodzaj ścieżki alternatywnej. Kiedy Azor zacznie szczekać, to jedna ścieżka reprezentuje sytuację, w której Tadek lub Janka usłyszą go i otworzą drzwiczki, a druga — sytuację, w której drzwiczki automatycznie otworzy system rozpoznawania szczekania. Jednak system jest zaprojektowany w taki sposób, iż może zostać wykonana tylko jedna ścieżka, czyli drzwiczki dla psa zostaną otworzone albo przy użyciu pilota, albo przez system rozpoznawania dźwięków, lecz nigdy przez oba te zdarzenia jednocześnie. Kompletna ścieżka prowadząca przez cały przypadek użycia, od jego pierwszego do ostatniego kroku, jest nazywana scenariuszem. Większość przypadków użycia posiada kilka różnych scenariuszy, jednak wszystkie one realizują ten sam cel użytkownika. jesteś tutaj  151 Ścieżki alternatywne są opcjonalne Przypadki użycia bez tajemnic W tym tygodniu: Wyznanie Ścieżki Alternatywnej Rusz głową!: Witamy, Ścieżko Alternatywna. Słyszeliśmy, że ostatnio nie jesteś zbyt szczęśliwa. Powiedz nam, co takiego się dzieje? Ścieżka Alternatywna: Po prostu czasami mam wrażenie, że nie jestem dość często włączana w bieg zdarzeń. Chodzi mi o to, że trudno beze mnie stworzyć dobry przypadek użycia, jednak wygląda na to, że niemal zawsze jestem ignorowana. Rusz głową!: Ignorowana? Ale sama właśnie powiedziałaś, że znajdujesz się niemal w każdym przypadku użycia. Zabrzmiało to tak, jakbyś była naprawdę ważna! Ścieżka Alternatywna: Może i zabrzmiało. Jednak nawet jeśli jestem fragmentem przypadku użycia, to i tak mogę zostać pominięta i zastąpiona jakimś innym zbiorem kroków. To naprawdę paskudne… To tak, jakby mnie tam w ogóle nie było! Rusz głową!: Czy możesz nam to wytłumaczyć na jakimś przykładzie? Ścieżka Alternatywna: Właśnie kilka dni temu byłam fragmentem przypadku użycia opisującego kupowanie płyt CD w nowym internetowym sklepie muzycznym — Muzykologia. Byłam tym tak bardzo poruszona… A okazało się, że obsługuję sytuacje, w których karta kredytowa klienta została odrzucona. Rusz głową!: Hm… ale to chyba naprawdę ważne zadanie! Zatem w czym problem? Ścieżka Alternatywna: Cóż… może. Sądzę, że to faktycznie istotne zadanie, jednak okazuje się, że zawsze jestem pomijana. Wygląda to tak, jak gdyby wszyscy składali zamówienia, a ich karty kredytowe były zawsze akceptowane. Chociaż byłam częścią przypadku użycia, to nie należałam do najczęściej realizowanych scenariuszy. Rusz głową!: Aha, rozumiem. Czyli jeśli czyjaś karta kredytowa nie została odrzucona, to w ogóle nie byłaś wykonywana. Ścieżka Alternatywna: Właśnie! A specjaliści od finansów i bezpieczeństwa wprost mnie uwielbiali; wciąż zachwycali się, jak bardzo jestem ważna dla firmy… Ale kto by chciał siedzieć cały czas na stołku i próżnować? Rusz głową!: Chyba zaczynam rozumieć. Niemniej jednak wciąż pomagasz temu przypadkowi użycia, prawda? Nawet jeśli nie jesteś nieustannie używana, to jednak od czasu do czasu musisz wkroczyć do akcji. Ścieżka Alternatywna: To prawda, wszyscy mamy ten sam cel. Po prostu nie zdawałam sobie sprawy z tego, że mogę być tak ważna dla przypadku użycia, a jednocześnie niemal całkowicie ignorowana. Rusz głową!: Cóż, tylko pomyśl… Przypadek użycia nigdy nie byłby kompletny bez ciebie. Ścieżka Alternatywna: No tak… Kroki 3.1 i 4.1 wciąż mi to powtarzają. Oczywiście, one są częścią ścieżki alternatywnej wykonywanej wtedy, gdy klienci mają już założone konto w naszym sklepie, i dlatego są wykonywane cały czas. Łatwo im mówić! Rusz głową!: Trzymaj się. Wszyscy wiemy, że jesteś bardzo ważną częścią przypadku użycia. 152 Rozdział 3. Wymagania ulegają zmianom Zaostrz ołówek Zaostrz ołówek Ile scenariuszy można wyróżnić w przypadku użycia opisującym drzwiczki dla Tadka i Janki? Na ile sposobów można przejść przypadek użycia opisujący działanie drzwiczek zamówionych przez Tadka i Jankę? Pamiętaj, że czasami konieczne jest wykorzystanie jednej z istniejących ścieżek alternatywnych, a niekiedy wszystkie ścieżki alternatywne można w ogóle pominąć. Drzwiczki dla psa, dla Tadka i Janki, wersja 2.3 Jak działają drzwiczki Ścieżka główna 1. Azor szczeka, by właściciele wypuścili go na spacer. „słyszy” szczekanie Azora. 2. System rozpoznawania dźwięków 3. System rozpoznawania dźwięków 4. Drzwiczki dla psa otwierają
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Analiza i projektowanie obiektowe. Rusz głową!
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ą: