Jzyk UML opis notacji

Transkrypt

1 POLITECHNIKA WARSZAWSKA WYDZIAŁ ELEKTRYCZNY INSTYTUT ELEKTROTECHNIKI TEORETYCZNEJ I MIERNICTWA ELEKTRYCZNEGO ZAKŁAD ELEKTROTECHNIKI TEORETYCZNEJ Jzyk UML opis notacji Paweł Gryczon Piotr Staczuk Fragment pracy dyplomowej magisterskiej pt. Obiektowy system konstrukcji scenariuszy przypadków uycia wykonanej pod opiek dr in. Michała miałka WARSZAWA, grudzie 2002 roku

2 Spis treci 1 Wstp UML ogólne spojrzenie Modelowanie architektury systemu Elementy w UML Elementy strukturalne Klasa Interfejs Kooperacja Przypadek uycia Klasa aktywna Komponent Wzeł Elementy czynnociowe Elementy grupujce Elementy komentujce Zwizki w UML Zaleno Uogólnienie Powizanie Realizacja Diagramy w UML Diagram klas Diagram obiektów Diagram przypadków uycia Diagram interakcji Diagram stanów Diagram czynnoci Diagram komponentów Diagram wdroenia Podstawowe mechanizmy jzykowe w UML Specyfikacje Dodatki Zasadnicze rozgraniczenia Mechanizmy rozszerzania

3 Wstp 1 Wstp Unified Modeling Language (UML) to graficzny jzyk do obrazowania, specyfikowania, tworzenia i dokumentowania elementów systemów informatycznych. Umoliwia standaryzacj sposobu opracowywania przekrojów systemu, obejmujcych obiekty pojciowe, takie jak procesy przedsibiorstwa i funkcje systemowe, a take obiekty konkretne, takie jak klasy zaprogramowane w ustalonym jzyku, schematy baz danych i komponenty programowe nadajce si do ponownego uycia. Jzyki modelowania obiektowego pojawiły si midzy połow lat siedemdziesitych a kocem lat osiemdziesitych. Z chwil powstania nowego rodzaju jzyków programowania obiektowego zaczto szuka innych rozwiza dotyczcych analizy i projektowania. Opracowanych zostało wiele metod obiektowych, z których jednymi z najwaniejszych były: metoda Boocha, metoda OOSE Jacobsona (Object- Oriented Software Engineering) i metoda OMT Rumbaugha (Object Modeling Technique). Kada z nich stanowiła zamknit cało. Metoda Boocha sprawdzała si podczas projektowania i implementacji, OOSE stanowiła znakomite wsparcie przy spełnianiu wymaga i wysokopoziomowym projektowaniu, za OMT-2 była bardzo przydatna do analizy oraz rozwijania systemów przetwarzajcych due iloci danych. W połowie lat dziewidziesitych Grady Booch, Ivan Jacobson i James Rumbaugh postanowili opracowa zunifikowany jzyk modelowania. Oficjalny pocztek prac nad UML datuje si na padziernik 1994 roku. W pierwszej kolejnoci ujednolicono metody Boocha i OMT. Robocz wersj 0.8 Unified Method (tak została wtedy nazwana) opublikowano w padzierniku 1995 roku. W tym okresie rozszerzono prace nad UML o uwzgldnienie w nim metody OOSE. W czerwcu 1996 roku powstała dokumentacja wersji 0.9. Przez cały rok zbierano uwagi rodowiska inynierów oprogramowania na temat nowego jzyka. Wynikiem współpracy kilku firm, m.in. Rational, IBM, Hewlett-Packard, Texas Instruments, Unisys, Microsoft, był UML 1.0 precyzyjnie zdefiniowany jzyk modelowania. W styczniu 1997 roku UML 1.0 został przekazany Object Management Group (OMG) w odpowiedzi na zapotrzebowanie na propozycj standardu jzyka modelowania obiektowego. Do współpracy włczyły si kolejne firmy, w wyniku czego powstała poprawiona wersja UML (numer 1.1), przyjta ostatecznie przez OMG 14 listopada OMG Revision Task Force (RTF) przejł zadanie pielgnacji standardu UML. Dokonał redakcyjnych poprawek i w czerwcu 1998 roku przedstawił wersj UML 1.2, a jesieni 1999 roku opublikował UML

4 UML ogólne spojrzenie 2 UML ogólne spojrzenie Unified Modeling Language (UML) jest jzykiem znormalizowanym, słucym do zapisywania projektu systemu. Moe by stosowany do obrazowania, specyfikowania, tworzenia i dokumentowania elementów powstałych podczas procesu budowy systemu informatycznego. UML wspomaga specyfikowanie wszystkich wanych decyzji analitycznych, projektowych i implementacyjnych, które musz by podejmowane w trakcie wytwarzania i wdraania systemu informatycznego. UML nie jest jzykiem programowania graficznego, jednak modele w nim zapisane mog by wprost powizane z wieloma jzykami programowania. Model utworzony w jzyku UML mona przekształci w taki jzyk, jak Java, C++ czy Visual Basic, albo w tabele relacyjnej bazy danych. To przekształcenie umoliwia inynieri do przodu, to znaczy generowanie kodu w jzyku programowania na podstawie modelu UML. Moliwe jest take odwrotne przekształcenie, czyli rekonstrukcja modelu na podstawie implementacji (inynieria wstecz). Przy przejciu od modelu do kodu kada informacja niezakodowana w implementacji jest tracona, dlatego inynieria wstecz wymaga odpowiednich narzdzi i udziału człowieka. UML jest na tyle wyrazisty i jednoznaczny, e umoliwia nie tylko bezporednie przekształcanie modeli, ale take symulacj systemów oraz dostrajanie elementów wdroonych systemów. W procesie tworzenia oprogramowania oprócz kodu wykonywalnego powstaje wiele elementów. S to: wymagania, architektura, projekt, kod ródłowy, plany projektu, testy, prototypy, kolejne wersje. Wszystkie te elementy odgrywaj istotn rol w kontrolowaniu, ocenianiu i przekazywaniu informacji o systemie podczas procesu tworzenia go i po jego wdroeniu i s przedstawiane na zakoczenie kolejnych etapów prac. UML obejmuje dokumentowanie architektury systemu i wszystkich jego szczegółów. Składa si na to nie tylko jzyk do zapisywania wymaga i testów, ale take jzyk modelowania czynnoci, które wykonywane s podczas planowania danego przedsiwzicia i zarzdzania wersjami systemu. Głównym przeznaczeniem UML jest budowa systemów informatycznych. Z powodzeniem stosowano go ju w: tworzeniu systemów informacyjnych przedsibiorstw, usługach bankowych i finansowych, przemyle obronnym i lotniczym, rozproszonych usługach internetowych, telekomunikacji, transporcie, sprzeday detalicznej, elektronice w medycynie, nauce. Jzyk UML jest na tyle bogaty, e oprócz oprogramowania mona modelowa w nim systemy nie zwizane z oprogramowaniem (np. przepływ pracy w ministerstwie, 4

5 UML ogólne spojrzenie struktura i zachowanie systemu opieki zdrowotnej oraz projektowanie sprztu komputerowego). 5

6 Modelowanie architektury systemu 3 Modelowanie architektury systemu Modelowanie systemu informatycznego wymaga podejcia do niego z kilku punktów widzenia. Kady rodzaj uytkownika (uytkownicy kocowi, programici i analitycy, specjalici od integracji systemu, osoby wykonujce testy, autorzy dokumentacji technicznej i kierownicy projektu) ma inne spojrzenie na system. Kady patrzy na zadanie z innej perspektywy i na innym etapie jego ycia. Architektura systemu umoliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Pozwala ogarn i opanowa wszystkie punkty widzenia, dlatego jest jednym z najistotniejszych elementów systemu. Architektura jest zbiorem decyzji dotyczcych: organizacji systemu komputerowego, wyboru elementów strukturalnych i ich interfejsów, z których system jest zbudowany, zachowania tych elementów opisanego w kooperacjach, składania elementów strukturalnych i czynnociowych w coraz wiksze podsystemy, charakterystycznych elementów statycznych i dynamicznych oraz ich interfejsów. Architektura oprogramowania oprócz jego struktury i zachowania, dotyczy take jego funkcjonalnoci, efektywnoci i moliwoci ponownego uycia. Obejmuje take ograniczenia ekonomiczne i technologiczne oraz elementy estetyki. Najlepszym sposobem zobrazowania architektury systemu komputerowego jest przedstawienie go w postaci piciu powizanych ze sob perspektyw. Wszystkie perspektywy dotycz struktury i organizacji systemu, jednak kada z nich przedstawia inny aspekt tego systemu. Rys. 1 Obrazowanie architektury systemu 6

7 Modelowanie architektury systemu W perspektywie przypadków uycia najwaniejsze jest przedstawienie zachowania systemu z punktu widzenia uytkowników, analityków i osób wykonujcych testy. Perspektywa ta opisuje czynniki wpływajce na kształt systemu. W UML aspekty statyczne tej perspektywy wyraa si za pomoc diagramów przypadków uycia, a dynamiczne za pomoc diagramów interakcji, diagramów stanów i diagramów czynnoci. W perspektywie projektowej umoliwia zapisywanie wymaga funkcjonalnych stawianych systemowi. Opisuje usługi, które system powinien udostpnia uytkownikom. Najwikszy nacisk połoony jest na klasy, interfejsy i kooperacje, które stanowi słownictwo danego zagadnienia. W UML aspekty statyczne tej perspektywy wyraa si za pomoc diagramów klas i diagramów obiektów, a dynamiczne za pomoc diagramów interakcji, diagramów stanów i diagramów czynnoci. Perspektywa procesowa dotyczy głównie efektywnoci systemu, jego skalowalnoci i przepustowoci. W perspektywie tej brane s pod uwag wtki i procesy, które kształtuj metody współbienoci i synchronizacji w systemie. W UML aspekty statyczne tej perspektywy wyraa si za pomoc diagramów klas (ze szczególnym uwzgldnieniem klas aktywnych, które reprezentuj procesy i wtki) i diagramów obiektów, a dynamiczne za pomoc diagramów interakcji, diagramów stanów i diagramów czynnoci. Perspektywie implementacyjna zwizana jest z zarzdzaniem konfiguracj poszczególnych wersji systemu. Kada wersja systemu składa si z niezalenych komponentów i plików, które mog by zespolone na wiele sposobów, tworzc działajcy system. W perspektywie tej najwiksze znaczenie maj komponenty i pliki, uyte do scalenia i udostpnienia systemu fizycznego. W UML aspekty statyczne tej perspektywy wyraa si za pomoc diagramów komponentów, a dynamiczne za pomoc diagramów interakcji, diagramów stanów i diagramów czynnoci. Perspektywa wdroeniowa dotyczy sprztu, na którym system bdzie uruchamiany. Obejmuje zagadnienia zwizane z rozmieszczeniem, dostarczeniem i instalacj czci systemu fizycznego. W UML aspekty statyczne tej perspektywy wyraa si za pomoc diagramów wdroenia, a dynamiczne za pomoc diagramów interakcji, diagramów stanów i diagramów czynnoci. Kada z tych piciu perspektyw stanowi niezalen cało. Kada osoba biorca udział w tworzeniu systemu moe skoncentrowa si na tym fragmencie architektury systemu, który j najbardziej interesuje. Przedstawione perspektywy cile s ze sob powizane. Wzły w perspektywie wdroeniowej zawieraj komponenty z perspektywy implementacyjnej, które z kolei reprezentuj fizyczn realizacj klas, interfejsów, kooperacji i klas aktywnych z perspektywy projektowej i procesowej. UML pozwala na przedstawienie kadej z tych perspektyw i ich wzajemnych oddziaływa. 7

8 Elementy w UML 4 Elementy w UML W UML istniej cztery rodzaje elementów: 1) strukturalne, 2) czynnociowe, 3) grupujce, 4) komentujce. S to podstawowe obiektowe bloki konstrukcyjne UML. Stosuje si je do budowy modeli. 4.1 Elementy strukturalne Elementy strukturalne w modelach UML wyraone s rzeczownikami. Reprezentuj składniki pojciowe albo fizyczne, s statycznymi czciami modelu. Niej przedstawiamy podstawowe rodzaje elementów strukturalnych Klasa Klasa jest opisem zbioru obiektów o takich samych atrybutach, zwizkach i znaczeniu. Symbolem graficznym klasy jest prostokt. Kada klasa ma przypisan nazw, wyróniajc j sporód innych klas. Nazwy mog by proste lub ciekowe, czyli poprzedzone nazw pakietu. Atrybut stanowi nazwan właciwo klasy. Okrela on zbiór wartoci, jakie mona przypisa do poszczególnych obiektów tej klasy. Liczba atrybutów klasy nie jest okrelona, klasa moe mie dowoln liczb atrybutów lub moe nie mie ich wcale. Atrybut reprezentuje właciwo pewnego modelowanego bytu, która jest okrelona dla wszystkich jego wystpie, np. kady klient sklepu ma nazwisko, adres i dat urodzenia. Atrybut jest abstrakcj pewnego rodzaju danych lub stanu, jakie obiekt klasy moe obejmowa. W graficznym symbolu klasy atrybuty przedstawiane s w pierwszej sekcji poniej nazwy klasy. Bardziej szczegółowym okreleniem atrybutu jest podanie jego klasy i domylnej wartoci pocztkowej (Rys. 2). Okno zarzdcy projektu NazwaPrzypadku : ListBox ciekaprzypadku : ListBox NazwaPlikuProjektu : String = "projekt.prj" Rys. 2 Klasa i atrybuty Operacja jest implementacj usługi, któr moe wykona kady obiekt tej klasy. Klasa moe mie dowoln liczb operacji lub nie mie ich wcale. W graficznym symbolu klasy operacje przedstawiane s w sekcji pod atrybutami. Bardziej szczegółowym opisem operacji jest podanie jej sygnatury, która zawiera domylne wartoci pocztkowe parametrów i w przypadku funkcji typ zwracanej wartoci (Rys. 3). 8

