r11-06.pdf

Rozdział 11.

Analiza i projektowanie

zorientowane obiektowo

Gdy skoncentrujesz się wyłącznie na składni języka C++, łatwo zapomnisz,

dlaczego techniki te są używane do tworzenia programów.

Z tego rozdziału dowiesz się, jak:

- używać analizy zorientowanej obiektowo w celu zrozumienia problemów, które

próbujesz rozwiązać,

- używać modelowania zorientowanego obiektowo do tworzenia stabilnych,

pewnych i możliwych do rozbudowania rozwiązań,

- używać zunifikowanego języka modelowania (UML, Unified Modeling

Language) do dokumentowania analizy i projektu.

Budowanie modeli

Jeśli chcemy ogarnąć złożony problem, musimy stworzyć „model świata”.

Zadaniem tego modelu jest symboliczne przedstawienie świata rzeczywistego.

Taki abstrakcyjny model powinien być prostszy niż świat rzeczywisty, ale

powinien poprawnie go odzwierciedlać, tak, aby na podstawie modelu można

było przewidzieć zachowanie przedmiotów istniejących w realnym świecie.

Klasycznym modelem świata jest dziecięcy globus. Model ten nie jest tylko

rzeczą; choć nigdy nie mylimy go z Ziemią, odwzorowuje on Ziemię na tyle

dobrze, że możemy poznać jej budowę oglądając powierzchnię globusa.

W modelu występują oczywiście znaczne uproszczenia. Na globusie mojej córki

nigdy nie pada deszcz, nie ma powodzi, trzęsień ziemi, itd., ale mogę go użyć, aby

przewidzieć, ile czasu zajmie mi podróż z domu do Indianapolis, gdybym musiał

osobiście stawić się w wydawnictwie i usprawiedliwić się, dlaczego rękopis się

opóźnia („Wiesz, wszystko szło dobrze, ale nagle pogubiłem się w metaforach i

przez kilka godzin nie mogłem się z nich wydostać”).

Metoda, która nie jest prostsza od modelowanej rzeczy, nie jest przydatna. Komik

Steve Wright zażartował kiedyś: „Mam mapę, na której jeden cal równa się

jednemu calowi. Mieszkam na E5.”

Projektowanie oprogramowania zorientowane obiektowo zajmuje się

budowaniem dobrych modeli. Składa się z dwóch ważnych elementów: języka

modelowania oraz procesu.

Projektowanie oprogramowania: język

modelowania

Język modelowania jest najmniej znaczącym aspektem obiektowo zorientowanej

analizy i projektowania; niestety, przyciąga on najwięcej uwagi. Język

modelowania nie jest tylko niż konwencją, określającą sposób rysowania modelu

na papierze. Możemy zdecydować, że trójkąty będą reprezentować klasy, a

przerywane linie będą symbolizować dziedziczenie. Przy takich założeniach

możemy stworzyć model geranium tak, jak pokazano na rysunku 11.1.

Rys. 11.1. Generalizacja – specjalizacja

Na tym rysunku widać, że Geranium jest szczególnym rodzajem Kwiatu. Jeśli

zarówno ty, jak i ja zgodzimy się na rysowanie diagramów dziedziczenia

(generalizacji – specjalizacji) w ten sposób, wtedy wzajemnie się zrozumiemy.

Prawdopodobnie wkrótce zechcemy stworzyć model mnóstwa złożonych

zależności, w tym celu opracujemy nasz złożony zestaw konwencji i reguł

rysowania.

Oczywiście, musimy przedstawić nasze konwencje wszystkim osobom, z którymi

pracujemy; będzie je musiał poznać każdy nowy pracownik lub współpracownik.

Możemy współpracować z innymi firmami, posiadającymi własne konwencje, w

związku z czym będziemy potrzebować czasu na wynegocjowanie wspólnej

konwencji i wyeliminowanie ewentualnych nieporozumień.

Dużo wygodniej byłoby, gdyby wszyscy zgodzili się na wspólny język

modelowania. (Wygodnie byłoby, gdyby wszyscy mieszkańcy Ziemi zgodzili się

na używanie wspólnego języka, ale to już inne zagadnienie.) Takim lingua franca

w projektowaniu oprogramowania jest UML – Unified Modeling Language

(zunifikowany język modelowania) 1 . Zadaniem UML jest udzielenie odpowiedzi

na pytania w rodzaju: „Jak rysować relację dziedziczenia?” Model geranium z

rysunku 11.1 w UML mógłby zostać przedstawiony tak, jak na rysunku 11.2.

Rys. 11.2. Specjalizacja narysowana w UML

1 Często określenie „język UML” utożsamia się z bardziej ogólnym pojęciem, jakim jest metodyka

(projektowania) UML — przyp.red.

W UML klasy są rysowane w postaci prostokątów, zaś dziedziczenie jest

przedstawiane jako linia zakończona strzałką. Strzałka przebiega w kierunku od

klasy bardziej wyspecjalizowanej do klasy bardziej ogólnej. Dla większości osób

