UML i wzorce projektowe. Analiza i projektowanie obiektowe oraz iteracyjny model wytwarzania aplikacji. Wydanie III

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 UML i wzorce projektowe. Analiza i projektowanie obiektowe oraz iteracyjny model wytwarzania aplikacji. Wydanie III Autor: Craig Larman Tłumaczenie: Justyna Walkowska ISBN: 978-83-246-2874-2 Tytuł oryginału: Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition) Format: 172 245, stron: 752 Poznaj metodologię projektowania i wytwarzania systemów informatycznych! Co to jest UML? Czym jest modelowanie zwinne? Jak wybrać narzędzia wspomagające proces projektowania? Projektanci wielokrotnie podejmowali próby opracowania sposobu prezentacji struktury i zasad działania systemów informatycznych. Poszukiwania metody, która zostałaby zaakceptowana przez rynek i uznana za standard, trwały długo i nie były łatwe. Zakończyły się jednak sukcesem, a ich efektem jest język UML. Z drugiej strony banda czterech (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides) w 1995 roku opracowała metody rozwiązywania typowych problemów wzorce projektowe. Craig Larman łączy znajomość języka UML z wiedzą na temat wzorców projektowych i przedstawia w swojej książce sposoby projektowania systemów informatycznych z wykorzystaniem języka UML 2. W trakcie lektury tego uznanego na całym świecie podręcznika dowiesz się, jak zbierać wymagania, tworzyć przypadki użycia, modelować dziedzinę, tworzyć architektury wielowarstwowe, a co najważniejsze, odkryjesz, jak wykorzystać przy tym wzorce projektowe. Najnowsze wydanie wzbogacone zostało o nowe studia przypadków, omówienie zwinnych metod projektowania oraz liczne dodatki ułatwiające naukę. Podręcznik ten jest niezastąpiony dla wszystkich osób mających styczność z procesem projektowania i wytwarzania systemów informatycznych. Przypadki użycia, diagram przypadków użycia Wykorzystanie testów do identyfikacji przypadków użycia Metody przyrostowe i ewolucyjne Cykl życia projektu w modelu kaskadowym Praktyki zwinne, modelowanie zwinne Modelowanie dziedziny Wzorce projektowe "bandy czterech" Analiza i projektowanie obiektowe Zarządzanie projektem Diagramy klas Projektowanie warstw Diagramy sekwencji i komunikacji Programowanie sterowane testami Narzędzia wspomagające UML Dołącz do grona najznamienitszych projektantów!

SPIS TRE CI S owo wst pne 19 Przedmowa 21 Cz I Wprowadzenie 1 Analiza i projektowanie obiektowe 29 1.1. Czego uczy ta ksi ka? Czy to si przyda? 29 1.2. Co jest g ównym celem nauki? 32 1.3. Czym s analiza i projektowanie? 33 1.4. Czym s analiza i projektowanie obiektowe? 33 1.5. Krótki przyk ad 34 1.6. Co to jest UML? 37 1.7. Modelowanie graficzne jest dobre 41 1.8. Historia 41 1.9. Polecane materia y 43 2 Iteracyjno, ewolucyjno i zwinno 45 Wprowadzenie 45 2.1. Czym jest UP? Czy mo na uzupe nia go innymi metodami? 46 2.2. Czym jest metoda iteracyjna i ewolucyjna? 47 2.3. Jak wygl da cykl ycia projektu w modelu kaskadowym? 51 2.4. Na czym polegaj przyrostowe i ewolucyjne projektowanie oraz analiza? 53 2.5. Czym jest planowanie iteracyjne sterowane ryzykiem i sterowane przez klienta? 56 2.6. Jakie metody i zasady sk adaj si na podej cie zwinne? 57 2.7. Czym jest modelowanie zwinne? 58 2.8. Czym jest zwinny UP? 60 2.9. Czy istniej inne wa ne praktyki UP? 62 2.10. Jakie s fazy UP? 62 2.11. Czym s dyscypliny UP? 63 2.12. Jak dostosowa UP do w asnych potrzeb? Przypadek wytwórczy 65 2.13. Symptomy braku zrozumienia UP 67 2.14. Historia 68 2.15. Polecane materia y 69 3 Studia przypadków 71 Wprowadzenie 71 3.1. Co zosta o, a co nie zosta o uwzgl dnione w studiach przypadków? 71 3.2. Strategia studiów przypadków: iteracyjne wytwarzanie aplikacji i iteracyjna nauka 73 3.3. Studium przypadku nr 1: system sprzeda y NextGen 73 3.4. Studium przypadku nr 2: gra Monopoly 74 Cz II Faza rozpocz cia 4 Faza rozpocz cia nie jest faz wymaga 77 Wprowadzenie 77 4.1. Czym jest faza rozpocz cia? 78 4.2. Ile trwa faza rozpocz cia? 79 4.3. Które artefakty pojawiaj si ju w fazie rozpocz cia? 79 4.4. Symptomy wiadcz ce o braku zrozumienia fazy rozpocz cia 81 4.5. Ilo UML w fazie rozpocz cia 82 9

SPIS TRE CI 5 Ewoluuj ce wymagania 83 Wprowadzenie 83 5.1. Definicja: wymagania 84 5.2. Wymagania kaskadowe a ewolucyjne 84 5.3. W jaki sposób umiej tnie wskazywa wymagania? 85 5.4. Jakie s typy i kategorie wymaga? 86 5.5. W jaki sposób artefakty UP organizuj wymagania? 87 5.6. Czy ta ksi ka zawiera przyk ady tych artefaktów? 88 5.7. Polecane zasoby 89 6 Przypadki u ycia 91 Wprowadzenie 91 6.1. Przyk ad 92 6.2. Definicja: aktorzy, scenariusze, przypadki u ycia 92 6.3. Przypadki u ycia a Model Przypadków U ycia 94 6.4. Motywacja: po co nam przypadki u ycia? 95 6.5. Definicja: czy przypadki u ycia to wymagania funkcjonalne? 95 6.6. Definicja: jakie s typy aktorów? 96 6.7. Notacja: jakie s trzy podstawowe formaty przypadków u ycia? 97 6.8. Przyk ad: pe ny opis przypadku u ycia Obs u sprzeda 97 6.9. Co opisuj poszczególne sekcje? 103 6.10. Notacja: czy istniej inne formaty zapisu przypadków u ycia? Wersja dwukolumnowa 110 6.11. Wskazówka: opisuj sedno sprawy i odsu si od interfejsu u ytkownika 111 6.12. Wskazówka: pisz zwi z e przypadki u ycia 113 6.13. Wskazówka: stosuj technik czarnej skrzynki 113 6.14. Wskazówka: przyjmij perspektyw aktora i jego celu 114 6.15. Wskazówka: jak znajdowa przypadki u ycia? 114 6.16. Wskazówka: jakie testy mog pomóc w identyfikacji przypadków u ycia? 119 6.17. Zastosowanie UML: diagramy przypadków u ycia 121 6.18. Zastosowanie UML: diagramy czynno ci 124 6.19. Motywacja: inne zyski ze stosowania przypadków u ycia? Kontekst dla wymaga 124 6.20. Przyk ad: gra Monopoly 125 6.21. Proces: jak stosowa przypadki u ycia w ramach metod iteracyjnych? 127 6.22. Historia 132 6.23. Polecane zasoby 132 7 Inne wymagania 135 Wprowadzenie 135 Artefakty zwi zane z innymi wymaganiami 136 7.1. Czy przyk ady s kompletne? 136 7.2. Czy te wymagania s w pe ni analizowane w fazie rozpocz cia? 136 7.3. Wskazówka: czy te artefakty powinny trafi na stron projektu? 137 7.4. Przyk ad NextGen: (niepe na) Specyfikacja Dodatkowa 138 7.5. Komentarz: Specyfikacja Dodatkowa 141 7.6. Przyk ad NextGen: (niepe na) Wizja 143 7.7. Komentarz: Wizja 146 7.8. Przyk ad NextGen: (niepe ny) S owniczek 149 7.9. Komentarz: S owniczek 150 7.10. Przyk ad NextGen: Regu y Biznesowe (Dziedzinowe) 151 7.11. Komentarz: Regu y Dziedzinowe 152 7.12. Proces: ewoluuj ce wymagania w metodach iteracyjnych 152 7.13. Polecane zasoby 155 10

SPIS TRE CI Cz III Faza opracowywania. Iteracja-1 podstawy 8 Iteracja-1 podstawy 159 Wprowadzenie 159 8.1. Wymagania w iteracji-1: zastosowanie najwa niejszych umiej tno ci z OOA/D 160 8.2. Proces: fazy rozpocz cia i opracowywania 162 8.3. Proces: planowanie nast pnej iteracji 165 9 Modele dziedziny 167 Wprowadzenie 167 9.1. Przyk ad 169 9.2. Czym jest model dziedziny? 170 9.3. Motywacja: po co tworzy model dziedziny? 174 9.4. Wskazówka: jak stworzy Model Dziedziny? 175 9.5. Jak znale klasy konceptualne? 175 9.6. Przyk ad: znajdowanie i rysowanie klas konceptualnych 179 9.7. Wskazówka: modelowanie zwinne szkicowanie diagramu klas 181 9.8. Wskazówka: modelowanie zwinne czy korzysta z narz dzi? 181 9.9. Wskazówka: obiekty raportuj ce czy umieszcza w modelu klas Receipt? 181 9.10. Wskazówka: my l jak kartograf, pos uguj si terminami z dziedziny 182 9.11. Wskazówka: jak modelowa wiat nierzeczywisty? 182 9.12. Wskazówka: atrybuty a klasy 183 9.13. Wskazówka: kiedy modelowa z u yciem klas opisowych? 183 9.14. Asocjacje 186 9.15. Asocjacje w modelach dziedziny 193 9.16. Atrybuty 194 9.17. Przyk ad: atrybuty w modelu dziedziny 201 9.18. Podsumowanie: czy model jest poprawny? 204 9.19. Proces: iteracyjne i ewolucyjne modelowanie dziedziny 204 9.20. Polecane zasoby 206 10 Systemowe diagramy sekwencji 207 Wprowadzenie 10.1. Przyk ad: SSD dla NextGen 209 10.2. Czym s systemowe diagramy sekwencji? 209 10.3. Motywacja: po co rysowa SSD? 210 10.4. Stosowanie UML: diagramy sekwencji 211 10.5. Jak maj si SSD do przypadków u ycia? 211 10.6. Jak nazywa zdarzenia i operacje systemowe? 212 10.7. Jak uwzgl dni zewn trzne systemy w SSD? 212 10.8. Jakie informacje z SSD powinny trafi do S owniczka? 213 10.9. Przyk ad: SSD dla gry Monopoly 213 10.10. Proces: iteracyjne i przyrostowe SSD 214 10.11. Historia i polecane zasoby 214 11 Kontrakty operacji 215 Wprowadzenie 215 11.1. Przyk ad 217 11.2. Z jakich sekcji sk ada si kontrakt? 217 11.3. Definicja: czym jest operacja systemowa? 217 11.4. Warunki ko cowe 218 11.5. Przyk ad: warunki ko cowe operacji enteritem 221 11.6. Wskazówka: czy aktualizowa model dziedziny? 222 11.7. Wskazówka: kiedy warto pisa kontrakty operacji? 222 11

SPIS TRE CI 11.8. Wskazówka: tworzenie kontraktów 223 11.9. Przyk ad: kontrakty NextGen 224 11.10. Przyk ad: kontrakty Monopoly 225 11.11. Stosowanie UML: operacje, kontrakty i OCL 226 11.12. Proces: kontrakty operacji w UP 227 11.13. Historia 227 11.14. Polecane zasoby 228 12 Od wymaga do projektowania iteracyjnie 229 Wprowadzenie 229 12.1. Zrobi co nale y i jak nale y iteracyjnie 230 12.2. Prowokowanie zmian na wczesnym etapie 230 12.3. Tylko czy analiza i modelowanie nie zaj y nam ca ych tygodni? 230 13 Architektura logiczna i diagramy pakietów UML 231 Wprowadzenie 231 13.1. Przyk ad 232 13.2. Czym jest architektura logiczna? Co to s warstwy? 232 13.3. Na której warstwie koncentruj si studia przypadków? 234 13.4. Czym jest architektura oprogramowania? 235 13.5. Stosowanie UML: diagramy pakietów 235 13.6. Wskazówka: projektowanie warstw 236 13.7. Wskazówka: zasada oddzielenia modelu od widoku 242 13.8. Jaki jest zwi zek pomi dzy SSD, operacjami systemowymi i warstwami? 244 13.9. Przyk ad: architektura logiczna i diagram pakietów NextGen 246 13.10. Przyk ad: architektura logiczna Monopoly 246 13.11. Polecane zasoby 246 14 Zaczynamy projektowa 247 Wprowadzenie 247 14.1. Modelowanie zwinne i szkicowanie UML 248 14.2. Narz dzia UML CASE 249 14.3. Ile czasu przeznaczy na UML przed rozpocz ciem kodowania? 250 14.4. Projektowanie obiektów: czym s modelowanie statyczne i dynamiczne? 250 14.5. Umiej tno projektowania obiektowego jest wa niejsza od znajomo ci notacji UML 252 14.6. Inne techniki projektowania obiektowego: karty CRC 252 15 Diagramy interakcji UML 255 Wprowadzenie 255 15.1. Diagramy sekwencji i komunikacji 256 15.2. Pocz tkuj cy projektanci za rzadko u ywaj diagramów interakcji! 259 15.3. Cz sto stosowana notacja diagramów interakcji 259 15.4. Podstawowa notacja diagramów sekwencji 261 15.5. Podstawowa notacja diagramów komunikacji 273 16 Diagramy klas UML 281 Wprowadzenie 281 16.1. Stosowanie UML: notacja diagramów klas UML 282 16.2. Definicja: projektowy diagram klas 283 16.3. Definicja: klasyfikator 283 16.4. Sposoby prezentacji atrybutów UML: tekst i linie asocjacji 284 16.5. Symbol notatki: uwagi, komentarze, ograniczenia i cia a metod 287 16.6. Operacje i metody 288 16.7. S owa kluczowe 290 16.8. Stereotypy, profile i znaczniki 291 16.9. W a ciwo ci i listy w a ciwo ci UML 292 12

SPIS TRE CI 16.10. Generalizacja, klasy abstrakcyjne, operacje abstrakcyjne 292 16.11. Zale no ci 293 16.12. Interfejsy 295 16.13. O przewadze kompozycji nad agregacj 296 16.14. Ograniczenia 297 16.15. Asocjacja kwalifikowana 298 16.16. Klasa asocjacyjna 299 16.17. Klasy singletonowe 299 16.18. Szablony klas i interfejsów 300 16.19. Przegródki definiowane przez u ytkownika 300 16.20. Klasa aktywna 301 16.21. Jaki jest zwi zek pomi dzy diagramami interakcji i klas? 301 17 GRASP: projektowanie obiektów i przydzia odpowiedzialno ci 303 Wprowadzenie 303 17.1. UML a zasady projektowania 304 17.2. Projektowanie obiektowe: przyk ad danych wej ciowych, czynno ci i wyników 304 17.3. Odpowiedzialno i projektowanie sterowane odpowiedzialno ci 308 17.4. GRASP: metodyczne podej cie do podstaw projektowania obiektowego 309 17.5. Jaki jest zwi zek pomi dzy zobowi zaniami, GRASP i diagramami UML? 310 17.6. Czym s wzorce? 311 17.7. Co ju wiemy? 313 17.8. Krótki przyk ad projektowania obiektowego z u yciem GRASP 314 17.9. Zastosowanie GRASP podczas projektowania obiektowego 324 17.10. Twórca (Creator) 325 17.11. Ekspert (Information Expert) 327 17.12. Niskie Sprz enie (Low Coupling) 332 17.13. Kontroler (Controller) 336 17.14. Wysoka Spójno (High Cohesion) 348 17.15. Polecane zasoby 353 18 Projektowanie obiektowe z u yciem GRASP przyk ady 355 Wprowadzenie 355 18.1. Czym jest realizacja przypadku u ycia? 356 18.2. Uwagi na temat artefaktów 358 18.3. Co dalej? 361 18.4. Realizacje przypadków u ycia rozpatrywanych w bie cej iteracji NextGen 361 18.5. Realizacje przypadków u ycia rozpatrywanych w bie cej iteracji gry Monopoly 382 18.6. Proces: iteracyjne i ewolucyjne projektowanie obiektowe 392 18.7. Podsumowanie 394 19 Widoczno obiektów 395 Wprowadzenie 395 19.1. Wzajemna widoczno obiektów 395 19.2. Czym jest widoczno? 396 20 Odwzorowanie wyników projektowania w kodzie 401 Wprowadzenie 401 20.1. Programowanie w ewolucyjnym modelu przyrostowym 402 20.2. Odwzorowanie wyników projektowania w kodzie 403 20.3. Tworzenie definicji klas na podstawie DCD 403 20.4. Tworzenie metod na podstawie diagramów interakcji 404 20.5. Kolekcje 406 13

SPIS TRE CI 20.6. Wyj tki i obs uga b dów 407 20.7. Definicja metody Sale.makeLineItem 407 20.8. Kolejno implementacji 408 20.9. Programowanie sterowane testami 408 20.10. Podsumowanie zasad odwzorowywania wyników projektowania w kodzie 409 20.11. Kod NextGen 409 20.12. Kod Monopoly 412 21 Programowanie sterowane testami i refaktoryzacja 417 Wprowadzenie 417 21.1. Programowanie sterowane testami 418 21.2. Refaktoryzacja 421 21.3. Polecane zasoby 425 22 Narz dzia UML i UML jako plan 427 Wprowadzenie 427 22.1. In ynieria post powa, wsteczna i wahad owa 428 22.2. Jaka jest opinia programistów na temat narz dzi UML CASE? 429 22.3. Na co zwróci uwag przy wyborze narz dzia? 429 22.4. Je li UML traktowany jest jako szkic, to jak aktualizowa diagramy po zmianach w kodzie? 430 22.5. Polecane zasoby 430 Cz IV Faza opracowywania. Iteracja-2 wi cej wzorców 23 Iteracja-2 wymagania 433 Wprowadzenie 433 23.1. Przej cie z iteracji-1 do iteracji-2 434 23.2. Iteracja-2: krótko o wymaganiach, nacisk na projektowanie obiektowe i wzorce 435 24 Szybka aktualizacja artefaktów analitycznych 439 Wprowadzenie 439 24.1. Studium przypadku: NextGen 439 24.2. Studium przypadku: Monopoly 441 25 GRASP: wi cej obiektów, wi cej zobowi za 445 Wprowadzenie 445 25.1. Polimorfizm (Polymorphism) 446 25.2. Czysty Wymys (Pure Fabrication) 453 25.3. Po rednictwo (Indirection) 458 25.4. Ochrona Zmienno ci (Protected Variations) 459 26 Wzorce projektowe GoF 467 Wprowadzenie 467 26.1. GoF: Adapter 468 26.2. Niektóre wzorce GRASP s uogólnieniem innych wzorców 470 26.3. Odkrycia analityczne na poziomie projektowania 471 26.4. Fabryka (Factory) 472 26.5. GoF: Singleton 474 26.6. Podsumowanie problemu zewn trznych us ug o odmiennych interfejsach 478 26.7. GoF: Strategia (Strategy) 479 26.8. GoF: Kompozyt (Composite) i inne zasady projektowe 483 26.9. GoF: Fasada (Facade) 492 26.10. GoF: Obserwator, Wydawca-Prenumerator lub Delegacja Obs ugi Zdarze 495 26.11. Wnioski 502 26.12. Polecane zasoby 503 14

SPIS TRE CI Cz V Faza opracowywania. Iteracja-3 rednio zaawansowane zagadnienia 27 Iteracja-3 wymagania 507 Wprowadzenie 507 27.1. NextGen 508 27.2. Monopoly 508 28 Diagramy czynno ci (aktywno ci) UML i modelowanie czynno ci 509 Wprowadzenie 509 28.1. Przyk ad 510 28.2. Jak stosowa diagramy czynno ci? 511 28.3. Diagramy czynno ci: wi cej notacji 513 28.4. Wskazówki 514 28.5. Przyk ad: diagram czynno ci NextGen 515 28.6. Proces: diagramy czynno ci w UP 516 28.7. Historia 516 29 Diagramy stanów UML 517 Wprowadzenie 517 29.1. Przyk ad 518 29.2. Definicje: zdarzenia, stany, przej cia 518 29.3. Jak stosowa diagramy stanów? 519 29.4. Diagramy stanów UML: wi cej notacji 521 29.5. Przyk ad: modelowanie nawigacji UI za pomoc diagramów stanów 522 29.6. Przyk ad: diagram stanów dla przypadku u ycia NextGen 523 29.7. Proces: diagramy stanów w UP 524 29.8. Polecane zasoby 524 30 Powi zania pomi dzy przypadkami u ycia 525 Wprowadzenie 30.1. Relacja include 526 30.2. Terminologia: konkretne, abstrakcyjne, bazowe i dodatkowe przypadki u ycia 529 30.3. Relacja extend 530 30.4. Relacja generalize 532 30.5. Diagramy przypadków u ycia 532 31 Udoskonalenie Modelu Dziedziny 535 Wprowadzenie 535 31.1. Nowe koncepty w Modelu Dziedziny NextGen 536 31.2. Generalizacja 538 31.3. Definiowanie konceptualnych nadklas i podklas 539 31.4. Kiedy definiowa podklasy konceptualne? 542 31.5. Kiedy definiowa nadklasy konceptualne? 544 31.6. Hierarchie klas konceptualnych w NextGen 545 31.7. Abstrakcyjne klasy konceptualne 548 31.8. Modelowanie zmian stanów 549 31.9. Hierarchie klas konceptualnych a dziedziczenie 550 31.10. Klasy asocjacyjne 550 31.11. Agregacja i kompozycja 553 31.12. Przedzia y czasowe i ceny produktów naprawa b du z iteracji-1 556 31.13. Nazwy ról w asocjacjach 557 31.14. Role jako koncepty a role w asocjacjach 557 31.15. Elementy pochodne 558 31.16. Asocjacje kwalifikowane 559 31.17. Asocjacje zwrotne 560 15

SPIS TRE CI 31.18. Wykorzystanie pakietów w celu lepszej organizacji Modelu Dziedziny 560 31.19. Przyk ad: udoskonalenie Modelu Dziedziny Monopoly 566 32 Wi cej SSD i kontraktów 569 Wprowadzenie 569 32.1. POS NextGen 569 33 Analiza architektoniczna 575 Wprowadzenie 575 33.1. Proces: kiedy zacz analiz architektoniczn? 576 33.2. Definicja: punkty zmienno ci i punkty ewolucji 576 33.3. Analiza architektoniczna 577 33.4. Etapy analizy architektonicznej 578 33.5. Nauka cis a: identyfikacja i analiza czynników architektonicznych 579 33.6. Przyk ad: fragment tabeli czynników architektonicznych NextGen 582 33.7. Sztuka: rozwi zywanie problemów stwarzanych przez czynniki architektoniczne 582 33.8. Podsumowanie motywów przewodnich analizy architektonicznej 591 33.9. Proces: architektura iteracyjna w UP 592 33.10. Polecane zasoby 593 34 Udoskonalenie architektury logicznej 595 Wprowadzenie 595 34.1. Przyk ad: architektura logiczna NextGen 596 34.2. Wspó praca oparta o wzorzec Warstwy 601 34.3. Dodatkowe uwagi na temat wzorca Warstwy 607 34.4. Oddzielenie modelu od widoku i komunikacja wzwy 612 34.5. Polecane zasoby 613 35 Projektowanie pakietów 615 Wprowadzenie 615 35.1. Wskazówki na temat organizacji pakietów 616 35.2. Polecane zasoby 622 36 Wi cej projektowania z zastosowaniem wzorców GoF 623 Wprowadzenie 623 36.1. Przyk ad: POS NextGen 624 36.2. Przej cie do us ug lokalnych. Wydajno dzi ki lokalnej pami ci podr cznej cache 624 36.3. Obs uga b dów 629 36.4. Przej cie do us ug lokalnych z wykorzystaniem Pe nomocnika (GoF) 635 36.5. Wp yw wymaga niefunkcjonalnych na architektur 638 36.6. Dost p do zewn trznych urz dze fizycznych za pomoc adapterów 639 36.7. Fabryka Abstrakcyjna dla rodzin powi zanych obiektów 641 36.8. Obs uga p atno ci z wykorzystaniem wzorców Polimorfizm i Zrób To Sam 644 36.9. Przyk ad: Monopoly 649 36.10. Podsumowanie 653 37 Projektowanie szkieletu (frameworku) trwa ych danych w oparciu o wzorce 655 Wprowadzenie 655 37.1. Problem: trwa e obiekty 656 37.2. Rozwi zanie: us uga trwa ych danych oparta o framework 657 37.3. Szkielety (frameworki) 657 37.4. Wymagania wobec us ugi i szkieletu trwa ych danych 658 37.5. Najwa niejsze idee 659 37.6. Wzorzec Reprezentacja Obiektów w Postaci Tabel 659 37.7. Profil modelowania danych w UML 660 16

SPIS TRE CI 37.8. Wzorzec Identyfikator Obiektu 660 37.9. Dost p do us ugi trwa ych danych poprzez fasad 661 37.10. Wzorzec Odwzorowywacz Bazodanowy (Database Mapper, Database Broker) 662 37.11. Projektowanie szkieletów z zastosowaniem wzorca Metoda Szablonowa 664 37.12. Materializacja z zastosowaniem wzorca Metoda Szablonowa 665 37.13. Konfiguracja odwzorowywaczy poprzez fabryk MapperFactory 670 37.14. Wzorzec Zarz dzanie Cache 671 37.15. Ukrycie kodu SQL wewn trz jednej klasy 671 37.16. Stany transakcyjne i wzorzec Stan 672 37.17. Projektowanie transakcji w oparciu o wzorzec Polecenie 676 37.18. Leniwa materializacja z zastosowaniem wzorca Pe nomocnik Wirtualny 678 37.19. Jak reprezentowa asocjacje w tabelach bazodanowych? 681 37.20. Nadklasa PersistentObject a zasada rozdzielenia zagadnie 681 37.21. Pozosta e problemy 682 38 Diagramy wdro eniowe i diagramy komponentów 683 38.1. Diagramy wdro eniowe 683 38.2. Diagramy komponentów 685 39 Dokumentacja architektury: UML i model N+1 widoków 687 Wprowadzenie 687 39.1. Dokument Architektura Aplikacji i widoki architektoniczne 688 39.2. Notacja: struktura dokumentu Architektura Aplikacji 691 39.3. Przyk ad NextGen: Architektura Aplikacji 692 39.4. Przyk ad: dokument Architektura Aplikacji Jakarta Struts 697 39.5. Proces: iteracyjna dokumentacja architektury 701 39.6. Polecane zasoby 701 Cz VI Dodatkowe zagadnienia 703 40 Zwinne zarz dzanie projektem 705 Wprowadzenie 705 40.1. Jak zaplanowa iteracj? 706 40.2. Planowanie adaptacyjne 706 40.3. Plan Faz i Plan Iteracji 708 40.4. Jak planowa iteracje w oparciu o przypadki u ycia i scenariusze? 708 40.5. (Nie)wiarygodno wczesnych szacunków 711 40.6. Organizacja artefaktów 712 40.7. Symptomy braku zrozumienia planowania iteracyjnego 713 40.8. Polecane zasoby 713 Bibliografia 715 S owniczek 723 Skorowidz 727 17

Rozdzia 2 ITERACYJNO, EWOLUCYJNO I ZWINNO Metoda przyrostowa powinna by stosowana jedynie w projektach, które maj zako czy si sukcesem. Martin Fowler Zawarto Uzasadnienie zakresu i uk adu ksi ki. Definicja procesów przyrostowego i zwinnego. Definicja podstawowych poj w UP. Wprowadzenie Metoda przyrostowa (iteracyjna) jest silnie zwi zana z najlepszymi przyk adami zastosowania OOA/D. W du ym stopniu wp yn a ona na kszta t tej ksi ki. Praktyki zwinne (ang. agile), takie jak zwinne modelowanie, pozwalaj wykorzysta UML w najbardziej efektywny sposób. Ten rozdzia przedstawia wspomniane poj cia wraz z metod UP (ang. Unified Process), która jest do popularn metod przyrostow i która pos u y nam za przyk ad. Co dalej? Poznali my ju OOA/D, teraz pora na przedstawienie metodologii przyrostowej. W nast pnym rozdziale pojawi si studia przypadków, które b d nam towarzyszy y przez reszt ksi ki, przechodz c przez trzy iteracje. 45

2 ITERACYJNO, EWOLUCYJNO I ZWINNO Przyrostowy i ewolucyjny model wytwarzania oprogramowania w przeciwie stwie do modelu kaskadowego (ang. waterfall) zak ada, e programowanie i testowanie aplikacji zaczyna si wcze nie i przebiega w krótkich, powtarzaj cych si cyklach. Z regu y programowanie rozpoczyna si jeszcze przed zako czeniem zbierania i definiowania wymaga. Wyniki testów kolejnych cykli wp ywaj na kszta t ewoluuj cej specyfikacji. Kroki procesu produkcji oprogramowania s krótkie. Du e znaczenie maj wyniki poprzednich kroków oraz adaptacja do zmieniaj cych si wymaga i za o e projektowych. Starszy model kaskadowy zak ada przeprowadzenie pe nej (cz sto opartej na przypuszczeniach) analizy wymaga i stworzenie pe nego projektu przed przyst pieniem do programowania. Badania wykazuj, e model kaskadowy przyczyni si do najwi kszego odsetka niepowodze projektów, a jego zachwalanie nie by o oparte na wiarygodnych danych statystycznych. Zgodnie z najnowszymi badaniami projekty, w których stosowano metody przyrostowe, cz ciej ko cz si sukcesem, charakteryzuj si wi ksz produktywno ci oraz mniejsz ilo ci b dów. 2.1. Czym jest UP? Czy mo na uzupe nia go innymi metodami? Proces wytwarzania oprogramowania definiuje podej cie do tworzenia, wdra- ania oraz z regu y utrzymywania oprogramowania. Unified Process (UP) [JBR99] jest przyrostowym (iteracyjnym) procesem przeznaczonym dla systemów obiektowych. Szczególn popularno zyska o jego rozwini cie o nazwie Rational Unified Process (RUP) [Kruchten00]. Z powodu popularno ci UP w rodowisku OOA/D oraz dlatego, e musia em wybra który proces w celu ilustracji omawianych zagadnie, UP wywar du y wp yw na uk ad tej ksi ki. UP jest szeroko stosowany i wspiera dobre praktyki, dlatego warto si z nim zapozna, niezale nie od tego, czy jest si profesjonalist, czy studentem szukaj cym pierwszej pracy. programowanie sterowane testami i refaktoryzacja, s. 417 UP jest elastyczny i otwarty, co umo liwia stosowanie wewn trz tego procesu rozwi za i praktyk pochodz cych z innych metod przyrostowych, jak programowanie ekstremalne (XP) czy Scrum. Przyk adowo mo liwe jest zastosowanie znanych z XP elementów, takich jak programowanie sterowane testami, refaktoryzacja i ci g a integracja. To samo mo na powiedzie o znanych ze Scrum codziennych zebraniach i wspólnym pokoju projektowym. UP nie bagatelizuje tych metod wr cz przeciwnie. W mojej pracy konsultacyjnej cz sto zach cam klientów do stosowania technik pochodz cych z ró nych metod, co wydaje mi si bardziej rozs dne ni dogmatyczne trzymanie si jednej metody i próby udowodnienia, e to w a nie ona liczb zalet przewy sza inne. UP czy w sobie wiele uznanych najlepszych praktyk, takich jak przyrostowy cykl ycia projektu i programowanie sterowane ryzykiem, daj c nam do r ki spójny i dobrze uporz dkowany opis procesu. 46

