Unified Modeling Language (UML)

Transkrypt

1 .. Unified Modeling Language (UML) Diagramy behawioralne Arkadiusz Chrobot Zakład Informatyki, Politechnika Świętokrzyska w Kielcach Kielce, 15 listopada 2017 Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

2 Plan wykładu.1 Motto.2 Wstęp.3 Diagram przypadków użycia.4 Diagram aktywności.5 Diagram stanu.6 Dodatkowe źródła informacji Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

3 Motto Motto «Diagrams are a good thing, but I feel that UML is too low-level; my boxes tend to be entire modules like UserManager. Until you code, you don t really know what is going to make sense.» Terence Parr Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

4 Wstęp Wstęp Na poprzednim wykładzie zostały przedstawione diagramy uml należące do grupy strukturalnych. Ten wykład będzie poświęcony diagramom behawioralnym, a dokładniej trzem diagramom z tej grupy: diagramowi przypadków użycia, aktywności oraz stanu. Pozostałe diagramy behawioralne (sekwencji, komunikacji, przebiegów czasowych i widoku interakcji) tworzą osobną grupę nazywaną diagramami interakcji i będą one omówione oraz opisane na następnym wykładzie. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

5 Diagram przypadków użycia Diagramy przypadków użycia Diagram przypadków użycia (ang. use case diagram) pozwala dokumentować wymagania funkcjonalne względem systemu, w związku z tym jest stosowany w procesie inżynierii wymagań. Wymagania funkcjonalne, to takie, które definiują usługi dostarczane przez system, w przeciwieństwie do wymagań niefunkcjonalnych, które określają ograniczenia, jakim te usługi podlegają (np. niezawodność, bezpieczeństwo). Diagram przypadków użycia przedstawia wymagania funkcjonalne dla budowanego oprogramowania, oraz jego otoczenie. Pozwala on zatem przedstawić usługi i własności systemu, jakie są widoczne na zewnątrz. Jest to bardzo wysokopoziomowa perspektywa, niezawierająca informacji, o sposobie realizacji funkcji systemu, tj. jego budowie i zachowaniu. Diagramy przypadków użycia służą jako środek komunikacji między uczestnikami systemu, a jego projektantami, oraz pozwalają śledzić postęp prac projektowych. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

6 Diagram przypadków użycia Diagramy przypadków użycia Granica systemu - notacja Multimedia System Multimedia System. Granica systemu (ang. system boundary) jest jednym z elementów diagramu przypadków użycia. Pozwala ona na oddzielenie na diagramie elementów będących częścią systemu od tych, które należą do jego otoczenia. Te ostatnie są rysowane na zewnątrz granicy systemu, a te pierwsze w jej wnętrzu. W górnej części granicy umieszcza się nazwę modelowanego systemu. Jeśli jest to podsystem, to ta nazwa może dodatkowo być opatrzona stereotypem <<subsystem>>. System w nomenklaturze uml określany jest także jako podmiot (ang. subject). Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

7 Diagram przypadków użycia Diagramy przypadków użycia Aktor - notacja... Movies Provider System Aktor (ang. actor) jest elementem diagramu przypadków użycia, który należy do otoczenia budowanego systemu. Reprezentuje on rolę lub zbiór ról jakie pełni w stosunku do tego oprogramowania. Aktor może być człowiekiem urządzeniem lub innym systemem. Wymogi formalne języka uml nakazują, aby każdy aktor był połączony relacją z co najmniej jednym przypadkiem użycia. Każdy aktor musi także posiadać identyfikator (nazwę), umieszczany poniżej ikony, która go symbolizuje. Aktorzy mogą wymieniać dane z systemem, dostarczać mu informacji lub być biernym odbiorcą danych z systemu. We wcześniejszych wersjach uml aktor był reprezentowany przez taką samą notację jak, klasa, ale ze stereotypem <<actor>> nad nazwą. Notacja ta może być używana również w najnowszych wersjach uml. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

8 Diagram przypadków użycia Diagramy przypadków użycia Aktor - odkrywanie Diagramy przypadków użycia stosowane są już na etapie odkrywania wymagań dla systemu. Jednym z elementów tego procesu jest zatem identyfikacja aktorów korzystających z systemu. Aby ustalić kto lub co jest aktorem należy odpowiedzieć na następujące pytania:.1 Jaka grupa użytkowników wymaga wspomagania ze strony systemu?.2 Jacy użytkownicy są niezbędni do działania systemu?.3 Z jakim sprzętem i innymi systemami musi współpracować system? Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

9 Diagram przypadków użycia Diagramy przypadków użycia Aktor - weryfikacja Po odkryciu aktorów należy poddać weryfikacji zasadność i poprawność ich określenia. W szczególności należy sprawdzić czy:.1 aktor określa rolę, czy konkretną osobę (powinien to pierwsze),.2 aktor ma odpowiednią nazwę, która jednoznacznie go opisuje,.3 relacje między aktorami, a konkretnymi użytkownikami są prawidłowo zdefiniowanie,.4 użytkownik może pełnić rolę więcej niż jednego aktora,.5 czy aktor ma prawidłowo przyporządkowane funkcje i zadania związane z dziedziną zastosowania systemu oraz jego działaniem? Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

10 Diagram przypadków użycia Diagramy przypadków użycia Przypadek użycia - notacja. Choose movie Przypadek użycia (ang. use case), oznaczany na diagramach zobrazowaną na ilustracji elipsą, symbolizuje pojedynczą usługę dostarczaną przez system, która jest rozumiana jako pojedyncza jednostka użytecznej pracy wykonanej przez oprogramowanie. Przypadek użycia, to także zbiór scenariuszy związanych z realizacją tej usługi oraz graficzna reprezentacja wymagań funkcjonalnych. Przypadki użycia są niekiedy nazywane także klasami interakcji, bowiem wymaganiem formalnym języka uml jest to, aby każdy przpadek użycia na diagramie był połączony relacją co najmniej z jedynm aktorem lub innym przypadkiem użycia. Atrybuty definiujące przypadek użycia to: identyfikator (nazwa) - zazwyczaj zawiera czasownik, opis, przepływ zdarzeń (scenariusze), zależności i relacje, diagramy aktywności, wymagania specjalne, warunki wstępne i warunki końcowe. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

11 Diagram przypadków użycia Diagramy przypadków użycia Przypadek użycia - scenariusze Związane z przypadkiem użycia scenariusze definiują zestaw czynności, jakie należy wykonać, aby zrealizować funkcjonalność opisaną przez dany przypadek. Można je dokumentować przy pomocy diagramów aktywności lub sekwencji. Scenariusze powiązane z przypadkiem użycia opisują zarówno domyślny przebieg czynności, który reprezentuje podstawowy i spodziewany przebieg zdarzeń, a także spodziewany wynik, który zostanie dostarczony użytkownikowi, ale również alternatywne możliwości zakończenia scenariusza, dodatkowe przypadki, czy przebieg zdarzeń związany z obsługą wyjątków. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

12 Diagram przypadków użycia Diagramy przypadków użycia Przypadek użycia - tworzenie Tworząc przypadki użycia należy wziąć pod uwagę:.1 strategiczne cele systemu, czyli to czemu budowane oprogramowania ma służyć,.2 potrzeby użytkownika (np. przypadek użycia logowanie do systemu jest błędny, bo nie wynika z zapotrzebowania użytkownika),.3 przypadki konstrukcyjne, czyli związane z wymaganiami zespołu wytwórczego. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

13 Diagram przypadków użycia Diagramy przypadków użycia Relacje - asocjacja... Choose movie User Relacją, która wiąże aktora z przypadkiem użycia jest asocjacja. Należy pamiętać, że każdy aktor powinien być powiązany co najmniej z jednym przypadkiem użycia, jeśli tak nie jest, to może to oznaczać, że aktor jest zbędny, lub nie odkryto jeszcze wszystkich przypadków użycia związanych z budowanym systemem. Asocjacja łącząca aktora i przypadek użycia może być skierowana w stronę tego ostatniego, żeby zaznaczyć, że to aktor inicjuje definiowaną przez przypadek usługę i że aktor zna przypadek, natomiast przypadek użycia na posiada wiedzy na temat aktora. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

14 Diagram przypadków użycia Diagramy przypadków użycia Relacje - generalizacja. User... Premium User Relacje generalizacji (uogólnienia) mogą zachodzić zarówno między aktorami, jak i między przypadkami użycia. Symbolizowane są one tak jak na diagramach np. klas, czyli za pomocą strzałki zakończonej pustym, trójkątnym grotem. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

15 Diagram przypadków użycia Diagramy przypadków użycia Relacje - generalizacja Pay Pay with Credit. Card Podobnie jak w przypadku diagramów klas lub pakietów, oznaczają one że elementy bardziej ogólne (te, w których stronę skierowana jest strzałka) mogą być zastępowane przez elementy bardziej szczegółowe. Należy uważnie rozróżnić relację generalizacji, od relacji rozszerzania. Ta pierwsza stosowana jest wtedy, gdy elementy nią powiązane wykazują podobieństwo do siebie. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

16 Diagram przypadków użycia Diagramy przypadków użycia Relacje - zawieranie Watch movie Listen to. music include include Pay Relacja zawierania jest oznaczona jako ukierunkowana zależność ze stereotypem <<include>> i zachodzi między przypadkami użycia. Oznacza ona, że przypadek użycia, od którego jest ona skierowana jest wykonywany zawsze wtedy, gdy wykonywany jest przypadek użycia, do którego jest ona skierowana. Innymi słowy pierwszy przypadek użycia jest częścią drugiego. Zawieranie stosowane jest wtedy, gdy pojedynczy przypadek użycia występuje w więcej niż jednym innym przypadku użycia. Celem uproszczenia ich realizacji jest on zatem wyłączany na zewnątrz, tak jak w matematyce wyłącza się przed nawias wspólna część wyrażenia lub w programowaniu część wspólną kodu zawiera w podprogramie. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

17 Diagram przypadków użycia Diagramy przypadków użycia Relacje - rozszerzanie Watch. movie extend Authenticate Relacja rozszerzenia oznaczana jest na diagramie jako ukierunkowana zależność ze stereotypem <<extend>> i oznacza ona, że przy spełnieniu pewnych warunków przypadek użycia, od którego jest skierowana rozszerza przypadek użycia, do którego jest skierowana. Warunek rozszerzenia może być opisany za pomocą notatki. Na przykładzie przedstawiono przypadek użycia Oglądaj Film, który jest rozszerzany przez przypadek Uwierzytelnij. Oznacza to, że ten ostatni przypadek będzie wykonany wraz z pierwszym, kiedy spełniony będzie określony warunek, np. należy sprawdzić, czy użytkownik może obejrzeć film należący do określonej kategorii wiekowej. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

18 Diagram przypadków użycia Diagramy przypadków użycia Przykład - system multimedialny (fragment) Multimedia System Multimedia System. User Watch movie Listen to music Store data Movies Provider System.... Premium User Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

19 Diagram przypadków użycia Diagramy przypadków użycia Przykład - system multimedialny (fragment) Poprzedni slajd zawiera przykładowy diagram ilustrujący fragment funkcjonalności systemu umożliwiającemu użytkownikowi korzystanie z materiałów multimedialnych. Stosują takie diagramy należy pamiętać, że nie mogą one narzucać sposobu implementacji systemu, tj. nie mogą określać w jakiej kolejności przypadki użycia będą wykonywane (ich wykonanie musi być niezależne od siebie) oraz nie mogą definiować struktury systemu. Na takich diagramach nie umieszcza się także informacji o wymaganiach niefunkcjonalnych, dlatego też nie zaleca stosowania się i najczęściej nie stosuje się krotności w zaznaczonych relacjach. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

20 Diagram aktywności Diagram aktywności Diagramy aktywności (ang. activity diagram), nazywane także diagramami czynności są uogólnieniem wcześniej używanych w informatyce schematów blokowych. Obrazują one sekwencję czynności wykonywanych przez modelowany fragment systemu. Najczęściej zawierają informację na temat przepływu sterowania (ang. control flow), ale również można w nich zilustrować przepływ danych (ang. data flow) w postaci obiektów 1 oraz które czynności mogą być wykonane współbieżnie. 1 Innymi słowy pokazać, jak obiekt zmienia stan, w trakcie wykonywania przez system określonych czynności. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

21 Diagram aktywności Diagram aktywności Aktywność - notacja. Aktywność jest wysokopoziomowym elementem diagramu aktywności i najczęściej zawiera w sobie inne elementy takiego diagramu. Raz zdefiniowana może być użyta wielokrotnie podczas tworzenia innych diagramów. Aktywność powinna posiadać identyfikator, który jest zapisywany w górnej, środkowej części jej notacji. Elementy, które na przykładowym diagramie widoczne są jako wypustki symbolizują aktywności, które ją poprzedzają lub po niej następują. Zwykle wymieniane są ich nazwy. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

22 Diagram aktywności Diagram aktywności Akcja - notacja Send notification. Czynność lub inaczej akcja (ang. action) jest najmniejszą jednostką pracy wykonywaną przez modelowane oprogramowania, która nie podlega dekompozycji (nie można jej podzielić na mniejsze czynności). Konsekwencją jej wykonania jest zmiana stanu systemu lub zwrócenie wyniku. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

23 Diagram aktywności Diagram aktywności Akcja - notacja <<localprecondition>> Event was received Event was received Send notification A <<localpostcondition>> <<localpostcondition>> Event. notification Event notification has been sent has been sent Wykonanie akcji może być uwarunkowane. Warunek, który musi być spełniony przed wykonaniem akcji może być opisany notatką, w której górnej części umieszczony jest stereotyp <<localprecondition>>. Warunek, który musi być spełniony po wykonaniu czynności może być opisany podobną notatką, ale ze stereotypem <<localpostcondition>>. Te warunki są asercjami. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

24 Diagram aktywności Diagram aktywności Węzły - notacja. Diagram na slajdzie przedstawia notacje używane do oznaczania węzłów, czyli elementów diagramu mających szczególne znaczenie. Pierwszy od lewej element, to węzeł początkowy oznaczający punkt początkowy, od którego rozpoczyna się aktywność. Na diagramie może występować tylko jeden taki węzeł. Element środkowy to węzeł wyjściowy (ang. flow final node), który oznacza zakończenie pojedynczego przepływu sterowania, np. na skutek wystąpienia jakiegoś wyjątku. Element z prawej strony, to węzeł końcowy (ang. activity final node), który oznacza zakończenie czynności, a więc jej wszystkich przepływów sterowania. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

25 Diagram aktywności Diagram aktywności Węzeł decyzyjny/połączenia - notacja. Węzeł decyzyjny, to węzeł, który oznacza że istnieje kilka możliwości dalszego wykonania czynności. Taki węzeł posiada jedno wejście dla przepływu sterowania i co najmniej dwa wyjścia. Każde wyjście jest opatrzone wyrażeniem logiczny, które nazywane jest warunkiem dozoru (ang. guard condition) i zapisywane jest w nawiasach kwadratowych. Jeśli to wyrażenie jest skomplikowane i dotyczy każdego wyjścia, to można na diagramie umieścić notatkę złączoną z węzłem decyzyjnym i zawierającą stereotyp <<decisioninput>>, które będzie zawierało taki warunek. Należy zadbać o to, aby zawsze istniała możliwość opuszczenia węzła decyzyjnego. Język uml przewiduje w tym celu możliwość zastosowania wyjścia oznaczonego warunkiem [else]. Węzeł połączenia, to węzeł w który scalanych jest kilka (co najmniej dwa) przepływów sterowania i z którego wychodzi pojedynczy przepływ. Oba węzły są przedstawiane na diagramie za pomocą notacji widocznej na slajdzie. Oba te węzły nie są także punktami synchronizacji. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

26 Diagram aktywności Diagram aktywności Węzeł rozwidlenia/scalenia - notacja. Węzły rozwidlenia i scalenia przedstawiane są na diagramie aktywności w ten sam sposób - za pomocą grubej zakończonej wyobleniami kreski, która może być narysowana zarówno pionowo, jak i poziomo. Węzeł rozwidlenia (ang. fork node) używany jest do oznaczenia czynności, które mogą być wykonane współbieżnie. Od tego węzła wychodzą co najmniej dwa osobne przepływy sterowania. Węzeł rozwidlenia nie jest punktem synchronizacji. Takim punktem jest za to węzeł scalenia (ang. join node). Taki węzeł służy do łączenia współbieżnych przepływów w jeden przepływ. Zasadami współbieżności w języku uml począwszy do wersji 2.0 rządzą te same prawa, co w przypadku sieci Petriego, tzn. liczba przepływów łączonych musi być równa liczbie przepływów opuszczających odpowiadający węzłowi scalenia węzeł rozwidlający. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

27 Diagram aktywności Diagram aktywności Przepływ sterowania/danych - notacja. Przepływ sterownia lub przepływ danych jest oznaczany na diagramie aktywności za pomocą strzałki skierowanej w kierunku czynności, która ma być wykonana jako następna, lub w kierunku obiektu, którego stan powinien się zmienić w wyniku wykonania czynności. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

