UML Zunifikowany jzyk modelowania Dlaczego UML UML ang

UML Zunifikowany język modelowania

Dlaczego UML ? • UML (ang. Unified Modeling Language) jest językiem modelowania, który przeszedł proces standaryzacyjny w ramach organizacji Object Management Group i jest obecnie jej standardem. • Stanowi graficzną notację wykorzystywaną do tworzenia modeli opisywanego systemu. • UML wspomaga przejście do obiektowości: powstał na podstawie obiektowych metod analizy i projektowania oprogramowania.

UML • Głównym powodem używania UML’a jest komunikacja. • Język naturalny jest nieprecyzyjny, gdy opisywane pojęcia charakteryzują się złożonością. • Kod jest precyzyjny, ale za szczegółowy i niezrozumiały dla odbiorcy oprogramowania.

UML definiuje. . . notację i semantyki dla następujących dziedzin: · Interakcje użytkownika lub model przypadków użycia (ang. Use Case Model) – opisuje brzeg (granice) i wzajemne oddziaływanie systemu i użytkowników. Odpowiada pod pewnymi względami modelowi wymagań. · Model oddziaływania i komunikacji – opisuje jak obiekty w systemie będą oddziaływały wzajemnie dla wykonania pracy (zadania).

UML definiuje. . . dziedzin: • Model stanów i dynamiki – diagram stanów opisuje stany oraz warunki, które przyjmują klasy w czasie. Graf aktywności opisuje przepływy prac które implementować będzie system. • Model logiczny lub klas – opisuje klasy i obiekty, z których składa się system. • Fizyczny model komponentów – opisuje oprogramowania (i czasami komponenty sprzętowe), tworzące system.

UML definiuje. . . dziedzin: • Fizyczny model wdrożenia – opisuje fizyczną architekturę i wdrożenie (rozmieszczenie) komponentów w architekturze sprzętowej. • UML definiuje także mechanizmy rozwinięcia dla poszerzenia UML do objęcia również specjalizowanych potrzeb (np. rozszerzenie modelowania procesów biznesowych)

Związki W modelowaniu obiektowym wyróżnia się trzy najważniejsze rodzaje związków: Ø zależności, które reprezentują używanie danej klasy przez inną; Ø uogólnienia, które obrazują relacje między klasami ogólnymi a klasami szczegółowymi; Ø powiązania, które są związkami strukturalnymi między obiektami;

Zależność • Zależność to związek użycia. Zmiany dokonane w specyfikacji jednego elementu mogą mieć wpływ na inny element, który używa tego pierwszego, ale niekoniecznie na odwrót. Na diagramie związek ten jest przedstawiony jako linia przerywana z grotem otwartym skierowanym na element, od którego coś zależy.

Uogólnienie • Uogólnienie to związek między elementem ogólnym (nadklasą bądź przodkiem) a pewnym jego rodzajem (podklasą lub potomkiem). Uogólnienie polega na tym, że potomek może wystąpić wszędzie tam, gdzie jest spodziewany przodek, ale nie na odwrót. Potomek dziedziczy wszystkie właściwości przodka, a zwłaszcza atrybuty i operacje. Potomek może mieć także własne cechy oprócz tych, które odziedziczył po przodku. Uogólnienie jest przedstawiane na diagramie jako linia ciągła zakończona zamkniętym, niewypełnionym grotem wskazującym przodka.

Powiązanie • Powiązanie to związek strukturalny, który wskazuje, że obiekty jednego elementu są połączone z obiektami innego. Powiązania między dwiema klasami oznacza, że można przejść z obiektu z jednej z tych klas do obiektu drugiej i vice versa. Na diagramie powiązanie jest przedstawione jako linia ciągła.

Liczebność jest ważnym aspektem powiązania. Określa, ile obiektów z jednej klasy może być powiązanych z jednym obiektem innej klasy. W UML stosuje się gwiazdkę (*) na oznaczenie więcej lub wiele. Or (lub) może być reprezentowane przez dwie kropki np. „ 1. . *” oznacza „jeden lub więcej”, bądź przez przecinek np. „ 5, 10” oznacza „ 5 lub 10”.

Powiązanie zwrotne – czasami klasa jest powiązana ze sobą. przedstawia się to kreśląc linię powiązania od prostokątnej ikony klasy z powrotem do tejże ikony.

Agregacja Klasa może składać się z wielu komponentów. Jest to specjalny związek zwany agregacją. Związek „całośćczęść”, w którym klasa reprezentuje większy element („całość”) składający się z mniejszych („części”). Na diagramie wyróżnia się ją poprzez dodanie do zwykłego symbolu powiązania pustego rombu po stronie całości. Agregacja całkowita to szczególnie silny typ agregacji, w której każdy komponent może należeć tylko do jednej całości.

Agregacja – symbole Agregację całkowitą oznacza się tak samo jak zwykłą, z tym, że romb agregacji całkowitej jest wypełniony.

Diagramy modelowania strukturalnego • Diagram klas lub struktury – dotyczy statycznego wyglądu perspektywy, diagram ten skupia klasy, interfejsy, kooperacje oraz oczywiście związki pomiędzy nimi. • Diagram obiektów – przedstawia obiekty oraz ich związki, diagram odzwierciedla pewne egzemplarze występujące na diagramie klas. • Diagram mieszany – diagram dostarczjący znaczenia warstw w strukturze elementów skupiający się na wewnętrznych detalach, konstrukcji i zależnościach. • Diagram komponentów – uwidacznia zależności pomiędzy fizycznymi elementami oprogramowania – komponentami. • Diagram wdrożenia – odnosi się do statycznej perspektywy końcowego etapu podczas wytwarzania systemu, występują tu węzły oraz komponenty które są ich składnikami.

Diagramy modelowania zachowania • Diagram przypadków użycia – widnieją tu przypadki użycia, aktorzy czerpiący z nich korzyści oraz związki między nimi. • Diagram przebiegu (sekwencji) – przedstawia dynamiczne aspekty tworzonego systemu, jest to rodzaj diagramu przedstawiający interakcję obiektów i związków między nimi skupiający się na kolejności przesyłania komunikatów w czasie. • Diagram kooperacji – wynika z tych samych założeń co diagram przebiegu – interakcji, natomiast tu uwidacznia się organizację strukturalną.

Diagramy modelowania zachowania • Diagram stanów – odnosi się do przedstawienia zmian zachodzących w systemie, modelujemy w nim zachowanie pewnych elementów. • Diagram czynności – ilustruje przepływ sterowania od czynności do czynności, modelujemy tu dynamiczne aspekty tworzonego systemu. • Diagram przebiegów czasowych – połączenie diagramów sekwencji i stanów dla dostarczenia informacji o obiektach w czasie i komunikatach zmieniających te stany

Diagram przypadków użycia • Model przypadków użycia opisuje proponowaną funkcjonalność nowego systemu. Przypadek użycia przedstawia dyskretną jednostkę oddziaływania pomiędzy użytkownikiem (człowiek lub maszyna) a systemem. • Przypadek użycia jest pojedynczą jednostką oznaczającą pracę; na przykład logowanie się do systemu, rejestrowanie się w systemie i utworzenie polecenia są to przypadki użycia. • Każdy przypadek użycia posiada opis, który obejmuje funkcjonalność wbudowywaną do proponowanego systemu.

Opis przypadku użycia. . . będzie zawierał ogólnie: 1. Ogólne uwagi i noty opisujące przypadek użycia; 2. Wymagania – Rzeczy, które przypadek użycia musi umożliwić użytkownikowi do wykonania, takie jak <możliwość zlecenia uaktualniania>, <możliwość polecenia modyfikacji> & etc. 3. Ograniczenia – reguły odnośnie możliwości i niemożliwości wykonania, zawierające: i) pre-warunki, które muszą być spełnione przed uruchomieniem przypadku użycia – np. <polecenie utworzenia> musi poprzedzać <polecenie modyfikacji>; ii) post-warunki, które muszą być spełnione po uruchomieniu przypadku użycia, np. <polecenie jest modyfikowane i spójne>; iii) niezmienność: są one zawsze spełnione – np. polecenie musi zawsze posiadać numer użytkownika.

Opis przypadku użycia. . . będzie zawierał ogólnie: 4. Scenariusze – Sekwencyjne opisy kroków wypełniających przypadek użycia. Mogą zawierać liczne scenariusze, do zaspokojenia potrzeb wyjątkowych okoliczności i różnych ścieżek procesów. 5. Diagramy scenariuszy – diagramy scenariuszy przedstawienia przebiegu pracy – podobne do (4) lecz przedstawione graficznie. 6. Dodatkowe atrybuty takie jak faza implementacji, numer wersji, współczynnik złożoności, stereotyp i status.

Formalna specyfikacja przypadku użycia • Wymagania. Są to formalne wymagania funkcjonalne, które musi dostarczać przypadek użycia do końcowego użytkownika. Odpowiadają one funkcjonalnym specyfikacjom zawartym w strukturalnych metodologiach. Wymaganie jest umową, że przypadek użycia wykona jakąś akcję (aktywność) lub dostarczy systemowi jakąś wartość.

Formalna specyfikacja przypadku użycia c. d. • Ograniczenia. Są one formalnymi regułami i ograniczeniami (limitations), z którymi realizowane są przypadki użycia, i obejmują warunki przed-, po- i niezmiennicze. Warunek „przed” określa (precyzuje) co musi się wpierw wydarzyć lub co musi mieć miejsce przed uruchomieniem przypadku użycia. Warunek „po” dokumentuje co musi być spełnione (true) po wypełnieniu przypadku użycia. Niezmienność wyszczególnia co powinno być spełnione podczas przeprowadzania przypadku użycia.

Formalna specyfikacja przypadku użycia c. d. • Scenariusze są formalnym opisem przebiegu zdarzeń, które mają miejsce podczas realizacji przypadku użycia. Są one zazwyczaj opisane tekstem i odpowiadają tekstowym reprezentacjom diagramu sekwencji.

Definicja przypadku użycia • ciąg akcji wykonywanych przez system, które dostarczają określonemu aktorowi godnego uwagi wyniku, • (wg. OMG) spójny zbiór funkcjonalności dostarczanej przez system reprezentowany jako ciąg komunikatów wymienianych pomiędzy systemem a aktorem.

Relacje pomiędzy przypadkami użycia • <<include>> stosowany w przypadku zawierania się jednego przypadku w drugim, głównie w celu uproszczenia diagramu; • <<extended>> stosowany podczas rozszerzenia przypadku użycia o inny, zwyczajowo gdy bazowy przypadek nie wystarcza; • Symbol uogólnienia, gdzie przypadek dziedziczy wartości i zachowanie przodka , i uzupełnia je o swoje cechy

Przykład modelowania przypadków użycia dla serwisu internetowego

„włączania przypadku użycia” Związki typu „włączanie przypadku użycia” – polegają na włączeniu przebiegu podstawowego jednego z przypadków użycia do przebiegu drugiego, tak jak to pokazano na rysunku. Możemy zobaczyć, że w przebieg podstawowy bazowego przypadku użycia, został niejako wtrącony przebieg innego przypadku użycia.

„rozszerzenie przypadku użycia” Związki typu „rozszerzenie przypadku użycia” – opisują, w jaki sposób przypadek rozszerzający rozszerza ciąg iteracji między systemem i aktorem przypadku bazowego. Ilustruje rysunek, zaczerpnięty z dokumentacji dostarczanej przez Rational-a.

Generalizacja to zależność pokazująca, że przypadek użycia (nazwijmy go potomnym) dziedziczy i uszczegóławia cechy funkcjonalne swojego przodka (przypadku nadrzędnego). Jest tu analogiczne podejście jak przy dziedziczeniu klas w obiektowo zorientowanym projektowaniu systemów informatycznych.

Aktorem może być każdy obiekt, który jakoś komunikuje się z systemem – wymienia z nim komunikaty. Podstawowe typy podmiotów, które podczas modelowania przypadków użycia mogą się przerodzić w aktorów: · użytkownik/udziałowiec systemu – człowiek, organizacja, komórka organizacyjna, itp. · sprzęt komputerowy – wszelakiego rodzaju sprzęt elektroniczny, czujniki, czytniki, komputery, itp. · oprogramowanie – systemy informatyczne, oprogramowanie narzędziowe, sterowniki, serwisy webowe, bazy danych, itp. · zegar (ang. timer) –czas, generowanie czasu, generowanie impulsów zegarowych.

Aktor - dziedziczenie Rzadko się zdarza by system był na tyle mały by podczas jego modelowania użyć jednego aktora. Jest ich wielu i często ich role w systemie są bardzo podobne, pokrywają się i ewentualnie różnią jedną lub kilkoma funkcjami.

Diagram klas • Diagram klas opisuje typy obiektów w systemie i różne rodzaje statycznych relacji między nimi. Klasa zawiera atrybuty i operacje, czyli procesy, które klasa potrafi wykonać. • Asocjacje reprezentują związki pomiędzy instancjami klas. Każda asocjacja ma dwa punkty końcowe. Punkt końcowy posiada krotność, która wskazuje ile obiektów może brać udział w danym związku. Strzałki na kreskach asocjacji wskazują „nawigowalność”, czyli możliwość przejścia z klasy do klasy. • Uogólnienie jest związane z dziedziczeniem w języku programowania. • Elementy klas można eksponować bądź ukrywać.

Dostępność elementów klas • + dostępność publiczna: oznacza, że każda inna klasa może dowolnie wpływać na wartość danego atrybutu • # dostępność chroniona: dany atrybut może być obserwowany tylko przez jego klasę macierzystą lub jej podklasy ępność • - macierzystej mogą odczytywać i modyfikować dany atrybut

Elementy diagramu klas Symbol klasy zawiera cztery odrębne części: • nazwę klasy • atrybuty • operacje oraz • zobowiązania klasy. Interfejs można scharakteryzować jako zestaw operacji, które klasa udostępnia innym klasom, przedstawiany bardzo często symbolem klasy ze stereotypem <<interface>> powiązanie, występuje, gdy między klasami istnieje związek znaczeniowy, np. w przykładzie klasa klient jest powiązana z informacją, na zasadzie wielu klientów czyta wiele informacji;

Elementy diagramu klas – związki dziedziczenie, nazywane również uogólnieniem, dotyczy sytuacji gdy jedna klasa (podklasa) dziedziczy od drugiej klasy (nadklasy) atrybuty; zależność jednej klasy od drugiej w tym znaczeniu, że w sygnaturze jednej klasy używamy drugiej, strzałka wskazuje na klasę niezależną; agregacja oznacza zależność klasy jako części składowej drugiej klasy agregacja całkowita, jako agregacja względem tylko jednej klasy ; usunięcie klasy oznacza usunięcie również klasy agregowanej; realizacja, związek pomiędzy klasą a interfejsem, strzałka wskazuje na interfejs

Przykład 1

Przykład 2

Przykład 3

Przykład 4

Zagnieżdżanie • Zagnieżdżenie jest połączeniem, które pokazuje, że element źródłowy jest zagnieżdżany we wskazywanym – celowym elemencie.

Diagram kompozycji (mieszany) • . . . pokazuje wewnętrzną strukturę klasyfikacji, zawierania się oddziaływań punktów do innych części systemu. Pokazuje konfigurację i relacje części, które ze sobą współpracują dla zachowania zawartej klasyfikacji. • Elementy klas zostają opisane z dużą szczegółowością w poszczególnych sekcjach diagramu klas. Ta część opisuje drogę, która pozwala prezentować klasy jako kompozycja elementów uwidaczniająca interfejsy porty i wydzielone części.

Diagram kompozycji

Diagram kompozycji

Diagram sekwencji (przebiegu) • Diagramy sekwencji: przedstawiają zachowanie systemu dotyczące jednego przypadku użycia. Jest to jeden z dwóch typów diagramów interakcji. • Diagram obrazującym interakcję obiektów z uwypukleniem czasu. To oddziaływanie obiektów obrazuje nam choćby scenariusz danego przypadku użycia. Obiekty umieszczamy na górze, czas jest przedstawiony na linii znajdującej się pod danym obiektem. Czas jego aktywności uwidacznia prostokąt na „jego linii czasu”.

Diagram sekwencji • Komunikaty, które są przesyłane pomiędzy obiektami możemy rozpatrywać na trzy różne sposoby: • proste (przekazanie sterowania od obiektu do obiektu), • synchroniczne (obiekt po wysłaniu komunikatu czeka na odpowiedź), • asynchroniczne (wysłanie komunikatu przez obiekt nie powoduje wstrzymanie jego działań).

Diagram sekwencji c. d. Wyróżniamy podstawowy podział diagramu przebiegu tzn. - diagram przebiegu egzemplarzowy gdzie jest przedstawiony jeden scenariusz danego przypadku użycia oraz - diagram przebiegu ogólny gdzie rozpatrujemy możliwe scenariusze.

