dsaasdasdasBartosz Walter
Wykad ten stanowi drug cz wprowadzenia do jzyka UML i przegldu jego najwaniejszych elementów.
UML cz. II
Podczas biecego wykadu zostan przedstawione pozostae diagramy dotyczce struktury programu: diagram komponentów oraz diagram pakietów. Nastpnie omówione bd diagramy interakcji, prezentujce dynamiczny aspekt modelu systemu, przede wszystkim – diagramy sekwencji i wspódziaania. Kolejna cz wykadu bdzie powicona diagramom czynnoci oraz stanu, opisujcym wewntrzne zachowanie klas, komponentów i podsystemów.
Po zakoczeniu przegldu diagramów przedstawiony zostanie jzyk OCL sucy do formalnego opisu ogranicze w UML. Mimo, e jego stosowanie nie jest obowizkowe, to jednak odgrywa on znaczc rol przy wykorzystaniu notacji UML jako podstawy do generowania kodu wykonywalnego.
Ostatni czci bdzie przedstawienie wybranych narzdzi UML, zarówno komercyjnych, jak i darmowych.
UML cz. II
Diagram komponentów pokazuje zalenoci pomidzy komponentami i interfejsami
komponent
implementuje interfejs Przeszukiwanie
Funkcjonalno oferowana przez komponent jest dostpna przez interfejsy, które implementuje. Z drugiej strony, komponent moe wymaga pewnych interfejsów, które musz by dostarczone przez inne komponenty.
Diagram komponentów (ang. component diagram) przedstawia komponenty, ich interfejsy oraz zalenoci pomidzy nimi.
Na powyszym slajdzie komponent Katalog implementuje interfejsy Sortowalny oraz Przeszukiwanie, natomiast interfejs Meneder kryteriów potrzebuje implementacji interfejsu Przeszukiwanie i korzysta w tym celu z komponentu Katalog.
Przedstawiony diagram stosuje notacj znan z UML 1.x. W przypadku UML 2.0 komponenty s przedstawiane w postaci prostoktów ze stereotypem «component», natomiast interfejsy dane przez komponent w postaci otwartych tzw. "apek" dopasowanych do tzw. "pieczek" reprezentujcych implementowane interfejsy.
UML cz. II
Meneder wydawnictw zaley od Bazy danych
dsdsadasdadsa
Bartosz Walter
Komponenty s midzy sob powizane relacj zalenoci. Oznacza ona, e komponent zaleny wymaga innego komponentu w celu realizacji wasnej funkcjonalnoci. Zaleno midzy A i B oznacza ponadto, e komponent A korzysta z komponentu B i zmiana w komponencie B moe spowodowa konieczno zmiany w A.
Liczba i jako tych zalenoci ma due znaczenie dla oceny jakoci modelu i projektu: dua liczba powiza pomidzy komponentami, a w szczególnoci zalenoci cykliczne, w znacznym stopniu utrudniaj wyznaczanie obszarów zmiennoci i ich hermetyzacj, a co za tym idzie – podnosz koszt pielgnacji oprogramowania. W odrónieniu od tego, system o dobrze zdefiniowanych interfejsach komponentów pozwala na ich wymian bez potrzeby modyfikacji pozostaej czci systemu.
Przykad przedstawiony na slajdzie pokazuje m.in. zaleno komponentu Katalog (który implementuje interfejs Sortowalny, jednak nie jest w ten sposób przez aden inny komponent wykorzystywany) od Menedera wydawnictw. Komponent Katalog posiada take interfejs Przeszukiwanie, który jest interfejsem wymaganym przez Menedera rozlicze i Menedera kryteriów. Interfejs ten stanowi punkt czcy Katalog z tymi komponentami.
UML cz. II
Diagram pakietów
Pakiety w UML su do przechowywania innych elementów jzyka, przede wszystkim klas. Dziki nim mona uporzdkowa struktur modelu.
Pakiet Obsuga czytelników::GUI
Diagramy pakietów (ang. package diagrams) su do modelowania fizycznego i logicznego podziau systemu. Pakiety s elementem strukturalizujcym elementy UML i su do grupowania ich wedug dowolnego kryterium. W pakiecie mona umieci praktycznie dowolne elementy: klasy, komponenty, przypadki uycia, a take inne pakiety. W ten sposób przedstawiaj one drzewiast struktur elementów modelu.
Pakiety doskonale nadaj si do wizualizacji podstawowych zalenoci pomidzy czciami systemu, dziki czemu atwo oceni jako i stopie powiza pomidzy nimi. Dobra struktura pakietów, w której zalenoci s jasno uporzdkowane oraz nie wystpuj (lub wystpuj tylko na niskim poziomie) zalenoci cykliczne, wspiera póniejsz rozbudow systemu. W szczególnoci przydaj si w duych aplikacjach, podzielonych na wiele podsystemów, poniewa w prosty sposób obrazuj podstawowe zalenoci pomidzy nimi.
Pakiet tworzy take pewnego rodzaju jednostk hermetyzacji: elementy z pakietu odwouj si do elementów zewntrznych posugujc si ich penymi kwalifikowanymi (zawierajcymi nazwy pakietów) nazwami, zgodnie z ich zakresem widocznoci, natomiast wewntrz pakietu elementy mog odwoywa si do siebie bezporednio.
Elementy wewntrz pakietu mog mie jeden z dwóch poziomów widocznoci: prywatny lub publiczny. Elementy publiczne s widziane i mog by uyte poza wasnym pakietem, natomiast prywatne – nie. Aby elementy pakietu mogy odwoa si do elementów prywatnych z innego pakietu, musz go importowa. Oznacza to, e elementy te staj si dla importujcego pakietu widoczne. Import pakietu oznaczany jest zalenoci ze sowem kluczowym «import».
UML cz. II
wze
Diagramy te s rzadko uywane przy modelowaniu mniejszych i rednich systemów, dlatego zwykle ich rola jest ograniczona. Poniewa posuguj si zaledwie kilkoma symbolami, dlatego kluczow rol odgrywaj stereotypy nadawane poszczególnym elementom. Pozwalaj one doprecyzowa znaczenie i funkcj oprogramowania oraz sprztu.
Diagramy wdroenia istotn rol odgrywaj przy wdraaniu duych, rozproszonych systemów.
UML cz. II
Diagramy interakcji w UMLu opisuj komunikacj midzy obiektami. Zwykle diagramy nale do okrelonych obiektów.
Rodzaje diagramów interakcji w UML:
diagram sekwencji
komunikacji (UML 2.0)
diagram przegldu interakcji
diagram uwarunkowa czasowych
Sporód nich najbardziej znanym i najczciej wykorzystywanym jest diagram sekwencji, pokazujcy przepyw komunikatów midzy obiektami w kontekcie czasu. Pozostae diagramy – komunikacji, przegldu interakcji czy uwarunkowa czasowych – zwykle odgrywaj mniejsz rol, ale warto o nich wspomnie.
UML cz. II
czas
sd
dsdsadasdadsa
Diagramy sekwencji (ang. sequence diagrams) w intuicyjny i czytelny sposób prezentuj kolejno wywoa operacji, przepyw sterowania pomidzy obiektami oraz szkielet algorytmu metody. Pomijaj natomiast cakowicie zwizany z komunikacj aspekt dostpu do danych i operacji na nich. Uczestnikami diagramów sekwencji s obiekty, opisane nazw obiektu i jego klas, które wymieniaj midzy sob komunikaty.
Diagram sekwencji jest zapisany w prostokcie oznaczonym operatorem sd (od angielskiej nazwy diagramu) i skada si z pionowych linii ycia (ang. lifelines) poszczególnych obiektów uczestniczcych w interakcji oraz wymienianych midzy nimi komunikatów (wywoa operacji). Biae prostokty umieszczone na linii ycia obiektu oznaczaj, e obiekt jest zajty wykonywaniem pewnej czynnoci (natomiast nie maj bezporedniego zwizku z istnieniem obiektu). Czas jest reprezentowany w postaci pionowej osi diagramu.
Linia ycia obiektu to czas, w którym konkretna instancja obiektu jest w stanie przyjmowa komunikaty i wysya je. Innymi sowy, obejmuje ona czas istnienia obiektu w systemie. Obiekt jest tworzony poprzez wysanie do niego komunikatu-konstruktora (Bibliotekarz tworzy obiekt klasy Karta Wydawnictwa), natomiast niekoniecznie jest fizycznie usuwany na kocu linii ycia – raczej przestaje by istotny i wychodzi poza zakres diagramu. Fizycznie usunicie obiektu mona wprost oznaczy jako znak X na linii ycia (na przykad obiekt Karta wydawnictwa).
UML cz. II
Bartosz Walter
Komunikat to forma kontaktu pomidzy obiektami, której efektem ma by podjcie przez docelowy obiekt pewnej akcji. Otrzymanie komunikatu przez obiekt wie si z wykonaniem przez niego jego wasnego kodu lub wysaniem kolejnego komunikatu do innego obiektu w celu wykonania przez niego pewnej akcji.
Komunikaty w UML s reprezentowane przez strzaki czce linie ycia poszczególnych obiektów. Kady komunikat wewntrz interakcji opatrzony jest kolejnym numerem, co pozwala na atwe ledzenie jej przebiegu. Istniej trzy podstawowe komunikaty, jakie mog zosta wymienione pomidzy obiektami: wywoanie procedury, powrót z niej oraz wywoanie asynchroniczne.
UML cz. II
loop
Bardzo czsto zachodzi konieczno wskazania specjalnej wasnoci pewnej czci interakcji, np. oznaczenie sekcji krytycznej czy zwyczajnej ptli. Na diagramach sekwencji tak grup operacji obejmuje si prostoktem, w którego lewym górnym naroniku, w piciokcie umieszcza si sowo kluczowe lub opis okrelajcy znaczenie danego bloku (tzw. operator interakcji), np.:
alt (od alternative) – okrelajcy warunek wykonania bloku operacji, odpowiadajcy instrukcji if-else; warunek umieszcza si wówczas wewntrz bloku w nawiasach kwadratowych
opt (od optional) – reprezentujcy instrukcj if (bez else)
par (od parallel) – nakazujcy wykona operacje równolegle
critical – oznaczajcy obszar krytyczny
loop – definiujcy ptl typu for (o okrelonej z góry liczbie iteracji) lub while (wykonywanej dopóki pewien warunek jest prawdziwy)
UML cz. II
UML cz. II
1.1: wyszukaj
1.2: status
1.2: wypoycz
Bartosz Walter
Diagram komunikacji (ang. communication diagram) jest rozszerzon i przemianowan wersj diagramu wspódziaania (ang. collaboration diagram) znanego z UML 1.x. W odrónieniu od diagramu sekwencji, skupia si on na obiektach wchodzcych w skad interakcji i wymienianymi przez nie komunikatach, natomiast w mniejszym stopniu (cho nadal obecnym) wskazuje na aspekt czasowy. Z tego powodu obiekty na diagramie komunikacji s umieszczone tak, aby atwo mona byo opisa ich relacje pomidzy sob. Komunikacje s przedstawiane za pomoc linii czcych obiekty, natomiast przesyane midzy obiektami komunikaty i dane s umieszczane obok tych linii. Kady komunikat jest opatrzony etykiet liczbow, wskazujc na kolejno ich wysyania. Etykieta ta ma posta liczb oddzielonych kropkami. W przypadku rozdzielenia sterowania kady krok powoduje dodanie do etykiet kroków nastpnych kolejnych pól z liczbami, np. krok 2 powoduje utworzenie kroków 2.1, 2.2 lecych bezporednio za nim. Krok 2.1 posiada kroki 2.1.1 i 2.1.2, itd.
W odrónieniu od diagramów sekwencji, diagramy komunikacji nie mog przekaza wielu informacji dotyczcych interakcji, np. bloków komunikatów. Z drugiej strony jednak prezentuj rzeczywiste powizania obiektów i ich relacji, co moe uatwi zrozumienie interakcji.
UML cz. II
[ksika niedostpna]
[ksika dostpna]
UML cz. II
Bibliotekarz
Czytelnik
rezerwacja
weryfikacja
rezerwacja
rozcz
Diagramy uwarunkowa czasowych (ang. timing diagrams) s specjaln form diagramów interakcji przeznaczon niemal wycznie do prezentowania zalenoci zwizanych z czasem wykonywania operacji przez obiekt lub grup obiektów. Linia czasu jest reprezentowana przez poziom o diagramu, natomiast o pionowa przedstawia kolejne obiekty uczestniczce w interakcji oraz ich zmieniajce si stany wewntrzne. Odlegoci pomidzy momentami zmian stanów wyznaczaj uwarunkowania czasowe.
Diagram ten ma due znaczenie np. w modelowaniu systemów czasu rzeczywistego.
UML cz. II
Diagram stanu reprezentuje zachowanie obiektu o skoczonej liczbie stanów i zdefiniowanych przejciach midzy nimi
dsdsadasdadsa
Diagramy stanu (ang. state machine diagram) reprezentuj zachowanie systemu lub jego elementu (zwykle klasy), a w szczególnoci zmiany tego zachowania.
Podstawowymi elementami diagramu s stany obiektu poczone strzakami przej. Obiekt, reagujc na nadchodzce zdarzenia, jeeli spenione s okrelone warunki, zmienia swój stan i pooenie na diagramie stanu.
UML cz. II
Stan
Stan jest etapem cyklu ycia obiektu. Obiekt przebywajcy w danym stanie spenia okrelony warunek.
entry: w momencie wejcia do stanu
do: wewntrz stanu
event: w momencie nadejcia zdarzenia
dsdsadasdadsa
Pojedynczy stan reprezentuje moment w zachowaniu obiektu, w którym pewien warunek jest prawdziwy.
Stany s reprezentowane przez prostokty z zaokrglonymi naronikami. Kady stan ma swoj nazw.
Ze stanem mog by zwizane pewne akcje, wykonywane w okrelonym momencie:
entry: jest akcj wykonywan w momencie gdy obiekt przyjmuje dany stan; akcja ta jest wykonywana jeden raz i niepodzielnie
do: jest akcj wykonywan nieprzerwanie w czasie, gdy obiekt przebywa w tym stanie
exit: oznacza (analogicznie do entry) moment opuszczenia stanu; podobnie, akcja taka jest wykonywana tylko raz.
event: reprezentuje akcj wykonywan w momencie nadejcia zdarzenia okrelonego typu
Wykonanie kadej z tych akcji moe równie generowa zdarzenie.
UML cz. II
Diagram zawiera take grup stanów niezwizanych z dziedzin zastosowa, tzw. pseudostanów
Nowa
Otwarta
Zamknita
Usunita
Obok stanów reprezentujcych wasnoci wynikajce z dziedziny zastosowa (np. Dostpna czy Wypoyczona w przypadku Ksiki), UML definiuje grup innych stanów pomocniczych, które pozwalaj na atwiejsze modelowanie rozmaitych maszyn stanowych. S to tzw. pseudostany:
pocztkowy, który reprezentuje obiekt w momencie jego utworzenia. Kady diagram stanu moe zawiera tylko jeden taki stan. Do stanu pocztkowego nie dochodz adne przejcia.
kocowy, który reprezentuje usunicie obiektu z systemu. Stan ten jest opcjonalny (nie wszystkie obiekty s usuwane), w systemie take moe wystpowa wiele rónych stanów kocowych. Ze stanów kocowych nie mona przej do innych stanów.
decyzja, przedstawiajca wybór pomidzy dwiema wartociami logicznymi pewnego wyraenia. Warto zauway, e odpowiednio korzystajc z warunków przej mona pomin ten pseudostan, jednak czsto jego uycie zwiksza czytelno modelu
zczenie/rozwidlenie – powoduje synchronizacj stanów (wszystkie dochodzce do niego przejcia musz by wykonane)
historia (reprezentowana przez literk H umieszczon w okrgu wewntrz stanu) – zapewnia moliwo zapamitania poprzedniego stanu obiektu i przywrócenie go.
UML cz. II
wyzwalacz [dozór] / akcja ^ wysyane zdarzenia
Zdarzenie wyzwalajce przejcie
Wysyane zdarzenia
Bartosz Walter
Stany s powizane ze sob przejciami. Przejcia definiuj warunki, jakie musz zaistnie, aby obiekt zmieni swój stan z ródowego na docelowy. Formalnie opis przejcia skada si z czterech elementów:
wyzwalacza (ang. trigger) – zdarzenia, które moe spowodowa przejcie i zmian stanu
dozoru (ang. guard condition) – warunku, jaki musi by speniony, aby przejcie zostao wykonane; warunek ten jest ewaluowany w momencie pojawienia si wyzwalacza
akcji (ang. action) – operacji wykonywanej w momencie przejcia ze stanu do stanu; nawet jeeli akcja przejcia jest zoona z wielu akcji elementarnych, jest ona wykonywana niepodzielnie
zdarzenia (ang. event) – wysyanego w momencie wykonania przejcia.
W podanym przykadzie, reprezentujcym dwa stany klasy Ksika, zdarzenie Przegld moe spowodowa zmian stanu z Dostpnej na Zniszczon, jeeli jej stan zostanie oceniony na mniej ni 10%. Efektem przejcia bdzie zmiana atrybutu dostpna na false oraz wysanie zdarzenia zablokowania ksiki w katalogu.
UML cz. II
Stany zoone
Stany zoone posiadaj wewntrzn maszyn stanów. Wejcie do stanu jest jej stanem pocztkowym, a wyjcie – kocowym.
dsdsadasdadsa
Bartosz Walter
Dotychczas bya mowa o stanach prostych. S one niepodzielne – znalezienie si obiektu w takim stanie ma zawsze taki sam efekt i pomija ewentualne zmieniajce si zewntrzne okolicznoci.
W niektórych sytuacjach wewntrz stanu mona jednake wyróni podstany. Innymi sowy, wewntrz stanu znajduje si inny diagram stanu.
Diagram podstanów jest przetwarzany w sposób zbliony do zwykego diagramu stanu. Jednak w ogólnym przypadku stan zoony dopuszcza take istnienie podstanów wspóbienych, co oznacza, e obiekt znajdujc si w jednym stanie jednoczenie znajduje si w kilku podstanach. Wówczas podstany równolege tworz niezalene regiony wewntrz stanu zewntrznego, w których przejcia nastpuj niezalenie od siebie.
Wejcie do stanu powoduje take wejcie wszystkich podstanów pocztkowych we wszystkich regionach. Nastpnie przejcia s realizowane równolegle i niezalenie we wszystkich regionach, a do podstanów kocowych. Przejcie do stanu kocowego we wszystkich regionach powoduje uruchomienie zdarzenia zakoczenia stanu i skojarzonych z nim wyzwalaczy.
Przykad dotyczy stanu Otwarta, reprezentujcego otwarty stan Rezerwacji ksiek. Rezerwacja moe obj do 4 ksiek jednoczenie. Stan Rezerwacji pozostaje otwarty w trakcie dodawania kolejnych ksiek, jednak wyróniono w nim podstany: Wyszukanie informacji o ksice, Weryfikacj, czy danej ksiki ju wczeniej nie zarezerwowano oraz Aktualizacj danych Rezerwacji. Wszystkie podstany prowadz do opuszczenia stanu przez Rezerwacj, co jest zwizane np. z prób dodania do niej nowej ksiki.
UML cz. II
zwrot
przeduenie[ liczba przedue < 3 ] / data oddania = teraz + 3 tygodnie
przegld[ stan < 10% ] / dostpna = false ^zablokuj w katalogu
dsdsadasdadsa
Bartosz Walter
Diagram ten obejmuje przykadowy cykl ycia obiektu Ksika w bibliotece. Ksika zostaje Nabyta (stan pocztkowy), a nastpnie (po rejestracji) staje si Dostpna. Jej wypoyczenie przez czytelnika (niezalenie od tego, czy bya rezerwowana, czy nie), przeprowadza j do stanu Wypoyczonej. Ksika moe pozosta w tym stanie np. wskutek przeduenia (warunkiem jest, e liczba przedue nie przekroczya 3) – wówczas data oddania jest przesuwana o 3 tygodnie. Zarówno ze stanu Dostpnoci, jak i Wypoyczenia ksika moe przej do stanu Zniszczenia, o ile wskutek zdarzenia Przegld jej stan zostanie oceniony na mniej ni 10%. Jeeli tak si stanie, atrybut Ksiki dostpna otrzymuje warto false oraz wysyane jest zdarzenie zablokowania dostpnoci Ksiki w katalogu. Wypoyczona ksika, której nie oddano w terminie 3 miesicy od terminu zwrotu, jest uwaana za Zagubion.
UML cz. II
w systemie oraz wynikajce z nich zmiany stanów.
akcja
stan
Diagramy czynnoci (ang. activity diagrams) prezentuj przepyw sterowania w systemie zwizany z wykonaniem pewnej funkcji. Przepywy cz czynnoci wykonywane przez poszczególne obiekty i stany obiektów, w których znajduj si po wykonaniu czynnoci.
Wygld tych diagramów przypomina diagramy stanu (w UML 1.x byy to diagramy pokrewne, blisko zwizane ze sob), jednak ich przeznaczenie jest inne. Diagramy stanu skupiaj si – jak nazwa wskazuje – na stanach, a akcje zwizane z ich zmian s elementem dodatkowym. W diagramach czynnoci jest odwrotnie: akcje s na pierwszym planie, a zmiany stanów s efektem ich wykonania. Dlatego diagramy czynnoci dobrze nadaj si do opisu przepywu sterowania pomidzy obiektami (szczególnie w przypadku przetwarzania wspóbienego) oraz przepywu danych pomidzy nimi.
Diagram, podobnie jak diagram stanu, moe posiada punkt startowy i dowoln liczb stanów kocowych. Najwaniejszym jego elementem s akcje, reprezentowane przez prostokty z zaokrglonymi naronikami oraz przejcia (uki) przedstawiajce przepyw sterowania. uki mog by opatrzone warunkami dozoru, które decyduj o wykonaniu przejcia oraz zdarzeniami, które s generowane w momencie gdy przejcie jest wykonywane. Diagramy czynnoci zawieraj take stany, w jakich moe znale si okrelony obiekt po wykonaniu akcji oraz elementy decyzyjne czy synchronizujce.
Umieszczanie akcji w torach (ang. swimlanes) pozwala na pogrupowanie ich wedug pewnego kryterium. Moe nim by np. obiekt, który wykonuje dan akcj lub inna wspólna cecha akcji.
Obiekty umieszczone na diagramach czynnoci s podporzdkowane przepywowi sterowania i reprezentuj parametry wejciowe lub wyniki dziaania czynnoci.
UML cz. II
Czytelnik jednoczenie uruchamia proces wykonywania lokalnego (w katalogu lokalnym) i zdalnego (w katalogu zdalnym), które s realizowane wspóbienie. Po zakoczeniu obu operacji nastpuje sprawdzenie, czy lista wyników jest pusta. Jeeli tak, wówczas proces wyszukiwania jest zakoczony, w przeciwnym przypadku lista jest czona z dodatkowymi informacjami prezentowanymi czytelnikowi, analizowana i zwracana inicjatorowi przeszukiwania
UML cz. II
UML posiada standardowy mechanizm rozszerze.
Pozwala on na objcie nowych dziedzin zastosowa bez potrzeby modyfikacji jzyka lub implementujcych go narzdzi.
Mechanizm obejmuje trzy elementy
UML suy obecnie do opisu modeli w wielu dziedzinach zastosowa. Aby umoliwi atwe modelowanie kolejnych dziedzin bez potrzeby modyfikowania lub rozszerzania jzyka, zastosowano w nim specjalny mechanizm rozszerze. Pozwala on redefiniowa pojcia i elementy oraz doprecyzowywa ich znaczenie tak, aby odpowiaday potrzebom nowego obszaru zastosowa.
W skad mechanizmu rozszerze wchodz trzy elementy:
profile, zawierajce rozszerzenia (stereotypy i metki) do modelowania okrelonych dziedzin
stereotypy, zmieniajce znaczenie poszczególnych elementów
metki, opisujce dodatkowe waciwoci elementów
UML cz. II
Profile UML s narzeczami jzyka UML przystosowanymi do modelowania pewnej dziedziny zastosowa.
Profil obejmuje zdefiniowane stereotypy, metki, ograniczenia.
dsdsadasdadsa
Wród tych mechanizmów najwaniejszym s profile, zawierajce kompletny i spójny zestaw elementów dedykowanych do modelowania okrelonej dziedziny, np. systemów czasu rzeczywistego, baz danych, logiki biznesowej etc. Zdefiniowane i zaakceptowane profile pozwalaj unikn kaskady rónorodnych rozszerze dokonywanych przez uytkowników na wasn rk, co znacznie zmniejszao czytelno i komunikatywno modeli. Profile zwykle s definiowane na zasadzie konsensusu przez organizacje standaryzujc (np. OMG) lub dostawc okrelonej technologii (np. Sun Microsystems w przypadku EJB), jednak mona je take definiowa samemu, ryzykujc jednak niespójno z innymi profilami dotyczcymi tego samego obszaru zastosowa.
Profile zawieraj zdefiniowany zestaw stereotypów i metek, z których powinni korzysta analitycy dziaajcy w dziedzinie zastosowa profilu. Na przykad, profil do modelowania ziaren EJB definiuje stereotypy EJBSessionBean, EJBPrimaryKey, EJBHomeInterface czy EJBCreateMethod, oznaczajce odpowiednio klas ziarna sesyjnego, atrybut bdcy kluczem podstawowym ziarna encyjnego, interfejs domowy ziarna oraz metod tworzc instancj interfejsu ziarna. Stereotyp EJBSessionBean definiuje m.in. metk EJBTransType, natomiast kada operacja moe posiada metk EJBRoleNames, okrelajc role, które musi posiada wywoujcy t operacj element.
UML cz. II
Stereotypy su do zmieniania lub doprecyzowania semantyki elementów modelu. Dziki nim mona dokadnie okreli ich rol w systemie.
Stereotypy s reprezentowane przez ikon lub sowo kluczowe ujte w "apki": «stereotyp»
Róne sposoby przedstawienia stereotypu «EJBSession» w klasie RejestratorCzytelników
dsdsadasdadsa
Kolejnym narzdziem mechanizmu rozszerze jest stereotyp, który historycznie by podstawowym narzdziem rozszerzania i modyfikowania UMLa. Stereotypy dodaj do znanych ju elementów: klas, atrybutów, asocjacji now semantyk. W UML 1.x stereotypami byy wszelkie dekoracje zmieniajce znaczenie wybranego elementu. Wersja ta zawieraa take spor grup zdefiniowanych stereotypów standardowych. W UML 2.0 nazw t zarezerwowano wycznie dla dekoracji wchodzcych w skad profili, natomiast pozostae uycia tego sowa zostay przemianowane na sowa kluczowe. Stereotypy posiadaj specjaln notacj, polegajc na umieszczeniu nazwy stereotypu w specjalnych znakach guillemets («stereotyp»). Stereotypy, szczególnie te najczciej uywane, posiadaj take wasn ikon, która jest umieszczana wewntrz stereotypowanego elementu lub cakowicie go zastpuje.
UML cz. II
Metki (ang. tagged values) pozwalaj doczy do elementu dodatkowe waciwoci
Metki posiadaj posta par klucz : warto
Stereotypy i profile definiuj wasne zestawy metek
Metki s zapisywane w postaci notatki doczonej do elementu, którego dotycz
metka EJBTransType okrela sposób zarzdzania transakcjami w ziarnie EJB
dsdsadasdadsa
Bartosz Walter
Na najniszym poziomie znajduj si tzw. metki (ang. tagged values), pozwalajce opisywa dodatkowe waciwoci elementu, które nie zostay przewidziane w UMLu. Metki s zapisywane w postaci par klucz-warto w nawiasach klamrowych i doczane do opisywanych elementów w postaci notatek. W wikszoci narzdzi s one jednak zapisywane w postaci metadanych, zawartych wewntrz elementu, poniewa tak atwiej je przetwarza. Metki, podobnie jak stereotypy, s zasadniczo definiowane wewntrz profili (i znajdujcych si w nich stereotypów), jednak istnieje take moliwo ich definiowania przez uytkowników.
Najprostszym przykadem metki moe by informacja o autorze modelu {autor = "Jan Kowalski"}.
UML cz. II
Na powyszym slajdzie przedstawiono prosty przykad wykorzystania jednego z profili UML, sucego do modelowania danych. Wprawdzie relacyjne bazy danych posiadaj wasn notacj, opart na diagramach ERD (Entity Relationship Diagrams), jednak moliwo ich tworzenia w UMLu jest wanym uzupenieniem tego jzyka.
Profil ten definiuje stereotypy, które mona umieszcza na istniejcych elementach UML w celu nadania im nowego znaczenia w dziedzinie projektowania baz danych. Na przykad, schemat bazy danych jest reprezentowany przez pakiet ze stereotypem «schema», tabela jest modelowana jako klasa ze stereotypem «RelationalTable», a jej klucze podstawowe i obce – jako atrybuty odpowiednio ze stereotypami «PK» i «FK». Ograniczenia integralnociowe wewntrz relacji s metodami ze stereotypem «constraint».
Tak opisany schemat danych moe by uyty do wygenerowania kodu w jzyku definicji baz danych (np. SQL DDL), który nastpnie posuy do utworzenia schematów i tabel zgodnych z nim.
UML cz. II
OCL (Object Constraint Language) jest jzykiem formalnego wyraania ogranicze w UML
Wasnoci OCL
nie moe modyfikowa modelu, jedynie go sprawdza
mona go zwiza z dowolnym elementem modelu (klas, operacj, atrybutem, asocjacj etc.)
dsdsadasdadsa
Bartosz Walter
OCL jest formalnym jzykiem wyraania wszelkiego rodzaju ogranicze obecnych w UMLu. Cho uycie jego nie jest obowizkowe (ograniczenia mona równie dobrze specyfikowa w jzyku naturalnym), jednak jego rola w dobie narzdzi generujcych kod z diagramów bdzie rosa.
Warto pamita, e OCL nie jest jzykiem programowania: posiada konstrukcje pozwalajce ewaluowa poszczególne elementy modelu, ale nie moe na ten model w aden sposób wpywa, w szczególnoci poprzez zmian ich wartoci. Ewaluacja wyrae OCL nastpuje w sposób atomiczny (niepodzielny), nie powodujc nigdy zmiany stanu jakiegokolwiek obiektu.
OCL posiada zestaw wbudowanych operatorów, predykatów, ma moliwo definiowania wasnych funkcji, warunków i niezmienników. Dziki nim moliwe jest uycie go przy niemal wszystkich elementach wystpujcych w UML
UML cz. II
Bartosz Walter
Diagram klas przedstawia rodzin, jej czonków i relacje zachodzce pomidzy nimi. Obiekt klasy M jest zwizany z dokadnie jednym obiektem klasy ona. Kade z nich jest zwizane z obiektami klasy Dziecko.
Tak przedstawiony rysunek, bez naoonych dodatkowych ogranicze, mógby prowadzi do rozmaitych interpretacji, take nieprawdziwych. Dlatego wprowadzenie ogranicze w OCL pozwala ucili model.
Relacja pomidzy Mem i on ma naoone ograniczenie, e data lubu obu obiektów musi by identyczna, a take nawigujc od Ma poprzez zwizany z nim relacj polubienia obiekt ona, trafiamy z powrotem na ródowy obiekt M (zatem M i ona s ze sob zwizani relacj wzajemnoci).
Kolejne ograniczenie mówi, e (zgodnie z polskim prawem) ona musi mie wiek powyej 18 lat, a M – 21.
Aby zapewni, e dzieci posiadane przez on byy take dziemi Ma, naoono odpowiednie ograniczenia na relacje midzy Mem i Dzieckiem oraz on i Dzieckiem.
UML cz. II
Bartosz Walter
Na tym zakoczone zostao omówienie podstaw jzyka UML. Obecnie przejdziemy do przegldu dwóch przykadowych narzdzi sucych do modelowania w tym jzyku.
Przykadem darmowego i otwartego narzdzia do modelowania w UML jest ArgoUML. Jest to program w caoci zaimplementowany w jzyku Java, który mona uruchomi na dowolnej platformie programowej wyposaonej w interpreter tego jzyka.
Posiada on wsparcie dla wersji 1.4 UML, natomiast nie ma zaimplementowanej obsugi adnego z nowych diagramów, jakie pojawiy si w wersji 2.0 jzyka. Posiada take modu inspekcji modelu, znajdujcy najpopularniejsze bdy popeniane przez analityków, zaimplementowane w postaci regu. Umoliwia take synchronizacj kodu z modelem dla wybranych jzyków programowania.
UML cz. II
narzdzia komercyjne
wsparcie dla UML 1.x (Rose) i UML 2.0 (Modeler)
wsparcie dla modelowania wybranych dziedzin i technologii
modelowanie biznesowe
Na drugim biegunie znajduj si narzdzia firmy Rational (obecnie Rational Division wewntrz IBMa). Klasycznym narzdziem do modelowania jest Rational Rose, natomiast nowsz lini produktow reprezentuje Rational Software Modeler. Ten ostatni produkt jest oparty na rodowisku Eclipse i posiada wsparcie dla wersji 2.0 UML.
Wród moliwoci obu rodowisk warto wymieni moliwo wykorzystania profili jzyka UML w postaci wtyczek dedykowanych do rozmaitych technologii (modelowania danych, modelowania biznesowego etc.). Narzdzia te atwo integruj si z innymi produktami Rational i IBM, posiadaj jednak take moliwo wspópracy z wybranymi innymi narzdziami.
UML cz. II
Diagramy interakcji su do opisu komunikacji pomidzy obiektami
Diagramy czynnoci definiuj algorytmy realizacji funkcji, a diagramy stanu – zmian zachowania obiektów
Mechanizm rozszerze UML pozwala na obejmowanie nowych obszarów zastosowa
OCL jest jzykiem formalnego opisu ogranicze
dsdsadasdadsa
Wykad zakoczy krótkie wprowadzenie do modelowania z wykorzystaniem jzyka UML. Przedstawiono najwaniejsze rodzaje diagramów i ich moliwoci wyrazu, a take rozszerzone moliwoci jzyka.
UML cz. II
zwrot
przeduenie[ liczba przedue < 3 ] / data oddania = teraz + 3 tygodnie
przegld[ stan < 10% ] / dostpna = false ^zablokuj w katalogu
Dostêpna
: Wypo¿yczaj¹cy