Head First Object-Oriented Analysis and Design Edycja polska.pdf

Head First Object-Oriented

Edycja polska

Autor: Brett D. McLaughlin,

Gary Pollice, David West

TĀumaczenie: Piotr Rajca

ISBN: 978-83-246-0965-9

TytuĀ oryginaĀu: Head First Object-Oriente d

Analysis and Design

Format: 200x230, stron: 616

PrzykĀady na ftp: 165 kB

Wydawnictwo Helion

ul. Koľciuszki 1c

44-100 Gliwice

tel. 032 230 98 63

e-mail: helion@helion.pl

Poznaj techniki analizy i projektowania obiektowego

¤ Naucz siķ zbieraě wymagania od uŃytkownikw 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 rwnieŃ 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 sposb,

wykorzystujĴcy najnowsze teorie skutecznego przekazywania wiedzy. Przeczytasz

o tym, w jaki sposb warto gromadziě wymagania i oczekiwania uŃytkownikw 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 wzorcw projektowych

¤ Projektowanie architektury systemu

¤ Testowanie

Analysis and Design.

Spis treści

Spis treści (skrócony)

1 Dobrze zaprojektowane aplikacje są super. Tu zaczyna się wspaniałe

oprogramowanie

2 Gromadzenie wymagań. Daj im to, czego chcą

3 Wymagania ulegają zmianom. Kocham cię, jesteś doskonały…

A teraz — zmień się

137

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

169

5 Część 1. Dobry projekt = elastyczne oprogramowanie. Nic nie pozostaje

wiecznie takie samo

221

Przerywnik. Obiektowa katastrofa

245

Część 2. Dobry projekt = elastyczne oprogramowanie. Zabierz swoje

oprogramowanie na 30-minutowy trening

257

6 Rozwiązywanie naprawdę dużych problemów. „Nazywam się Art Vandelay...

jestem Architektem”

301

7 Architektura. Porządkowanie chaosu

343

8 Zasady projektowania. Oryginalność jest przereklamowana

395

9 Iteracja i testowanie. Oprogramowanie jest wciąż przeznaczone dla klienta

441

10 Proces projektowania i analizy obiektowej. Scalając to wszystko w jedno

499

Dodatek A Pozostałości

571

Dodatek B Witamy w Obiektowie

589

Skorowidz

603

Spis treści (szczegółowy)

Wprowadzenie

Twój mózg koncentruje się na analizie i projektowaniu obiektowym. Podczas gdy Ty

starasz się czegoś nauczyć , Twój mózg robi Ci przysługę i dba o to, abyś przez przypadek nie zapamiętał

zdobywanych informacji. Myśli sobie: „Lepiej zostawić trochę miejsca na bardziej istotne sprawy, na przykład

jakich zwierząt unikać albo czy jazda na snowboardzie nago jest dobrym pomysłem”. W jaki zatem sposób

możesz oszukać swój mózg i przekonać go, że Twoje życie zależy od znajomości analizy i projektowania

obiektowego?

Dla kogo jest ta książka?

Wiemy, co sobie myślisz

Metapoznanie: myślenie o myśleniu

Zmuś swój mózg do posłuszeństwa

Ważne uwagi

Recenzenci techniczni

Podziękowania

Spis treści

1 Dobrze zaprojektowane aplikacje są super

A zatem, w jaki sposób w praktyce pisze się wspaniałe oprogramowanie?

Zawsze bardzo trudno jest określić, od czego należy zacząć . Czy aplikacja faktycznie robi to,

co powinna robić i czego od niej oczekujemy ? A co z takimi problemami jak powtarzający się kod —

przecież to nie może być dobre ani właściwe rozwiązanie, prawda? Zazwyczaj trudno jest określić, które

z wielu problemów należy rozwikłać w pierwszej kolejności, a jednocześnie mieć pewność, że podczas

wprowadzania poprawek nie popsujemy innych fragmentów aplikacji. Bez obaw. Po zakończeniu lektury

tego rozdziału będziesz już dokładnie wiedział, jak pisać doskonałe oprogramowanie , i pewnie

podążał w kierunku trwałego poprawienia sposobu tworzenia programów. I w końcu zrozumiesz,

dlaczego OOA&D to czteroliterowy skrót (pochodzący od angielskich słów: Object-Oriented Analysis

and Design , analiza i projektowanie obiektowe), który Twoja matka chciałaby , byś poznał.