taki kierunek strzałki jest niezgodny ze zdrowym rozsądkiem, ale nie ma to

większego znaczenia; gdy wszyscy się na to zgodzimy, cały system zadziała

poprawnie.

Szczegóły działania UML są raczej proste. Diagramy nie są trudne w użyciu i

zrozumieniu; zostaną opisane w trakcie ich wykorzystywania. Choć na temat

UML można napisać całą książkę, jednak w 90 procentach przypadków będziesz

korzystał jedynie z małego podzbioru tego języka; podzbiór ten jest bardzo łatwy

do zrozumienia.

Projektowanie oprogramowania: proces

Proces obiektowo zorientowanej analizy i projektowania jest dużo bardziej

złożony i ważniejszy niż język modelowania. Oczywiście, słyszy się o nim dużo

mniej. Dzieje się tak dlatego, że niezgodności dotyczące języka modelowania

zostały już w dużym stopniu wyeliminowane; przemysł informatyczny

zdecydował się na używanie UML. Debata na temat procesu wciąż trwa.

Metodolog jest osobą, która opracowuje lub studiuje jedną lub więcej metod.

Zwykle metodolodzy opracowują i publikują własne metody. Metoda jest

językiem modelowania i procesem. Trzech wiodących w branży metodologów to:

Grady Booch, który opracował metodę Boocha, Ivar Jacobson, który opracował

obiektowo zorientowaną inżynierię oprogramowania oraz James Rumbaugh, który

opracował technologię OMT (Object Modeling Technology). Ci trzej mężczyźni

stworzyli wspólnie tzw. Rational Unified Process (dawniej znany jako Objectory),

metodę oraz komercyjny produkt firmy Rational Software Inc. Wszyscy trzej są

zatrudnieni we wspomnianej wyżej firmie, gdzie są znani jako trzej przyjaciele

( Three Amigos ) 2 .

Ten rozdział przedstawia w ogólnym zarysie stworzony przez nich procesem. Nie

będę szczegółowo go przedstawiał, gdyż nie wierzę w niewolnicze przywiązanie

do akademickiej teorii – dużo bardziej niż postępowanie zgodne z metodą

interesuje mnie sprzedanie produktu. Inne metody również dostarczają ciekawych

rozwiązań, więc będę starał się wybierać z nich to, co wydaje mi się najlepsze i

łączyć to użyteczną całość.

Proces projektowania oprogramowania jest iteracyjny . Oznacza to, że

opracowując program „przechodzimy” przez cały proces wielokrotnie, coraz

lepiej rozumiejąc jego wymagania. Projekt ukierunkowuje implementację, ale

szczegóły, na które zwracamy uwagę podczas implementacji, wpływają z kolei na

projekt. Nie próbujemy opracować jakiegokolwiek niebanalnego projektu w

pojedynczym, uporządkowanym procesie liniowym; zamiast tego rozwijamy

fragmenty projektu, wciąż poprawiając jego założenia oraz ulepszając szczegóły

implementacji.

Opracowywanie iteracyjne można odróżnić od opracowywania kaskadowego. W

opracowywaniu kaskadowym wynik jednego etapu staje się wejściem dla

następnego, przy czym nie istnieje możliwość powrotu (patrz rysunek 11.3). W

procesie opracowywania kaskadowego wymagania są szczegółowo przedstawione

klientowi i podpisane przez niego („Tak, właśnie tego potrzebuję”); następnie

wymagania te są przekazywane projektantowi. Projektant tworzy projekt, po

czym przekazuje go programiście, w celu implementacji. Z kolei programista

2 Każdy z tych panów był autorem odrębnej metodyki projektowania.

J. Rumbaugh opracował Object Modelling Technique ( OMT ), która jest wystarczająca w przypadku

modelowania dziedziny zagadnienia (problem domain). Nie odzwierciedla jednak dokładnie ani wymagań

użytkowników systemów, ani wymagań implementacji.

I. Jacobson rozwinął Object-Oriented System Engineering ( OOSE ), który w sposób zadowalający

uwzględnia aspekty modelowania użytkowników i cyklu życia systemu jako całości. Nie odzwierciedla

jednak w sposób wystarczający sposobu modelowania dziedziny oraz aspektu implementacji.

G. Booch jest autorem Object-Oriented Analysis and Design Methods ( OOAD ), spełniającej wszelkie

wymogi w dziedzinie projektowania, konstrukcji i związków ze środowiskiem implementacji. Nie

uwzględnia jednak w sposób dostateczny fazy rozpoznania i analizy wymagań użytkowników.

UML ma stanowić syntezę wymienionych metodyk. Ma jednak wielu krytyków. W wielu publikacjach

można przeczytać, że jest to rzecz przereklamowana i w niewystarczający sposób zdefiniowana. Konkurencją

dla ciągle uzupełnianej metodyki UML jest m.in. metodyka i notacja oparta na tzw. technice “design by

contracts”. — przyp.red

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: