Download
1 / 81
810 likes | 1.08k Views
UML Zunifikowany język modelowania. Dariusz Badura. 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.
E N D
UML Zunifikowany język modelowania Dariusz Badura
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.
UMLdefiniuje ... 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ść 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 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. 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 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.
Aktor 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 • - dostępność prywatna: tylko metody klasy 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
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 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.
Symbol Znaczenie komunikat prosty, który może być synchroniczny lub asynchroniczny komunikat prosty powrotu„return” (optionalne) komunikat synchroniczny komunikat asynchroniczny Diagramy sekwencji - oznaczenia
Diagram sekwencji c.d. • Możliwe jesttworzenie 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.