Rock-and-roll jest wieczny!

Nowa elegancka aplikacja Ryśka…

Co przede wszystkim zmieniłbyś w aplikacji Ryśka?

Niby skąd mam wiedzieć, od

czego należy zacząć? Mam wrażenie, że ilekroć

zaczynam pracę nad nowym projektem, każdy ma inne

zdanie odnośnie tego, co należy zrobić w pierwszej

kolejności. Czasami zrobię coś dobrze, lecz

czasami kończy się na tym, że muszę przerobić

całą aplikację od początku, bo zacząłem w złym

miejscu. A ja chcę jedynie pisać świetne

oprogramowanie! A zatem, od czego

powinienem zacząć pisanie aplikacji

dla Ryśka?

Doskonałe oprogramowanie…

ma więcej niż jedną z wymienionych już cech

Wspaniałe oprogramowanie w trzech prostych krokach

W pierwszej kolejności skoncentruj się na funkcjonalności

Test

Szukamy problemów

Analiza metody search()

Stosuj proste zasady projektowania obiektowego

Projekt po raz pierwszy, projekt po raz drugi

Jak łatwo można wprowadzać zmiany w Twojej aplikacji?

Poddawaj hermetyzacji to, co się zmienia

Delegowanie

Nareszcie doskonałe oprogramowanie (jak na razie)

OOA&D ma na celu tworzenie wspaniałego oprogramowania,

a nie dodanie Ci papierkowej roboty

Kluczowe zagadnienia

Tu zaczyna się wspaniałe oprogramowanie

Spis treści

Gromadzenie wymagań

Daj im to, czego chcą

Każdy lubi zadowolonych klientów. Już wiesz, że pierwszy krok w pisaniu doskonałego

oprogramowania polega na upewnieniu się, czego chce klient. Ale jak się dowiedzieć, czego klient

oczekuje? Co więcej — skąd mieć pewność, że klient w ogóle wie , czego tak naprawdę chce? Właśnie

wówczas na arenę wkraczają „dobre wymagania” . W tym rozdziale dowiesz się, w jaki sposób

zadowolić klientów , upewniając się, że dostarczysz im właśnie to, czego chcą. Kiedy skończysz lekturę,

wszystkie swoje projekty będziesz mógł opatrzyć etykietą „Satysfakcja gwarantowana” i posuniesz się

o kolejny krok na drodze do tworzenia doskonałego oprogramowania… i to za każdym razem.

Nadszedł czas na kolejny pokaz Twych

programistycznych umiejętności

Test programu

Nieprawidłowe zastosowanie (coś w tym stylu)

Czym jest wymaganie?

Tworzenie listy wymagań

Zaplanuj, co może się popsuć w systemie

Problemy w działaniu systemu są obsługiwane

przez ścieżki alternatywne

(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

System

Drzw iczki

d la psa o raz

pilot s tanowią

ele menty

system u, bądź

też znajdują się

w ewnątrz niego.

Spis treści

3 Wymagania ulegają zmianom

Kocham cię, jesteś doskonały…

A teraz — zmień się

Sądzisz, że dowiedziałeś się już wszystkiego o tym, czego chciał klient? Nie tak

szybko… A zatem przeprowadziłeś rozmowy z klientem, zgromadziłeś wymagania, napisałeś przypadki

użycia, napisałeś i dostarczyłeś klientowi odlotową aplikację. W końcu nadszedł czas na miłego,

relaksującego drinka, nieprawdaż? Pewnie… aż do momentu gdy klient uzna, że tak naprawdę chce

czegoś innego niż to, co Ci powiedział . Bardzo podoba mu się to, co zrobiłeś — poważnie! — jednak

obecnie nie jest już w pełni usatysfakcjonowany . W rzeczywistym świecie wymagania zawsze się

zmieniają ; to Ty musisz sobie z tymi zmianami poradzić i pomimo nich zadbać o zadowolenie klienta.

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

public void pressButton() {

System.out.println(”Naciśnięto przycisk na pilocie...”);

if (door.isOpen()) {

door.close();

} else {

door.open();

final Timer timer = new Timer();

timer.schedule(new TimerTask() {

public void run() {

door.close();

timer.cancel();

}

}, 5000);

}

class

Remote {

press-

Button()

}

<OWY^OTK`K

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: