• Naucz siÄ™ zbierać wymagania od użytkowników systemu
• ZarzÄ…dzaj zmianami w specyfikacji
• Przeprowadź analizÄ™ i wykonaj projekt

Systemy informatyczne stają się coraz bardziej rozbudowane. Programowanie obiektowe znacznie ułatwia ich tworzenie i późniejsze modyfikacje, aby jednak system był sprawny i funkcjonalny, musi zostać zaprojektowany w oparciu o prawidłowo zebrane wymagania. Tu również z pomocą przychodzi metodologia obiektowa -- wzorce projektowe, język UML i odpowiednie narzędzia niezwykle ułatwiają przygotowanie dobrego projektu.

Jeśli rozbudowane przykłady, skomplikowane diagramy i niezrozumiałe wywody teoretyczne wywołują w Tobie niechęć, koniecznie sięgnij po tę książkę! Dzięki niej poznasz metody analizy i projektowania obiektowego w nietypowy i ciekawy sposób, wykorzystujący najnowsze teorie skutecznego przekazywania wiedzy. Przeczytasz o tym, w jaki sposób warto gromadzić wymagania i oczekiwania użytkowników wobec projektowanego systemu, jak uwzględniać w projekcie postulowane zmiany i przeprowadzać proces analizy obiektowej. Nauczysz się stosować notację UML do przedstawiania struktury systemu i przetwarzanych przez niego danych. Dowiesz się także, jak testować projektowany system.

• Zasady i cele projektowania obiektowego
• Gromadzenie wymagaÅ„
• Przypadki użycia
• Analiza obiektowa
• Diagramy UML przedstawiajÄ…ce strukturÄ™ systemu
• Korzystanie ze wzorców projektowych
• Projektowanie architektury systemu
• Testowanie

Osoby które kupowały "Head First Object-Oriented Analysis and Design. Edycja polska (Rusz głową!)", wybierały także:

• Zosta 149,00 zÅ‚, (44,70 zÅ‚ -70%)
• Metoda dziel i zwyci 89,00 zÅ‚, (26,70 zÅ‚ -70%)
• Matematyka. Kurs video. Teoria dla programisty i data science 399,00 zÅ‚, (119,70 zÅ‚ -70%)
• Design Thinking. Kurs video. My 129,00 zÅ‚, (38,70 zÅ‚ -70%)
• Konwolucyjne sieci neuronowe. Kurs video. Tensorflow i Keras w rozpoznawaniu obraz 149,00 zÅ‚, (44,70 zÅ‚ -70%)

Spis treści

Head First Object-Oriented Analysis and Design. Edycja polska (Rusz głową!) -- spis treści

Wprowadzenie

• Dla kogo jest ta książka? (20)
  
• Wiemy, co sobie myÅ›lisz (21)
  
• Metapoznanie: myÅ›lenie o myÅ›leniu (23)
  
• ZmuÅ› swój mózg do posÅ‚uszeÅ„stwa (25)
  
• Ważne uwagi (26)
  
• Recenzenci techniczni (28)
  
• PodziÄ™kowania (29)

Rozdział 1. Tu zaczyna się wspaniałe oprogramowanie

• Rock-and-roll jest wieczny! (31)
  
• Nowa elegancka aplikacja RyÅ›ka... (33)
  
• Co przede wszystkim zmieniÅ‚byÅ› w aplikacji RyÅ›ka? (38)
  
• DoskonaÅ‚e oprogramowanie... ma wiÄ™cej niż jednÄ… z wymienionych już cech (40)
  
• WspaniaÅ‚e oprogramowanie w trzech prostych krokach (43)
  
• W pierwszej kolejnoÅ›ci skoncentruj siÄ™ na funkcjonalnoÅ›ci (48)
  
• Test (53)
  
• Szukamy problemów (55)
  
• Analiza metody search() (56)
  
• Stosuj proste zasady projektowania obiektowego (61)
  
• Projekt po raz pierwszy, projekt po raz drugi (66)
  
• Jak Å‚atwo można wprowadzać zmiany w Twojej aplikacji? (68)
  
• Poddawaj hermetyzacji to, co siÄ™ zmienia (71)
  
• Delegowanie (73)
  
• Nareszcie doskonaÅ‚e oprogramowanie (jak na razie) (76)
  
• OOA&D ma na celu tworzenie wspaniaÅ‚ego oprogramowania, a nie dodanie Ci papierkowej roboty (79)
  
• Kluczowe zagadnienia (80)

Rozdział 2. Daj im to, czego chcą

• NadszedÅ‚ czas na kolejny pokaz Twych programistycznych umiejÄ™tnoÅ›ci (84)
  
• Test programu (87)
  
• NieprawidÅ‚owe zastosowanie (coÅ› w tym stylu) (89)
  
• Czym jest wymaganie? (90)
  
• Tworzenie listy wymagaÅ„ (92)
  
• Zaplanuj, co może siÄ™ popsuć w systemie (96)
  
• Problemy w dziaÅ‚aniu systemu sÄ… obsÅ‚ugiwane przez Å›cieżki alternatywne (98)
  
• (Ponowne) przedstawienie przypadku użycia (100)
  
• Jeden przypadek użycia, trzy części (102)
  
• Porównaj wymagania z przypadkami użycia (106)
  
• Twój system musi dziaÅ‚ać w praktyce (113)
  
• Poznajemy SzczęśliwÄ… ÅšcieżkÄ™ (120)
  
• Przybornik projektanta (134)

Rozdział 3. Kocham cię, jesteś doskonały... A teraz - zmień się

• JesteÅ› bohaterem! (138)
  
• JesteÅ› pataÅ‚achem! (139)
  
• Jedyny pewnik analizy i projektowania obiektowego (141)
  
• Åšcieżka oryginalna? Åšcieżka alternatywna? Kto to wie? (146)
  
• Przypadki użycia muszÄ… być zrozumiaÅ‚e przede wszystkim dla Ciebie (148)
  
• Od startu do mety: jeden scenariusz (150)
  
• Wyznanie Åšcieżki Alternatywnej (152)
  
• UzupeÅ‚nienie listy wymagaÅ„ (156)
  
• Powielanie kodu jest bardzo zÅ‚ym pomysÅ‚em (164)
  
• Ostateczny test drzwiczek (166)
  
• Napisz swojÄ… wÅ‚asnÄ… zasadÄ™ projektowÄ…! (167)
  
• Przybornik projektanta (168)

Rozdział 4. Zaczynamy używać naszych aplikacji w rzeczywistym świecie

• Jeden pies, dwa psy, trzy psy, cztery... (170)
  
• Twoje oprogramowanie ma kontekst (171)
  
• OkreÅ›l przyczynÄ™ problemu (172)
  
• Zaplanuj rozwiÄ…zanie (173)
  
• Opowieść o dwóch programistach (180)
  
• Delegowanie w kodzie Szymka - analiza szczegółowa (184)
  
• PotÄ™ga aplikacji, których elementy sÄ… ze sobÄ… luźno powiÄ…zane (186)
  
• Zwracaj uwagÄ™ na rzeczowniki wystÄ™pujÄ…ce w przypadku użycia (191)
  
• Od dobrej analizy do dobrych klas... (204)
  
• Diagramy klas bez tajemnic (206)
  
• Diagramy klas to nie wszystko (211)
  
• Kluczowe zagadnienia (215)

Rozdział 5. (część 1.) Nic nie pozostaje wiecznie takie samo

• Firma Gitary/Instrumenty Strunowe RyÅ›ka rozwija siÄ™ (222)
  
• Klasy abstrakcyjne (225)
  
• Diagramy klas bez tajemnic (ponownie) (230)
  
• ÅšciÄ…gawka z UML-a (231)
  
• Porady dotyczÄ…ce problemów projektowych (237)
  
• Trzy kroki tworzenia wspaniaÅ‚ego oprogramowania (po raz kolejny) (239)

Rozdział 5. (część 2.) Zabierz swoje oprogramowanie na 30-minutowy trening

• Wróćmy do aplikacji wyszukiwawczej RyÅ›ka (258)
  
• DokÅ‚adniejsza analiza metody search() (261)
  
• KorzyÅ›ci, jakie daÅ‚a nam analiza (262)
  
• DokÅ‚adniejsza analiza klas instrumentów (265)
  
• Åšmierć projektu (decyzja) (270)
  
• ZmieÅ„my zÅ‚e decyzje projektowe na dobre (271)
  
• Zastosowanie "podwójnej hermetyzacji" w aplikacji RyÅ›ka (273)
  
• Nigdy nie obawiaj siÄ™ wprowadzania zmian (279)
  
• Elastyczna aplikacja RyÅ›ka (282)
  
• Testowanie dobrze zaprojektowanej aplikacji RyÅ›ka (285)
  
• Jak Å‚atwo można zmodyfikować aplikacjÄ™ RyÅ›ka? (289)
  
• Wielki konkurs Å‚atwoÅ›ci modyfikacji (290)
  
• Spójna klasa realizuje jednÄ… operacjÄ™ naprawdÄ™ dobrze (293)
  
• PrzeglÄ…d zmian wprowadzanych w oprogramowaniu dla RyÅ›ka (296)
  
• DoskonaÅ‚e oprogramowanie to zazwyczaj takie, które jest "wystarczajÄ…co dobre" (298)
  
• Przybornik projektanta (300)

Rozdział 6. "Nazywam się Art Vandelay... jestem Architektem"

• RozwiÄ…zywanie dużych problemów (302)
  
• Wszystko zależy od sposobu spojrzenia na duży problem (303)
  
• Wymagania i przypadki użycia to dobry punkt wyjÅ›ciowy... (308)
  
• Potrzebujemy znacznie wiÄ™cej informacji (309)
  
• OkreÅ›lanie możliwoÅ›ci (312)
  
• Możliwość czy wymaganie (314)
  
• Przypadki użycia nie zawsze pomagajÄ… ujrzeć ogólny obraz tworzonego oprogramowania (316)
  
• Diagramy przypadków użycia (318)
  
• MaÅ‚y aktor (323)
  
• Aktorzy to także ludzie (no dobrze... nie zawsze) (324)
  
• A zatem zabawmy siÄ™ w analizÄ™ dziedziny! (329)
  
• Dziel i rzÄ…dź (331)
  
• Nie zapominaj, kim tak naprawdÄ™ jest klient (335)
  
• Czym jest wzorzec projektowy? (337)
  
• PotÄ™ga OOA&D (i trochÄ™ zdrowego rozsÄ…dku) (340)
  
• Przybornik projektanta (342)

Rozdział 7. Porządkowanie chaosu

• Czy czujesz siÄ™ nieco przytÅ‚oczony? (344)
  
• Potrzebujemy architektury (346)
  
• Zacznijmy od funkcjonalnoÅ›ci (349)
  
• Co ma znaczenie dla architektury (351)
  
• Trzy P dotyczÄ…ce architektury (352)
  
• Wszystko sprowadza siÄ™ do problemu ryzyka (358)
  
• Scenariusze pomagajÄ… zredukować ryzyko (361)
  
• Koncentruj siÄ™ na jednej możliwoÅ›ci w danej chwili (369)
  
• Architektura jest strukturÄ… Twojego projektu (371)
  
• PodobieÅ„stwa po raz kolejny (375)
  
• Analiza podobieÅ„stw: Å›cieżka do elastycznego oprogramowania (381)
  
• Co to znaczy? Zapytaj klienta (386)
  
• Zmniejszanie ryzyka pomaga pisać wspaniaÅ‚e oprogramowanie (391)
  
• Kluczowe zagadnienia (392)

Rozdział 8. Oryginalność jest przereklamowana

• Zasada projektowania - w skrócie (396)
  
• Zasada otwarte-zamkniÄ™te (397)
  
• OCP, krok po kroku (399)
  
• Zasada nie powtarzaj siÄ™ (402)
  
• Zasada DRY dotyczy obsÅ‚ugi jednego wymagania w jednym miejscu (404)
  
• Zasada jednej odpowiedzialnoÅ›ci (410)
  
• Wykrywanie wielu odpowiedzialnoÅ›ci (412)
  
• Przechodzenie od wielu do jednej odpowiedzialnoÅ›ci (415)
  
• Zasada podstawienia Liskov (420)
  
• Studium bÅ‚Ä™dnego sposobu korzystania z dziedziczenia (421)
  
• LSP ujawnia ukryte problemy zwiÄ…zane ze strukturÄ… dziedziczenia (422)
  
• Musi istnieć możliwość zastÄ…pienia typu bazowego jego typem pochodnym (423)
  
• Naruszenia LSP sprawiajÄ…, że powstajÄ…cy kod staje siÄ™ mylÄ…cy (424)
  
• Deleguj funkcjonalność do innej klasy (426)
  
• Użyj kompozycji, by zebrać niezbÄ™dne zachowania z kilku innych klas (428)
  
• Agregacja - kompozycja bez nagÅ‚ego zakoÅ„czenia (432)
  
• Agregacja a kompozycja (433)
  
• Dziedziczenie jest jedynie jednÄ… z możliwoÅ›ci (545)
  
• Kluczowe zagadnienia (437)
  
• Przybornik projektanta (438)

Rozdział 9. Oprogramowanie jest wciąż przeznaczone dla klienta

• Twój przybornik narzÄ™dziowy powoli siÄ™ wypeÅ‚nia (442)
  
• WspaniaÅ‚e oprogramowanie tworzy siÄ™ iteracyjnie (444)
  
• Schodzenie w gÅ‚Ä…b: dwie proste opcje (445)
  
• Programowanie w oparciu o możliwoÅ›ci (446)
  
• Programowanie w oparciu o przypadki użycia (447)
  
• Dwa podejÅ›cia do tworzenia oprogramowania (448)
  
• Analiza możliwoÅ›ci (452)
  
• Pisanie scenariuszy testowych (455)
  
• Programowanie w oparciu o testy (458)
  
• PodobieÅ„stwa po raz wtóry (460)
  
• KÅ‚adziemy nacisk na podobieÅ„stwa (464)
  
• Hermetyzujemy wszystko (466)
  
• Dopasuj testy do projektu (470)
  
• Testy bez tajemnic... (472)
  
• Udowodnij klientowi, że wszystko idzie dobrze (478)
  
• Jak dotÄ…d używaliÅ›my programowania w oparciu o kontrakt (480)
  
• Tak naprawdÄ™ programowanie w oparciu o kontrakt dotyczy zaufania (481)
  
• Programowanie defensywne (482)
  
• Podziel swojÄ… aplikacjÄ™ na mniejsze fragmenty funkcjonalnoÅ›ci (491)
  
• Kluczowe zagadnienia (493)
  
• Przybornik projektanta (496)

Rozdział 10. Scalając to wszystko w jedno

• Tworzenie oprogramowania, w stylu obiektowym (500)
  
• Trans-Obiektów (504)
  
• Mapa metra w Obiektowie (506)
  
• Lista możliwoÅ›ci (509)
  
• Przypadki użycia odpowiadajÄ… zastosowaniu, możliwoÅ›ci odpowiadajÄ… funkcjonalnoÅ›ci (515)
  
• A teraz zacznij powtarzać te same czynnoÅ›ci (519)
  
• DokÅ‚adniejsza analiza sposobu reprezentacji sieci metra (521)
  
• Używać klasy Line czy też nie używać... oto jest pytanie (530)
  
• Najważniejsze sprawy zwiÄ…zane z klasÄ… Subway (536)
  
• Ochrona wÅ‚asnych klas (539)
  
• Czas na przerwÄ™ (547)
  
• Wróćmy znowu do etapu okreÅ›lania wymagaÅ„ (549)
  
• Koncentruj siÄ™ na kodzie, a potem na klientach (551)
  
• Powtarzanie sprawia, że problemy stajÄ… siÄ™ Å‚atwiejsze (555)
  
• Jak wyglÄ…da trasa? (560)
  
• Samemu sprawdź Przewodnik Komunikacyjny po Obiektowie (564)
  
• KtoÅ› chÄ™tny na trzeci cykl prac? (567)
  
• Podróż jeszcze nie dobiegÅ‚a koÅ„ca... (569)

Dodatek A Dziesięć najważniejszych tematów (których nie poruszyliśmy)

• Nr 1. JEST i MA (572)
  
• Nr 2. Sposoby zapisu przypadków użycia (574)
  
• Nr 3. Antywzorce (577)
  
• Nr 4. Karty CRC (578)
  
• Nr 5. Metryki (580)
  
• Nr 6. Diagramy sekwencji (581)
  
• Nr 7. Diagramy stanu (582)
  
• Nr 8. Testowania jednostkowe (584)
  
• Nr 9. Standardy kodowania i czytelny kod (586)
  
• Nr 10. Refaktoryzacja (588)

Dodatek B Stosowanie języka obiektowego

• UML i diagramy klas (591)
  
• Dziedziczenie (593)
  
• Polimorfizm (595)
  
• Hermetyzacja (596)
  
• Kluczowe zagadnienia (600)

Skorowidz (603)