Szablon dla tlumaczy

5

Cz I ( Podstawy obsugi systemu WhizBang (Nagwek strony)

Rozdzia 11.

Analiza i projektowanie zorientowane obiektowo

Gdy skoncentrujesz si wycznie na skadni jzyka C++, atwo zapomnisz, dlaczego techniki te s uywane do tworzenia programw.

Z tego rozdziau dowiesz si, jak:

- uywa analizy zorientowanej obiektowo w celu zrozumienia problemw, ktre prbujesz rozwiza,

- uywa modelowania zorientowanego obiektowo do tworzenia stabilnych, pewnych i moliwych do rozbudowania rozwiza,

- uywa zunifikowanego jzyka modelowania (UML, Unified Modeling Language) do dokumentowania analizy i projektu.

Budowanie modeli

Jeli chcemy ogarn zoony 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 mona byo przewidzie zachowanie przedmiotw istniejcych w realnym wiecie.

Klasycznym modelem wiata jest dziecicy globus. Model ten nie jest tylko rzecz; cho nigdy nie mylimy go z Ziemi, odwzorowuje on Ziemi na tyle dobrze, e moemy pozna jej budow ogldajc powierzchni globusa.

W modelu wystpuj oczywicie znaczne uproszczenia. Na globusie mojej crki nigdy nie pada deszcz, nie ma powodzi, trzsie ziemi, itd., ale mog go uy, aby przewidzie, ile czasu zajmie mi podr z domu do Indianapolis, gdybym musia osobicie stawi si w wydawnictwie i usprawiedliwi si, dlaczego rkopis si opnia (Wiesz, wszystko szo dobrze, ale nagle pogubiem si w metaforach i przez kilka godzin nie mogem si z nich wydosta).

Metoda, ktra nie jest prostsza od modelowanej rzeczy, nie jest przydatna. Komik Steve Wright zaartowa kiedy: Mam map, na ktrej jeden cal rwna si jednemu calowi. Mieszkam na E5.

Projektowanie oprogramowania zorientowane obiektowo zajmuje si budowaniem dobrych modeli. Skada si z dwch wanych elementw: jzyka modelowania oraz procesu.

Projektowanie oprogramowania: jzyk modelowania

Jzyk modelowania jest najmniej znaczcym aspektem obiektowo zorientowanej analizy i projektowania; niestety, przyciga on najwicej uwagi. Jzyk modelowania nie jest tylko ni konwencj, okrelajc sposb rysowania modelu na papierze. Moemy zdecydowa, e trjkty bd reprezentowa klasy, a przerywane linie bd symbolizowa dziedziczenie. Przy takich zaoeniach moemy stworzy model geranium tak, jak pokazano na rysunku 11.1.

Rys. 11.1. Generalizacja specjalizacja

Na tym rysunku wida, e Geranium jest szczeglnym rodzajem Kwiatu. Jeli zarwno ty, jak i ja zgodzimy si na rysowanie diagramw dziedziczenia (generalizacji specjalizacji) w ten sposb, wtedy wzajemnie si zrozumiemy. Prawdopodobnie wkrtce zechcemy stworzy model mnstwa zoonych zalenoci, w tym celu opracujemy nasz zoony zestaw konwencji i regu rysowania.

Oczywicie, musimy przedstawi nasze konwencje wszystkim osobom, z ktrymi pracujemy; bdzie je musia pozna kady nowy pracownik lub wsppracownik. Moemy wsppracowa z innymi firmami, posiadajcymi wasne konwencje, w zwizku z czym bdziemy potrzebowa czasu na wynegocjowanie wsplnej konwencji i wyeliminowanie ewentualnych nieporozumie.

Duo wygodniej byoby, gdyby wszyscy zgodzili si na wsplny jzyk modelowania. (Wygodnie byoby, gdyby wszyscy mieszkacy Ziemi zgodzili si na uywanie wsplnego jzyka, ale to ju inne zagadnienie.) Takim lingua franca w projektowaniu oprogramowania jest UML Unified Modeling Language (zunifikowany jzyk modelowania). Zadaniem UML jest udzielenie odpowiedzi na pytania w rodzaju: Jak rysowa relacj dziedziczenia? Model geranium z rysunku 11.1 w UML mgby zosta przedstawiony tak, jak na rysunku 11.2.

Rys. 11.2. Specjalizacja narysowana w UML

W UML klasy s rysowane w postaci prostoktw, za dziedziczenie jest przedstawiane jako linia zakoczona strzak. Strzaka przebiega w kierunku od klasy bardziej wyspecjalizowanej do klasy bardziej oglnej. Dla wikszoci osb taki kierunek strzaki jest niezgodny ze zdrowym rozsdkiem, ale nie ma to wikszego znaczenia; gdy wszyscy si na to zgodzimy, cay system zadziaa poprawnie.

Szczegy dziaania UML s raczej proste. Diagramy nie s trudne w uyciu i zrozumieniu; zostan opisane w trakcie ich wykorzystywania. Cho na temat UML mona napisa ca ksik, jednak w 90 procentach przypadkw bdziesz korzysta jedynie z maego podzbioru tego jzyka; podzbir ten jest bardzo atwy do zrozumienia.

Projektowanie oprogramowania: proces

Proces obiektowo zorientowanej analizy i projektowania jest duo bardziej zoony i waniejszy ni jzyk modelowania. Oczywicie, syszy si o nim duo mniej. Dzieje si tak dlatego, e niezgodnoci dotyczce jzyka modelowania zostay ju w duym stopniu wyeliminowane; przemys informatyczny zdecydowa si na uywanie UML. Debata na temat procesu wci trwa.

Metodolog jest osob, ktra opracowuje lub studiuje jedn lub wicej metod. Zwykle metodolodzy opracowuj i publikuj wasne metody. Metoda jest jzykiem modelowania i procesem. Trzech wiodcych w brany metodologw to: Grady Booch, ktry opracowa metod Boocha, Ivar Jacobson, ktry opracowa obiektowo zorientowan inynieri oprogramowania oraz James Rumbaugh, ktry opracowa technologi OMT (Object Modeling Technology). Ci trzej mczyni stworzyli wsplnie tzw. Rational Unified Process (dawniej znany jako Objectory), metod oraz komercyjny produkt firmy Rational Software Inc. Wszyscy trzej s zatrudnieni we wspomnianej wyej firmie, gdzie s znani jako trzej przyjaciele (Three Amigos).

Ten rozdzia przedstawia w oglnym zarysie stworzony przez nich procesem. Nie bd szczegowo go przedstawia, gdy nie wierz w niewolnicze przywizanie do akademickiej teorii duo bardziej ni postpowanie zgodne z metod interesuje mnie sprzedanie produktu. Inne metody rwnie dostarczaj ciekawych rozwiza, wic bd stara si wybiera z nich to, co wydaje mi si najlepsze i czy to uyteczn cao.

Proces projektowania oprogramowania jest iteracyjny. Oznacza to, e opracowujc program przechodzimy przez cay proces wielokrotnie, coraz lepiej rozumiejc jego wymagania. Projekt ukierunkowuje implementacj, ale szczegy, na ktre zwracamy uwag podczas implementacji, wpywaj z kolei na projekt. Nie prbujemy opracowa jakiegokolwiek niebanalnego projektu w pojedynczym, uporzdkowanym procesie liniowym; zamiast tego rozwijamy fragmenty projektu, wci poprawiajc jego zaoenia oraz ulepszajc szczegy implementacji.

Opracowywanie iteracyjne mona odrni od opracowywania kaskadowego. W opracowywaniu kaskadowym wynik jednego etapu staje si wejciem dla nastpnego, przy czym nie istnieje moliwo powrotu (patrz rysunek 11.3). W procesie opracowywania kaskadowego wymagania s szczegowo przedstawione klientowi i podpisane przez niego (Tak, wanie tego potrzebuj); nastpnie wymagania te s przekazywane projektantowi. Projektant tworzy projekt, po czym przekazuje go programicie, w celu implementacji. Z kolei programista wrcza kod osobie zajmujcej si kontrol jakoci, ktra sprawdza jego dziaanie i przekazuje go klientowi. Wspaniae w teorii, katastrofalne w praktyce.

Rys. 11.3. Model kaskadowy

Przy opracowywaniu iteracyjnym zaczynamy od koncepcji; pomysu, jak moglibymy to zbudowa. W miar poznawania szczegw nasza wizja moe rozrasta si i ewoluowa.

Gdy ju dobrze znamy wymagania, moemy rozpocz projektowanie, doskonale zdajc sobie spraw, e pytania, ktre si wtedy pojawi, mog wprowadzi zmiany w wymaganiach. Pracujc nad projektem, zaczynamy tworzy prototyp, a nastpnie implementacj produktu. Zagadnienia pojawiajce si podczas opracowywania programu wpywaj na zmiany w projekcie i mog nawet wpyn na zrozumienie wymaga. Projektujemy i implementujemy tylko czci produktu, powtarzajc za kadym razem fazy projektowania i implementacji.

Cho poszczeglne etapy tego procesu s powtarzane, jednak opisanie ich w sposb cykliczny jest prawie niemoliwe. Dlatego opisz je w nastpujcej kolejnoci: koncepcja pocztkowa, analiza, projekt, implementacja, testowanie, prezentacja. Nie zrozum mnie le w rzeczywistoci, podczas tworzenia pojedynczego produktu przechodzimy przez kady z tych krokw wielokrotnie. Po prostu proces iteracyjny byby trudny do przedstawienia, gdybymy chcieli pokaza cykliczne wykonywanie kadego z krokw.

Oto kolejne kroki iteracyjnego procesu projektowania:

1. Konceptualizacja.

2. Analiza.

3. Projektowanie.

4. Implementacja.

5. Testowanie

6. Prezentacja.

Konceptualizacja to tworzenie wizji. Jest pojedynczym zdaniem, opisujcym dany pomys.

Analiza jest procesem zrozumienia wymaga.

Projektowanie jest procesem tworzenia modelu klas, na podstawie ktrego wygenerujemy kod.

Implementacja jest pisaniem kodu (na przykad w C++).

Testowanie jest upewnianiem si, czy wykonalimy wszystko poprawnie.

Prezentacja to pokazanie produktu klientom.

Buka z masem. Caa reszta to detale.

Kontrowersje

Pojawia si mnstwo kontrowersji na temat tego, co dzieje si na kadym etapie procesu projektowania iteracyjnego, a nawet na temat nazw poszczeglnych etapw. Zdradz ci sekret: to nie ma znaczenia. Podstawowe kroki s w kadym obiektowo zorientowanym procesie takie same: dowiedz si, co chcesz zbudowa, zaprojektuj rozwizanie i zaimplementuj projekt.

Cho w grupach dyskusyjnych i listach mailingowych dyskutujcych o technologii obiektowej dzieli si wos na czworo, podstawowa analiza i projektowanie obiektowe s niezmienne. W tym rozdziale przedstawi pewien punkt widzenia na ten temat, majc nadziej, e utworz w ten sposb fundament, na ktrym bdziesz mg stworzy architektur swojej aplikacji.

Celem tej pracy jest stworzenie kodu, ktry spenia zaoone wymagania i ktry jest stabilny, moliwy do rozbudowania i atwy do modyfikacji. Najwaniejsze jest stworzenie kodu o wysokiej jakoci (w okrelonym czasie i przy zaoonym funduszu).

Programowanie ekstremalne

Ostatnio pojawia si nowa koncepcja analizy i projektowania, zwana programowaniem ekstremalnym. Programowanie to zostao omwione przez Kena Becka w ksice Extreme Programming Expanded: Embrace Change (Addison-Wesley, 1999 ISBN 0201616416).

W tej ksice Beck przedstawia kilka radykalnych i cudownych pomysw, np. by nie kodowa niczego, dopki nie bdzie mona sprawdzi, czy to dziaa, a take programowanie w parach (dwch programistw przy jednym komputerze). Jednak z naszego punktu widzenia, najwaniejszym jego stwierdzeniem jest to, e zmianom ulegaj wymagania. Naley wic sprawi, by program dziaa i utrzymywa to dziaanie; naley projektowa dla wymaga, ktre si zna i nie tworzy projektw na wyrost.

Jest to, oczywicie, ogromne uproszczenie wypowiedzi Becka i sdz, e mgby uzna je za przeinaczenie, jednak w kadym razie wierz w jego sedno: spraw by program dziaa, tworzc go dla wymaga, ktre rozumiesz i staraj si nie doprowadzi do sytuacji, w ktrej, programu nie mona ju zmieni.

Bez zrozumienia wymaga (analiz) i planowania (projekt), trudno jest stworzy stabilny i atwy do modyfikacji program, jednak staraj si nie kontrolowa zbyt wielu czynnoci.

Pomys

Wszystkie wspaniae programy powstaj z jakiego pomysu. Kto ma wizj produktu, ktry uwaa za warty wdroenia. Poyteczne pomysy rzadko kiedy powstaj w wyniku pracy zbiorowej. Pierwsz faz obiektowo zorientowanej analizy i projektowania jest zapisanie takiego pomysu w pojedynczym zdaniu (a przynajmniej krtkim akapicie). Pomys ten staje si myl przewodni tworzonego programu, za zesp, ktry zbiera si w celu zaimplementowania tego pomysu, powinien podczas pracy odwoywa si do tej myli przewodniej w razie potrzeby nawet j modyfikujc.

Nawet jeli pomys narodzi si w wyniku zespoowej pracy dziau marketingu, wizjonerem powinna zosta jedna osoba. Jej zadaniem jest utrzymywanie czystoci idei. W miar rozwoju projektu wymagania bd ewoluowa. Harmonogram pracy moe (i powinien) modyfikowa to, co prbujesz osign w pierwszej iteracji programowania, jednak wizjoner musi zapewni, e wszystko to, co zostanie stworzone, odzwierciedli pierwotny pomys. Wanie jego bezwzgldne powicenie i arliwe zaangaowanie doprowadza do ukoczenia projektu. Gdy stracisz z oczu pierwotny zamys, twj produkt jest skazany na niepowodzenie.

Analiza wymaga

Faza konceptualizacji, w ktrej precyzowany jest pomys, jest bardzo krtka. Moe trwa krcej ni bysk olnienia poczony z czasem wymaganym do zapisania pomysu na kartce. Czsto zdarza si, e doczasz do projektu jako ekspert zorientowany obiektowo wtedy, gdy wizja zostaa ju sprecyzowana.

Niektre firmy myl pomys z wymaganiami. Wyrana wizja jest potrzebna, lecz sama w sobie nie jest wystarczajca. Aby przej do analizy, musisz zrozumie, w jaki sposb produkt bdzie uywany i jak musi dziaa. Celem fazy analizy jest sprecyzowanie tych wymaga. Efektem kocowym tej fazy jest stworzenie dokumentu zawierajcego opracowane wymagania. Pierwsz czci tego dokumentu jest analiza przypadkw uycia produktu.

Przypadki uycia

Istotn czci analizy, projektowania i implementacji s przypadki uycia. Przypadek uycia jest oglnym opisem sposobu, w jaki produkt bdzie uywany. Przypadki uycia nie tylko ukierunkowuj analiz, ale take pomagaj w okreleniu klas i s szczeglnie wane podczas testowania produktu.

Tworzenie stabilnego i wyczerpujcego zestawu przypadkw uycia moe by najwaniejszym zadaniem caej analizy. Wanie wtedy jeste najbardziej uzaleniony od ekspertw w danej dziedzinie, to oni wiedz najwicej o dziedzinie pracy, ktrej wymagania prbujesz okreli.

Przypadki uycia s w niewielkim stopniu zwizane z interfejsem uytkownika, nie s natomiast zwizane z wntrzem budowanego systemu. Kada osoba (lub system) wsppracujca z projektowanym systemem jest nazywana aktorem.

Dokonajmy krtkiego podsumowania:

- przypadek uycia opis sposobu, w jaki uywane bdzie oprogramowanie,

- eksperci osoby znajce si na dziedzinie, dla ktrej tworzysz produkt,

- aktor kada osoba (lub system) wsppracujca z projektowanym systemem.

Przypadek uycia jest opisem interakcji zachodzcych pomidzy aktorem a samym systemem. W trakcie analizy przypadku uycia system jest traktowany jako czarna skrzynka. Aktor wysya komunikat do systemu, po czym zwracana jest informacja, zmienia si stan systemu, statek kosmiczny zmienia kierunek, itd.

Identyfikacja aktorw

Naley pamita, e nie wszyscy aktorzy s ludmi. Systemy wsppracujce z budowanym systemem take s aktorami. Gdy budujesz na przykad bankomat, aktorami mog by urzdnik bankowy i klient a take inny system wsppracujcy z aktualnie tworzonym systemem, na przykad system ledzenia poyczek czy udzielania kredytw studenckich. Oto podstawowa charakterystyki aktorw:

- s oni na zewntrz dla systemu,

- wsppracuj z systemem.

Czsto najtrudniejsz czci analizy przypadkw uycia jest jej pocztek. Zwykle najlepsz metod ruszenia z miejsca jest sesja burzy mzgw. Po prostu spisz list osb i systemw, ktre bd pracowa z nowym systemem. Pamitaj, e mwic o ludziach, w rzeczywistoci mamy na myli role urzdnika bankowego, kasjera, klienta, itd. Jedna osoba moe peni wicej ni jedn rol.

We wspomnianym przykadzie z bankomatem, na naszej licie mog wystpi nastpujce role:

- klient

- personel banku

- system bankowy

- osoba wypeniajca bankomat pienidzmi i materiaami

Na pocztku nie ma potrzeby wychodzenia poza t list. Wygenerowanie trzech czy czterech aktorw moe wystarczy do rozpoczcia generowania przypadkw uycia. Kady z tych aktorw pracuje z systemem w inny sposb; chcemy wykry te interakcje w naszych sposobach uycia.

Wyznaczanie pierwszych przypadkw uycia

Zacznijmy od roli klienta. Podczas burzy mzgw moemy okreli nastpujce przypadki uycia dla klienta:

- klient sprawdza stan swojego rachunku,

- klient wpaca pienidze na swj rachunek,

- klient wypaca pienidze ze swojego rachunku,

- klient przelewa pienidze z rachunku na rachunek,

- klient otwiera rachunek,

- klient zamyka rachunek.

Czy powinnimy dokona rozrnienia pomidzy klient wpaca pienidze na swj rachunek biecy a klient wpaca pienidze na lokat, czy te powinnimy te dziaania poczy (tak jak na powyszej licie) w klient wpaca pienidze na swj rachunek? Odpowied na to pytanie zaley od tego, czy takie rozrnienie ma znaczenie dla danej dziedziny (dziedzina jest rzeczywistym rodowiskiem, ktre modelujemy w tym przypadku jest ni bankowo).

Aby sprawdzi, czy te dziaania s jednym przypadkiem uycia, czy te dwoma, musisz zapyta, czy ich mechanizmy s rne (czy klient w kadym z przypadkw robi co innego) i czy rne s wyniki (czy system odpowiada na rne sposoby). W naszym przykadzie, w obu przypadkach odpowied brzmi nie: klient skada pienidze na kady z rachunkw w ten sam sposb, przy czym wynik take jest podobny, gdy bankomat odpowiada, zwikszajc stan odpowiedniego rachunku.

Zakadajc, e aktor i system dziaaj i odpowiadaj mniej wicej identycznie, bez wzgldu na to, na jaki rachunek dokonuje wpaty, te dwa przypadki uycia s w rzeczywistoci jednym sposobem. Pniej, gdy opracujemy scenariusze przypadkw uycia, moemy wyprbowa obie wariacje i sprawdzi, czy ich rezultatem s jakiekolwiek rnice.

Odpowiadajc na ponisze pytania, moesz odkry dodatkowe przypadki uycia:

1. Dlaczego aktor uywa tego systemu?

Klient uywa tego systemu, aby zdoby gotwk, zoy depozyt lub sprawdzi biecy stan rachunku.

2. Jakiego wyniku oczekuje aktor po kadym daniu?

Zwikszenia stanu rachunku lub uzyskania gotwki na zakupy.

3. Co spowodowao, e aktor uywa w tym momencie systemu?

By moe ostatnio otrzyma wypat lub jest na zakupach.

4. Co aktor musi zrobi, aby uy systemu?

Woy kart do szczeliny w bankomacie.

Aha! Potrzebujemy przypadku uycia dla logowania si klienta do systemu.5. Jakie informacje aktor musi dostarczy systemowi?

Musi wprowadzi kod PIN.

Aha! Potrzebujemy przypadkw uycia dla uzyskania i edycji kodu PIN.6. Jakich informacji aktor oczekuje od systemu?

Stanu rachunku itd.

Czsto dodatkowe przypadki uycia moemy znale, skupiajc si na atrybutach obiektw w danej dziedzinie. Klient posiada nazwisko, kod PIN oraz numer rachunku; czy wystpuj przypadki uycia dla zarzdzania tymi obiektami? Rachunek posiada swj numer, stan oraz histori transakcji; czy wykrylimy te elementy w przypadkach uycia?

Po szczegowym przeanalizowaniu przypadkw uycia dla klienta, nastpnym krokiem w opracowywaniu listy przypadkw uycia jest opracowanie przypadkw uycia dla wszystkich pozostaych aktorw. Ponisza lista przedstawia pierwszy zestaw przypadkw uycia dla naszego przykadu z bankomatem:

- klient sprawdza stan swojego rachunku,

- klient wpaca pienidze na swj rachunek,

- klient wypaca pienidze ze swojego rachunku,

- klient przekazuje pienidze z rachunku na rachunek,

- klient otwiera rachunek,

- klient zamyka rachunek,

- klient loguje si do swojego rachunku,

- klient sprawdza ostatnie transakcje,

- urzdnik bankowy loguje si do specjalnego konta przeznaczonego do zarzdzania,

- urzdnik bankowy dokonuje zmian w rachunku klienta,

- system bankowy aktualizuje stan rachunku klienta na podstawie dziaa zewntrznych,

- zmiany rachunku uytkownika s odzwierciedlane w systemie bankowym,

- bankomat sygnalizuje niedobr pienidzy,

- technik uzupenia w bankomacie gotwk i materiay.

Tworzenie modelu dziedziny

Gdy masz ju pierwsz wersj przypadkw uycia, moesz zacz wypenia dokument wymaga szczegowym modelem dziedziny. Model dziedziny jest dokumentem zawierajcym wszystko to, co wiesz o danej dziedzinie (zagadnieniu, nad ktrym pracujesz). Jako cz modelu dziedziny tworzysz obiekty dziedziny, opisujce wszystkie obiekty wymienione w przypadkach uycia. Przykad z bankomatem zawiera nastpujce obiekty: klient, personel banku, system bankowy, rachunek biecy, lokata, itd.

Dla kadego z tych obiektw dziedziny chcemy uzyska tak wane dane, jak nazwa obiektu (na przykad klient, rachunek, itd.), czy obiekt jest aktorem, podstawowe atrybuty i zachowanie obiektu, itd. Wiele narzdzi do modelowania wspiera zbieranie tych informacji w opisach klas. Na przykad, rysunek 11.4 przedstawia sposb, w jaki te informacje s zbierane w systemie Rational Rose.

Rys. 11.4. Rational Rose

Naley zdawa sobie spraw, e to, co opisujemy, nie jest obiektem projektu, ale obiektem dziedziny. Odzwierciedla sposb funkcjonowania wiata, a nie sposb dziaania naszego systemu.

Moemy okreli relacje pomidzy obiektami dziedziny pojawiajcymi si w przykadzie z bankomatem, uywajc UML korzystajc z takich samych konwencji rysowania, jakich uyjemy pniej do opisania relacji pomidzy klasami w dziedzinie. Jest to jedna z waniejszych zalet UML: moemy uywa tych samych narzdzi na kadym etapie projektu.

Na przykad, uywajc konwencji UML dla klas i powiza generalizacji, moemy przedstawi rachunki biece i rachunki lokat jako specjalizacje bardziej oglnej koncepcji rachunku bankowego, tak jak pokazano na rysunku 11.5.

Rys. 11.5. Specjalizacje

Na diagramie z rysunku 11.5 prostokty reprezentuj rne obiekty dziedziny; za strzaki wskazuj generalizacj. UML zakada, e linie s rysowane w kierunku od klasy wyspecjalizowanej do bardziej oglnej klasy bazowej. Dlatego, zarwno Rachunek biecy, jak i Rachunek lokaty, wskazuj na Rachunek bankowy, informujc e kady z nich jest wyspecjalizowan form Rachunku bankowego.

UWAGAPamitajmy, e w tym momencie widzimy tylko zalenoci pomidzy obiektami w dziedzinie. Pniej by moe zdecydujesz si na zastosowanie w projekcie obiektw o nazwach RachunekBiezacy oraz RachunekBankowy i moe odwzorujesz te zalenoci, uywajc dziedziczenia, ale bd to decyzje podjte w czasie projektowania. W czasie analizy dokumentujemy jedynie obiekty istniejce w danej dziedzinie.

UML jest bogatym jzykiem modelowania i mona w nim umieci dowoln ilo relacji. Jednak podstawowe relacje wykrywane podczas analizy to: generalizacja (lub specjalizacja), zawieranie i powizanie.

Generalizacja

Generalizacja jest czsto porwnywana z dziedziczeniem, lecz istnieje pomidzy nimi wyrana, istotna rnica. Generalizacja opisuje relacj; dziedziczenie jest programow implementacj generalizacji jest sposobem przedstawienia generalizacji w kodzie. Odwrotnoci generalizacji jest specjalizacja. Kot jest wyspecjalizowan form zwierzcia, za zwierz jest generaln form kota lub psa.

Specjalizacja okrela, e obiekt wyprowadzony jest podtypem obiektu bazowego. Zatem rachunek biecy jest rachunkiem bankowym. Ta relacja jest symetryczna: rachunek bankowy generalizuje oglne zachowanie i atrybuty rachunku biecego i rachunku lokaty.

Podczas analizowania dziedziny chcemy przedstawi te zalenoci dokadnie tak, jak wystpuj w realnym wiecie.

Zawieranie

Czsto obiekt skada si z wielu podobiektw. Na przykad samochd skada si z kierownicy, k, drzwi, radia, itd. Rachunek biecy skada si ze stanu, historii transakcji, identyfikatora klienta, itd. Mwimy, e rachunek biecy posiada te elementy; zawieranie modeluje wanie takie relacje posiadania. UML ilustruje relacj zawierania za pomoc strzaki z rombem, wskazujcej obiekt zawierany (patrz rysunek 11.6).

Rys. 11.6. Zawieranie

Diagram z rysunku 11.6 sugeruje, e rachunek osobisty posiada stan. Mona poczy oba diagramy, przedstawiajc w ten sposb do zoony zestaw relacji (patrz rysunek 11.7).

Rys. 11.7. Relacje pomidzy obiektami

Diagram z rysunku 11.7 informuje, e rachunek biecy i rachunek lokaty s rachunkami bankowymi oraz, e rachunki bankowe posiadaj zarwno stan, jak i histori transakcji.

Powizania

Trzeci relacj, wykrywan zwykle podczas analizowania dziedziny, jest proste powizanie. Powizanie sugeruje, e dwa obiekty w jaki sposb ze sob wsppracuj. Ta definicja staje si duo bardziej precyzyjna w fazie projektowania, ale w fazie analizy sugerujemy jedynie, e obiekt A wsppracuje z obiektem B, i e jeden obiekt nie zawiera drugiego; a take, e aden z nich nie jest specjalizacj drugiego. W UML powizania midzy obiektami s przedstawiane jako zwyka prosta linia pomidzy obiektami, co pokazuje rysunek 11.8.

Diagram z rysunku 11.8 wskazuje, e obiekt A w jaki sposb wsppracuje z obiektem B.

Rys. 11.8.

Tworzenie scenariuszy

Gdy mamy ju gotowy wstpny zestaw przypadkw uycia oraz narzdzi, dziki ktrym moemy przedstawi relacje pomidzy obiektami w dziedzinie, jestemy gotowi do uporzdkowania przypadkw uycia i zdefiniowania ich przeznaczenia.

Kady przypadek uycia mona rozbi na serie scenariuszy. Scenariusz jest opisem okrelonego zestawu okolicznoci towarzyszcych danemu przypadkowi uycia. Na przykad, przypadek uycia klient wypaca pienidze ze swojego rachunku moe posiada nastpujce scenariusze:

- klient da trzystu dolarw z rachunku biecego, otrzymuje gotwk, po czym system drukuje kwit,

- klient da trzystu dolarw z rachunku biecego, lecz na rachunku znajduje si tylko dwiecie dolarw. Klient jest informowany, e na koncie znajduje si zbyt mao rodkw, aby speni jego danie,

- klient da trzystu dolarw z rachunku biecego, ale tego dnia pobra ju sto dolarw, a limit dzienny wynosi trzysta dolarw. Klient jest informowany o problemie i moe si zdecydowa na pobranie jedynie dwustu dolarw,

- klient da trzystu dolarw z rachunku biecego, ale skoczy si papier w drukarce kwitw. Klient jest informowany o problemie i moe si zdecydowa na pobranie pienidzy bez potwierdzenia w postaci kwitu.

I tak dalej. Kady scenariusz przedstawia wariant tego samego przypadku uycia. Czsto te sytuacje s sytuacjami wyjtkowymi (zbyt mao rodkw na rachunku, zbyt mao gotwki w bankomacie, itd.). Czasem warianty dotycz niuansw w podejmowaniu decyzji w samym sposobie uycia (na przykad, czy przed podjciem gotwki klient chce dokona transferu rodkw).

Nie musimy analizowa kadego ewentualnego scenariusza. Szukamy tych scenariuszy, ktre prezentuj wymagania systemu lub szczegy interakcji z aktorem.

Tworzenie wytycznych

Teraz, jako cz metodologii, bdziemy tworzy wytyczne dla udokumentowania kadego ze scenariuszy. Te wytyczne znajd si w dokumentacji wymaga. Zwykle chcemy, by kady scenariusz zawiera:

- warunki wstpne jakie warunki musz by spenione, aby scenariusz si rozpocz,

- wczniki co powoduje, e scenariusz si rozpoczyna,

- akcje, jakie podejmuje aktor,

- wyniki lub zmiany powodowane przez system,

- informacj zwrotn otrzymywan przez aktora,

- informacje o wystpowaniu cyklicznych operacji i o przyczynach ich wykonywania,

- schematyczny opis przebiegu scenariusza,

- okolicznoci powodujce zakoczenie scenariusza,

- warunki kocowe jakie warunki musz by spenione w momencie zakoczenia scenariusza.

Ponadto, kademu sposobowi uycia i kademu scenariuszowi powinno si nada nazw. Moesz spotka si z nastpujc sytuacj:

Przypadek uycia:Klient wypaca pienidze.

Scenariusz:Pomylne pobranie gotwki z rachunku biecego.

Warunki wstpne:Klient jest ju zalogowany do systemu.

Wcznik:Klient da gotwki.

Opis:Klient decyduje si na wypacenie gotwki z rachunku biecego. Na rachunku znajduje si wystarczajca ilo rodkw, w bankomacie jest wystarczajco duo pienidzy i papieru na kwity, a sie dziaa. Bankomat prosi klienta o podanie wysokoci wypaty, klient prosi o trzysta dolarw, co w tym momencie jest kwot dozwolon. Maszyna wydaje trzysta dolarw i wypisuje kwit; klient odbiera pienidze i kwit.

Warunki kocowe:Rachunek klienta jest obciany kwot trzystu dolarw, za klient otrzymuje trzysta dolarw w gotwce.

Ten przypadek uycia moe zosta przedstawiony za pomoc prostego diagramu, pokazanego na rysunku 11.9.

Rys. 11.9. Diagram przypadku uycia

Ten diagram nie dostarcza zbyt wielu informacji, poza wysokopoziomow abstrakcj interakcji pomidzy aktorem (klientem) a systemem. Diagram stanie si nieco bardziej uyteczny, gdy przedstawimy interakcj pomidzy sposobami uycia. Tylko nieco bardziej uyteczny, gdy moliwe s tylko dwie interakcje: () i (). Stereotyp wskazuje, e jeden przypadek uycia jest nadzestawem innego. Na przykad, nie jest moliwa wypata gotwki bez wczeniejszego zalogowania si. T relacj przedstawiamy za pomoc diagramu, pokazanego na rysunku 11.10.

Rys. 11.10. Stereotyp

Rysunek 11.10 pokazuje, e przypadek uycia Wypata Gotwki korzysta z przypadku uycia Logowanie i w peni implementuje Logowanie jako cz Wypaty Gotwki.

Przypadek uycia zosta opracowany w celu wskazania relacji warunkowych i czciowo odnosi si do dziedziczenia, ale wywoywa tyle nieporozumie wrd projektantw obiektowych (zwizanych z odrnieniem go od ), e wielu z nich odrzuca go, uwaajc e nie jest wystarczajco dobrze zrozumiany. Ja uywam aby unikn kopiowania i wklejania caego przypadku uycia, a uywam wtedy, gdy korzystam z przypadku uycia tylko w okrelonych warunkach.

Diagramy interakcji

Cho diagram przypadku uycia moe mie ograniczon warto, mona powiza go z przypadkiem uycia, ktry moe znacznie wzbogaci dokumentacj i uatwi zrozumienie interakcji. Na przykad wiemy, e scenariusz Wypata Gotwki reprezentuje interakcj pomidzy nastpujcymi obiektami dziedziny: klientem, rachunkiem biecym oraz interfejsem uytkownika. Moemy przedstawi t interakcj na diagramie interakcji, widocznym na rysunku 11.11.

Rys. 11.11. Diagram interakcji w jzyku UML

Diagram interakcji z rysunku 11.11 przedstawia te szczegy scenariusza, ktre mog nie zosta zauwaane podczas czytania tekstu. Wspdziaajce ze sob obiekty s obiektami dziedziny, a cay bankomat (ATM) wraz z interfejsem uytkownika traktowany jest jako pojedynczy obiekt, wywoywany szczegowo jest tylko okrelony rachunek bankowy.

Ten prosty przykad bankomatu pokazuje jedynie ograniczony zestaw interakcji, ale szczegowe ich przeanalizowanie moe okaza si bardzo pomocne w zrozumieniu zarwno dziedziny problemu, jak i wymaga nowego systemu.

Tworzenie pakietw

Poniewa dla kadego problemu o znacznej zoonoci generuje si wiele przypadkw uycia, UML umoliwia grupowanie ich w pakiety.

Pakiet przypomina kartotek lub folder jest zbiorem obiektw modelowania (klas, aktorw, itd.). Aby opanowa zoono przypadkw uycia, moemy tworzy pakiety pogrupowane wedug charakterystyk, majcych znaczenie dla danego projektu. Moesz wic pogrupowa swoje przypadki uycia wedug rodzaju rachunku (wszystko, co odnosi si do rachunku biecego albo do lokaty), wedug wpyww albo obcie, wedug rodzaju klienta czy wedug jakiejkolwiek innej charakterystyki, ktra ma sens w danym przypadku. Pojedynczy przypadek uycia moe wystpowa w kilku rnych pakietach, uatwiajc w ten sposb projektowanie.

Analiza aplikacji

Oprcz tworzenia przypadkw uycia, dokument wymaga powinien zawiera zaoenia i ograniczenia twojego klienta, a take wymagania wobec sprztu i systemu operacyjnego. Wymagania aplikacji s zaoeniami pochodzcymi od konkretnego klienta zwykle okreliby je podczas projektowania i implementacji, ale klient zadecydowa o nich za ciebie.

Wymagania aplikacji s czsto narzucane przez konieczno wsppracy z istniejcymi systemami. W takim przypadku kluczowym elementem analizy jest zrozumienie sposobw dziaania istniejcych systemw.

W idealnych warunkach analizujesz problem, projektujesz rozwizanie, po czym decydujesz, jaka platforma i system operacyjny najlepiej odpowiadaj potrzebom twojego projektu. Taka sytuacja jest nie tylko idealna, ale i rzadka. Duo czciej zdarza si, e klient zainwestowa ju w okrelony sprzt lub system operacyjny. Plany jego firmy opieraj si na dziaaniu twojego oprogramowania w istniejcym ju systemie, wic musisz pozna te wymagania jak najwczeniej i odpowiednio si do nich dostosowa.

Analiza systemw

Czasem oprogramowanie jest zaprojektowane jako samodzielne; wsppracuje ono jedynie z kocowym uytkownikiem. Czsto jednak twoim zadaniem bdzie wsppraca z istniejcym systemem. Analiza systemw to proces zbierania wszystkich informacji na temat systemw, z ktrymi bdziesz wsppracowa. Czy twj nowy system bdzie serwerem, dostarczajcym usugi istniejcym systemom, czy te bdzie ich klientem? Czy bdziesz mg negocjowa interfejs pomidzy systemami, czy te musisz si dostosowa do istniejcego standardu? Czy inne systemy pozostan niezmienne, czy te przez cay czas bdziesz ledzi zachodzce w nich zmiany?

Na te i inne pytania naley odpowiedzie podczas fazy analizowania, jeszcze przed przystpieniem do projektowania nowego systemu. Oprcz tego, powiniene pozna ograniczenia wynikajce ze wsppracy z innymi systemami. Czy spowolni one szybko odpowiedzi twojego systemu? Czy nakadaj one na twj system wysokie wymagania, zajmujc zasoby i czas procesora?

Tworzenie dokumentacji

Gdy ju okrelisz zadania systemu i sposb jego dziaania, nadchodzi czas, aby podj pierwsz prb stworzenia dokumentu, okrelajcego czas i budet produkcji. Czsto termin jest narzucony przez klienta z gry: Masz na to osiemnacie miesicy. Byoby wspaniale, gdyby mg przeanalizowa wymagania i oszacowa czas, jaki zajmie ci zaprojektowanie i zaimplementowanie rozwizania. W praktyce wikszo systemw powstaje w bardzo krtkim terminie i przy niskich kosztach, za prawdziwa sztuka polega na okreleniu, jak dua cz zaoe moe zosta speniona w zadanym czasie oraz przy zaoonym budecie.

Oto wytyczne, o ktrych powiniene pamita, okrelajc harmonogram i budet projektu:

- jeli musisz zmieci si w pewnym przedziale, wtedy zaoeniem optymistycznym jest najprawdopodobniej jego ograniczenie zewntrzne,

- zgodnie z prawem Libertyego, wszystko bdzie trwa duej ni tego oczekujesz nawet jeli uwzgldnisz to prawo.

Konieczne bdzie te okrelenie priorytetw. Nie skoczysz w wyznaczonym terminie po prostu. Zadbaj, by system dziaa w momencie, gdy koczy si czas ukoczenia prac i by by wystarczajcy sprawny dla pierwszego wydania. Gdy budujesz most zblia si termin ukoczenia prac, a nie zostaa jeszcze wykonana cieka rowerowa, to niedobrze; moesz jednak otworzy ju most i zacz pobiera myto. Jeli jednak most siga dopiero poowy rzeki, to ju bardzo le.

Dokumentw planowania przewanie s bdne. Na tak wczesnym etapie projektu praktycznie nie jest moliwe waciwe oszacowanie czasu jego trwania. Gdy ju znasz wymagania, moesz w przyblieniu okreli ilo czasu, jak zajmie projektowanie systemu, jego implementacja i testowanie. Do tego musisz zaplanowa dodatkowo od dwudziestu do dwudziestu piciu procent zapasu, ktry moesz zmniejsza w trakcie wykonywania zlecenia (gdy dowiadujesz si coraz wicej).

UWAGAUwzgldnienie zapasu czasu nie moe by wymwk dla uniknicia tworzenia planu. Jest jedynie ostrzeeniem, e nie mona na nim do koca polega. W trakcie prac nad projektem lepiej poznasz dziaanie systemu, a obliczenia stan si bardziej dokadne.

Wizualizacje

Ostatnim elementem dokumentu wymaga jest wizualizacja. Jest to nazwa wszystkich diagramw, rysunkw, zrzutw ekranu, prototypw i wszelkich innych wizualnych reprezentacji, przeznaczonych do wsparcia analizy i projektu graficznego interfejsu uytkownika dla produktu.

W przypadku duych projektw moesz opracowa peny prototyp, ktry pomoe tobie (i twoim klientom) zrozumie jak bdzie dziaa system. W niektrych przypadkach prototyp staje si odzwierciedleniem wymaga; prawdziwy system jest projektowany tak, by implementowa funkcje zademonstrowane w prototypie.

Dokumentacja produktu

Na koniec kadej fazy analizy i projektowania stworzysz seri dokumentw produktu. Tabela 11.1 pokazuje kilka z takich dokumentw dla fazy analizy. S one uywane przez klienta w celu upewnienia si, czy rozumiesz jego potrzeby, przez kocowego uytkownika jako wsparcie i wytyczne dla projektu, za przez zesp projektowy do zaprojektowania i zaimplementowania kodu. Wiele z tych dokumentw dostarcza take materiau istotnego zarwno dla zespou zajmujcego si dokumentacj, jak i zespou kontroli jakoci, informujc ,w jaki sposb powinien zachowywa si system.

Tabela 11.1. Dokumenty produktu tworzone podczas fazy analizy

DokumentOpis

Raport przypadkw uyciaDokument opisujcy szczegowo przypadki uycia, scenariusze, stereotypy, warunki wstpne, warunki kocowe oraz wizualizacje.

Analiza dziedzinyDokument i diagramy, opisujce powizania pomidzy obiektami dziedziny.

Diagramy analizy wsppracyDiagramy wsppracy, opisujce interakcje pomidzy obiektami dziedziny.

Diagramy analizy dziaaDiagramy dziaa, opisujce interakcje pomidzy obiektami dziedziny.

Analiza systemuRaport i diagramy, opisujce na niszym poziomie system i sprzt, dla ktrego bdzie tworzony projekt.

Dokument analizy zastosowaRaport i diagramy, opisujce wymagania klienta wobec konkretnego produktu.

Raport ogranicze dziaaniaRaport charakteryzujcy wydajno oraz ograniczenia narzucone przez klienta.

Dokument kosztw i harmonogramuRaport z wykresami Ganta i Perta, opisujcymi zakadany harmonogram, etapy i koszty.

Projektowanie

Analiza skupia si na dziedzinie problemu, natomiast projektowanie zajmuje si stworzeniem rozwizania. Projektowanie jest procesem przeksztacenia wymaga w model, ktry moe by zaimplementowany w postaci oprogramowania. Rezultatem tego procesu jest stworzenie dokumentu projektowego.

Dokument projektowy jest podzielony na dwie czci: projekt klas oraz mechanizmy architektury. Cz projektu klas dzieli si z kolei na projekt statyczny (szczegowo okrelajcy poszczeglne klasy, ich powizania i charakterystyki) oraz projekt dynamiczny (okrelajcy, jak te klasy ze sob wsppracuj).

Cz mechanizmw architektury zawiera informacje na temat implementacji przechowywania obiektw, rozproszonego systemu obiektw, konkurencji pomidzy elementami, itd. W nastpnej czci rozdziau skupimy si na aspekcie projektowania klas; za do projektowania mechanizmw architektury wykorzystamy wiadomoci zawarte w nastpnych rozdziaach tej ksiki.

Czym s klasy?

Jako programista C++, przywyke do tworzenia klas. Metodologia projektowania wymaga operowania klasami C++ poprzez klasy projektu, mimo, i s one do cile powizane. Klasa C++ zapisana w kodzie programu stanowi implementacj klasy zaprojektowanej. Kada klasa stworzona w kodzie bdzie stanowi odzwierciedlenie klasy w projekcie, ale nie naley myli jednej z drug. Oczywicie, klasy projektu mona zaimplementowa take w innym jzyku, jednak skadnia definicji klasy moe by inna.

Z tego powodu przez wikszo czasu bdziemy mwi o klasach bez dokonywania takiego rozrnienia, gdy rnice midzy nimi s zbyt abstrakcyjne. Gdy mwimy, e w naszym modelu klasa Cat posiada metod Meow(), naszym zdaniem oznacza to, e metod Meow() umiecimy take w naszej klasie C++.

Klasy modelu przedstawia si w postaci diagramw UML, za klasy C++ jako kod, ktry moe zosta skompilowany. Rozrnienie, cho subtelne, jest jednak istotne.

Najwikszym wyzwaniem dla wielu nowicjuszy jest okrelenie pocztkowego zestawu klas i zrozumienie, z czego skada si dobrze zaprojektowana klasa. Jedn z technik jest wypisanie scenariuszy przypadkw uycia, a nastpnie stworzenie osobnej klasy dla kadego rzeczownika. Spjrzmy na poniszy scenariusz przypadku uycia:

Klient decyduje si na wypat gotwki z rachunku osobistego. Na rachunku znajduje si wystarczajca ilo rodkw, w bankomacie jest wystarczajca ilo gotwki i papieru, dziaa take sie. Bankomat prosi klienta o podanie kwoty wypaty, za klient prosi o wypat trzystu dolarw, co w tym momencie jest moliwe. Maszyna wydaje trzysta dolarw i drukuje kwit, po czym klient bierze pienidze i odbiera kwit.

Z tego scenariusza moesz wybra nastpujce klasy:

- klient

- gotwka

- rachunek biecy

- rachunek

- kwity

- bankomat

- sie

- kwota

- wypata

- maszyna

- pienidze

Moesz nastpnie usun z listy synonimy, po czym stworzy klasy dla kadego z nastpujcych rzeczownikw:

- klient

- gotwka (pienidze, kwota, wypata)

- rachunek biecy

- rachunek

- kwity

- bankomat (maszyna)

- sie

Jak na razie, to niezy pocztek. Moesz nastpnie przedstawi na diagramie relacje pomidzy niektrymi z tych klas (patrz rysunek 11.12).

Rysunek 11.12. Wstpnie zdefiniowane klasy

Przeksztacenia

Proces, ktry zacz si w poprzednim podrozdziale, jest nie tyle wybieraniem rzeczownikw ze scenariusza, ile pocztkiem przeksztacania obiektw z analizy dziedziny w obiekty projektowe. To wany, pierwszy krok. Wiele obiektw dziedziny bdzie posiadao w projekcie reprezentacje. Obiekt jest nazywany reprezentacj w celu odrnienia, na przykad, rzeczywistego papierowego kwitu wydawanego przez bankomat od obiektu w projekcie, ktry jest jedynie zaimplementowan w kodzie abstrakcj.

Najprawdopodobniej odkryjesz, e wikszo obiektw dziedziny posiada izomorficzn reprezentacj w projekcie tj. pomidzy obiektem dziedziny a obiektem projektu istnieje relacja jeden do jednego. Zdarza si jednak, e pojedynczy obiekt dziedziny jest reprezentowany w projekcie przez ca seri obiektw. Kiedy indziej seria obiektw dziedziny moe by reprezentowana przez pojedynczy obiekt projektowy.

Zwr uwag, e w rysunku 11.12 ju zauwaylimy fakt, i RachunekBiecy jest specjalizacj Rachunku. Nie przygotowywalimy si do wyszukiwania relacji generalizacji, ale ta bya tak oczywista, e od razu j zauwaylimy. Z analizy dziedziny wiemy, e Bankomat wydaje Gotwk i Kwity, wic natychmiast wyszukalimy t informacj w projekcie.

Relacja pomidzy Klientem a RachunkiemBieacym jest ju mniej oczywista. Wiemy, e taka relacja istnieje, ale poniewa jej szczegy nie s oczywiste, na razie nie bdziemy si ni zajmowa.

Inne przeksztacenia

Gdy przeksztacimy ju obiekty dziedziny, moemy zacz szuka innych uytecznych obiektw projektowych. Mog by nimi np. interfejsy. Kady interfejs pomidzy nowym systemem a systemami ju istniejcymi, powinien zosta ujty w klasie interfejsu. Jeli wsppracujesz z baz danych (obojtne, jakiego rodzaju), baza ta take jest dobrym kandydatem na klas interfejsu.

Klasy interfejsw umoliwiaj ukrycie szczegw interfejsu i w ten sposb chroni nas przed zmianami w innych systemach. Klasy interfejsw pozwalaj na zmian wasnego projektu lub dostosowywanie si do zmian w projekcie innych systemw, bez zmian w pozostaej czci kodu. Dopki dwa systemy wsppracuj ze sob poprzez uzgodniony interfejs, mog si zmienia niezalenie od siebie.

Manipulowanie danymi

Gdy stworzysz klasy dla manipulowania danymi, a musisz przeksztaca dane z formatu do formatu (na przykad ze skali Celsjusza do Fahrenheita lub z systemu angielskiego na metryczny), moesz ukry szczegy takiej transformacji w klasie. Moesz uy tej techniki, przekazujc dane w danym formacie do innego systemu lub transmitujc je poprzez Internet. Gdy musisz manipulowa danymi w okrelonym formacie, moesz ukry szczegy protokou w klasie manipulowania danymi.

Widoki

Kady widok lub raport generowany przez system (lub w przypadku, gdy generujesz wiele raportw, kady zestaw raportw) jest kandydatem na klas. Reguy tworzenia raportu sposb gromadzenia informacji i ich przedstawiania mona ukry wewntrz klasy.

Urzdzenia

Gdy twj system wsppracuje z urzdzeniami (takimi jak drukarki, modemy, skanery, itd.) lub operuje nimi, specyfika protokou komunikacji z urzdzeniem take powinna zosta ukryta w klasie. Take w tym przypadku, przez stworzenie klas dla interfejsu urzdzenia, moesz podcza nowe urzdzenia z nowymi protokoami, nie naruszajc przy tym adnych pozostaych czci swojego kodu; po prostu tworzysz now klas interfejsu, obsugujc ten sam (lub wyprowadzony) interfejs. I gotowe!

Model statyczny

Gdy okrelisz ju wstpny zestaw klas, pora rozpocz modelowanie powiza i interakcji pomidzy nimi. W tym rozdziale najpierw opiszemy model statyczny, a dopiero potem model dynamiczny. W rzeczywistym procesie projektowania bdziesz swobodnie przechodzi pomidzy tymi modelami, dodajc nowe klasy i, szkicujc je w miar postpu prac.

Model statyczny skupia si na trzech obszarach: odpowiedzialnoci, atrybutach i powizaniach. Najwaniejszy z nich i na nim skupisz si najpierw jest zestaw odpowiedzialnoci dla kadej z klas. Najwaniejsz wytyczn bdzie teraz: Kada klasa powinna by odpowiedzialna za jedn rzecz.

Nie chc przez to powiedzie, e kada klasa ma tylko jedn metod; wiele klas bdzie miao tuziny metod. Jednak wszystkie te metody musz by spjne i wzajemnie do siebie przystajce; tj. wszystkie musz by ze sob powizane i zapewnia klasie zdolno osignicia okrelonego obszaru odpowiedzialnoci.

W dobrze zaprojektowanym systemie, kady obiekt jest egzemplarzem dobrze zdefiniowanej i dobrze zrozumianej klasy, odpowiedzialnej za okrelony obszar. Klasy zwykle deleguj zewntrzne odpowiedzialnoci na inne, powizane z nimi klasy. Dziki stworzeniu klas, ktre zajmuj si tylko jednym obszarem, umoliwiasz tworzenie kodu atwego do konserwacji i rozbudowy.

Aby okreli obszar odpowiedzialnoci swoich klas, moesz zacz projektowanie od uycia kart CRC.

Karty CRC

CRC oznacza Class, Responsibility i Collaboration (klasa, odpowiedzialno, wsppraca). Karta CRC jest tylko zwyk kartk z notatnika. To proste urzdzenie umoliwia nawizanie wsppracy z innymi osobami w celu okrelenia podstawowych odpowiedzialnoci dla pocztkowego zestawu klas. W tym celu u na stole stos pustych kart CRC, a przy stole zorganizuj seri sesji CRC.

W jaki sposb przeprowadza sesj CRC

Kada sesja CRC powinna odbywa si w grupie od trzech do szeciu osb; przy wikszej ich iloci staje si nieefektywna. Powiniene wyznaczy koordynatora, ktrego zadaniem bdzie zapewnienie waciwego przebiegu sesji i pomaganie jej uczestnikom w zidentyfikowaniu najwaniejszych zagadnie. Powinien by obecny co najmniej jeden dowiadczony architekt oprogramowania, najlepiej kto z duym dowiadczeniem w obiektowo zorientowanej analizie i projektowaniu. Oprcz tego, w sesji powinien wzi udzia co najmniej jeden ekspert w danej dziedzinie, rozumiejcy wymagania systemu i mogcy udzieli fachowej porady na temat dziaania systemu.

Najwaniejszym elementem sesji CRC jest nieobecno menederw. Sprawia ona, e sesja jest kreatywnym, swobodnie toczcym si spotkaniem, na przebieg ktrego nie moe mie wpywu ch zrobienia wraenia na czyim szefie. Celem jej jest eksperyment, podjcie ryzyka, odkrycie wymaga klas oraz zrozumienie, w jaki sposb mog one ze sob wsppracowa.

Sesj CRC rozpoczyna si od zebrania grupy przy stole, na ktrym znajduje si niewielki stos kartek. Na grze kadej karty CRC wypisuje si nazw pojedynczej klasy. Poniej narysuj pionow lini biegnc w poprzez kartki, nastpnie opisz rubryk po lewej stronie jako Odpowiedzialnoci, za po prawej stronie jako Wsppraca.

Zacznij od wypenienia kart dla najwaniejszych zidentyfikowanych dotd klas. Na odwrocie kadej karty zapisz jedno lub dwuzdaniow definicj. Moesz take wskaza, jak klas specjalizuje dana klasa (o ile jest to wiadome w czasie posugiwania si kart CRC). Poniej nazwy klasy napisz po prostu Superklasa: oraz nazw klasy, od ktrej ta klasa pochodzi.

Skup si na odpowiedzialnociach

Celem sesji CRC jest zidentyfikowanie odpowiedzialnoci kadej z klas. Nie zwracaj wikszej uwagi na atrybuty, wychwytuj tylko te najwaniejsze. Najwaniejszym zadaniem jest zidentyfikowanie odpowiedzialnoci. Jeli w celu wypenienia odpowiedzialnoci klasa musi delegowa prac na inn klas, zapisz t informacj w rubryce Wsppraca.

W miar postpu prac zwracaj uwag na list odpowiedzialnoci. Gdy na karcie CRC zabraknie miejsca, zadaj sobie pytanie, czy nie dasz od klasy zbyt wiele. Pamitaj, kada klasa powinna by odpowiedzialna za jeden oglny obszar pracy, za wymienione na karcie odpowiedzialnoci powinny by spjne i przystajce tj. powinny wspgra ze sob w celu zapewnienia oglnej odpowiedzialnoci klasy.

Nie powiniene teraz skupia si na powizaniach ani na interfejsie klasy lub na tym, ktra metoda bdzie publiczna, a ktra prywatna. Postaraj si jedynie zrozumie, co robi kada z klas.

Antropomorfizacja i ukierunkowanie na przypadki uycia

Kluczow cech kart CRC jest ich antropomorfizacja tj. przypisywanie kadej z klas ludzkich atrybutw. Oto sposb jej dziaania: gdy masz ju wstpny zestaw klas, wr do scenariuszy uycia. Rozdziel karty wrd uczestnikw sesji i razem przeledcie scenariusz. Na przykad, zastanwmy si nad nastpujcym scenariuszem:

Klient decyduje si na wypat gotwki z rachunku osobistego. Na rachunku znajduje si wystarczajca ilo rodkw, w bankomacie jest wystarczajca ilo gotwki i papieru, dziaa take sie. Bankomat prosi klienta o podanie kwoty wypaty, za klient prosi o wypat trzystu dolarw, co jest w tym momencie moliwe. Maszyna wydaje trzysta dolarw i drukuje kwit, klient odbiera pienidze i kwit.

Zamy, e w sesji uczestniczy pi osb: Amy, koordynator i projektant obiektowo zorientowanego oprogramowania; Barry, gwny programista; Charlie, klient; Dorris, ekspert w danej dziedzinie oraz Ed, programista.

Amy trzyma kart CRC reprezentujc RachunekBiecy i mwi: Mwi klientowi, ile pienidzy jest dostpnych. Klient prosi mnie o wypacenie trzystu dolarw. Wysyam do dystrybutora polecenie wypacenia trzystu dolarw w gotwce. Barry podnosi swoj kart i mwi: Jestem dystrybutorem; wydaj trzysta dolarw i wysyam do Amy komunikat nakazujcy jej zmniejszenie stanu rachunku o trzysta dolarw. Komu mam powiedzie, e maszyna zawiera teraz o trzysta dolarw mniej? Czy te ja to ledz? Charlie odpowiada: Myl, e potrzebujemy obiektu do ledzenia iloci gotwki w maszynie. Ed mwi: Nie, dystrybutor powinien wiedzie, ile ma gotwki; to naley do jego zada. Amy nie zgadza si z tym i mwi: Nie, kto powinien koordynowa wydawanie pienidzy. Dystrybutor musi wiedzie, czy gotwka jest dostpna i czy klient posiada wystarczajc ilo rodkw na koncie, powinien wypaci pienidze i w odpowiednim momencie zamkn szuflad. Powinien delegowa na kogo innego odpowiedzialno za ledzenie iloci dostpnej gotwki na pewien rodzaj wewntrznego rachunku. osoba, ktra zna ilo dostpnej gotwki, moe take poinformowa biuro o tym, e zasoby bankomatu powinny zosta uzupenione. W przeciwnym razie dystrybutor miaby zbyt wiele zada.

Dyskusja trwa dalej. Trzymajc karty i wsppracujc z innymi, odkrywa si wymagania i moliwoci delegacji; kada klasa oywa i odkrywa swoje odpowiedzialnoci. Gdy grupa zbytnio zagbi si w projekt, koordynator moe podj decyzj o przejciu do nastpnego zagadnienia.

Ograniczenia kart CRC

Cho karty CRC mog stanowi dobre narzdzie dla rozpoczcia projektowania, posiadaj one due ograniczenia. Podstawowym problemem jest to, e nie zapewniaj dobrego skalowania. W bardzo skomplikowanym projekcie posugiwanie si kartami CRC moe by trudne.

Karty CRC nie odzwierciedlaj take wzajemnych relacji pomidzy klasami. Cho mona zapisa na nich zakres wsppracy, jednak nie da si nimi wymodelowa tej wsppracy. Patrzc na kart CRC, nie jeste w stanie powiedzie, czy klasa agreguje inn klas, kto kogo tworzy itd. Karty CRC nie wychwytuj take atrybutw, wic trudno jest z nich przej bezporednio do kodu. Karty CRC s statyczne; cho moesz za ich pomoc ustali interakcje midzy klasami, same karty CRC nie wychwytuj tej informacji.

Karty CRC s dobre na pocztek, ale jeli chcesz stworzy stabilny i kompletny model swojego projektu, powiniene przedstawi klasy w jzyku UML. Cho przejcie do UML nie jest zbyt trudne, jest jednak operacj jednokierunkow. Gdy przeniesiesz swoje klasy do diagramw UML, nie bdzie ju odwrotu; nie wrcisz do kart CRC. Po prostu synchronizacji obu modeli jest zbyt trudna.

Przeksztacanie kart CRC na UML

Kada karta CRC moe zosta przeksztacona bezporednio w klas wymodelowan w UML. Odpowiedzialnoci s przeksztacane na metody klasy, ewentualnie dodawane s take wychwycone atrybuty. Definicja klasy z odwrotnej strony karty jest umieszczana w dokumentacji klasy. Rysunek 11.13 przedstawia relacj pomidzy kart CRC RachunekBiecy, a stworzon na podstawie tej karty klas UML.

Rys. 11.13. Karta CRC

Klasa: RachunekBiecy

Superklasa: Rachunek

Odpowiedzialnoci:

ledzenie stanu biecego

przyjmowanie depozytw i transfery na rachunek

wypisywanie czekw

transfery z rachunku

ledzenie dziennego limitu wypaty gotwki z bankomatu

Wsppraca:

inne rachunki

system bankowy

dystrybutor gotwki

Relacje pomidzy klasami

Gdy klasy zostan ju przedstawione w UML, moesz zwrci uwag na relacje pomidzy rnymi klasami. Podstawowe modelowane relacje to:

- generalizacja

- powizania

- agregacja

- kompozycja

Relacja generalizacji jest w C++ implementowana poprzez publiczne dziedziczenie. Pamitajc jednak e najwaniejszy jest projekt, nie skupimy si mechanizmie dziaania relacji, ale na semantyce: co z takiej relacji wynika.

Relacje sprawdzilimy ju w fazie analizy, teraz skupimy si nie tylko na obiektach dziedziny, ale take na obiektach w naszym projekcie. Naszym zadaniem jest okrelenie wsplnej funkcjonalnoci w powizanych ze sob klasach i wydzielenie z nich klas bazowych, obejmujcych te wsplne waciwoci.

Gdy okrelisz wspln funkcjonalno, powiniene przenie j z klas specjalizowanych do klasy bardziej oglnej. Gdy zauwaymy, e oba rachunki, biecy i lokaty, potrzebuj metod do transferu pienidzy do i z rachunku, metod Transferrodkw() przeniesiemy do klasy bazowej Rachunek. Im wicej funkcji przeniesiemy z klas potomnych, tym bardziej polimorficzny stanie si projekt.

Jedn z moliwoci dostpnych w C++, lecz niedostpnych w Javie, jest wielokrotne dziedziczenie (Java ma podobn, cho ograniczon, moliwo posiadania wielu interfejsw). Wielokrotne dziedziczenie pozwala klasie na dziedziczenie po wicej ni jednej klasie bazowej, wprowadzajc skadowe i metody z dwch lub wicej klas.

Dowiadczenie wykazao, e wielokrotne dziedziczenie powinno by uywane rozwanie, gdy moe skomplikowa zarwno projekt, jak i implementacj. Wiele problemw rozwizywanych dawniej poprzez wielokrotne dziedziczenie obecnie rozwizuje si poprzez agregacj. Naley jednak pamita, e wielokrotne dziedziczenie jest uytecznym narzdziem, za projekt moe wymaga, by pojedyncza klasa specjalizowaa zachowanie dwch lub wicej innych klas.

Wielokrotne dziedziczenie a zawieranie

Czy obiekt jest sum swoich czci? Czy ma sens modelowanie obiektu Samochd jako specjalizacji Kierownicy, Drzwi i K, tak jak pokazano na rysunku 11.14?

Rys. 11.14. Faszywe dziedziczenie

Trzeba powrci do rde: publiczne dziedziczenie powinno zawsze modelowa generalizacj. Oglnie przyjtym wyraeniem tej reguy jest stwierdzenie, e dziedziczenie powinno modelowa relacj jest czym. Jeli chcesz wymodelowa relacj posiada (na przykad samochd posiada kierownic), powiniene uy agregacji, jak pokazano na rysunku 11.15.

Rys. 11.15. Agregacja

Diagram z rysunku 11.15 wskazuje, e samochd posiada kierownic, cztery koa oraz od dwch do piciu drzwi. Jest to waciwy model relacji pomidzy samochodem a jego elementami. Zwr uwag, e romby na rysunku nie s wypenione; rysujemy je w ten sposb, aby wskaza, e modelujemy agregacj, a nie kompozycj. Kompozycja implikuje kontrol czasu ycia obiektu. Cho samochd posiada koa i drzwi, mog one istnie jako elementy samochodu, a take jako samodzielne obiekty.

Rysunek 11.16 modeluje kompozycj. Ten model pokazuje, e ciao jest nie tylko agregacj gowy, dwch rk i dwch ng, ale take, e obiekty te (gowa, rce, nogi) s tworzone w momencie tworzenia ciaa i znikaj w chwili, gdy znika ciao. Nie mog istnie niezalenie; ciao jest zoone z tych rzeczy, a czas ich istnienia jest powizany.

Rys. 11.16. Kompozycja

Cechy i gwne typy

Jak zaprojektowa klasy potrzebne do zaprezentowania rnych linii modelowych typowego producenta samochodw? Przypumy, e zostae wynajty do zaprojektowania systemu dla Acme Motors, ktry aktualnie produkuje pi modeli: Pluto (powolny, kompaktowy samochd z niewielkim silnikiem), Venus (czterodrzwiowy sedan ze rednim silnikiem), Mars (sportowe coupe z najwikszym silnikiem, opracowanym w celu uzyskiwania rekordowych szybkoci), Jupiter (minwan z takim samym silnikiem, jak w sportowym coupe, lecz z moliwoci zmiany biegw przy niszych obrotach oraz dostosowaniemm do napdzania wikszej masy) oraz Earth (furgonetka z niewielkim silnikiem o wysokich obrotach).

Moesz zacz od stworzenia podtypw samochodw, odzwierciedlajcych rne modele, po czym tworzy egzemplarze kadego z modelu w miar ich schodzenia z linii montaowej, tak jak pokazano na rysunku 11.17.

Rys. 11.17. Modelowanie podtypw

Czym rni si te modele? Typem nadwozia oraz rozmiarem i charakterystykami silnika. Te elementy mog by czone i dopasowywane w celu stworzenia rnych modeli. Moemy to wymodelowa w UML za pomoc stereotypu cecha, tak jak pokazano na rysunku 11.18.

Rys. 11.18. Modelowanie cech

Diagram z rysunku 11.18 wskazuje, e klasy mog by wyprowadzone z klasy samochd dziki mieszaniu i dopasowaniu trzech atrybutw cech. Rozmiar silnika okrela si pojazdu, za charakterystyka wydajnoci okrela, czy samochd jest pojazdem sportowym, czy rodzinnym. Dziki temu moemy stworzy siln, sportow furgonetk, saby rodzinny sedan, itd.

Kady atrybut moe by zaimplementowany za pomoc zwykego wyliczenia. Typ nadwozia mona zaimplementowa w kodzie za pomoc poniszego wyliczenia:

enum TypNadwozia = { sedan, coupe, minivan, furgonetka };

Moe si jednak okaza, e pojedyncza warto nie wystarcza do wymodelowania okrelonej cechy. Na przykad, charakterystyka wydajnoci moe by raczej zoona. W takim przypadku cecha moe zosta wymodelowana jako klasa, za okrelona cecha obiektu moe istnie jako konkretny egzemplarz tej klasy.

Model samochodu moe modelowa charakterystyk wydajnoci, np. typ wydajno, zawierajcy informacje o tym, w ktrym momencie silnik zmienia bieg i jak wysokie obroty moe osign. Stereotyp UML dla klasy obejmujcej cech klasa ta moe suy do tworzenia egzemplarzy klasy (Samochd) nalecej logicznie do innego typu (np. SamochdSportowy i SamochdLuksusowy) to . W tym przypadku, klasa Wydajno jest typem gwnym dla klasy Samochd. Gdy tworzymy egzemplarz klasy Samochd, jednoczenie tworzymy obiekt Wydajno, wic go z danym obiektem Samochd, jak pokazano na rysunku 11.19.

Rys. 11.19. Cecha jako typ gwny

Typy gwne umoliwiaj tworzenie rnorodnych typw logicznych, bez potrzeby uywania dziedziczenia. Dziki temu mona obsuy duy i zoony zestaw typw, bez gwatownego wzrostu zoonoci klas, jaki mgby nastpi przy uywaniu samego dziedziczenia.

W C++ typy gwne s najczciej implementowane za pomoc wskanikw. W tym przypadku klasa Samochd zawiera wskanik do egzemplarza klasy CharakterystykaWydajnoci (patrz rysunek 11.20). Zamian cech nadwozia i silnika w typy gwne pozostawi ambitnym czytelnikom.

Rys. 11.20. Relacja pomidzy obiektem Samochd a jego typem gwnym

Class Samochod : public Pojazd

{

public:

Samochod();

~Samochod();

// inne publiczne metody

private:

CharakterystykaWydajnosci * pWydajnosc;

};

I jeszcze jedna uwaga. Typy gwne umoliwiaj tworzenie nowych typw (a nie tylko egzemplarzy) w czasie dziaania programu. Poniewa typy logiczne rni si od siebie jedynie atrybutami powizanego z nim typu gwnego, atrybuty te mog by parametrami konstruktora typu gwnego. Oznacza to, e w czasie dziaania programu moesz na bieco tworzy nowe typy samochodw. Przekazujc rne rozmiary silnika i rne punkty zmiany biegw do typu gwnego, moesz efektywnie tworzy nowe charakterystyki wydajnoci. Przypisujc te charakterystyki rnym samochodom, moesz zwiksza zestaw typw samochodw w czasie dziaania programu.

Model dynamiczny

Oprcz modelowania relacji pomidzy klasami, bardzo wane jest take wymodelowanie sposobu wsppracy pomidzy klasami. Na przykad, klasy RachunekBiecy, Bankomat oraz Kwit mog wsppracowa z klas Klient, wypeniajc przypadek uycia Wypata gotwki. Wkrtce wrcimy do diagramw sekwencji uywanych wczeniej w fazie analizy, ale tym razem, na podstawie metod opracowanych dla klas, wypenimy je szczegami, tak jak na rysunku 11.21.

Rys. 11.21. Diagram sekwencji

Ten prosty diagram interakcji pokazuje wspdziaanie pomidzy klasami projektowymi oraz ich nastpstwo w czasie. Sugeruje, e klasa Bankomat deleguje na klas RachunekBiecy ca odpowiedzialno za zarzdzanie stanem rachunku, za klasa RachunekBiecy przenosi na klas Bankomat zadanie wywietlania informacji dla uytkownika.

Diagramy interakcji wystpuj w dwch odmianach. Odmiana pokazana na rysunku 11.21 jest nazywana diagramem sekwencji. Diagramy wsppracy dostarczaj innego widoku tych samych informacji. Diagramy sekwencji kad nacisk na kolejno zdarze, za diagramy wsppracy obrazuj wspdziaanie pomidzy klasami. Diagram wsppracy mona stworzy bezporednio z diagramu sekwencji; programy takie jak Rational Rose potrafi stworzy taki diagram po jednym klikniciu na przycisku (patrz rysunek 11.22).

Rys. 11.22. Diagram wsppracy

Diagramy zmian stanu

Przechodzc do zagadnienia interakcji pomidzy obiektami, musimy pozna rne moliwe stany kadego z obiektw. Przejcia pomidzy stanami moemy wymodelowa na diagramie stanu (lub diagramie zmian stanw). Rysunek 12.23 przedstawia rne stany obiektu RachunekBiecy w czasie, gdy klient jest zalogowany do systemu.

Rys. 11.23. Stan rachunku klienta

Kady diagram stanu rozpoczyna si od stanu start, a koczy na stanie koniec. Poszczeglne stany posiadaj nazwy, za zmiany stanw mog by opisane za pomoc etykiet. Stranik wskazuje warunek, ktry musi by speniony, aby obiekt mg przej ze stanu do stanu.

Superstany

Klient moe w kadej chwili zmieni zamiar i zrezygnowa z logowania si. Moe to uczyni po woeniu karty w celu zidentyfikowania swojego rachunku lub ju po wprowadzeniu kodu PIN. W obu przypadkach system musi zaakceptowa jego danie anulowania operacji i powrci do stanu nie zalogowany (patrz rysunek 11.24).

Rys. 11.24. Uytkownik moe zrezygnowa

Jak wida, w bardziej skomplikowanych diagramach, stan Anulowany szybko zaczyna przeszkadza. Jest to szczeglnie irytujce, gdy anulowanie jest stanem wyjtkowym, ktry nie powinien dominowa w diagramie. Moemy uproci ten diagram, uywajc superstanu, tak jak pokazano na rysunku 11.25.

Rys. 11.25. Superstan

Diagram z rysunku 11.25 dostarcza takich samych informacji, jak diagram z rysunku 11.24, lecz jest duo bardziej przejrzysty i atwiejszy do odczytania. Od momentu rozpoczcia logowania, a do chwili jego zakoczenia przez system, moesz ten proces anulowa. Gdy to uczynisz, powrcisz do stanu Nie zalogowany.

Czsto okrelenie jzyk UML utosamia si z bardziej oglnym pojciem, jakim jest metodyka (projektowania) UML przyp.red.

Kady z tych panw by autorem odrbnej metodyki projektowania.

J. Rumbaugh opracowa Object Modelling Technique (OMT), ktra jest wystarczajca w przypadku modelowania dziedziny zagadnienia (problem domain). Nie odzwierciedla jednak dokadnie ani wymaga uytkownikw systemw, ani wymaga implementacji.

I. Jacobson rozwin Object-Oriented System Engineering (OOSE), ktry w sposb zadowalajcy uwzgldnia aspekty modelowania uytkownikw i cyklu ycia systemu jako caoci. Nie odzwierciedla jednak w sposb wystarczajcy sposobu modelowania dziedziny oraz aspektu implementacji.

G. Booch jest autorem Object-Oriented Analysis and Design Methods (OOAD), speniajcej wszelkie wymogi w dziedzinie projektowania, konstrukcji i zwizkw ze rodowiskiem implementacji. Nie uwzgldnia jednak w sposb dostateczny fazy rozpoznania i analizy wymaga uytkownikw.

UML ma stanowi syntez wymienionych metodyk. Ma jednak wielu krytykw. W wielu publikacjach mona przeczyta, e jest to rzecz przereklamowana i w niewystarczajcy sposb zdefiniowana. Konkurencj dla cigle uzupenianej metodyki UML jest m.in. metodyka i notacja oparta na tzw. technice design by contracts. przyp.red

PAGE

F:\korekta\r11-06.doc1