CZYM JEST METODA ITERACYJNA I EWOLUCYJNA? Podsumowuj c, umie ci em w tym rozdziale wprowadzenie do UP, poniewa : 1. UP to proces iteracyjny i przyrostowy. Iteracyjno wp ywa na sposób przedstawienia OOA/D w tej ksi ce i wi e si z najlepszym wykorzystaniem analizy i projektowania. 2. UP dostarcza struktur, wewn trz której mo na praktykowa (i obja nia ) zagadnienia OOA/D. Struktura ta jest zwi zana ze struktur tej ksi ki. 3. UP jest elastyczny, dzi ki czemu mo na go stosowa w lekkich i zwinnych podej ciach w po czeniu z praktykami znanymi z innych metod zwinnych, jak XP i Scrum (w dalszej cz ci ksi ki powiem wi cej na ten temat). Ksi ka zawiera wst p do zwinnego podej cia do UP, nie jest jednak kompletnym podr cznikiem. Przedstawia równie najwa niejsze idee i artefakty zwi zane z OOA/D oraz z analiz wymaga. A je li nie interesuje mnie UP? UP pojawia si tutaj jako przyk ad procesu, w ramach którego przyjrzymy si przyrostowej i ewolucyjnej analizie wymaga i OOA/D jaki proces musia zosta wybrany. Niemniej najwa niejsze tematy z tej ksi ki: my lenie i projektowanie obiektowe, stosowanie UML, wzorce projektowe, modelowanie zwinne, ewolucyjna analiza wymaga, pisanie przypadków u ycia itp., s niezale ne od procesu i maj zastosowanie w wielu innych nowoczesnych, przyrostowych, ewolucyjnych i zwinnych metodach, takich jak Scrum, programowanie odchudzone, DSDM, programowanie sterowane funkcjonalno ciami, programowanie adaptacyjne i inne. 2.2. Czym jest metoda iteracyjna i ewolucyjna? Metoda iteracyjna (przyrostowa) jest jedn z najwa niejszych praktyk w UP w innych nowoczesnych procesach. Cykl ycia projektu jest podzielony na pewn liczb miniprojektów o ustalonej d ugo ci (np. 3 tygodnie), nazywanych iteracjami. Wynikiem ka dej iteracji jest przetestowany, zintegrowany i uruchamialny system cz ciowy. W ka dym przyro cie przeprowadzane s : analiza wymaga, projektowanie, implementacja oraz testy. Celem podzia u cyklu ycia projektu na iteracje jest d enie do uzyskania coraz bardziej rozbudowanego i coraz lepszego systemu, dopasowanego do nowych wymaga i wniosków wyci gni tych w poszczególnych iteracjach (rysunek 2.1). Metodologi iteracyjn mo na równie okre li mianem ewolucyjnej, poniewa wytwarzany w ten sposób system ewoluuje, aby dopasowa si do zmieniaj cych si wymaga. 47

2 ITERACYJNO, EWOLUCYJNO I ZWINNO Rysunek 2.1. Metoda przyrostowa i ewolucyjna Wczesne metodologie iteracyjne by y okre lane mianem spiralnych lub ewolucyjnych [Boehm88, Gilb88]. Przyk ad Prace nad projektem mog (cho nie musz ) wygl da tak: podczas trzytygodniowej iteracji na wczesnym etapie projektu w ka dy poniedzia ek rano odbywa si odprawa zespo u, w trakcie której obja niane s zadania i cele w tej iteracji. W mi dzyczasie jedna osoba przeprowadza proces in ynierii wstecznej na wytworzonym ju kodzie (przy u yciu narz dzi CASE) i prezentuje najistotniejsze diagramy. Reszt dnia zespó sp dza przy tablicach, w parach projektuj c i rysuj c diagramy, które nast pnie s fotografowane. Powstaje troch pseudokodu i notatek projektowych. Pozosta a cz tygodnia to implementacja, testy (jednostkowe, akceptacyjne, u yteczno ci...), dalsze projektowanie, integracja oraz codzienna kompilacja kodu i tworzenie binariów z cz ciowym systemem. Inne zadania to prezentacje i ewaluacja z interesariuszami oraz planowanie kolejnej iteracji. Podej cie zastosowane w przyk adzie nie zawiera ani zbyt pospiesznego przyst pienia do kodowania, ani d ugiego okresu przygotowa, w którym analitycy chcieliby przewidzie i zaplanowa wszystkie detale przed rozpocz ciem implementacji. Planowanie zwi zane z projektem i modelem graficznym, przy do nieformalnym u yciu UML, nie zajmuje zbyt wiele czasu programi- ci/projektanci po wi caj dzie lub pó dnia na rysowanie w parach diagramów na tablicy. Wynikiem ka dej iteracji jest uruchamialny, lecz niekompletny system. Nie jest on gotowy do wdro enia do produkcji. Wdro enie jest mo liwe po pewnej liczbie iteracji, np. po 10 lub 15. 48

CZYM JEST METODA ITERACYJNA I EWOLUCYJNA? Wynik iteracji nie jest prototypem przeznaczonym do eksperymentów i odrzucenia, a metody iteracyjnej nie nale y myli z prototypowaniem. Wynik jest raczej produkcyjnym podzbiorem ostatecznego systemu. Jak radzi sobie ze zmianami w projektach przyrostowych? Podtytu jednej z ksi ek po wi conych metodzie przyrostowej to Embrace Change (czyli pogód si ze zmianami, przyjmij zmiany lub wr cz korzystaj ze zmian ) [Beck00]. Wyra a on jedn z podstawowych zasad metody przyrostowej: zamiast walki z nieuchronno ci zmian w wymaganiach, prowadzonej za pomoc skazanych na niepowodzenie pe nych, szczegó owych i zamro- onych specyfikacji i projektów tworzonych przed rozpocz ciem implementacji (w procesie kaskadowym), metoda przyrostowa i ewolucyjna zak ada, e zmiana i proces adaptacji to nieuniknione i niezb dne czynniki rozwoju. Nie znaczy to bynajmniej, e metoda iteracyjna i UP pochwalaj niekontrolowany i reakcyjny proces wkradania si nowych funkcjonalno ci. W kolejnych rozdzia ach wyja ni, w jaki sposób UP odnajduje równowag pomi dzy potrzeb uzgodnienia i ustabilizowania zbioru wymaga a zmianami pojawiaj cymi si, w miar jak interesariusze precyzuj wizj i dostosowuj j do zmieniaj cych si potrzeb rynkowych. W ka dej iteracji wybiera si pewien niewielki podzbiór wymaga, po którym nast puje do szybkie projektowanie, implementacja i testowanie. W pocz tkowych iteracjach wymagania i projekt mog odbiega od tego, czego ostatecznie b dzie oczekiwa klient. Jednak ma e kroki, podejmowane zanim zamknie si opis wymaga i powstanie pe en projekt, pozwalaj na uzyskanie natychmiastowego odzewu od u ytkowników, programistów i testerów (np. po testach obci eniowych i u yteczno ci). Te pozyskane na wczesnym etapie informacje s na wag z ota. Zespó nie musi prowadzi teoretycznych rozwa a na temat zamkni tego, sko czonego projektu. Zbiera on praktyczne dane podczas tworzenia i testowania rzeczywistych fragmentów aplikacji, dzi ki czemu ma szans zmieni lub dostosowa swoje pojmowanie wymaga i projektu. U ytkownicy ko cowi maj okazj zobaczenia cz ciowo sprawnego systemu i powiedzenia: Tak, o to prosi em, ale po wypróbowaniu chcia bym otrzyma co troch innego. To tak, ale... nie oznacza wcale pora ki. Wczesne i cz sto pojawiaj ce si cykle tak, ale... mo na wykorzysta do rozwoju aplikacji i odkrycia, co tak naprawd ma znaczenie dla interesariuszy. Nie chodzi jednak o wyra enie zgody na chaotyczne i reakcyjne programowanie, gdzie zespó bez przerwy zmienia kierunek mo liwy jest z oty rodek. Poza coraz lepszym okre leniem i zrozumieniem wymaga, przyrosty pozwalaj równie przeprowadzi testy (np. obci eniowe) potwierdzaj ce, e implementacja zmierza w dobrym kierunku, lub sugeruj ce potrzeb zmiany u podstaw architektury aplikacji w nast pnym przyro cie. Lepiej analizowa oraz sprawdza ryzykowne i kluczowe decyzje projektowe wcze niej ni pó niej. Metoda przyrostowa s u y tu wieloma przydatnymi mechanizmami. 49

2 ITERACYJNO, EWOLUCYJNO I ZWINNO Prace nad aplikacj post puj w cyklach zbuduj odbierz informacj zwrotn dostosuj. Co zrozumia e, odchylenia wymaga i projektu od idealnej cie ki s wi ksze na pocz tku cyklu ycia ni w pó niejszych przyrostach. Z czasem system zbli a si do idealnej cie ki, co wida na rysunku 2.2. Rysunek 2.2. W wyniku zbierania danych po kolejnych iteracjach i procesu adaptacji system przybli a si do idealnej cie ki. Wymagania i projekt stabilizuj si z up ywem czasu Czy s jakie zyski z metody iteracyjnej? Tak. Obejmuj one: mniejsz liczb nieudanych projektów, lepsz produktywno, mniej b dów co wykaza y badania metod przyrostowych i ewolucyjnych, wcze niejsze wykrycie i zmniejszenie ró nych rodzajów ryzyka (technicznego, zwi zanego z wymaganiami, celami, u yteczno ci itp.), wcze nie widoczny post p prac, mo liwo pozyskania informacji zwrotnej od u ytkowników na wczesnym etapie rozwoju i dostosowania si do nich, co prowadzi do powstawania systemów bardziej odpowiadaj cych rzeczywistym potrzebom interesariuszy, ograniczenie z o ono ci: zespo owi nie grozi parali wywo any zbytnim stopniem skomplikowania systemu i koniecznych do przeprowadzenia kroków, pozyskiwanie wiedzy na etapie poszczególnych przyrostów, która mo e zosta wykorzystana do ulepszenia kolejnych przyrostów. 50

JAK WYGL DA CYKL YCIA PROJEKTU W MODELU KASKADOWYM? Ile powinna trwa iteracja? Co z terminami? W wi kszo ci metod zaleca si iteracje trwaj ce od dwóch do sze ciu tygodni. Ma e kroki, natychmiastowe zbieranie informacji i adaptacja to najwa niejsze elementy takiego wytwarzania aplikacji. D u sze iteracje niweluj zyski z wyboru metodologii iteracyjnej (przyrostowej) i zwi kszaj ryzyko niepowodzenia. Jeden tydzie najcz ciej nie wystarcza do wykonania pracy wartej prezentacji i testowania, za wi cej ni sze tygodni powoduje zbytnie zwi kszenie z o ono ci i opó nia pozyskanie informacji zwrotnej. D ugo i termin zako czenia iteracji s nieprzekraczalne (ang. timeboxing). Je li podj ta zosta a decyzja o trzytygodniowej iteracji, powstaj cy w jej wyniku system musi zosta zintegrowany, przetestowany i ustabilizowany przed okre- lon dat. Je li wydaje si, e nie ma mo liwo ci dotrzymania terminu, zaleca si zmniejszenie zakresu, czyli wy czenie pewnych zada lub wymaga z przyrostu i przeniesienie ich do którego z kolejnych. 2.3. Jak wygl da cykl ycia projektu w modelu kaskadowym? W modelu kaskadowym podejmuje si prób szczegó owego zdefiniowania wszystkich wymaga, a cz sto równie prób stworzenia pe nego projektu (zestawu modeli) przed rozpocz ciem programowania. Towarzyszy im próba ustalenia wiarygodnego planu b d harmonogramu we wczesnej fazie projektu. Ostrze enie: nak adanie modelu kaskadowego na model iteracyjny Je li okazuje si, e w projekcie iteracyjnym przed rozpocz ciem programowania pisana jest wi kszo wymaga lub podejmowane s próby stworzenia wielu pot nych i szczegó owych specyfikacji b d modeli i projektów UML, oznacza to, e projekt zosta zara ony my leniem kaskadowym. Nie mo na uzna go za dobrze rokuj cy projekt iteracyjny lub zgodny z UP, niezale nie od zapewnie cz onków zespo u. wyniki bada na temat wykorzystania funkcjonalno ci, s. 85 Badania (zebrane z wielu róde i omówione w [Larman03] i [LB03]) wykaza y bez w tpienia, e zalecana w latach sze dziesi tych i siedemdziesi tych metoda kaskadowa w wi kszo ci projektów sprawdza a si bardzo le. Jest ona ci le zwi zana z wysokim odsetkiem niepowodze, mniejsz produktywno ci oraz wi ksz liczb b dów (ni projekty przyrostowe). rednio 45% funkcjonalno ci opisanych w wymaganiach stworzonych w ramach metody kaskadowej nigdy nie jest u ywanych, a szacunkowy czas trwania projektu ró ni si nawet o 400% od ko cowego rezultatu. Z perspektywy czasu wiemy, e metoda kaskadowa by a zalecana w oparciu o spekulacje i wyobra enia, a nie dowody. W odró nieniu od niej praktyki iteracyjne 51

2 ITERACYJNO, EWOLUCYJNO I ZWINNO i ewolucyjne s wspierane dowodami. Badania wykazuj, e projekty rzadziej ko cz si niepowodzeniem, produktywno jest wy sza, a b dy pojawiaj si rzadziej. Dobra rada: nie pozwól my leniu kaskadowemu wkra si do projektu przyrostowego lub opartego o UP Jeszcze raz podkre l, e my lenie kaskadowe nadal cz sto przedostaje si do projektów deklarowanych jako przyrostowe lub oparte o UP. Takie pomys y, jak: napiszmy wszystkie przypadki u ycia, zanim zaczniemy programowa lub stwórzmy mas szczegó owych modeli obiektowych w UML przed programowaniem, s przyk adami niepo danego na o enia modelu kaskadowego na model przyrostowy. Twórcy UP podaj ten powód zbyt z o on analiz i modelowanie przed rozpocz ciem projektowania jako podstawow przyczyn nieudanego wdro enia tego procesu [KL01]. Dlaczego model kaskadowy jest a tak podatny na niepowodzenia? Nie istnieje jedna poprawna odpowied na pytanie, dlaczego projekty, w których zastosowano model kaskadowy, tak cz sto ko cz si niepowodzeniem, jednak z pewno ci ma to zwi zek z b dnym za o eniem, e mo liwe jest zdefiniowanie stabilnej specyfikacji wymaga na pocz tku cyklu ycia projektu i e zmiany wprowadzane do niej w pó niejszych etapach b d niewielkie. Jest to ogromne, kosztowne nieporozumienie. Badanie przeprowadzone przez Boehma i Papaccio wykaza o, e w typowym projekcie programistycznym wymagania zmieniaj si o 25% [BP88]. Trend ten zosta potwierdzony przez inne badania, w których przetestowano tysi ce projektów, uzyskuj c jeszcze wy szy wska nik zmian: od 35 do 50% w du ych projektach, co ilustruje rysunek 2.3 [Jones97]. To niezwykle wysokie wyniki. Dane te pokazuj co, czego bole nie wiadomi s wszyscy do wiadczeni programi ci i kierownicy projektu e wytwarzanie oprogramowania (z regu y) jest dziedzin o du ej zmienno ci i niestabilno ci. Jest to dziedzina wytwarzania nowego produktu. Oprogramowanie rzadko powstaje w warunkach przewidywalnych i rzadko jest produkowane masowo, a tylko w takich dziedzinach o niewielkim stopniu zmian mo liwe jest efektywne stworzenie stabilnej specyfikacji i wiarygodnego planu na samym pocz tku. Zatem ka de podej cie do analizy, modelowania, implementacji i zarz dzania oparte na za o eniu, e elementy wp ywaj ce na kszta t projektu s sta e (czyli, innymi s owy, model kaskadowy), jest z gruntu wadliwe. To zmiana jest jedyn sta sk adow projektu programistycznego. Metody przyrostowe i ewolucyjne s przygotowane na zmiany i potrzeb adaptacji cz ciowych, ewoluuj cych specyfikacji, modeli i planów w oparciu o dane zwrotne pozyskane po ka dym przyro cie. 52

NA CZYM POLEGAJ PRZYROSTOWE I EWOLUCYJNE PROJEKTOWANIE ORAZ ANALIZA? Rysunek 2.3. Procentowy wspó czynnik zmian w projektach programistycznych ró nej wielko ci Potrzeba informacji zwrotnej i adaptacji W z o onych, zmieniaj cych si systemach (czyli w wi kszo ci projektów programistycznych) pozyskiwanie informacji zwrotnej oraz proces adaptacji to podstawowe warunki sukcesu. Mo na wyró ni nast puj ce typy informacji zwrotnej: Informacje pochodz ce z pierwszych prób implementacji, od programistów czytaj cych specyfikacj oraz z demonstracji u klienta celem ich gromadzenia jest ulepszenie i dostosowanie opisu wymaga. Informacje pochodz ce z testów i od programistów poprawienie projektu i modeli. Informacje na temat post pów zespo u implementuj cego pierwsze funkcjonalno ci stworzenie realistycznych szacunków i harmonogramu. Informacje pochodz ce od klienta oraz z rynku mog doprowadzi do zmian priorytetów poszczególnych funkcjonalno ci w nast pnej iteracji. 2.4. Na czym polegaj przyrostowe i ewolucyjne projektowanie oraz analiza? Z dotychczasowej lektury tej ksi ki mo na by wysnu mylny wniosek, e staram si przekona Czytelnika, i przeprowadzanie analizy i projektowania przed rozpocz ciem programowania jest bezwarto ciowe. Takie my lenie jest jednak b dem równie powa nym co wiara w sens i mo liwo wykonania pe nej analizy na wczesnym etapie. Istnieje rozwi zanie po rednie. Poni ej 53

2 ITERACYJNO, EWOLUCYJNO I ZWINNO przedstawiam krótki przyk ad (nieb d cy jedynym mo liwym dobrym rozwi zaniem), jak stosowa OOA/D w poprawnym, dobrze zarz dzanym projekcie UP. Zak adanych jest 20 iteracji przed oddaniem ostatecznej wersji projektu. 1. Przed rozpocz ciem pierwszej iteracji odbywaj si spotkania na temat wymaga, z okre lonym terminem zako czenia (na przyk ad dwa dni). Obecne s zarówno osoby zwi zane ze stron biznesow, jak i z programowaniem (w tym g ówny architekt aplikacji). Pierwszego dnia rano przeprowadzana jest analiza wymaga wysokiego poziomu, podczas której okre lane s nazwy przypadków u ycia i funkcjonalno ci oraz najwa niejsze wymagania niefunkcjonalne. G ówny architekt oraz klienci wybieraj 10% spo ród wymienionych wysokopoziomowych wymaga, które spe niaj nast puj ce warunki: 1) maj kluczowe znaczenie dla architektury (ich implementacja wymaga zaprojektowania, zaimplementowania i przetestowania rdzenia aplikacji), 2) maj wysok warto biznesow (klientowi bardzo na nich zale y), 3) cechuj si wysokim ryzykiem (przyk adowo wymagaj utrzymania 500 otwartych transakcji naraz). Za ó my, e w tym kroku zosta y wyodr bnione trzy przypadki u ycia: UC2, UC11 i UC14. Przez pozosta e pó tora dnia odbywa si intensywna i szczegó owa analiza wymaga funkcjonalnych i niefunkcjonalnych tych trzech przypadków u ycia. Po jej zako czeniu mamy 10% dok adnie przeanalizowanych i 90% ogólnych przypadków. 2. Przed iteracj numer 1 odbywa si spotkanie planuj ce, na którym wybierane s podzbiory najwa niejszych przypadków u ycia (podzbiory UC2, UC11 i UC14) do zaprojektowania, zaimplementowania i przetestowania w ustalonym czasie (np. cztery tygodnie). Zaimplementowanie wszystkich trzech przypadków u ycia zaj oby zbyt du o czasu. Po wyborze podzbioru funkcjonalno ci do implementacji nale y podzieli je, z pomoc zespo u programistów, na mniejsze podzadania przyrostowe. 3. Pierwsza iteracja trwa trzy lub cztery tygodnie (termin musi zosta dotrzymany). Pierwsze dwa dni up ywaj na modelowaniu i projektowaniu w parach z wykorzystaniem uproszczonych diagramów UML (i innych modeli) rysowanych na tablicach we wspólnym pokoju pod przewodnictwem g ównego architekta. Nast pnie cz onkowie zespo u projektowego przechodz z fazy modelowania do fazy implementacji. Rozpoczynaj programowanie, testowanie i integracj w oparciu o stworzone szkice, pami taj c jednak, e s one niekompletne i niedok adne. Po up ywie d u szego czasu nast puj testy: jednostkowe, akceptacyjne, obci eniowe, u yteczno ci itd. Tydzie przed ko cem iteracji zespó musi odpowiedzie na pytanie, czy mo liwe jest osi gni cie celów wyznaczonych na pocz tku, czy 54

NA CZYM POLEGAJ PRZYROSTOWE I EWOLUCYJNE PROJEKTOWANIE ORAZ ANALIZA? mo e konieczne jest ograniczenie zakresu w takim wypadku cz zada l duje na li cie to do ( do zrobienia pó niej ). We wtorek w ostatnim tygodniu nast puje zamro enie kodu. Kod musi zosta oddany, zintegrowany i przetestowany. W rod rano wynik iteracji (przyrost) jest prezentowany interesariuszom, którzy s proszeni o uwagi. 4. Pod koniec iteracji numer 1 ( roda lub czwartek) powinna si odby druga tura spotka na temat wymaga. Wymagania uzyskane w pierwszej turze zostan ponownie przeanalizowane i poprawione. Wybranych zostanie kolejnych 10 lub 15% przypadków u ycia istotnych z punktu widzenia architektury i priorytetów klienta. W wyniku tych spotka oko o 25% przypadków u ycia i wymaga niefunkcjonalnych powinno by szczegó owo opisanych, co nie znaczy, e ich opis jest idealny i nie ulegnie zmianie. 5. W pi tek rano odbywa si spotkanie, na którym planowana jest kolejna iteracja. 6. Iteracja numer 2 jest przeprowadzana w sposób analogiczny do iteracji 1. 7. W podobny sposób powinny wygl da mniej wi cej cztery iteracje i pi tur zebra na temat wymaga. Pod koniec iteracji numer 4 oko o 80 90% wymaga b dzie szczegó owo opisanych, ale zaimplementowane zostanie tylko 10% systemu. Uzyskany w ten sposób szczegó owy opis wymaga jest oparty o informacj zwrotn i proces adaptacji, w zwi zku z czym jego jako jest o wiele wy sza ni w przypadku, opartych o domys y, wymaga znanych z metody kaskadowej. 8. Min o oko o 20% czasu trwania projektu. W terminologii UP oznacza to koniec fazy opracowywania (elaboracji). Na tym etapie nale y szczegó owo oszacowa czas i wysi ek potrzebny do implementacji dok adnie opisanych wymaga. Szacunki b d do wiarygodne, poniewa zostan oparte o dotychczasowe do wiadczenia, informacj zwrotn oraz pierwsze podej- cia do programowania i testów. 9. Po osi gni ciu tego punktu potrzeba zwo ywania dodatkowych zebra po wi conych kwestii wymaga jest ma o prawdopodobna. Wymagania s ustabilizowane, ale nie kompletnie zamro one. Nast pi seria trzytygodniowych iteracji, dla których konkretne cele i zadania b d ustalane przed rozpocz ciem ka dego z nich. Spotkania podsumowuj ce poszczególne przyrosty b d si odbywa y w pi tki. Na ka dym z nich powinno zosta zadane pytanie: W oparciu o posiadan przez nas obecnie wiedz, jakie s najwa niejsze funkcjonalno ci techniczne i biznesowe, które powinni my zaimplementowa w ci gu kolejnych trzech tygodni?. Rysunek 2.4 jest ilustracj takiego projektu z o onego z 20 iteracji. Po kilku pocz tkowych iteracjach przygotowuj cych nadchodzi moment, w którym zespó mo e w bardziej wiarygodny sposób odpowiedzie na pytania co?, za ile? i kiedy?. 55

2 ITERACYJNO, EWOLUCYJNO I ZWINNO Rysunek 2.4. Analiza i projektowanie ewolucyjne wi kszo ma miejsce w pocz tkowych przyrostach 2.5. Czym jest planowanie iteracyjne sterowane ryzykiem i sterowane przez klienta? Unified Process (podobnie jak wi kszo nowych metod) zach ca do planowania cz cego w sobie cechy modelu sterowanego ryzykiem i sterowanego przez klienta. Oznacza to, e cele okre lane w pocz tkowych iteracjach wybiera si tak, by 1) zidentyfikowa i ograniczy ryzyko, 2) zaprogramowa widoczne elementy najbardziej po dane przez klienta. Planowanie sterowane ryzykiem mo na uzna za architekturocentryczne pocz tkowe iteracje maj za zadanie implementacj, przetestowanie i stabilizacj architektury oraz rdzenia systemu. Dlaczego? Poniewa niestabilna architektura to jeden z najpowa niejszych rodzajów ryzyka. 56

JAKIE METODY I ZASADY SK ADAJ SI NA PODEJ CIE ZWINNE? Iteracje w ksi ce a iteracje w rzeczywistych projektach Iteracje numer 1 w studiach przypadków zaprezentowanych w tej ksi ce maj g ównie cel edukacyjny, co stawia rzeczywiste cele projektowe na drugim miejscu. Iteracja numer 1 nie jest zatem ani sterowana ryzykiem, ani sterowana przez klienta. W rzeczywistym projekcie najpierw nale a oby zaj si rzeczami trudnymi i ryzykownymi. Jednak w ramach ksi ki ucz cej podstaw OOA/D i UML podej cie to nie mog oby si sprawdzi dlatego zaczynamy od problemów ilustruj cych podstawowe zasady. 2.6. Jakie metody i zasady sk adaj si na podej cie zwinne? Metody zwinne (ang. agile) zwykle opieraj si na podej ciu przyrostowym i ewolucyjnym, adaptacyjnym planowaniu oraz innych warto ciach i praktykach wspieraj cych zwinno, czyli szybkie i elastyczne reagowanie na zmiany. Metod zwinnych nie mo na zdefiniowa precyzyjnie, poniewa stosowane praktyki ró ni si w istotny sposób. Maj jednak wspólne elementy: krótkie iteracje o nieprzekraczalnych terminach, ewolucyjna korekta planów, wymaga i projektu. Wszystkie wspieraj rozwi zania uwzgl dniaj ce ma y stopie skomplikowania aplikacji, dobr komunikacj i samodzieln organizacj zespo ów. TDD, programowanie sterowane testami, s. 417 Przyk adowe praktyki znane ze zwinnej metody Scrum to mi dzy innymi wspólny pokój projektowy oraz samodzielne zespo y koordynowane za pomoc spotka na stoj co, na których ka dy cz onek zespo u odpowiada na trzy znane pytania. Przyk adowe praktyki z metody XP (programowanie ekstremalne) to programowanie w parach oraz programowanie sterowane testami. Ka dy proces przyrostowy, w tym UP, mo e by stosowany w duchu agile. Sam UP jest elastyczny i umo liwia stosowanie podej cia byle dzia a o, co pozwala na wykorzystanie praktyk ze Scrum, XP i innych metod. Manifest i zasady programowania zwinnego Manifest Ludzie i komunikacja Dzia aj cy kod Wspó praca z klientem Reakcja na zmian wa niejsi ni procesy i narz dzia wa niejszy ni rozbudowana dokumentacja wa niejsza od negocjacji umów wa niejsza od pod ania za planem 57

2 ITERACYJNO, EWOLUCYJNO I ZWINNO Zasady 1. Najwy szy priorytet ma satysfakcja klienta, osi gana poprzez wczesne i ci g e dostarczanie warto ciowego oprogramowania. 2. Zmiana wymaga jest mo liwa nawet na pó nym etapie wytwarzania aplikacji. Zmiana mo e wiadczy o konkurencyjno ci klienta. 3. Dzia aj ce oprogramowanie jest dostarczane w miar cz sto, w przedzia ach o d ugo ci od kilku tygodni do kilku miesi cy. Preferowane s krótsze przedzia y. 4. Reprezentanci biznesu i programi ci musz wspólnie pracowa przez ca y okres trwania projektu. 5. Projekty s tworzone wokó dobrze zmotywowanych pracowników. Je li zostan obdarzeni zaufaniem oraz otrzymaj wsparcie i dobrze przygotowane rodowisko pracy, to z pewno ci wykonaj swoj prac na medal. 6. Najefektywniejszy sposób przekazywania informacji wewn trz zespo u projektowego stanowi rozmowa twarz w twarz. 7. Dzia aj cy kod jest podstawowym miernikiem post pu. 8. Procesy zwinne promuj zrównowa ony rozwój. 9. Sponsorzy, programi ci i u ytkownicy powinni stale utrzymywa wspólne tempo. 10. Ci g e przyk adanie uwagi do doskona o ci technicznej i dobrego projektu zwi ksza zwinno. 11. Najwa niejsza jest prostota, czyli sztuka maksymalizacji ilo ci pracy, której nie trzeba wykonywa. 12. Najlepsze rozwi zania architektoniczne, opisy wymaga i projekty powstaj w zespo ach, które samodzielnie organizuj swoj prac. 13. W wyznaczonych terminach zespó analizuje swoj prac w celu zwi kszenia efektywno ci i stosuje si do powsta ych w tym procesie ustale. W 2001 r. odby o si spotkanie grupy osób zainteresowanych metodami przyrostowymi i zwinnymi (na którym ukuty zosta termin agile) w celu ustalenia wspólnej p aszczyzny. W ten sposób narodzi o si przymierze Agile Alliance (www.agilealliance.com), posiadaj ce manifest oraz zestaw zasad opisuj cych istot metod zwinnych. 2.7. Czym jest modelowanie zwinne? wi cej na temat modelowania zwinnego, s. 248 Do wiadczeni twórcy modeli znaj sekret modelowania: Celem modelowania (szkicowania UML itp.) jest przede wszystkim osi gni cie zrozumienia, a nie tworzenie dokumentacji. Innymi s owy, modelowanie mo e i powinno pomóc w lepszym zrozumieniu problemu i przestrzeni rozwi za. Z tego punktu widzenia celem tworzenia diagramów UML (co jest w a ciwie równoznaczne z celem stosowania OOA/D) nie jest stworzenie przez projektanta du ej liczby modeli, które nast pnie 58