Diagramy sekwencji - oznaczenia

Diagramy sekwencji - oznaczenia Symbol Znaczenie komunikat prosty, który może być synchroniczny lub asynchroniczny komunikat prosty powrotu „return” (optionalne) komunikat synchroniczny komunikat asynchroniczny

Diagram sekwencji c. d. • Możliwe jest tworzenie i usuwanie obiektów w trakcie działania programu i diagram ten jest w stanie zrealizować tą potrzebę wizerunku. • Tworzony obiekt przedstawiamy zwyczajnie w postaci prostokąta zawierającego jego nazwę, umieszczając go niżej od już istniejących. Komunikat „Create” tworzy obiekt natomiast „destroy” usuwa obiekt.

Diagram sekwencji c. d. Dopuszczalne jest przedstawienie • rozgałęzienia if (warunek jeżeli jest przedstawiony w nawiasach kwadratowych) oraz • pętli while (warunek dopóki przedstawiony w nawiasach prostokątnych z gwiazdką po lewej stronie). • Rekurencja również jest rozwiązywalną konstrukcją. Przedstawiamy jako strzałkę wychodzącą i wchodzącą do miejsca aktywacji obiektu. • Możliwe jest również umieszczanie na tej linii czasu, stanów znanych z diagramów stanów poszczególnych obiektów.

Przykład 1

Przykład 2

Diagram sekwencji – inny obraz

Diagramy współdziałania (kooperacji) • Diagram obrazuje dynamiczne aspekty systemu. Jest rozszerzeniem diagramu obiektów, gdzie oprócz obiektów i występujących powiązań przedstawia się również komunikaty pomiędzy tymi obiektami. • Diagram kooperacji przedstawia działania w przestrzeni – czyli komunikujące się w odpowiedniej kolejności obiekty bez wyszczególnionego czasu jak to było w diagramie przebiegu. • Strzałka symbolizująca komunikat jest opatrzona w nazwę oraz numer porządkowy kolejności komunikatów, który umożliwia dodatkowo uchwycenie zagnieżdżonych komunikatów.

Diagram współdziałania • Występują w nim warunki umieszczone w nawiasach prostokątnych oraz nawiasy z dodatkową gwiazdką pętle - while. • Możliwe jest również pokazanie zmian stanów obiektów, w tym celu umieszcza się ten sam obiekt w dwóch stanach połączonych przerywaną linią stereotypowaną jako <>. • Często również korzysta się ze stereotypu <> który, przedstawia komunikat przyczyniający się do powstania obiektu.

Diagram współdziałania • Konieczne czasami bywa zaprezentować obiekty wielokrotne gdzie jeden z obiektów inicjujących przesyła komunikat do wielu obiektów jednej klasy, które czasami należy obsługiwać w odpowiedniej kolejności – i to również się tu obrazuje zapisem „ 1. . n”. • W następstwie wysłania komunikatu może być zwrócenie wyniku – przedstawia się zapisem „nazwa wartości do zwrócenia : = operacja która ma być wykonana (w nawiasie argumenty wyliczeń)”. • Diagram kooperacji zawiera taki sam symbol obiektu, komunikatów oraz dodatkowo: obiekt zmieniający stan, symbol aktywny, obiekt wielokrotny.

Diagram współdziałania - przykład

Diagram obiektów . . . jest obrazem obiektów w systemie w określonej chwili; przydatny, gdy możliwe powiązania pomiędzy obiektami są skomplikowane.

Diagram stanów • . . . są techniką opisu zachowania systemu. • Opisują wszystkie możliwe stany, do których może przejść dany obiekt, a także to, jak zmienia się stan obiektu pod wpływem docierających do niego zdarzeń. • Najczęściej są rysowane dla pojedynczych klas, aby pokazać cały cykl życia obiektu. • Każdy diagram ma początek i pierwsze przejście. Przejścia, zwane akcjami, oznacza się etykietami „zdarzenie [warunek] / akcja”. • Stan nazywa się zdarzeniem. • Akcje są związane z przejściami i traktuje się je jako procesy atomowe, szybkie i nie przerwane. • Czynności są związane ze stanami i mogą trwać dłużej. Czynność może zostać przerwana przez jakieś zdarzenie.

