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

Transkrypt

1

2 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 Gliwice tel helion@helion.pl Helion UML i wzorce projektowe. Analiza i projektowanie obiektowe oraz iteracyjny model wytwarzania aplikacji. Wydanie III Autor: Craig Larman Tłumaczenie: Justyna Walkowska ISBN: Tytuł oryginału: Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition) Format: , 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!

3 SPIS TRE CI S owo wst pne 19 Przedmowa 21 Cz I Wprowadzenie 1 Analiza i projektowanie obiektowe Czego uczy ta ksi ka? Czy to si przyda? Co jest g ównym celem nauki? Czym s analiza i projektowanie? Czym s analiza i projektowanie obiektowe? Krótki przyk ad Co to jest UML? Modelowanie graficzne jest dobre Historia Polecane materia y 43 2 Iteracyjno, ewolucyjno i zwinno 45 Wprowadzenie Czym jest UP? Czy mo na uzupe nia go innymi metodami? Czym jest metoda iteracyjna i ewolucyjna? Jak wygl da cykl ycia projektu w modelu kaskadowym? Na czym polegaj przyrostowe i ewolucyjne projektowanie oraz analiza? Czym jest planowanie iteracyjne sterowane ryzykiem i sterowane przez klienta? Jakie metody i zasady sk adaj si na podej cie zwinne? Czym jest modelowanie zwinne? Czym jest zwinny UP? Czy istniej inne wa ne praktyki UP? Jakie s fazy UP? Czym s dyscypliny UP? Jak dostosowa UP do w asnych potrzeb? Przypadek wytwórczy Symptomy braku zrozumienia UP Historia Polecane materia y 69 3 Studia przypadków 71 Wprowadzenie Co zosta o, a co nie zosta o uwzgl dnione w studiach przypadków? Strategia studiów przypadków: iteracyjne wytwarzanie aplikacji i iteracyjna nauka Studium przypadku nr 1: system sprzeda y NextGen Studium przypadku nr 2: gra Monopoly 74 Cz II Faza rozpocz cia 4 Faza rozpocz cia nie jest faz wymaga 77 Wprowadzenie Czym jest faza rozpocz cia? Ile trwa faza rozpocz cia? Które artefakty pojawiaj si ju w fazie rozpocz cia? Symptomy wiadcz ce o braku zrozumienia fazy rozpocz cia Ilo UML w fazie rozpocz cia 82 9

4 SPIS TRE CI 5 Ewoluuj ce wymagania 83 Wprowadzenie Definicja: wymagania Wymagania kaskadowe a ewolucyjne W jaki sposób umiej tnie wskazywa wymagania? Jakie s typy i kategorie wymaga? W jaki sposób artefakty UP organizuj wymagania? Czy ta ksi ka zawiera przyk ady tych artefaktów? Polecane zasoby 89 6 Przypadki u ycia 91 Wprowadzenie Przyk ad Definicja: aktorzy, scenariusze, przypadki u ycia Przypadki u ycia a Model Przypadków U ycia Motywacja: po co nam przypadki u ycia? Definicja: czy przypadki u ycia to wymagania funkcjonalne? Definicja: jakie s typy aktorów? Notacja: jakie s trzy podstawowe formaty przypadków u ycia? Przyk ad: pe ny opis przypadku u ycia Obs u sprzeda Co opisuj poszczególne sekcje? Notacja: czy istniej inne formaty zapisu przypadków u ycia? Wersja dwukolumnowa Wskazówka: opisuj sedno sprawy i odsu si od interfejsu u ytkownika Wskazówka: pisz zwi z e przypadki u ycia Wskazówka: stosuj technik czarnej skrzynki Wskazówka: przyjmij perspektyw aktora i jego celu Wskazówka: jak znajdowa przypadki u ycia? Wskazówka: jakie testy mog pomóc w identyfikacji przypadków u ycia? Zastosowanie UML: diagramy przypadków u ycia Zastosowanie UML: diagramy czynno ci Motywacja: inne zyski ze stosowania przypadków u ycia? Kontekst dla wymaga Przyk ad: gra Monopoly Proces: jak stosowa przypadki u ycia w ramach metod iteracyjnych? Historia Polecane zasoby Inne wymagania 135 Wprowadzenie 135 Artefakty zwi zane z innymi wymaganiami Czy przyk ady s kompletne? Czy te wymagania s w pe ni analizowane w fazie rozpocz cia? Wskazówka: czy te artefakty powinny trafi na stron projektu? Przyk ad NextGen: (niepe na) Specyfikacja Dodatkowa Komentarz: Specyfikacja Dodatkowa Przyk ad NextGen: (niepe na) Wizja Komentarz: Wizja Przyk ad NextGen: (niepe ny) S owniczek Komentarz: S owniczek Przyk ad NextGen: Regu y Biznesowe (Dziedzinowe) Komentarz: Regu y Dziedzinowe Proces: ewoluuj ce wymagania w metodach iteracyjnych Polecane zasoby

5 SPIS TRE CI Cz III Faza opracowywania. Iteracja-1 podstawy 8 Iteracja-1 podstawy 159 Wprowadzenie Wymagania w iteracji-1: zastosowanie najwa niejszych umiej tno ci z OOA/D Proces: fazy rozpocz cia i opracowywania Proces: planowanie nast pnej iteracji Modele dziedziny 167 Wprowadzenie Przyk ad Czym jest model dziedziny? Motywacja: po co tworzy model dziedziny? Wskazówka: jak stworzy Model Dziedziny? Jak znale klasy konceptualne? Przyk ad: znajdowanie i rysowanie klas konceptualnych Wskazówka: modelowanie zwinne szkicowanie diagramu klas Wskazówka: modelowanie zwinne czy korzysta z narz dzi? Wskazówka: obiekty raportuj ce czy umieszcza w modelu klas Receipt? Wskazówka: my l jak kartograf, pos uguj si terminami z dziedziny Wskazówka: jak modelowa wiat nierzeczywisty? Wskazówka: atrybuty a klasy Wskazówka: kiedy modelowa z u yciem klas opisowych? Asocjacje Asocjacje w modelach dziedziny Atrybuty Przyk ad: atrybuty w modelu dziedziny Podsumowanie: czy model jest poprawny? Proces: iteracyjne i ewolucyjne modelowanie dziedziny Polecane zasoby Systemowe diagramy sekwencji 207 Wprowadzenie Przyk ad: SSD dla NextGen Czym s systemowe diagramy sekwencji? Motywacja: po co rysowa SSD? Stosowanie UML: diagramy sekwencji Jak maj si SSD do przypadków u ycia? Jak nazywa zdarzenia i operacje systemowe? Jak uwzgl dni zewn trzne systemy w SSD? Jakie informacje z SSD powinny trafi do S owniczka? Przyk ad: SSD dla gry Monopoly Proces: iteracyjne i przyrostowe SSD Historia i polecane zasoby Kontrakty operacji 215 Wprowadzenie Przyk ad Z jakich sekcji sk ada si kontrakt? Definicja: czym jest operacja systemowa? Warunki ko cowe Przyk ad: warunki ko cowe operacji enteritem Wskazówka: czy aktualizowa model dziedziny? Wskazówka: kiedy warto pisa kontrakty operacji?

6 SPIS TRE CI Wskazówka: tworzenie kontraktów Przyk ad: kontrakty NextGen Przyk ad: kontrakty Monopoly Stosowanie UML: operacje, kontrakty i OCL Proces: kontrakty operacji w UP Historia Polecane zasoby Od wymaga do projektowania iteracyjnie 229 Wprowadzenie Zrobi co nale y i jak nale y iteracyjnie Prowokowanie zmian na wczesnym etapie Tylko czy analiza i modelowanie nie zaj y nam ca ych tygodni? Architektura logiczna i diagramy pakietów UML 231 Wprowadzenie Przyk ad Czym jest architektura logiczna? Co to s warstwy? Na której warstwie koncentruj si studia przypadków? Czym jest architektura oprogramowania? Stosowanie UML: diagramy pakietów Wskazówka: projektowanie warstw Wskazówka: zasada oddzielenia modelu od widoku Jaki jest zwi zek pomi dzy SSD, operacjami systemowymi i warstwami? Przyk ad: architektura logiczna i diagram pakietów NextGen Przyk ad: architektura logiczna Monopoly Polecane zasoby Zaczynamy projektowa 247 Wprowadzenie Modelowanie zwinne i szkicowanie UML Narz dzia UML CASE Ile czasu przeznaczy na UML przed rozpocz ciem kodowania? Projektowanie obiektów: czym s modelowanie statyczne i dynamiczne? Umiej tno projektowania obiektowego jest wa niejsza od znajomo ci notacji UML Inne techniki projektowania obiektowego: karty CRC Diagramy interakcji UML 255 Wprowadzenie Diagramy sekwencji i komunikacji Pocz tkuj cy projektanci za rzadko u ywaj diagramów interakcji! Cz sto stosowana notacja diagramów interakcji Podstawowa notacja diagramów sekwencji Podstawowa notacja diagramów komunikacji Diagramy klas UML 281 Wprowadzenie Stosowanie UML: notacja diagramów klas UML Definicja: projektowy diagram klas Definicja: klasyfikator Sposoby prezentacji atrybutów UML: tekst i linie asocjacji Symbol notatki: uwagi, komentarze, ograniczenia i cia a metod Operacje i metody S owa kluczowe Stereotypy, profile i znaczniki W a ciwo ci i listy w a ciwo ci UML

7 SPIS TRE CI Generalizacja, klasy abstrakcyjne, operacje abstrakcyjne Zale no ci Interfejsy O przewadze kompozycji nad agregacj Ograniczenia Asocjacja kwalifikowana Klasa asocjacyjna Klasy singletonowe Szablony klas i interfejsów Przegródki definiowane przez u ytkownika Klasa aktywna Jaki jest zwi zek pomi dzy diagramami interakcji i klas? GRASP: projektowanie obiektów i przydzia odpowiedzialno ci 303 Wprowadzenie UML a zasady projektowania Projektowanie obiektowe: przyk ad danych wej ciowych, czynno ci i wyników Odpowiedzialno i projektowanie sterowane odpowiedzialno ci GRASP: metodyczne podej cie do podstaw projektowania obiektowego Jaki jest zwi zek pomi dzy zobowi zaniami, GRASP i diagramami UML? Czym s wzorce? Co ju wiemy? Krótki przyk ad projektowania obiektowego z u yciem GRASP Zastosowanie GRASP podczas projektowania obiektowego Twórca (Creator) Ekspert (Information Expert) Niskie Sprz enie (Low Coupling) Kontroler (Controller) Wysoka Spójno (High Cohesion) Polecane zasoby Projektowanie obiektowe z u yciem GRASP przyk ady 355 Wprowadzenie Czym jest realizacja przypadku u ycia? Uwagi na temat artefaktów Co dalej? Realizacje przypadków u ycia rozpatrywanych w bie cej iteracji NextGen Realizacje przypadków u ycia rozpatrywanych w bie cej iteracji gry Monopoly Proces: iteracyjne i ewolucyjne projektowanie obiektowe Podsumowanie Widoczno obiektów 395 Wprowadzenie Wzajemna widoczno obiektów Czym jest widoczno? Odwzorowanie wyników projektowania w kodzie 401 Wprowadzenie Programowanie w ewolucyjnym modelu przyrostowym Odwzorowanie wyników projektowania w kodzie Tworzenie definicji klas na podstawie DCD Tworzenie metod na podstawie diagramów interakcji Kolekcje

8 SPIS TRE CI Wyj tki i obs uga b dów Definicja metody Sale.makeLineItem Kolejno implementacji Programowanie sterowane testami Podsumowanie zasad odwzorowywania wyników projektowania w kodzie Kod NextGen Kod Monopoly Programowanie sterowane testami i refaktoryzacja 417 Wprowadzenie Programowanie sterowane testami Refaktoryzacja Polecane zasoby Narz dzia UML i UML jako plan 427 Wprowadzenie In ynieria post powa, wsteczna i wahad owa Jaka jest opinia programistów na temat narz dzi UML CASE? Na co zwróci uwag przy wyborze narz dzia? Je li UML traktowany jest jako szkic, to jak aktualizowa diagramy po zmianach w kodzie? Polecane zasoby 430 Cz IV Faza opracowywania. Iteracja-2 wi cej wzorców 23 Iteracja-2 wymagania 433 Wprowadzenie Przej cie z iteracji-1 do iteracji Iteracja-2: krótko o wymaganiach, nacisk na projektowanie obiektowe i wzorce Szybka aktualizacja artefaktów analitycznych 439 Wprowadzenie Studium przypadku: NextGen Studium przypadku: Monopoly GRASP: wi cej obiektów, wi cej zobowi za 445 Wprowadzenie Polimorfizm (Polymorphism) Czysty Wymys (Pure Fabrication) Po rednictwo (Indirection) Ochrona Zmienno ci (Protected Variations) Wzorce projektowe GoF 467 Wprowadzenie GoF: Adapter Niektóre wzorce GRASP s uogólnieniem innych wzorców Odkrycia analityczne na poziomie projektowania Fabryka (Factory) GoF: Singleton Podsumowanie problemu zewn trznych us ug o odmiennych interfejsach GoF: Strategia (Strategy) GoF: Kompozyt (Composite) i inne zasady projektowe GoF: Fasada (Facade) GoF: Obserwator, Wydawca-Prenumerator lub Delegacja Obs ugi Zdarze Wnioski Polecane zasoby

9 SPIS TRE CI Cz V Faza opracowywania. Iteracja-3 rednio zaawansowane zagadnienia 27 Iteracja-3 wymagania 507 Wprowadzenie NextGen Monopoly Diagramy czynno ci (aktywno ci) UML i modelowanie czynno ci 509 Wprowadzenie Przyk ad Jak stosowa diagramy czynno ci? Diagramy czynno ci: wi cej notacji Wskazówki Przyk ad: diagram czynno ci NextGen Proces: diagramy czynno ci w UP Historia Diagramy stanów UML 517 Wprowadzenie Przyk ad Definicje: zdarzenia, stany, przej cia Jak stosowa diagramy stanów? Diagramy stanów UML: wi cej notacji Przyk ad: modelowanie nawigacji UI za pomoc diagramów stanów Przyk ad: diagram stanów dla przypadku u ycia NextGen Proces: diagramy stanów w UP Polecane zasoby Powi zania pomi dzy przypadkami u ycia 525 Wprowadzenie Relacja include Terminologia: konkretne, abstrakcyjne, bazowe i dodatkowe przypadki u ycia Relacja extend Relacja generalize Diagramy przypadków u ycia Udoskonalenie Modelu Dziedziny 535 Wprowadzenie Nowe koncepty w Modelu Dziedziny NextGen Generalizacja Definiowanie konceptualnych nadklas i podklas Kiedy definiowa podklasy konceptualne? Kiedy definiowa nadklasy konceptualne? Hierarchie klas konceptualnych w NextGen Abstrakcyjne klasy konceptualne Modelowanie zmian stanów Hierarchie klas konceptualnych a dziedziczenie Klasy asocjacyjne Agregacja i kompozycja Przedzia y czasowe i ceny produktów naprawa b du z iteracji Nazwy ról w asocjacjach Role jako koncepty a role w asocjacjach Elementy pochodne Asocjacje kwalifikowane Asocjacje zwrotne

10 SPIS TRE CI Wykorzystanie pakietów w celu lepszej organizacji Modelu Dziedziny Przyk ad: udoskonalenie Modelu Dziedziny Monopoly Wi cej SSD i kontraktów 569 Wprowadzenie POS NextGen Analiza architektoniczna 575 Wprowadzenie Proces: kiedy zacz analiz architektoniczn? Definicja: punkty zmienno ci i punkty ewolucji Analiza architektoniczna Etapy analizy architektonicznej Nauka cis a: identyfikacja i analiza czynników architektonicznych Przyk ad: fragment tabeli czynników architektonicznych NextGen Sztuka: rozwi zywanie problemów stwarzanych przez czynniki architektoniczne Podsumowanie motywów przewodnich analizy architektonicznej Proces: architektura iteracyjna w UP Polecane zasoby Udoskonalenie architektury logicznej 595 Wprowadzenie Przyk ad: architektura logiczna NextGen Wspó praca oparta o wzorzec Warstwy Dodatkowe uwagi na temat wzorca Warstwy Oddzielenie modelu od widoku i komunikacja wzwy Polecane zasoby Projektowanie pakietów 615 Wprowadzenie Wskazówki na temat organizacji pakietów Polecane zasoby Wi cej projektowania z zastosowaniem wzorców GoF 623 Wprowadzenie Przyk ad: POS NextGen Przej cie do us ug lokalnych. Wydajno dzi ki lokalnej pami ci podr cznej cache Obs uga b dów Przej cie do us ug lokalnych z wykorzystaniem Pe nomocnika (GoF) Wp yw wymaga niefunkcjonalnych na architektur Dost p do zewn trznych urz dze fizycznych za pomoc adapterów Fabryka Abstrakcyjna dla rodzin powi zanych obiektów Obs uga p atno ci z wykorzystaniem wzorców Polimorfizm i Zrób To Sam Przyk ad: Monopoly Podsumowanie Projektowanie szkieletu (frameworku) trwa ych danych w oparciu o wzorce 655 Wprowadzenie Problem: trwa e obiekty Rozwi zanie: us uga trwa ych danych oparta o framework Szkielety (frameworki) Wymagania wobec us ugi i szkieletu trwa ych danych Najwa niejsze idee Wzorzec Reprezentacja Obiektów w Postaci Tabel Profil modelowania danych w UML

11 SPIS TRE CI Wzorzec Identyfikator Obiektu Dost p do us ugi trwa ych danych poprzez fasad Wzorzec Odwzorowywacz Bazodanowy (Database Mapper, Database Broker) Projektowanie szkieletów z zastosowaniem wzorca Metoda Szablonowa Materializacja z zastosowaniem wzorca Metoda Szablonowa Konfiguracja odwzorowywaczy poprzez fabryk MapperFactory Wzorzec Zarz dzanie Cache Ukrycie kodu SQL wewn trz jednej klasy Stany transakcyjne i wzorzec Stan Projektowanie transakcji w oparciu o wzorzec Polecenie Leniwa materializacja z zastosowaniem wzorca Pe nomocnik Wirtualny Jak reprezentowa asocjacje w tabelach bazodanowych? Nadklasa PersistentObject a zasada rozdzielenia zagadnie Pozosta e problemy Diagramy wdro eniowe i diagramy komponentów Diagramy wdro eniowe Diagramy komponentów Dokumentacja architektury: UML i model N+1 widoków 687 Wprowadzenie Dokument Architektura Aplikacji i widoki architektoniczne Notacja: struktura dokumentu Architektura Aplikacji Przyk ad NextGen: Architektura Aplikacji Przyk ad: dokument Architektura Aplikacji Jakarta Struts Proces: iteracyjna dokumentacja architektury Polecane zasoby 701 Cz VI Dodatkowe zagadnienia Zwinne zarz dzanie projektem 705 Wprowadzenie Jak zaplanowa iteracj? Planowanie adaptacyjne Plan Faz i Plan Iteracji Jak planowa iteracje w oparciu o przypadki u ycia i scenariusze? (Nie)wiarygodno wczesnych szacunków Organizacja artefaktów Symptomy braku zrozumienia planowania iteracyjnego Polecane zasoby 713 Bibliografia 715 S owniczek 723 Skorowidz

12 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

13 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 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

14 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 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

15 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

16 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

17 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

18 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 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

19 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

20 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 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

21 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

22 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 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

23 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

24 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 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

25 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 ( posiadaj ce manifest oraz zestaw zasad opisuj cych istot metod zwinnych 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