9 Elementy w UML Okno zarzdcy projektu W ywietlokno(tytuł : String) Zam knijokno() ZwróSz eroko() : int Rys. 3 Operacje i ich sygnatury Symbol klasy nie musi zawiera wszystkich atrybutów i operacji zwizanych z t klas. Najczciej jest ich na tyle duo, e nie mieszcz si wszystkie na rysunku. Ponadto nie wszystkie s niezbdne do zrozumienia modelu. Dlatego na diagramie mona umieci niepełny symbol klasy, który pokazuje tylko cz atrybutów lub operacji. Niekiedy symbol klasy w ogóle nie zawiera atrybutów lub operacji. Istnieje moliwo zaznaczenia na diagramie, e klasa ma wicej atrybutów lub operacji, ni zostało to przedstawione w symbolu. Wystarczy na kocu kadej listy elementów umieci wielokropek. Listy atrybutów i operacji mona podzieli na grupy wykorzystujc stereotypy (Rys. 4). Menu <<przypadki>> UtwórzNowyP rzypadek() <<przypadki>> Otwórz Przypadek() <<kom unikaty>> InfoB łdodczytu() <<kom unikaty>> InfoP rzypadek Odczytany() Rys. 4 Stereotypy Interfejs Interfejs jest zestawem operacji, które wyznaczaj usługi oferowane przez klas lub komponent, ale takich, które dotycz zewntrznie obserwowalnych zachowa elementu. Moe reprezentowa pełne zachowanie klasy lub komponentu lub jedynie cz zachowania. Interfejs zawsze okrela zbiór deklaracji operacji, czyli ich sygnatur nie dotyczy implementacji operacji. Podstawowym graficznym symbolem interfejsu jest okrg z nazw zapisan niej. Na diagramie interfejs najczciej powizany jest z realizujc go klas lub komponentem. Przykład interfejsu widoczny jest na rysunku (Rys. 5). 9

10 Elementy w UML IObsługa Zap isu Rys. 5 Interfejs Graficzny symbol interfejsu w postaci okrgu z nazw jest tzw. postaci normaln. W takim przypadku nie s uwidocznione operacje interfejsu. Niekiedy jednak jest niezbdne do zrozumienia modelu. Wówczas interfejs przedstawiany jest jako stereotypowana klasa i operacje, tak jak w przypadku symbolu zwykłej klasy, podawane s pod sekcj atrybutów (Rys. 6). < <Inte rface>> ObsługaZapisu SprawdNazw(Nazwa : S tring) : bool ZapiszDoPliku() Rys. 6 Operacje Kooperacja Kooperacja zwizana jest z architektur systemu, słuy do specyfikowania realizacji przypadków uycia oraz do modelowania mechanizmów systemowych, które s istotne z punktu widzenia architektury systemu. Z kad kooperacj wi si dwa aspekty: struktura i zachowanie. Cz dotyczca struktury najczciej przedstawiana jest w postaci diagramów klas, natomiast cz dotyczca zachowania obrazowana jest za pomoc diagramów interakcji. Pojedyncza klasa moe bra udział w wielu kooperacjach. Kooperacje mog take modelowa realizacj operacji. Jest to szczególnie przydatne gdy implementacja operacji wymaga współpracy wielu obiektów. Na diagramie kooperacje przedstawione s w postaci elipsy z przerywan lini brzegow i nazw (Rys. 7) Zarzdzanie Zapisem Projektu Rys. 7 Kooperacja 10

11 Elementy w UML Przypadek uycia Przypadek uycia jest opisem zbioru sekwencji czynnoci, które s wykonywane przez gotowy system, aby dostarczy kademu aktorowi danego wyniku. Słuy do okrelania w modelu struktury zachowania systemu. Przypadek uycia realizowany jest przez kooperacj. Symbolem graficznym przypadku uycia jest elipsa narysowana cigł lini i nazwa (Rys. 8) Utworzenie słownika Rys. 8 Przypadek uycia Zadaniem przypadków uycia jest modelowanie oczekiwanego zachowania systemu. Modelujc zachowanie za pomoc przypadków uycia nie ma koniecznoci zagłbiania si w zagadnienia zwizane z implementacj tego zachowania. Przypadki uycia pozwalaj osign porozumienie midzy programistami a uytkownikami i specjalistami z danej dziedziny. Umoliwiaj weryfikacj struktury i architektury systemu w trakcie jego tworzenia. Poprawne przypadki uycia skupiaj si tylko na zasadniczych zachowaniach systemu. Kady cig czynnoci, opisywany przez przypadek uycia, reprezentuje oddziaływanie elementów stanowicych otoczenie systemu, czyli aktorów, z samym systemem. Oddziaływania s w zasadzie funkcjami systemowymi, uywanymi do okrelania danych zachowa budowanego systemu jeszcze na etapie analizy zachowania systemu i okrelania wymaga funkcjonalnych. Przypadek uycia reprezentuje wymaganie funkcjonalne dla systemu jako całoci. Bardziej rozbudowane systemy zawieraj przypadki uycia, które stanowi uszczegółowienie innych przypadków uycia lub s ich czciami. S take takie, które stanowi rozszerzenie głównych przypadków uycia. Z punktu widzenia konkretnego aktora przypadek uycia opisuje działanie dajce rezultat, którego ten aktor oczekuje, na przykład obliczenie wyniku, utworzenie nowego obiektu lub zmian stanu danego obiektu. Przypadki uycia pozwalaj analizowa cały system, jednak mog mie take zastosowanie podczas analizy czci systemu (np. podsystemów) lub pojedynczych klas i interfejsów. Przypadki uycia opisuj oczekiwane zachowanie tych elementów i stanowi podstaw do opracowania dla nich przypadków testowych w miar ich rozbudowywania. Elementami nie bdcymi czci systemu, ale cile z nim zwizanymi, s aktorzy. Aktorzy Reprezentuj role odgrywane przez uytkowników przypadku uycia w czasie interakcji z tym przypadkiem. Stanowi kontekst przypadku uycia. Dobre opracowanie modelu aktorów pozwala na zrozumienie kto lub co bdzie wchodziło w interakcj z systemem. Aktor moe by zwykłym klasycznym uytkownikiem (człowiekiem), moe to by te program a nawet urzdzenie sprztowe. Na rysunku (Rys. 9) przedstawiono graficzny symbol aktora. Stosujc uogólnienia mona definiowa ogólne rodzaje aktorów (np. Administrator) i uszczegółowienia (np. Administrator bazy danych). 11

12 Elementy w UML Adm inistrator Adm inist rat or bazy danych Rys. 9 Aktorzy Niektórzy aktorzy mog stanowi formy specjalizacji innych aktorów, pewna funkcja jednego aktora moe wchodzi w zakres obowizków innego aktora. Tworzenie hierarchii aktorów pozwala na uproszczenie diagramów przypadków uycia. Przypadek uycia moe by wyspecyfikowany przez opisanie cigu zdarze w formie tekstu zrozumiałego nawet dla osoby nie znajcej dogłbnie tematu. Kady przypadek ma główny cig zdarze i cigi poboczne (alternatywne). Kady taki cig nosi nazw scenariusza. Scenariusze przypadku uycia jest tekstowym opisem kroków składajcych si na dany przypadek. Liczba scenariuszy jest zawsze znacznie wiksza ni liczba przypadków uycia. Scenariusz zazwyczaj prezentowany jest w postaci numerowanej listy, z podziałem na aktora i system, oznaczajcy w tym wypadku oprogramowanie implementujce analizowany przypadek. Scenariusze s pisane z myl o klientach i powinny by dostosowane do ich poziomu zrozumienia tematu. Głównym celem jest zachowanie przejrzystoci. Naley unika zagłbiania si w opisy interfejsów uytkownika lub konkretnych rozwiza sprztowych. Scenariusz powinien by abstrakcyjny. Decyzje dotyczce interfejsów zostaj przesunite na etap projektowania, a scenariusz prezentuje jedynie ogólne zachowanie systemu. Przypadki uycia podobnie jak klasy mona grupowa w pakiety. Mona je take uporzdkowa przez zdefiniowanie uogólnie midzy nimi oraz zwizków zawierania i rozszerzania. Polega to na wydzieleniu wspólnych fragmentów zachowania przez usunicie ich z obejmujcych je przypadków uycia lub wspólnych wariantów przez wklejanie ich do rozszerzajcych je przypadków. Uogólnienie midzy przypadkami uycia oznacza, e przypadek uycia - potomek dziedziczy całe zachowanie i znaczenie po przypadku uycia przodku. Zwizek zawierania midzy przypadkami polega na tym, e bazowy przypadek uycia jawnie włcza zachowanie innego przypadku uycia w miejscu przez siebie okrelonym. Włczany przypadek nigdy nie wystpuje samodzielnie jego egzemplarze mog by tylko czci wikszego zawierajcego go przypadku uycia. Zwizku zawierania uywa si w celu uniknicia wielokrotnego opisywania tego samego cigu zdarze. Wspólne zachowanie jest definiowane w odrbnym przypadku uycia, który jest nastpnie włczany przez bazowe przypadki 12

13 Elementy w UML uycia. Zwizek zawierania obrazuje si w postaci zalenoci stereotypowanej jako <<include>>. Zwizek rozszerzania midzy przypadkami uycia polega na tym, e bazowy przypadek uycia w sposób domniemany włcza zachowanie innego przypadku w miejscu okrelonym porednio przez rozszerzajcy przypadek uycia. Bazowy przypadek uycia moe wystpi samodzielnie, ale pod pewnymi warunkami jego zachowanie moe by rozszerzone przez zachowanie innego przypadku uycia. Zwizek rozszerzania słuy do modelowania fragmentów przypadku uycia postrzeganych przez uytkownika jako opcjonalne zachowanie systemu. Obrazuje si go w postaci zalenoci stereotypowanej jako <<extend>>. Uogólnianie, zawieranie i rozszerzanie zostało przedstawione na rysunku (Rys. 10). <<extend>> Dodanie słowa <<include>> Zapisanie słownika Odczytanie form podstawowych Otworzenie słownika <<extend>> <<include>> Odczytanie opisów Usunicie słowa Rys. 10 Uogólnienia i zwizki midzy przypadkami Kolejne trzy rodzaje elementów strukturalnych, to znaczy klasy aktywne, komponenty i wzły, s podobne do klas. Okrelaj one zbiory obiektów o zblionych atrybutach, operacjach, zwizkach i znaczeniu. S jednak na tyle inne i na tyle potrzebne do modelowania pewnych aspektów systemu obiektowego, e naley si im specjalne potraktowanie Klasa aktywna Klasa aktywna jest podobna do zwykłej klasy, jednak zawiera obiekty, w skład których wchodzi co najmniej jeden proces lub wtek. Takie obiekty mog samodzielnie rozpocz przepływ sterowania. Obiekty klasy aktywnej reprezentuj elementy działajce równolegle z innymi. Na diagramie jest przedstawiana jak zwykła klasa - rónic jest pogrubione obramowanie prostokta (Rys. 11) 13

14 Elementy w UML Zarzdca czynnoci UruchomCzynno() W strzymajczynno() Rys. 11 Klasa aktywna Obiekty klas aktywnych słu do modelowania niezalenych przepływów sterowania. Obiekt aktywny (egzemplarz klasy aktywnej) reprezentuje proces lub wtek. Z chwil utworzenia obiektu aktywnego zostaje uruchomiony zwizany z nim przepływ sterowania. W momencie zniszczenia takiego obiektu przepływ ten zostaje przerwany. Klasy aktywne maj te same właciwoci co zwykłe klasy. Maj egzemplarze, atrybuty i operacje. Mog by elementami zalenoci, uogólnie i powiza. Mona wobec nich stosowa wszystkie mechanizmy rozszerzania UML, to znaczy stereotypy, metki i ograniczenia. Mog by realizacjami interfejsów i mog by realizowane przez kooperacje. Ich zachowanie moe by zdefiniowane za pomoc maszyny stanowej. Pozostałe dwa rodzaje elementów strukturalnych, komponenty i wzły, w odrónieniu od dotychczas omówionych, reprezentuj byty fizyczne, a nie pojciowe i logiczne Komponent Komponent stanowi fizyczn cz systemu. Jest elementem wymiennym, wykorzystujcym i realizujcym pewien zbiór interfejsów. Komponent jest fizycznym opakowaniem klas, interfejsów i kooperacji. Kady system posiada wiele komponentów bdcych elementami procesu wytwarzania (np. pliki z kodem ródłowym) oraz komponentów ju wdroonych. Na diagramach symbolem graficznym komponentu jest prostokt z bolcami z nazw w rodku (Rys. 12). Interfejs graficzny Rys. 12 Komponent Komponenty maj wiele cech wspólnych z klasami: maj nazwy, realizuj pewien zbiór interfejsów, mog bra udział w zalenociach, uogólnieniach i powizaniach, mog by zagniedone, mie egzemplarze i uczestniczy w interakcjach. W UML jest zdefiniowanych pi standardowych stereotypów komponentów: 1. executable - okrela komponent, który mona wykona na wle. 2. library - okrela dynamiczn lub statyczn bibliotek obiektów. 3. table - okrela komponent reprezentujcy tabel bazy danych. 14

15 Elementy w UML 4. file - okrela komponent reprezentujcy dokument zawierajcy kod ródłowy lub dane. 5. document okrela komponent reprezentujcy dokument Wzeł Wzeł jest fizycznym składnikiem działajcego systemu, który reprezentuje pewne zasoby obliczeniowe. Cechuje go posiadanie pewnej iloci pamici i zdolnoci przetwarzania. Najczciej w wzłach znajduj si komponenty, niekiedy komponenty przemieszczaj si midzy wzłami. Symbolem graficznym wzła jest jako szecian z nazw w rodku (Rys. 13). Serwer apli kacyjny Rys. 13 Wzeł Wzły mog bra udział w zalenociach, uogólnieniach i powizaniach. Mog by zagniedone i mog uczestniczy w interakcjach. Najczciej wystpujcym zwizkiem midzy wzłami jest powizanie. W przypadku wzłów oznacza ono połczenie fizyczne, takie jak sie Ethernet, łcze szeregowe lub wspólna szyna. Powiza mona take uy do modelowania połcze porednich, takich jak komunikacja satelitarna midzy odległymi procesorami. Wzeł jest podobny do klasy, mona wic wykorzystywa wszystkie właciwoci powiza, czyli role, liczebno i ograniczenia. 4.2 Elementy czynnociowe Elementy czynnociowe dotycz dynamicznej czci modelu w UML. Wyraone s czasownikami opisujcymi zachowanie w czasie i w przestrzeni. Wyróniamy dwa rodzaje takich elementów. Interakcja jest zachowaniem polegajcym na wymianie komunikatów midzy obiektami. Interakcje wykorzystywane s do modelowania przepływu sterowania w ramach operacji, klasy, komponentu czy przypadku uycia. Za pomoc interakcji mona zdefiniowa zarówno zachowanie zespołu obiektów, jak i pojedyncz operacj. Interakcja składa si z komunikatów, cigów akcji bdcych odpowiedzi na ten komunikat i połcze midzy obiektami. Komunikat jest przedstawiany na diagramie jako strzałka z nazw operacji (Rys. 14). 15