28 Diagram aktywności Diagram aktywności Przepływ obiektów Send message. Message Receive message Przepływ obiektów jest ścieżką w diagramie aktywności, wzdłuż której przekazywane są dane (obiekty). W wersjach języka uml wcześniejszych niż 2.0 oznaczenie na diagramie takiego przepływu wymagało umieszczenia elementu reprezentującego obiekt zgodnie z notacją używaną na diagramie obiektów. Taki zapis jest używany również w nowszych wersjach języka. Specjalnym przypadkiem obiektu, jest obiekt oznaczony stereotypem <<datastore>>, który reprezentuje trwały magazyn danych. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

29 Diagram aktywności Diagram aktywności Przepływ obiektów - piny. Send message Receive message Począwszy od wersji 2.0 uml możliwe jest oznaczanie przepływu obiektu między akcjami za pomocą pinów, które symbolizują parametry wejściowe i wyjściowe dla czynności. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

30 Diagram aktywności Diagram aktywności Partycja aktywności - notacja Vision System. Partycja aktywności jest elementem diagramu aktywności, który pozwala na pogrupowanie czynności, które mają wspólną charakterystykę, np. są związane z jakąś funkcją systemu, częścią systemu lub aktorem. Może ona być rysowana zarówno pionowo, jaki i poziomo i obejmuje swoim zakresem fragment diagramu, którego dotyczy. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

31 Diagram aktywności Diagram aktywności Region rozszerzenia - notacja iterative. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

32 Diagram aktywności Diagram aktywności Region rozszerzenia Regiony rozszerzenia (ang. expansion region) są strukturalnymi fragmentami aktywności, które są wykonywane wielokrotnie. Widoczne na diagramie trzy kwadraty symbolizują węzły wejściowe lub wyjściowe dla regionu i oznaczają wybór kilku możliwych parametrów. Wewnątrz diagramu regionu, w jego górnym lewym rogu umieszczane jest słowo kluczowe określające charakter wykonania tego regionu. Może to być słowo iterative dla wykonania w pętli (iteracyjnego), parallel dla wykonania współbieżnego i stream dla wykonania sekwencyjnego (strumieniowego). Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

33 Diagram aktywności Diagram aktywności Wyjątek - notacja. Open file Handle I/O exception Wystąpienie wyjątku i procedura jego obsługi mogą być przedstawione na diagramie aktywności tak, jak zostało to zilustrowane na slajdzie. Procedura jest zobrazowana przez wyoblony prostokąt z widocznym punktem wejściowym, a przepływ sterowania związany z wyjątkiem jest zaznaczony zygzakowatą strzałką. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

34 Diagram aktywności Diagram aktywności Region przerwania - notacja Cancel Cancel operation B Withdraw A money Finish operation C. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

35 Diagram aktywności Diagram aktywności Region przerwania Region przerwania (ang. Interruptible activity region), to obszar otaczający czynności w diagramie aktywności, których wykonanie może zostać przerwane. Na umieszczonym na poprzednim slajdzie diagramie czynność wypłaty pieniędzy z bankomatu może być przerwana w wyniku naciśnięcia klawisza Cancel, który jest źródłem przerwania. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

36 Diagram aktywności Diagram aktywności Przykład [Existing user] [Unregistered user] Get user data Display welcoming page Register user Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

37 Diagram aktywności Diagram aktywności Przykład Widoczny na poprzednim slajdzie przykład jest prostym diagramem aktywności. Użyto w nim pojedynczego węzła decyzyjnego oraz połączenia. Proszę zwrócić uwagę na to, że warunki dozoru wyczerpują wszystkie przypadki dla tego węzła decyzyjnego. Użytkownik może lub nie może być zarejestrowany w systemie, innych możliwości nie ma. Zatem nie istnieje także potrzeba używania warunku [else]. Na diagramie użyto także węzła rozwidlającego i węzła scalającego. Zarówno pobranie danych o zgłaszającym się do systemu użytkowniku, jak i wyświetlenie strony powitalnej mogą być wykonane współbieżnie, ale dalsze czynności powinny być wykonywane dopiero po zakończeniu tych dwóch akcji. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

38 Diagram stanu Diagram stanu Diagram stanu nazywany również diagramem maszyny stanowej (ang. state machine diagram) obrazuje zmiany stanu pojedynczego obiektu w odpowiedzi na pojawiające się w jego otoczeniu wydarzenia. Innymi słowy taki diagram modeluje zachowanie takiego obiektu. Składa się on elementów nazywanych stanami, między którymi poprowadzone są przejścia. Razem te elementy tworzą maszynę stanową, która jest uogólnieniem koncepcji automatów skończonych, znanych z informatyki teoretycznej. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

39 Diagram stanu Diagram stanu Stan - notacja Alarm. Podstawowym elementem diagramu stanu jest stan, który oznaczany jest wyoblonym prostokątem z nazwą tego stanu zapisaną w środku. Stan jest niezmienną (ang. invariant) sytuacją, w której obiekt może się znaleźć podczas całego swojego cyklu życia, jeśli zostaną spełnione odpowiednie ku temu warunki. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

40 Diagram stanu Diagram stanu Przejście - notacja Opened gate. Close signal [Gateway is empty]/closed Closed gate Przejście (ang. transition) obrazowane jest na diagramach stanu przy pomocy strzałki z opcjonalnym dodatkowym opisem. Oznacza ono, że obiekt pod wpływem zdarzenia przejdzie ze stanu w którym bieżąco się znajduje do kolejnego stanu. W szczególności stanem bieżącym jest stan znajdujący się na początku strzałki, a stanem następnym ten znajdujący się na jej końcu. Przejście może być opisane według następującego wzorca: wyzwalacz [dozór]/efekt Każdy element tego opisu jest opcjonalny; wyzwalacz oznacza zdarzenie, spowodowane przez inny obiekt, upływ czasu lub mechanizm wewnętrzny pod wpływem którego przejście jest wykonywane, dozór to wyrażenie logiczne, którego wartość musi być prawdą, aby przejście nastąpiło, a efekt to rezultat przejścia (proszę porównać z automatem Mealy ego). Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

41 Diagram stanu Diagram stanu Akcje - notacja Change password entry/ask for a new password do/check the new password. Stan może posiadać akcje (proszę porównać z budową automatu Moora), które mogą być wykonane po przejściu do niego (entry), wyjściu z niego (exit), w trakcie jego trwania (do), lub w sytuacji pojawienia się określonych zdarzeń (np. on click). Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

42 Diagram stanu Diagram stanu Stany złożone - notacja Setting clock Setting hours. set hours Setting minutes set minutes set hours set seconds set minutes set seconds Setting seconds Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

43 Diagram stanu Diagram stanu Stany złożone Poprzedni slajd zawiera diagram stanu złożonego lub po prostu maszyny stanowej. Taki stan jest zbudowany z innych stanów, między którymi zachodzą przejścia. Tak zdefiniowana maszyna może być użyta na innym diagramie jako jego część lub jako osobny diagram. W tym drugim przypadku użycie takiej maszyny zaznacza się jako stan przedstawiony tak jak zwykły stan, ale z nazwą maszyny i z symbolem nieskończoności umieszczonym w dolnym prawym rogu. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

44 Diagram stanu Diagram stanu Pseudo stany - notacja... Język uml definiuje dla diagramu stanu tak zwane pseudo stany. Ich określenie związane jest z tym, że nie posiadają one wszystkich cech właściwych stanom i są nietrwałe. Pseudo stany używane są do zapewnienia połączeń między stanami i przejścia z nimi związane są zawsze bezwarunkowe. Pseudo stan zaprezentowany na slajdzie jako pierwszy od lewej, to stan początkowy oznaczający inicjację działania maszyny. Drugi pseudo stan, to stan końcowy oznaczający normalne zakończenie działania maszyny. Z tego stanu nie można przejść do następnego. Następny to pseudo stan wyboru, który posiada jedno przejście wchodzące i co najmniej dwa wychodzące. Każde z tych jego wyjść jest opisane warunkiem dozorującym, który jest wzajemnie wykluczający z pozostałymi. Podobnie jak na diagramie aktywności jedno z przejść może być opisane warunkiem dozorującym [else]. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

45 Diagram stanu Diagram stanu Pseudo stany - notacja Kolejny pseudo stan to punkt wejścia. Oznacza on miejsce wejścia przepływu z innej maszyny i jest używany jeśli istnieje wiele takich przepływów, lub kiedy maszyna jest zdefiniowana na innym diagramie, albo traktowana jako czarna skrzynka. W tym ostatnim przypadku taki punkt jest umieszczany na brzegu notacji stanu. Następnym z przedstawionych na poprzednim slajdzie pseudo stanów jest punkt wyjścia. Oznacza on przejście lub przejścia, które wychodzą na zewnątrz maszyny stanowej. Podobnie jak w przypadku punktu wejścia może być wiele punktów wyjścia z pojedynczej maszyny lub pojedynczy taki punkt może być umieszczony na brzegu maszyny, która jest modelowana na diagramie za pomocą pojedynczego stanu. Po punkcie wyjścia na poprzednim slajdzie znajduje się pseudo stan przerwania (ang. terminate) działania maszyny stanowej, na skutek np. pojawienia się wyjątku. Dwa ostatnie pseudo stany są nazywane stanami wznowienia (ang. history state) i związane są z zapamiętaniem stanu maszyny po jej opuszczeniu przez sterowanie. W przypadku powrotu do maszyny sterowania jej działanie zaczyna się od tego zapamiętanego stanu. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

46 Diagram stanu Diagram stanu Pseudo stany - notacja Różnica między dwoma stanami wznowienia polega na tym, że pierwszy z nich (bez kropki w środku) jest tak zwany płytki stanem wznowienia (ang. shallow history), czyli pozwala zapamiętać tylko ogólny stan maszyny, natomiast dugi (z kropką) jest głębokim stanem wznowienia (ang. deep history) i pozwala zapamiętać także stan maszyn składowych opuszczanej maszyny. Oprócz tych pseudo stanów używany jest także na diagramie stanów pseudo stan skrzyżowania (ang. junction), który pozwala złączyć wiele przejść. Do takiego skrzyżowania może wchodzić wiele (co najmniej jedno) przejść i również wiele wychodzić (co najmniej jedno). Każde z nich może posiadać swój warunek dozorujący. Taki pseudo stan nie przekłada się jednak an implementację, warunki związane z jego przejściami mają naturę statyczną, a nie dynamiczną. Na diagramie pseudo stan skrzyżowania oznaczany jest taką kropką jak pseudo stan początkowy, ale trochę mniejszą. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

47 Diagram stanu Diagram stanu Regiony współbieżne Na diagramach stanów można używać pseudo stanów rozwidlenia i scalenia, które pełnią taką samą rolę, jak węzły rozwidlenia i scalenia na diagramach aktywności. Jeśli te pseudo stany znajdują się na zewnątrz stanu złożonego (maszyny stanowej), to wychodzące z pseudo stanu rozwidlenia przepływy mogą podzielić ten stan na pod stany (ang. sub-states), które istnieją i są wykonywane współbieżnie, czyli na osobne regiony współbieżne. Granice między tymi regionami zaznacza się na diagramie za pomocą kreskowanej linii składającej się z naprzemiennie umieszczonych długich i krótkich kresek. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

48 Diagram stanu Diagram stanu Przykład - system alarmowy Alarm Set alarm. Enter PIN [Incorrect PIN] Enter PIN [Correct PIN] Trigger alarm On Disarmed Switch on Armed Enter PIN [Correct PIN] Off power outage Power off. power restore Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

49 Diagram stanu Diagram stanu Przykład - system alarmowy Na poprzednim slajdzie znajduje się diagram stanu opisujący zachowanie obiektu realizującego alarm przeciwwłamaniowy. Posiada on trzy stany, w których system alarmowy jest nieuzbrojony, uzbrojony oraz wyzwolony. Wykorzystano na nim również pseudo stan wznowienia. Zastosowana wariant płytkiego wznowienia, z uwagi na to, że wszystkie stany składowe są prostymi stanami. Ten pseudo stan jest używany wówczas, kiedy nastąpi awaria zasilania i oznacza, że system alarmowy powinien wrócić do stanu sprzed jego zaniku. Proszę również zwrócić uwagę na przejście zwrotne przy stanie wyzwolenia alarmu. Oznacza ono, że obiekt nie zmieni stanu, jeśli użytkownik poda błędny pin. Można modelować również przejścia zwrotne, które następują na skutek upływu czasu. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

50 Dodatkowe źródła informacji Dodatkowe źródła informacji The Unified Modeling Language UML Tutorial Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

51 Dodatkowe źródła informacji Pytania? Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52

52 Dodatkowe źródła informacji koniec Dziękuję Państwu za uwagę. Arkadiusz Chrobot Unified Modeling Language (UML) Kielce, 15 listopada / 52