Diagram stanów • Podobnie do diagramu czynności, diagram ten czasami ma przypisywaną nazwę maszyny stanowej ale w tym innym znaczeniu, że tu uwypukla się stany obiektów a tam przepływ sterowania. • Przedstawia poszczególne stany i przejścia danego obiektu. Istotną różnicą jest również fakt że diagram ten skupia swoją uwagę na stanach jednego elementu - obiektu, a nie jak to było w przypadku wcześniejszych diagramów (np. diagramów klas) gdzie przedstawialiśmy grupę elementów. • Symbol stanu zawiera standardowo nazwę (w przykładzie dwa stany podczas tworzenia komentarza), zmienne ( np. autor komentarza może być zmienną), oraz czynności (często spotykane: entry – określa co się dzieje przy wejściu do stanu, exit – określa co się dzieje przy wyjściu ze stanu, do – co się dzieje w danym stanie).

Diagram stanów – symbole

Diagram stanów – przykład

Diagram stanów – przykład

Diagram czynności . . . opisuje jak uszeregowane są działania oraz daje możliwość opisu czynności warunkowych lub współbieżnych - odmiana diagramu stanów. • Czynność jest rozumiana jako stan działania lub działalności, wykonywanie pewnego rzeczywistego procesu. • Proces warunkowy jest określony za pomocą rozgałęzienia i scalenia.

Diagram czynności • Rozgałęzienie ma jedno wejście i kilka warunkowych wyjść. • Scalenie ma kilka wejść i jedno wyjście. Scalenie oznacza koniec procesów warunkowych rozpoczętych rozgałęzieniem. • Procesy współbieżne są realizowane za pomocą rozwidleń i złączeń. Rozwidlenie ma jedno wejście i kilka wyjść. Kiedy odpalane jest wejście, równocześnie odpalane są wszystkie wyjścia. • Złączenie ma wiele wejść i jedno wyjście – kończy rozwidlenie.

Diagram czynności – przykład

Diagram czynności – przykład

Diagram czynności – podział wg obiektów

Ogólny diagram czynności

Diagramy pakietów. . . są stosowane do podziału modelu na logiczne części lub ‘pakiety’ i opisują oddziaływanie pomiędzy nimi na wysokim poziomie opisu. • Odzwierciedlają organizację pakietów i rozkład ich elementów

Diagram komponentów • . . . pokazuje różne składowe systemu i ich powiązania. • Komponent reprezentuje jeden fizyczny moduł kodu systemu. Często komponent to jeden pakiet. • Zależności istniejące pomiędzy komponentami pokazują, jak zmiany dotyczące jednej części wpływają na pozostałe. • Na diagramach komponentów można przedstawiać zależności wszelkiego rodzaju, w tym kompilacyjne i komunikacyjne.

Interfejsy

Przykład komponentów serwera

Komponenty zabezpieczeń

Diagram wdrożenia • . . . przedstawia fizyczne powiązania pomiędzy składowymi programistycznymi i sprzętowymi w dostarczanym systemie. • Każdy węzeł na diagramie przestawia pewien rodzaj jednostki obliczeniowej, najczęściej element sprzętowy. • Połączenia pomiędzy węzłami wskazują ścieżki komunikacji, które będą służyły elementom systemu do interakcji.

Diagram wdrożenia Węzeł fizyczny Połączenie

Diagram wdrożenia

Komponenty i węzły

Diagram przebiegów czasowych. . . diagramy są używane do prezentowania zmian stanów lub wartości jednego lub kilku elementów w czasie. Może to być oddziaływanie pomiędzy zdarzeniami w czasie a czasem i trwaniem warunków (ograniczeń), które tym rządzą Linia przebiegu stanów. . . pokazuje zmianę stanu pozycji w czasie. Linia X prezentuje upływający czas w dowolnych jednostkach, podczas gdy linia Y jest etykietowana zadaną listą wartości.

Diagram przebiegów czasowych Linia przebiegu wartości. . . przedstawia zmianę wartości pozycji w czasie. Linia X – zmiana w czasie wyrażona w dowolnej jednostce. Wartość jest prezentowana pomiędzy parą linii poziomych przecinających się przy każdej zmianie wartości.

Diagram przebiegów czasowych