16 Elementy w UML otwórz Rys. 14 Komunikat Drugim elementem czynnociowym jest maszyna stanowa. Okrela ona cig stanów, jakie obiekt lub interakcja przyjmuje w odpowiedzi na zdarzenia zachodzce w czasie ich ycia oraz ich odpowiedzi na te zdarzenia. Za jej pomoc moe by zdefiniowane zachowanie pojedynczej klasy lub kooperacji. Maszyna stanowa składa si z innych elementów, takich jak stany, przejcia midzy stanami, zdarzenia, które powoduj przejcia i czynnoci, bdce odpowiedziami na zdarzenia. Stan jest przedstawiany na diagramie jako prostokt z zaokrglonymi rogami z nazw w rodku (Rys. 15). Oczekiwanie Rys. 15 Stan 4.3 Elementy grupujce Elementy grupujce odgrywaj w UML rol organizacyjn. S to bloki, na które dany model moe by rozłoony. Podstawowym rodzajem tego typu elementu jest pakiet. Pakiet w rozumieniu UML-owym to zgrupowanie elementów modelu. Pozwala na organizowanie klas w zbiory niezalene od struktur zapisanych na diagramach klas. Oznacza to, e mona umieci wszystkie klasy na pojedynczym diagramie, mona take rozbi go na szereg prostszych diagramów. Pakiety to w rzeczywistoci jedynie przestrzenie nazewnicze, grupujce elementy, które powinny zawiera unikatowe nazwy w obrbie danej grupy. Z pakietów mona korzysta przy porzdkowaniu elementów składowych podsystemów, bez koniecznoci tworzenia dodatkowych przypadków uycia. Na diagramie pakiet przedstawiany jest jako prostokt z fiszk, zazwyczaj tylko z nazw w rodku (Rys. 16). O b s łu g a s ło w n ik a Rys. 16 Pakiet Składnikami pakietu mog by róne byty, takie jak klasy, interfejsy, komponenty, wzły, operacje, przypadki uycia, diagramy, a nawet inne pakiety. Model w 16

17 Elementy w UML rozumieniu UML-owym stanowi pakiet zawierajcy pełn reprezentacj systemu w konkretnym aspekcie. Potraktowanie architektury systemu jako zbioru powizanych i zagniedonych pakietów pomaga w optymalizacji tworzonych struktur. Celem pakietyzacji elementów modelu jest rozdzielenie podstawowych czci składowych systemu i uniezalenienie ich od siebie. To z kolei pozwala na enkapsulacj duych fragmentów systemu w pakietach i daje moliwo ich powtórnego wykorzystania. Pakietom towarzysz zazwyczaj interfejsy lub zestawy interfejsów reprezentujce udostpniane przez nie usługi. W UML zakłada si, e w modelu istnieje nienazwany pakiet nadrzdny. Konsekwencj tego załoenia jest konieczno unikatowego nazywania bytów kadego rodzaju, zdefiniowanych u góry modelu. Wszystkie mechanizmy rozszerzania UML dotycz take pakietów. Najczciej s to metki definiujce nowe właciwoci pakietów. Pakiety s podstawowymi elementami grupujcymi, za pomoc których mona usystematyzowa model zapisany w UML. Istniej te inne elementy tego typu, takie jak zrby, modele i podsystemy (rodzaje pakietów). 4.4 Elementy komentujce Elementy komentujce odgrywaj w UML rol objaniajc. S to adnotacje, których mona uy w celu opisania, uwypuklenia lub zaznaczenia dowolnych składników modelu. Podstawowym rodzajem tego typu elementu jest notatka. Jest to symbol umoliwiajcy skojarzenie dodatkowych ogranicze i objanie z pojedynczym bytem lub grup bytów. Na diagramie jest przedstawiana jako prostokt z zagitym rogiem, z komentarzem tekstowym lub graficznym w rodku (Rys. 17). P akiet zawiera klasy zwizane z edytorem przypadków uycia Rys. 17 Notatka Notatka to podstawowy element komentujcy, który moe si pojawi w modelu zapisanym w UML. Zwykle uywa si jej w celu wzbogacenia diagramu o ograniczenia i objanienia, które najłatwiej wyrazi za pomoc formalnego lub nieformalnego tekstu. S te inne rodzaje elementów tego typu, takie jak wymagania, które definiuj zachowanie oczekiwane przez otoczenie modelu. 17

18 Zwizki w UML 5 Zwizki w UML W UML s uwzgldnione cztery rodzaje zwizków: 1) zaleno, 2) uogólnienie, 3) powizanie, 4) realizacja. Zwizki te s podstawowymi blokami konstrukcyjnymi UML, słucymi do łczenia elementów. 5.1 Zaleno Zaleno pozwala na pokazanie, e jedna klasa uywa drugiej jako argumentu w sygnaturze operacji (Rys. 18). Jest to najczciej spotykany sposób uycia zalenoci. Ponadto UML dopuszcza stosowanie zalenoci take midzy pakietami i notatkami, jednak s one rzadziej uywane. Zmiany dokonane w specyfikacji jednego elementu mog mie wpływ na inny element, który go uywa. Na diagramie zaleno przedstawiana jest jako linia przerywana z grotem skierowanym na element, od którego co zaley. Edytor WypełnijList(okno : Okno wyboru*) Okno wyboru Słowa : ListBox Rys. 18 Zaleno 5.2 Uogólnienie Uogólnienie jest zwizkiem midzy elementem ogólnym (zwanym nadklas lub przodkiem) a pewnym specyficznym jego rodzajem (zwanym podklas lub potomkiem). Uogólnienie polega na tym, e potomek moe wystpi wszdzie tam, gdzie jest spodziewany przodek, ale nie na odwrót. Potomek dziedziczy wszystkie właciwoci przodka, w szczególnoci atrybuty i operacje, i zawsze moe go zastpi. Najczciej potomek oprócz cech odziedziczonych po przodku ma take własne cechy. Operacja potomka majca t sam sygnatur co operacja przodka jest waniejsza (polimorfizm). Uogólnienie jest przedstawiane na diagramie jako linia cigła zakoczona zamknitym, niewypełnionym grotem wskazujcym przodka (Rys. 19). 18

19 Zwizki w UML Słowo W spółrzdne : Point Sz eroko : Integer W ysoko : Integer Słowo ze słownika TypS łownika : Integer FormaP odst awowa : String Odmiany : List Słowo spoza słownika Nazwa : String Rys. 19 Uogólnienie Najczciej uogólnie uywa si wzgldem klas i interfejsów w celu przedstawienia dziedziczenia. UML umoliwia tworzenie uogólnie take midzy innymi elementami, w szczególnoci midzy pakietami. 5.3 Powizanie Powizanie jest zwizkiem słucym do pokazania, e obiekty jednego elementu s połczone z obiektami innego. Powizanie midzy dwiema klasami oznacza, e mona przej z obiektu jednej z tych klas do obiektu drugiej i odwrotnie. Moliwe jest take takie powizanie, którego oba koce wskazuj t sam klas. Oznacza to, e kady obiekt tej klasy moe by połczony z innymi obiektami tej klasy. Na diagramie powizanie jest przedstawiane jako linia cigła, łczca klas z sob sam lub z inn klas. Powizanie moe mie przypisan nazw, która okrela istot danego zwizku (Rys. 20). Aby unikn niejednoznacznoci, mona poda kierunek odczytu w postaci trójktnego znacznika umieszczonego za nazw powizania. Przypadek uycia pos iada Scenariusz Rys. 20 Nazwa powizania Kada klasa biorca udział w powizaniu odgrywa w nim okrelon rol. Rola klasy moe by jawnie nazwana w powizaniu. Na rysunku (Rys. 21) klasa Osoba odgrywajca rol pracownika jest powizana z klas Firma w roli pracodawcy. 19

20 Zwizki w UML Osoba +pracownik + pracodawca Firma Rys. 21 Role Czsto w powizaniu zachodzi potrzeba podania liczebnoci, czyli liczby obiektów jaka moe by połczona przez jeden egzemplarz powizania. Ilo obiektów nazywana jest take krotnoci. Liczebno zapisywana jest w postaci wyraenia, którego wartoci jest przedział liczbowy lub pojedyncza liczba (Rys. 22). Podajc liczebno przy jednym kocu powizania wskazujemy ile obiektów jednej klasy musi by połczonych z kadym obiektem klasy znajdujcej si na kocu przeciwnym. Liczebno mona ustali na dokładnie jeden (1), zero lub jeden (0..1), dowolnie wiele (0..*) albo co najmniej jeden (1..*). Moe to by take pewna ustalona liczba (np. 3). Edytor przypadków uy cia 1 0..* Przypadek uycia Rys. 22 Liczebno Najczciej powizanie dwóch klas jest zwizkiem strukturalnym elementów równorzdnych, czyli powizane klasy znajduj si na tym samym poziomie pojciowym. Czasami wystpuje potrzeba zapisania agregacji, czyli zwizku rodzaju cało-cz. W takim zwizku jedna klasa reprezentuje wikszy element stanowicy cało, a druga reprezentuje elementy mniejsze, czyli czci, z których składa si cało. Agregacja jest szczególnym rodzajem powizania. Na diagramie wyróniana jest przez dodanie do zwykłego symbolu powizania pustego rombu po stronie całoci (Rys. 23). 20

21 Zwizki w UML Oddział 1 Filia 1..* Rys. 23 Agregacja 5.4 Realizacja Realizacja jest zwizkiem znaczeniowym midzy klasyfikatorami, z których jeden okrela kontrakt, a drugi zapewnia wywizanie si z niego. Takie zwizki wystpuj najczciej midzy interfejsami a klasami i komponentami oraz midzy przypadkami uycia a kooperacjami. Na diagramach realizacja przedstawiana jest jako połczenie symboli uogólniania i zalenoci, czyli jako linia przerywana zakoczona zamknitym niewypełnionym grotem (Rys. 24). Rys. 24 Realizacja Omówione cztery rodzaje zwizków to podstawowe bloki konstrukcyjne umoliwiajce łczenie elementów modelu w UML. 21

22 Diagramy w UML 6 Diagramy w UML Diagram jest schematem przedstawiajcym zbiór bytów. Najczciej ma posta grafu, w którym wierzchołkami s elementy, a krawdziami zwizki. Diagram to swego rodzaju rzut systemu. Tylko w przypadku najprostszych systemów diagram przedstawia pełny obraz bytów wchodzcych w skład systemu. Ten sam byt moe si pojawi na wszystkich diagramach, jednak najczciej wystpuje tylko na niektórych. W wyjtkowych przypadkach dany byt moe nie wystpi na adnym diagramie. Teoretycznie diagram moe zawiera dowoln kombinacj elementów i zwizków. W praktyce jednak tylko niektóre z kombinacji odpowiadaj piciu najbardziej uytecznym perspektywom architektonicznym systemu oprogramowania. Z tego powodu w UML wyrónia si nastpujce rodzaje diagramów: 1) diagram klas, 2) diagram obiektów, 3) diagram przypadków uycia, 4) diagram przebiegu (sekwencji), 5) diagram kooperacji, 6) diagram stanów, 7) diagram czynnoci, 8) diagram komponentów, 9) diagram wdroenia. 6.1 Diagram klas Diagramy klas to najczciej wystpujce diagramy w modelach obiektowych. Kady z nich przedstawia okrelony fragment struktury systemu klas. Diagramów klas uywa si do modelowania statycznych aspektów perspektywy projektowej. Wie si z tym w głównej mierze modelowanie słownictwa systemu, kooperacji lub schematów. Diagramy klas stanowi baz wyjciow do dwóch innych diagramów: diagramu komponentów i diagramu wdroenia. Diagram klas uwzgldniajcy klasy aktywne dotyczy statycznych aspektów perspektywy procesowej. Diagramy klas nie ograniczaj si tylko do samych klas, mona za ich pomoc modelowa interfejsy, relacje a nawet pojedyncze instancje klas. Diagramy klas pozwalaj na sformalizowanie specyfikacji danych i metod. Specyfikacja ta jest zwizana z oprogramowaniem, ale dotyczy jego zewntrznego opisu bez wchodzenia w szczegóły implementacyjne. Diagramy klas mog take pełni rol graficznego rodka pokazujcego szczegóły implementacji klas np. w C++. Przykład diagramu klas przedstawiony jest na rysunku (Rys. 25). 22

23 Diagramy w UML Przypadek uycia Nazwa : String W spółrzdne : Point Scenariusze : PtrArray ZwróAktywnyScenariusz() W czytajprzypadek() +jest zwizany Relacja Tre : String Przypadek : String TypRelacji : Integer W spółrzdne : Point UtwórzRelacj() +wykorzyst uje lub jest rozszerzany przez +posiada 1 0..* +rozsz erza lub jest wykorzystywany Scenariusz Nazwa : String NumerScenariusza : Integer Elementy : PtrArray Relacje : PtrArray W stawrelacj() UtwórzSłowo() Słowo W spółrzdne : Point UtwórzSlowo() 0..* 1 Słowo ze słownika FormaPodstawowa : String Odmiany : List Słowo spoza słownika Nazwa : String Rys. 25 Diagram klas Na diagramach klas mog si znale równie pakiety i podsystemy, uywane do grupowania bytów modelu w wiksze porcje. 6.2 Diagram obiektów Na diagramie obiektów przedstawia si obiekty, czyli konkretne instancje klas i zwizki midzy nimi. Diagram ten wyobraa statyczny rzut pewnych egzemplarzy elementów wystpujcych na diagramie klas. Podobnie jak diagram klas, odnosi si do statycznych aspektów perspektywy projektowej lub procesowej. Korzystajc z niego bierze si 23

24 Diagramy w UML jednak pod uwag przypadki rzeczywiste lub prototypowe. Przykład diagramu obiektów przedstawiony jest na rysunku (Rys. 26). f : Firma ubezpieczeniowa nazwa = "Ubezpieczenia S.A." oddz1 : Jednostka organizacyjna rodzaj = "Oddział" nazwa = "Oddział w Krakowie" oddz2 : Jednost ka organizac yjna rodzaj = "Oddział" naz wa = "Oddział w W arsz awie" prz : Jednost ka organizacyjna rodzaj = "Przedstawicielstwo" pr : P racownik stanowisk o = "Dyrektor" nazwisko = "Kowalski" Rys. 26 Diagram obiektów 6.3 Diagram przypadków uycia Diagram przypadków uycia ukazuje zwizki pomidzy aktorami i przypadkami. Umieszcza si take na nim wzajemne relacje midzy poszczególnymi przypadkami uycia. Diagram ten odnosi si do statycznych aspektów perspektywy przypadków uycia. Wykorzystywany jest głównie do wyznaczania i modelowania zachowania systemu w taki sposób, eby uytkownicy mogli zrozumie jak z niego korzysta, a programici mogli go zaimplementowa. Dziki diagramom przypadków uycia systemy, podsystemy i klasy staj si bardziej przystpne i zrozumiałe. Model przypadków uycia przekształca wymagania wstpne w przejrzyst reprezentacj systemu, który naley skonstruowa. Mona go doprecyzowywa i uszczegóławia poprzez dodawanie nowych aktorów, nowych przypadków uycia i powiza pomidzy nimi. Diagram przypadków uycia dostarcza bardzo abstrakcyjnego pogldu na system z pozycji aktorów, którzy go uywaj. Nie włcza szczegółów, co pozwala wnioskowa o systemie na odpowiednio ogólnym, abstrakcyjnym poziomie. Przykładowy diagram przypadków przedstawiony jest na rysunku (Rys. 27). 24

25 Diagramy w UML Uytkownik Utworzenie słownika Usunicie słowa <<include>> Dodanie słowa <<inclu de>> <<extend>> <<extend>> Ot worzen ie słownika Zapisanie słownika Rys. 27 Diagram przypadków uycia Mona wyróni dwa zasadnicze cele istnienia diagramów przypadków uycia: modelowanie otoczenia systemu i modelowanie wymaga stawianych systemowi. Modelowanie otoczenia polega midzy innymi na wyznaczeniu granicy wokół całego systemu i na wskazaniu lecych poza ni aktorów, którzy wchodz w interakcj z systemem. Diagramy przypadków uycia w tym wypadku słu do zdefiniowania aktorów i znaczenia ich ról. Modelowanie wymaga polega na okreleniu, co system ma robi z punktu widzenia jego otoczenia, bez zagłbiania si w to, w jaki sposób ma to robi. W tym przypadku diagram słuy do zdefiniowania oczekiwanego działania systemu. Na diagramach przypadków uycia zaznaczane s uogólnienia oraz zwizki zawierania i rozszerzania. Zostało to omówione w punkcie dotyczcym przypadków uycia. 6.4 Diagram interakcji Diagram przebiegu (sekwencji) i diagram kooperacji to rodzaje diagramu interakcji, na którym przedstawia si interakcj jako zbiór obiektów i zwizków midzy nimi, w tym te komunikaty, jakie obiekty przekazuj midzy sob. Diagram interakcji odnosi si do modelowania dynamicznych aspektów systemu. Diagram przebiegu obrazuje kolejno przesyłania komunikatów w czasie. Na diagramie kooperacji kładzie si nacisk na organizacj strukturaln obiektów wymieniajcych komunikaty. Oba te diagramy mona przekształca jeden w drugi. Na diagramach interakcji uwzgldnia si konkretne 25

26 Diagramy w UML i prototypowe egzemplarze klas, interfejsów, komponentów i wzłów, a take komunikaty przekazywane midzy nimi. Elementy te s rozpatrywane w kontekcie pewnego scenariusza ilustrujcego zachowanie systemu. Diagram sekwencji jest połczeniem midzy wiatem funkcjonalnym i obiektowym. Odpowiada konkretnemu scenariuszowi danego przypadku uycia. Główny nacisk połoony jest na uwypuklenie kolejnoci komunikatów w czasie. W górnej czci diagramu sekwencji, wzdłu osi X, umieszczone s obiekty uczestniczce w interakcji. Obiekt inicjujcy interakcj znajduje si zazwyczaj po lewej stronie diagramu, a coraz bardziej podrzdne kolejno po prawej. Komunikaty s uporzdkowane w czasie wzdłu osi Y, im póniejsza chwila wysłania, tym komunikat umieszczony niej. Taki sposób obrazowania ułatwia zrozumienie przepływu sterowania w czasie. Diagramy sekwencji maj dwie cechy, które odróniaj je od diagramów kooperacji. Po pierwsze wystpuj na nich linie ycia obiektów pionowe przerywane kreski reprezentujce czas istnienia obiektów. Wikszo obiektów z diagramu interakcji yje przez cały czas trwania interakcji. Znajduj si one w górnej czci diagramu, a ich linie ycia biegn od góry do dołu. Podczas interakcji mog powstawa nowe obiekty. Ich linie ycia rozpoczynaj si w chwili odebrania przez nie komunikatu o stereotypie create. Pewne obiekty s niszczone. Ich linie ycia kocz si w chwili odebrania przez nie komunikatu o stereotypie destroy. Drug cech odróniajc diagram przebiegu od diagramu kooperacji jest uwzgldnienie orodka sterowania. Jest to podłuny, cienki prostokt reprezentujcy okres wykonywania przez obiekt jakiej akcji. Górna krawd tego prostokta znajduje si na tej samej wysokoci co pocztek akcji, a dolna na wysokoci zakoczenia akcji. Zakoczenie akcji moe by dodatkowo oznaczone komunikatem przekazania. Mona wyróni scentralizowany i zdecentralizowany sposób współpracy obiektów. Przy scentralizowanym sposobie wymiany komunikatów jeden z obiektów kontroluje cały przebieg przypadku, steruje operacjami i poredniczy w wymianie danych. W przypadku zdecentralizowanego sposobu wymiany komunikatów nie ma obiektu kontrolujcego i obiekty komunikuj si ze sob bezporednio. Przykładowy diagram przebiegu pokazany jest na rysunku (Rys. 28). 26

27 Diagramy w UML : Uytkownik : Menu : Okno zarzdcy projektu : Zarzdca projektu : Projekt UruchomZarzdcProjektu( ) Uruchom Zarz dc( ) W ywietlokno( ) UtwórzNowyProjekt( ) PotwierdOperacj( ) OK( ) UtwórzProjekt( ) Ut wórzprojekt( ) UsuZawartoList( ) Rys. 28 Diagram przebiegu Istot diagramu kooperacji jest przedstawienie przepływu komunikatów pomidzy obiektami. Współpraca midzy obiektami włcza dwa aspekty: struktur uczestniczcych obiektów oraz sekwencj komunikatów wymienianych pomidzy obiektami. Czas nie jest wprost odwzorowany, natomiast odwzorowane s powizania pomidzy obiektami. Na diagramie kooperacji uwypukla si organizacj obiektów uczestniczcych w interakcji. Obiekty s rozmieszczone jako wierzchołki grafu. Krawdziami grafu s wizania łczce te obiekty. Od diagramu przebiegów odróniaj go dwie cechy. Po pierwsze, wystpuj na nim cieki. Sposób połczenia jednego obiektu z drugim wskazuje si przez dodanie stereotypu cieki do drugiego koca wizania. Po drugie, na diagramach kooperacji uwzgldnia si cig komunikatów. Wskazanie kolejnoci komunikatu w czasie polega na poprzedzeniu go odpowiednim numerem w cigu (pierwszy komunikat ma numer 1, a nastpne s ponumerowane kolejnymi liczbami naturalnymi). Zagniedenia obrazuje si za pomoc notacji Doweya (1 oznacza pierwszy komunikat, 1.1 pierwszy komunikat zagniedony w komunikacie numer 1 itd.). Zagniedenie moe mie dowoln głboko. Rysunek (Rys. 29) pokazuje przykładowy diagram kooperacji, który jest odpowiednikiem przedstawionego wczeniej diagramu przebiegu. 27

28 Diagramy w UML 2. Utwórz NowyProjek t( ) 3. OK( ) 2.1. PotwierdOperacj( ) 3.2. UsuZawarto List( ) : Uytkownik 1. UruchomZarzdc Projektu( ) : Okno zarzdcy projektu WywietlOkno( ) : Menu 1.1. UruchomZarzdc( ) 3.1. UtwórzProjekt( ) : Zarzdca projektu UtwórzProjekt( ) : Projekt Rys. 29 Diagram kooperacji 6.5 Diagram stanów Diagram stanów nawizuje do automatu skoczonego, przedstawia maszyn stanow składajc si ze stanów, przej, zdarze i czynnoci. Opisuje on stany pewnego procesu, które s istotne z punktu widzenia modelu pojciowego tego procesu, oraz przejcia pomidzy stanami wymuszane poprzez wywoływane usługi obiektu. Okrela te reakcje obiektu na zdarzenia zachodzce podczas jego ycia. Diagram stanów odnosi si do modelowania dynamicznych aspektów systemu. Jest szczególnie przydatny w modelowaniu zachowania interfejsów, klas i kooperacji. Przedstawia reakcje obiektów na cigi zdarze i dlatego wietnie nadaje si do projektowania systemów interakcyjnych. Przykładowy diagram stanów pokazany jest na rysunku (Rys. 30). 28

