plik


ÿþIDZ DO IDZ DO PRZYK£ADOWY ROZDZIA£ PRZYK£ADOWY ROZDZIA£ Zrozumieæ UML 2.0. SPIS TRERCI SPIS TRERCI Metody modelowania KATALOG KSI¥¯EK KATALOG KSI¥¯EK obiektowego KATALOG ONLINE KATALOG ONLINE Autor: Micha³ Smia³ek ISBN: 83-7361-918-6 ZAMÓW DRUKOWANY KATALOG ZAMÓW DRUKOWANY KATALOG Format: B5, stron: 296 TWÓJ KOSZYK TWÓJ KOSZYK Usprawnij proces tworzenia oprogramowania, stosuj¹c modelowanie w jêzyku UML " Poznaj podstawy modelowania obiektowego DODAJ DO KOSZYKA DODAJ DO KOSZYKA " Zamodeluj Srodowisko, wymagania i architekturê systemu " Zaprojektuj system w oparciu o model UML Tworzenie z³o¿onego systemu informatycznego wymaga przygotowania projektu. CENNIK I INFORMACJE CENNIK I INFORMACJE Nale¿y okreSliæ w nim Srodowisko dzia³ania systemu, wymagania u¿ytkowników, procesy realizowane przez system i jego elementy sk³adowe. Opis s³owny, przydatny ZAMÓW INFORMACJE ZAMÓW INFORMACJE w trakcie zbierania za³o¿eñ funkcjonalnych, mo¿e okazaæ siê zbyt skomplikowany O NOWORCIACH O NOWORCIACH i niejednoznaczny na pozosta³ych etapach opisywania powstaj¹cego systemu. Niezbêdny jest taki sposób opisu, który by³by jednakowo interpretowany i zrozumia³y ZAMÓW CENNIK ZAMÓW CENNIK dla wszystkich cz³onków zespo³u projektowego. W tym celu opracowano jêzyk UML  notacjê umo¿liwiaj¹c¹ zamodelowanie systemu w sposób graficzny, w postaci diagramów. Modele zapisane w jêzyku UML s¹ jednakowo interpretowane przez CZYTELNIA CZYTELNIA wszystkie osoby zaanga¿owane w dany projekt. S¹ te¿ niezwykle uniwersalne. Mo¿na je stosowaæ we wszystkich fazach projektowania i budowy oprogramowania. FRAGMENTY KSI¥¯EK ONLINE FRAGMENTY KSI¥¯EK ONLINE Ksi¹¿ka  Zrozumieæ UML 2.0. Metody modelowania obiektowego to podrêcznik modelowania systemów informatycznych z wykorzystaniem notacji UML 2.0. Przedstawia podstawy modelowania obiektowego i najwa¿niejsze pojêcia zwi¹zane z obiektowoSci¹. Opisuje sposoby modelowania otoczenia systemu, jego zakresu funkcjonalnego oraz struktury. W ksi¹¿ce opisano równie¿ proces przejScia z modelu do kodu xród³owego systemu oraz metodyki projektowe oparte na jêzyku UML. Ka¿dy, kto bierze udzia³ w procesie wytwarzania oprogramowania, znajdzie w tej ksi¹¿ce przydatne dla siebie informacje. " Zasady modelowania obiektowego " Formu³owanie i realizacja wymagañ " Modelowanie otoczenia systemu oraz jego funkcjonalnoSci Wydawnictwo Helion " Projektowanie architektury systemu ul. Chopina 6 " Realizacja systemu w oparciu o projekt 44-100 Gliwice " Metodyki wytwarzania oprogramowania tel. (32)230-98-63 Przekonaj siê, jak bardzo UML mo¿e u³atwiæ proces tworzenia oprogramowania e-mail: helion@helion.pl Spis tre[ci RozdziaB 1. Wstp .............................................................................................. 5 1.1. Czym jest ta ksi|ka? ................................................................................................ 5 1.2. Dla kogo jest ta ksi|ka? ........................................................................................... 6 1.3. Dlaczego modelowanie? ............................................................................................ 7 1.4. Dlaczego jzyk UML? ............................................................................................... 8 1.5. Co dalej w ksi|ce? ................................................................................................... 9 1.6. Oznaczenia typograficzne ........................................................................................ 12 1.7. Podzikowania ........................................................................................................ 13 RozdziaB 2. Wprowadzenie do modelowania ....................................................... 15 2.1. Trudna sztuka modelowania .................................................................................... 15 2.2. ZBo|ono[ oprogramowania. Jak j pokona? ......................................................... 17 2.3. Metodyka wytwarzania oprogramowania ................................................................ 20 RozdziaB 3. Podstawy modelowania obiektowego .............................................. 25 3.1. Jak modelowa [wiat obiektowo? ........................................................................... 25 3.2. Obiekty .................................................................................................................... 27 3.3. Klasy obiektów ........................................................................................................ 32 3.4. Modelowanie struktury ............................................................................................ 37 3.5. Modelowanie dynamiki ........................................................................................... 43 3.6. Które modele musz dobrze pozna? ..................................................................... 50 RozdziaB 4. Od opisu [rodowiska do kodu .......................................................... 53 4.1. Jak zapewni zgodno[ kodu ze [rodowiskiem? ..................................................... 53 4.2. Zcie|ka od opisu [rodowiska do kodu ..................................................................... 57 4.3. Tworzenie systemów sterowane modelami ........................................................... 60 4.4. FormuBowanie wymagaD ......................................................................................... 63 4.5. Realizacja wymagaD ................................................................................................ 65 4.6. Modele, narzdzia, jako[ ....................................................................................... 67 RozdziaB 5. Modelowanie [rodowiska ................................................................ 71 5.1. Jak opisa [rodowisko? ........................................................................................... 71 5.2. Struktura  aktorzy, jednostki organizacyjne i pojcia .......................................... 77 5.3. Dynamika  procesy, czynno[ci i stany ................................................................. 87 5.4. Spójno[ modeli [rodowiska ................................................................................. 100 5.5. PrzykBadowe problemy .......................................................................................... 102 4 Zrozumie UML 2.0. Metody modelowania obiektowego RozdziaB 6. Modelowanie wymagaD ................................................................. 105 6.1. Jak okre[li zakres funkcjonalny systemu oprogramowania? ................................ 105 6.2. Struktura  aktorzy, klasy .................................................................................... 108 6.3. Dynamika  przypadki u|ycia, scenariusze, czynno[ci, stany ............................. 124 6.4. Spójno[ modelu wymagaD i zgodno[ ze [rodowiskiem ..................................... 145 6.5. PrzykBadowe problemy .......................................................................................... 148 RozdziaB 7. Tworzenie architektury .................................................................. 151 7.1. Co to jest i z czego si skBada architektura systemu oprogramowania? ................. 151 7.2. Struktura  komponenty, interfejsy, klasy, wzBy ................................................ 155 7.3. Dynamika  interakcje, czynno[ci ....................................................................... 177 7.4. Spójno[ architektury i zgodno[ z wymaganiami ................................................ 189 7.5. PrzykBadowe problemy .......................................................................................... 193 RozdziaB 8. Projektowanie i realizacja systemu ................................................ 195 8.1. Jak stworzy szczegóBowy projekt systemu? ......................................................... 195 8.2. Struktura  interfejsy, klasy ................................................................................. 197 8.3. Dynamika  interakcje, czynno[ci ....................................................................... 205 8.4. Spójno[ projektu i zgodno[ z architektur ......................................................... 219 8.5. PrzykBadowe problemy .......................................................................................... 222 RozdziaB 9. Modelowanie w procesie wytwórczym ........................................... 225 9.1. Nowoczesne metodyki wytwarzania oprogramowania .......................................... 225 9.2. Proces techniczny oparty na modelach w jzyku UML ......................................... 232 9.3. Podsumowanie: czy modelowanie to  srebrna kula ? ........................................... 239 Dodatek A Podsumowanie skBadni jzyka UML 2.0 ......................................... 241 Dodatek B Organizacja modeli w narzdziu CASE ............................................ 259 Dodatek C Krótki sBownik metod obiektowych i jzyka UML ............................ 267 Literatura ..................................................................................... 287 Skorowidz ..................................................................................... 295 RozdziaB 3. Podstawy modelowania obiektowego 3.1. Jak modelowa [wiat obiektowo? Z poprzedniego rozdziaBu wiemy, |e system oprogramowania powinien by jak naj- wierniejszym modelem otaczajcego [wiata. Powstaje zatem pytanie, w jaki sposób skonstruowa ten model, aby speBniaB to podstawowe wymaganie wierno[ci? Mamy bowiem do czynienia z dwoma ró|nymi punktami widzenia na oprogramowanie. Z jednej strony stoj zamawiajcy, którzy maj pewne wymagania w stosunku do systemu. Z dru- giej strony mamy programistów, którzy wiedz, jak konstruowa systemy. Zamawiajcy znaj dziedzin problemu i potrafi o niej opowiada za pomoc specjalistycznego sBownictwa. Nie s to zazwyczaj osoby skBonne do czytania, a tym bardziej tworzenia, technicznych opisów systemu. Zamawiajcy chc opisa system w sposób jak najprostszy i jak najbardziej zrozumiaBy w kontek[cie swoich codziennych obowizków. Wynika to oczywi[cie z tego, |e system powinien im pomaga w pracy, któr wykonuj. Z drugiej strony programi[ci tworz system z bardzo precyzyjnych konstrukcji odpowiedniego jzyka programowania. S oni najcz[ciej dokBadnie zorientowani w szczegóBach plat- formy sprztowej lub programowej, czy te| w niuansach okre[lonej biblioteki kodu. Nie s natomiast zazwyczaj ekspertami w dziedzinie, dla której tworz system. Ich sBownictwo jest zasadniczo ró|ne od sBownictwa zamawiajcych. Wymagaj zatem bardzo dokBadnego opisu sposobu konstrukcji systemu. {eby byBo jeszcze trudniej, zarówno zamawiajcy, jak i programi[ci musz panowa nad systemem, który zwykle skBada si z tysicy ró|nych wymagaD, dziesitków mo- duBów czy setek tysicy wierszy kodu. Podkre[lali[my to ju| w poprzednim rozdziale. Jak zatem pogodzi sprzeczne spojrzenia zamawiajcych i programistów? Jak zapano- wa nad zBo|ono[ci problemu? Czy istnieje jaka[ mo|liwo[ porozumienia? Czytelnik zapewne ju| si domy[la, |e sposobem na wzajemne zrozumienie, który bdziemy chcieli zaproponowa w tej ksi|ce, jest modelowanie za pomoc technik obiektowych. 26 Zrozumie UML 2.0. Metody modelowania obiektowego Elementem, który w modelowaniu obiektowym pozwala pogodzi jzyk u|ytkownika z jzykiem programisty oraz pokona problem zBo|ono[ci systemu, jest obiekt. Obiekty znajdujce si w [rodowisku ustalaj wspólny jzyk w zespole odpowiedzialnym za powstanie systemu oprogramowania (rysunek 3.1). Z jednej strony obiekty odpowiadaj pojciom z modelowanej dziedziny problemu. Z drugiej strony s podstaw imple- mentacji realizowanego systemu. Jest to mo|liwe dziki istnieniu obiektowych jzyków programowania. Obiekty umo|liwiaj realizacj zasady abstrakcji, gdy| mog repre- zentowa skomplikowane struktury (skBadajce si z wielu elementów, które znowu skBadaj si z wielu elementów itd.). Dziki temu obiekty na danym poziomie abstrakcji ukrywaj informacje nieistotne dla czytelnika modelu. Obiekty s zatem pewnego rodzaju czarnymi skrzynkami (rysunek 3.7). Dopiero po otwarciu takiej czarnej skrzynki i wej[ciu w gBb odkrywamy dalsze szczegóBy. Rysunek 3.1. Obiekty  wspólny jzyk dla ró|nych ról projektowych  modelarz zamawiajcy programista Na bazie obiektów powstaj obiektowe ’!modele (ang. model), czyli  tak jak ju| mówili[my w poprzednim rozdziale  kopie rzeczywistych systemów. ’!Modelowanie obiektowe (ang. object modeling) polega zatem na: znajdowaniu obiektów w otoczeniu, opisywaniu struktury i dynamiki dziaBania obiektów, klasyfikacji obiektów, opisywaniu struktury powizaD klas obiektów oraz opisywaniu dynamiki wspóBpracy obiektów podczas funkcjonowania systemu. Mo|emy te| powiedzie, |e modelowanie obiektowe polega na rysowaniu diagramów opisujcych struktur i dynamik systemu skBadajcego si z obiektów. Diagramy ukazuj system na ró|nym poziomie abstrakcji. Modele obiektowe bdziemy tworzy za pomoc jednolitej notacji. Bdzie ni graficzny jzyk UML. W rozdziale przedstawimy podstawowe pojcia modelowania obiektowego i ich notacj w jzyku UML: obiekty, klasy, diagramy opisu struktury i diagramy opisu dynamiki. Bdzie to podstawowy jzyk porozumiewania si. Zostanie on wykorzystany i rozbudowany w nastpnych rozdziaBach do ustanowienia [cie|ki od wymagaD do kodu. RozdziaB 3. f& Podstawy modelowania obiektowego 27 3.2. Obiekty Jak ju| powiedzieli[my, obiekty wystpuj w [rodowisku, ale równie| mog by ele- mentami systemu oprogramowania. Obiekty mog zatem by przedmiotami (urzdze- niami technicznymi, budynkami, tworami przyrody), osobami, ale równie| ró|nego rodzaju jednostkami organizacyjnymi, zdarzeniami lub dokumentami. W systemie oprogramowania, oprócz obiektów odpowiadajcych elementom [rodowiska, mog wystpowa np. ekrany, interfejsy, bazy danych, zarzdcy aplikacji czy komunikacji. Zwrómy uwag, |e obiekty zwizane z opisem systemu s zale|ne od wykorzystywanej technologii, a nie od modelowanego [rodowiska. Takie obiekty techniczne pojawiaj si w momencie, kiedy zaczynamy projektowa system wraz z jego architektur. Zastanówmy si teraz nad tym, w jaki sposób nale|y opisywa obiekty. ’!Obiekt (ang. object) w rozumieniu modelowania obiektowego mo|e by opisany za pomoc trzech elementów: to|samo[ci, stanu i zachowania. Ka|dy obiekt ma zatem indywidualn to|samo[ odró|niajc go od innych obiektów. Obiekty zawieraj równie| elementarne skBadniki o zmieniajcych si warto[ciach, które okre[laj ich stan. Potrafi te| zacho- wywa si w odpowiedni sposób w ró|nych sytuacjach  w odpowiedzi na komunikaty wykonuj okre[lone usBugi na rzecz innych obiektów. W jzyku UML ’!obiekt jest reprezentowany za pomoc prostokta, który UML zawiera podkre[lon nazw obiektu (rysunek 3.2). 2.0 Rysunek 3.2. mój_samochód UML: Podstawowa samochód_kolegi notacja obiektu Zanim przedstawimy bli|ej wymienione powy|ej elementy opisu obiektów, rozwa|my krótki przykBad. Poniewa| najBatwiej jest chyba operowa na przykBadzie znanych nam urzdzeD technicznych, wezmiemy pod uwag nasz samochód1 (rysunek 3.3). Ma on niewtpliwie indywidualn to|samo[, ró|n od to|samo[ci samochodu naszego ssiada. Nie ma tutaj znaczenia fakt, |e obydwa samochody wygldaj na pierwszy rzut oka identycznie. Aatwo jest rozró|ni to|samo[ samochodów, je|eli widzimy je obok siebie. Ten samochód jest nasz, a tamten  naszego ssiada. S to przecie| ró|ne przedmioty, nawet je[li wygldaj tak samo. Nasz samochód jest oczywi[cie w okre[lonym stanie: jest koloru brzowego, ma silnik pojemno[ci 1200 cm3, silnik jest wyBczony, hamulec jest zacignity, numer nadwozia to ABC-3597564 itd. Samochód mo|e si te| w okre- [lony sposób zachowywa  mo|e uruchomi silnik, mo|e te| skrci w lewo lub w prawo albo pojecha do tyBu. Musimy tylko go o to  poprosi  przekrci kluczyk w stacyjce, skrci kierownic czy wrzuci wsteczny bieg. Na bazie tego przykBadu spróbujmy teraz formalnie zdefiniowa poszczególne elementy opisu obiektu. 1 Zwrómy uwag, |e bierzemy pod uwag  nasz samochód , a nie ogólnie   jakikolwiek samochód . 28 Zrozumie UML 2.0. Metody modelowania obiektowego Rysunek 3.3. To|samo[, stan i zachowanie samochodu wBcz silnik! ’!Stan (ang. state) obiektu to zbiór warto[ci (cech charakterystycznych) wszystkich jego wBa[ciwo[ci. Warto[ci wBa[ciwo[ci ’!obiektu mo|e by np. jaka[ liczba, napis lub element innego typu. Ka|dy obiekt ma przypisany zbiór wBa[ciwo[ci, które go charak- teryzuj. S one nierozerwalnie zwizane z danym obiektem  s jego skBadowymi. Zwrómy te| uwag, |e wBa[ciwo[ci s tak naprawd obiektami, które s w caBo[ci kontrolowane przez obiekt gBówny. W czasie swojego |ycia obiekt ma zawsze ten sam zestaw wBa[ciwo[ci. Jednak|e wBa[ciwo[ci obiektu mog w trakcie |ycia obiektu przyj- mowa ró|ne warto[ci. Te ró|ne warto[ci wyznaczaj stan obiektu w danym momencie. ’!Stan ’!obiektu okre[lamy, podajc warto[ci jego ’!wBa[ciwo[ci (ang. pro- UML perty), które umieszczamy w ’!przegródce (ang. compartment) poni|ej nazwy 2.0 obiektu (rysunek 3.4). Po nazwie wBa[ciwo[ci umieszczamy znak  = , a nastpnie warto[ wBa[ciwo[ci. Oczywi[cie taka notacja jest mo|liwa dla wBa[ciwo[ci, które przybieraj warto[ci typów elementarnych (warto[ci liczbowe, napisy itp.). W przypadku gdy wBa[ciwo[ obiektu jest obiektem zBo|onym, wewntrz prze- gródki wBa[ciwo[ci umieszczamy zazwyczaj jedynie nazw obiektu skBadowego. Stan wBa[ciwo[ci skBadowej mo|emy pokaza, umieszczajc obok obiekt odpo- wiadajcy tej wBa[ciwo[ci i okre[lajc warto[ci wBa[ciwo[ci tego obiektu skBado- wego. Dodatkowo Bczymy obiekt gBówny i obiekt skBadowy ’!Bcznikiem (ang. link) wskazujcym na obiekt podrzdny. Na rysunku 3.4 obiektem gBów- nym jest mój_samochód. Jak widzimy, jedn z wBa[ciwo[ci tego obiektu jest silnik. Aktualny stan silnika okre[la obiekt o tej samej nazwie jak odpowiednia wBa[ciwo[ mojego_samochodu. mój_samochód numer nadwozia="ABC-3597564" silnik kolor=brz numer="HH22123" kierunek_skrtu=30 silnik pojemno[=1200 status=wyBczony Rysunek 3.4. UML: PrzykBad notacji dla wBa[ciwo[ci elementarnych i zBo|onych 4 6 y 5 7 w 9 o 5 z y 3  n - r o b C z = B c r A  o B l = y o a i w K z = o w a k d i a n l n i s r n n a t s a d a i s  s j ó m RozdziaB 3. f& Podstawy modelowania obiektowego 29 ’!To|samo[ (ang. identity) obiektu wyró|nia ’!obiekt w[ród innych obiektów jako osobn jednostk. Mo|na j okre[li jako wyró|nion cech obiektu, która pozostaje niezmienna przez caBy czas |ycia tego obiektu. Co wicej, warto[ tej cechy powinna by unikalna w[ród wszystkich obiektów, które otaczaj nasz obiekt. W najprostszym przypadku cech obiektu, która stanowi o jego to|samo[ci, jest umiejscowienie obiektu (np. w pamici systemu). Mo|e si jednak okaza, |e obiekt zmienia swoje poBo|enie albo znajduje si w zbiorze nieuporzdkowanych obiektów o swobodnym dostpie (np. w bazie danych). Wtedy to|samo[ obiektu powinni[my okre[li poprzez dodanie wyró|nionej ’!wBa[ciwo[ci (np. nadajc jej wyró|nik «identity»). Nale|y tu podkre[li, |e taka dodatkowa wBa[ciwo[ nie mo|e stanowi elementu stanu obiektu. Jako taka powinna zatem przybiera warto[ci caBkowicie abstrakcyjne  niezale|ne od ’!dziedziny problemu (ang. problem domain), czyli od otaczajcej rzeczywisto[ci. Je|eli to|samo[ nie byBaby cech abstrakcyjn obiektu, to mogBaby ulec zmianie w trakcie |ycia obiektu  w miar zmian ’!dziedziny problemu. Warto te| podkre[li, |e oczywi[cie mo|liwe jest rozró|nienie to|samo[ci obiektów za pomoc ich ’!stanu (np. stwierdzajc, jaki kolor ma samochód). Mo|e si jednak zdarzy, |e w systemie wystpi dwa ró|ne obiekty o identycznym stanie. Wtedy jedyn mo|liwo[ci rozró|- nienia obiektów bdzie ich abstrakcyjna to|samo[. Najbardziej oczywiste rozró|nienie ’!to|samo[ci ’!obiektów to po prostu UML umieszczenie na diagramie ró|nych obiektów, które w szczególno[ci posiadaj 2.0 ró|ne nazwy ( mój samochód i  samochód kolegi na rysunku 3.5). Wtedy rozró|nienie i dostp do ’!stanu obiektów nastpuje poprzez odwoBanie si do ich unikalnego poBo|enia. Problem pojawia si wtedy, gdy obiekty chcemy zapisa np. w bazie danych. W takiej sytuacji musimy do ka|dego obiektu  doczepi dodatkow  metk odró|niajc go od innych. Na rysunku 3.5 tak metk jest dodatkowa wBa[ciwo[ o nazwie  num . Aby zaznaczy, |e ta wBa- [ciwo[ nie jest elementem stanu obiektu, nadali[my jej wyró|nik «identity»2. Zwrómy te| uwag, |e obiekty na rysunku 3.5 s w identycznym stanie. Wszystkie warto[ci ich wBa[ciwo[ci s takie same. Dotyczy to nawet nume- rów nadwozi, które s (zapewne przez pomyBk) identycznymi napisami. Gdyby[my zapisali te dwa obiekty w bazie danych bez wyró|nika, to niemo|- liwe byBoby ich rozró|nienie. mój_samochód samochód_kolegi <<identity>> num=sX000001 <<identity>> num=sX000002 numer_nadwozia="ABC-3597564" numer_nadwozia="ABC-3597564" kolor=brz kolor=brz kierunek_skrtu=30 kierunek_skrtu=30 Rysunek 3.5. UML: PrzykBad notacji dla rozró|nienia to|samo[ci obiektów 2 Takie wyró|niki umieszczone w podwójnych nawiasach uko[nych nazywamy w jzyku UML stereotypami. Zostan one omówione dokBadniej w dalszych rozdziaBach ksi|ki. 30 Zrozumie UML 2.0. Metody modelowania obiektowego Na koniec zauwa|my, |e wyró|nik «identity» jest warto[ci, która powinna by generowana automatycznie, tak aby zapewni jego unikalno[ (zwrómy uwag na wyró|niki obiektów na rysunku 3.5 bdce kolejnymi unikalnymi warto[ciami w cigu). ’!Zachowanie (ang. behavior) obiektu to zbiór usBug, które ’!obiekt potrafi wykonywa na rzecz innych obiektów. Zachowanie ustanawia bardzo istotny element dynamiki modelu (tzn. sposobu dziaBania systemu). W ramach tej dynamiki obiekty mog prosi inne obiekty o wykonanie odpowiednich usBug. Obiekt reaguje na tak pro[b, je|eli usBuga jest w zbiorze obsBugiwanych przez niego usBug. Pro[by obiektów o wykonanie usBug bdziemy nazywali ’!komunikatami (ang. message). W ramach wykonania usBugi obiekt przeprowadza odpowiednie dla usBugi przetwarzanie danych. Jego efektem mo|e by zmiana ’!stanu obiektu albo dostarczenie drugiemu obiektowi odpowied- niego rezultatu przetwarzania. Efekt wykonania usBugi zale|y od trzech rzeczy: a) stanu obiektu, b) parametrów komunikatu, c) stanu innych obiektów, z których usBug korzysta obiekt podczas przetwarzania. Zale|no[ od stanu obiektu jest oczywista. Inaczej si bdzie zachowywaB np. samochód ze stanem paliwa równym 100%, a inaczej przy stanie paliwa równym zero. ’!Parametry (ang. parameter) komunikatu to lista warto[ci obiektów, które pozwalaj na sterowanie zachowaniem usBugi. UsBuga mo|e si zatem zachowywa ró|nie w zale|no[ci od warto[ci parametrów. Na przykBad parametrem usBugi  skr powinien by kt skrtu. W trakcie wykonywania usBugi obiekt mo|e równie| poprosi inne obiekty o pomoc. Wtedy wysyBa do nich odpowiednie komuni- katy. Dlatego te| przetwarzanie usBugi mo|e by zale|ne od stanu innych obiektów. Po zakoDczeniu wykonania usBugi czsto nastpuje komunikat zwrotny  od obiektu, który wykonaB usBug ( wykonawcy ), do obiektu proszcego o wykonanie usBugi ( klienta ). Przekazywane s w nim warto[ci obiektów, które s rezultatem przetwarza- nia i na które oczekuje klient usBugi. Na rysunku 3.6 widzimy opis fragmentu zachowania si ’!obiektu  mój samo- UML chód . Jest to ’!diagram sekwencji (ang. sequence diagram) pokazujcy 2.0 wymian ’!komunikatów podczas jednego z wykonaD usBugi  uruchom si . Komunikaty wymieniane s midzy kolumnami nazywanymi ’!liniami |ycia (ang. lifeline). Ka|da kolumna odpowiada jednemu obiektowi. Kolejno[ wymie- nianych komunikatów jest liczona od góry do doBu diagramu. Komunikat wywoBujcy usBug jest zaznaczony poziom strzaBk o peBnym grocie, skiero- wan od obiektu klienta do obiektu wykonawcy. Na rysunku rozpoczcie dziaBania usBugi  uruchom si nastpuje poprzez skierowanie komunikatu  uruchom si do obiektu  mój samochód . Zauwa|my, |e komunikat ten ma ’!parametr   kod klucza . Nazwa parametru umieszczona jest w nawiasach po nazwie komunikatu. Gdyby parametrów byBo wicej, mogliby[my je umie- [ci  rozdzielone przecinkami  wewntrz nawiasu. Po uruchomieniu usBugi (przesBaniu komunikatu) nastpuje ’!wykonanie usBugi (ang. execution occurence). Zaznaczane jest jako wski prostokt umieszczony na ’!linii |ycia. Z diagramu mo|emy wywnioskowa, |e po wywoBaniu usBugi samochód sprawdza, czy kod klucza jest odpowiedni. Prawdopodobnie spraw- dzany jest równie| stan paliwa w zbiorniku. W tym konkretnym przypadku RozdziaB 3. f& Podstawy modelowania obiektowego 31 stan_paliwa=53% ja mój_samochód silnik stan_oleju=0% uruchom_si(kod_klucza) [kod klucza O.K.]: wBcz_si "zepsuty" "zepsuty silnik" Rysunek 3.6. UML: PrzykBad sekwencji komunikatów podczas realizacji usBugi zarówno stan paliwa, jak i kod klucza byBy prawidBowe. W zwizku z tym samochód przesyBa do silnika ’!komunikat  wBcz si . Zwrómy uwag, |e przesBanie komunikatu nastpuje pod pewnym ’!warunkiem (ang. condition). Jest on umieszczony w nawiasach prostoktnych. Mo|emy si domy[la, |e gdyby ten warunek nie byB speBniony (kod klucza nie byBby  O.K. ), nastpiBaby jaka[ inna akcja (np. wysBanie innego komunikatu). Po otrzymaniu komunikatu  wBcz si silnik zapewne próbuje si uruchomi. Z diagramu wynika, |e mu si to nie udaBo. WysyBa zatem ’!komunikat zwrotny, sygnalizujcy, |e silnik jest zepsuty. Komunikat zwrotny zaznaczany jest prze- rywan lini. Przyczyn  zepsucia silnika wyja[nia ’!notatka (ang. note) przyczepiona do obiektu  brakuje oleju. Notatki umieszczone na rysunku 3.6 zawieraj w sobie opis aktualnych warto[ci niektórych wBa[ciwo[ci poszcze- gólnych obiektów (czyli fragmenty stanów tych obiektów). Po otrzymaniu komunikatu od silnika samochód wysyBa komunikat zwrotny sygnalizujcy zepsucie silnika. Zwrómy uwag, |e komunikat zwrotny koDczy wykonanie usBugi. Wykonanie usBugi zawarte jest zatem midzy komunikatem wywoBujcym usBug a komunikatem zwrotnym. Podsumowujc rozwa|ania na temat cech ’!obiektów, nale|y stwierdzi, |e bardzo istotn wBasno[ci modelowania obiektowego jest to, |e obiekty stanowi pewnego rodzaju  czarne skrzynki . Obiekt pokazuje na zewntrz tylko te swoje wBa[ciwo[ci lub usBugi, które s potrzebne innym obiektom. Inne szczegóBy s ukryte. Umo|liwia to realizacj zasady abstrakcji, o której byBa mowa w rozdziale 2. Mo|emy sobie zatem wyobrazi obiekt jako czarn skrzynk z przyciskami (rysunek 3.7). Naci[nicie przycisku oznacza uruchomienie odpowiedniej usBugi obiektu. Wynikiem wykonania usBugi jest rezultat, który otrzymuje ten, kto nacisnB przycisk. Dla naciskajcego nie jest natomiast wa|ne, jak usBuga jest w [rodku wykonywana i kto jeszcze w jej wykonaniu uczestniczy. Wa|ne jest jednak, aby przyciski byBy dobrze opisane, tak aby naciskajcy wiedziaB, co dostanie po naci[niciu przycisku. 32 Zrozumie UML 2.0. Metody modelowania obiektowego Rysunek 3.7. Obiekt jako czarna skrzynka z przyciskami

Wyszukiwarka

Podobne podstrony:
Metody modelowania procesow 12 cz I (1)
UML język modelowania danych
Metody modelowania procesow 12 cz II
Metody modelowania procesow 12 cz III
Jezyk UML 20 w modelowaniu systemow informatycznych
Metody modelowania procesow 12 cz II
2007 08 UML – modelowanie statycznych aspektów oprogramowania [Inzynieria Oprogramowania]
Modelowanie zmienności i ryzyka Metody ekonometrii finansowej
Modelowanie UML

więcej podobnych podstron