• 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:

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)

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)

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 (207)
• 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.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)
• 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)
• 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)

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 (525)
• 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)
• 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)
• 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)