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

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

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

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

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

• Zasady i cele projektowania obiektowego
• Metody zbierania wymagaÅ„
• Przypadki użycia i ich analiza
• Graficzna prezentacja systemu i zasad jego dziaÅ‚ania - diagramy UML
• Wzorce projektowe - sprawy skomplikowane stajÄ… siÄ™ proste, a proste jeszcze prostsze
• Projektowanie architektury systemu
• Testowanie

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

Osoby które kupowały "Analiza i projektowanie obiektowe. Rusz głową!", wybierały także:

• Ruby on Rails. Ćwiczenia 18,75 zÅ‚, (3,00 zÅ‚ -84%)
• Zen Steve'a Jobsa 29,67 zÅ‚, (8,90 zÅ‚ -70%)
• ASP.NET MVC. Kompletny przewodnik dla programistów interaktywnych aplikacji internetowych w Visual Studio 86,77 zÅ‚, (26,90 zÅ‚ -69%)
• TDD. Sztuka tworzenia dobrego kodu 48,54 zÅ‚, (19,90 zÅ‚ -59%)
• GitHub. Przyjazny przewodnik 32,90 zÅ‚, (16,45 zÅ‚ -50%)

Spis treści

Analiza i projektowanie obiektowe. 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)
  
• Zespół techniczny (28)
  
• PodziÄ™kowania (29)

1. Tu zaczyna się wspaniałe oprogramowanie

• Rock-and-roll jest wieczny! (32)
  
• 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 (42)
  
• 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)
  
• Celne spostrzeżenia (80)

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)

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)

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)
  
• Celne spostrzeżenia (215)

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

• Firma 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)

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)

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)

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)
  
• Celne spostrzeżenia (392)

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 (434)
  
• Celne spostrzeżenia (437)
  
• Przybornik projektanta (438)

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)
  
• Celne spostrzeżenia (493)
  
• Przybornik projektanta (496)

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)

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)

B Stosowanie języka obiektowego

• UML i diagramy klas (591)
  
• Dziedziczenie (593)
  
• Polimorfizm (595)
  
• Hermetyzacja (596)
  
• Celne spostrzeżenia (600)

Skorowidz (603)