29 Diagramy w UML Dodane do słownika U ywane w sce nariuszac h Edytowane Usunite ze słownika Rys. 30 Diagram stanów 6.6 Diagram czynnoci Diagram czynnoci to szczególny przypadek diagramu stanów, który obrazuje strumie kolejno wykonywanych czynnoci. Odnosi si do modelowania dynamicznych aspektów systemu. Jest bardzo przydatny w modelowaniu funkcji systemu. Kładzie si na nim nacisk na przepływ sterowania midzy obiektami. Wikszo diagramów czynnoci przedstawia sekwencyjne lub współbiene kroki procesu obliczeniowego. Na diagramie czynnoci mona take zobrazowa zmiany zachodzce w obiekcie, gdy przechodzi on z jednego stanu do drugiego w rónych fazach przepływu sterowania. Rysunek (Rys. 31) pokazuje przykładowy diagram czynnoci. 29

30 Diagramy w UML Uruchomienie zarzdcy projektu W ywietlenie okna zarzdcy W ybranie opcji utworzenia nowego projektu Potwierdzenie operacji [nie] [tak] Utworzenie projek tu Rys. 31 Diagram czynnoci 6.7 Diagram komponentów Diagramy komponentów pokazuj zalenoci pomidzy komponentami oprogramowania, włczajc komponenty kodu ródłowego, kodu binarnego oraz kodu wykonywalnego. Komponenty mog istnie w rónym czasie: niektóre z nich w czasie kompilacji, niektóre w czasie konsolidacji, inne w czasie wykonania. Diagram komponentów odnosi si do statycznych aspektów perspektywy implementacyjnej. cile wie si z diagramem klas, poniewa zwykle kademu komponentowi s przyporzdkowane pewne klasy, interfejsy i kooperacje. Główny nacisk połoony jest na zarzdzanie konfiguracj poszczególnych czci systemu. Czci te składaj si z komponentów, które mog by rozmaicie scalone w gotowy system. Przykładowy diagram komponentów pokazuje rysunek (Rys. 32). 30

31 Diagramy w UML logowanie.asp aplikacja.exe <<DLL>> grafika.dll <<DLL>> jzyki.dll Rys. 32 Diagram komponentów 6.8 Diagram wdroenia Diagram wdroenia obrazuje konfiguracj poszczególnych wzłów działajcych w czasie wykonania i zainstalowane na nich komponenty. Odnosi si do statycznych aspektów perspektywy wdroeniowej. Wie si z diagramem komponentów, poniewa zwykle kady wzeł zawiera co najmniej jeden komponent. Umoliwia zbadanie układu procesorów i urzdze, na których działa oprogramowanie. Przykład takiego diagramu pokazuje rysunek (Rys. 33). 31

32 Diagramy w UML S erwer bazodanowy Serwer W W W Sie lokalna Intern et Serwer aplikacyjny 1 Serwer aplikacyjny 2 Klient W W W Rys. 33 Diagram wdroenia Projektujc nasz program korzystalimy z diagramu klas, diagramu przypadków uycia i diagramu przebiegu (sekwencji). 32

33 Podstawowe mechanizmy jzykowe w UML 7 Podstawowe mechanizmy jzykowe w UML UML jest prostszy dziki czterem podstawowym mechanizmom, które s stosowane konsekwentnie w całym jzyku. S to: 1) specyfikacje, 2) dodatki, 3) zasadnicze rozgraniczenia, 4) mechanizmy rozszerzania (wprowadzania nowych konstrukcji). 7.1 Specyfikacje UML jest czym wicej ni tylko graficznym jzykiem modelowania. Za kadym fragmentem graficznego zapisu kryje si specyfikacja definiujca składni i znaczenie bloku konstrukcyjnego. Ikona klasy reprezentuje specyfikacj okrelajc zestaw wszystkich atrybutów, operacji (łcznie z ich pełnymi sygnaturami) i funkcji, które ta klasa moe spełnia. Symbol klasy nie musi wyobraa całej specyfikacji, a tylko pewn niewielk jej cz. Co wicej, symbol tej samej klasy moe przedstawia zupełnie inny zestaw jej składowych i bdzie to całkowicie poprawne. Notacja graficzna UML słuy do zobrazowania systemu, a specyfikacje do definiowania jego szczegółów. Dziki takiemu podziałowi mona przystpi do przyrostowego konstruowania modelu najpierw narysowa diagramy, a nastpnie doda do nich specyfikacje. Mona take budowa model od podstaw zacz od utworzenia specyfikacji np. za pomoc inynierii wstecz, a potem opracowa diagramy bdce rzutami na ten zbiór specyfikacji. 7.2 Dodatki Wikszo bytów UML ma jedyn i niezalen posta graficzn, która oddaje najwaniejsze ich aspekty. Symbol klasy jest na przykład tak zaprojektowany, aby mona go było łatwo narysowa, poniewa jest najczciej wystpujcym składnikiem modeli obiektowych. Ten symbol podkrela najwaniejsze aspekty klasy, to znaczy nazw, atrybuty i operacje. Specyfikacja klasy moe zawiera take inne szczegóły, takie jak informacje o abstrakcyjnoci klasy lub widocznoci poszczególnych atrybutów i operacji. Wiele z nich moe by umieszczonych na diagramach jako graficzne lub tekstowe uzupełnienia prostoktnego symbolu klasy. Kady element notacji UML składa si z symbolu podstawowego i rozmaitych charakterystycznych dla niego dodatków. Na rysunku (Rys. 34) wida przykład klasy z dodatkami wskazujcymi, e jest to klasa abstrakcyjna z czterema operacjami: dwiema publicznymi, jedn chronion i jedn prywatn. 33

34 Podstawowe mechanizmy jzykowe w UML Transak cja Wy konaj() W ycofaj() Zatwierd() ZapiszCzas() Rys. 34 Dodatki 7.3 Zasadnicze rozgraniczenia W modelowaniu systemów obiektowych wiat jest podzielony na kilka sposobów. Po pierwsze, rozrónia si klas i obiekt. Klasa jest abstrakcj, a obiekt jest jednym konkretnym urzeczywistnieniem tej abstrakcji. W UML mona modelowa zarówno klasy, jak i obiekty (Rys. 35). oddz1 : Oddział Oddz iał Nazwa Adres oddz2 : Oddział Rys. 35 Klasy i obiekty Prawie z kadym blokiem konstrukcyjnym UML zwizana jest podobna zaleno jak w przypadku klasy i obiektu. Mona mie przypadki uycia i egzemplarze przypadków uycia, komponenty i ich egzemplarze, wzły i ich egzemplarze. Graficznie symbol obiektu róni si od symbolu klasy tego obiektu jedynie tym, e nazwa obiektu jest podkrelona lini cigł. Po drugie, rozrónia si interfejs i implementacj. Interfejs to deklaracja kontraktu, a implementacja to jedna z wielu konkretnych realizacji tego kontraktu. Wszystko musi przebiega zgodnie ze znaczeniem interfejsu. W UML mona modelowa zarówno interfejsy, jak i ich implementacje. Na rysunku (Rys. 36) wida komponent wyszukiwanie.dll, który jest implementacj interfejsu ISzukanieSłów. ISzukanie Słów Rys. 36 Interfejsy i implementacje wyszuki wanie.dll 34