Znaleziony - jeżeli nadawca nie jest znany w obrębie danego fragmentu Utracony - jeżeli odbiorca komunikatu nie jest znany w obrębie danego fragmentu



Podobne dokumenty
Język UML w modelowaniu systemów informatycznych

NIFIED M L ODELLING ANGUAGE. Diagramy czynności

Inżynieria oprogramowania Jarosław Kuchta. Modelowanie interakcji

Wymiar poziomy: oś na której umieszczono instancje klasyfikatorów biorące udział w interakcji.

TECHNOLOGIE OBIEKTOWE. Wykład 3

Diagramy interakcji. Jarosław Kuchta Dokumentacja i Jakość Oprogramowania

TECHNOLOGIE OBIEKTOWE WYKŁAD 2. Anna Mroczek

koniec punkt zatrzymania przepływów sterowania na diagramie czynności

Język UML w modelowaniu systemów informatycznych

Projektowanie interakcji. Jarosław Kuchta

Diagramy sekwencji. wymienianych między nimi

Modelowanie aktywności. Jarosław Kuchta Programowanie Współbieżne

Język UML w modelowaniu systemów informatycznych

Inżynieria oprogramowania

Diagramy stanów i aktywności. Jarosław Kuchta Dokumentacja i Jakość Oprogramowania

Źródło: S. Wrycza, B. Marcinkowski, K. Wyrzykowski Język UML 2.0 w modelowaniu systemów informatycznych Helion DIAGRAMY INTERAKCJI

Diagram sekwencji. Komunikaty mogą być opisane w sposób sformalizowany. poprz / [warunek] *[iter] nr sekw : wynik := operacja(lista)

Diagramy czynności. Widok logiczny. Widok fizyczny

UML. dr inż. Marcin Pietroo

Diagramy maszyn stanowych, wzorce projektowe Wykład 5 część 1

UML cz. III. UML cz. III 1/36

Diagramy maszyn stanowych, wzorce projektowe Wykład 5 część 1

Diagramy stanów tworzenie modeli analizy i projektowania Na podstawie UML 2.0 Tutorial

UML - zarys 2007/2008

Kurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017

UML w Visual Studio. Michał Ciećwierz

Diagramy czynności Na podstawie UML 2.0 Tutorial

Modelowanie obiektowe - Ćw. 6.

Analiza i programowanie obiektowe 2016/2017. Wykład 6: Projektowanie obiektowe: diagramy interakcji

Diagram maszyny stanowej - POJĘCIA

Projektowanie systemów informacyjnych

MovementAgent. Wywołanie jest zazwyczaj zdarzeniem synchronicznym. Sygnał. position velocity

Inżynieria oprogramowania. Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Podstawy programowania III WYKŁAD 4

Diagramy interakcji. Opracowano w Lab. Informatyki AGH (Kraków)

Modelowanie obiektowe

Zalety projektowania obiektowego

Unified Modeling Language

Podstawy języka UML2 w realnych projektach

Diagramy czynności tworzenie modelu przypadków użycia Wykład 2

Diagramy czynności. sekwencyjnych i współbieŝnych. pomiędzy uporządkowanymi ciągami czynności, akcji i obiektów

Zagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 3 Ćwiczenia w narzędziu CASE diagram sekwencji. Materiały dla studentów

Podstawy modelowania w języku UML

Język UML w modelowaniu systemów informatycznych

Diagramy klas. dr Jarosław Skaruz

Graficzna notacja procesów biznesowych BPMN. Porównanie z notacja UML. Jakub Morkis, Piotr Chmielewski

Modelowanie i analiza systemów informatycznych.

UML cz. I. UML cz. I 1/1

Podstawy inżynierii oprogramowania

Język UML w modelowaniu systemów informatycznych

procesów Współbieżność i synchronizacja procesów Wykład prowadzą: Jerzy Brzeziński Dariusz Wawrzyniak

Zmiany. Initial Step krok inicjujący sekwenser

Diagramy zachowania. Diagramy struktury. Przypadków użycia. Stanów. Przeglądu interakcji widoku interakcji (ang. interaction overview)

Spis treúci. 1. Wprowadzenie... 13

Rysunek 1: Przykłady graficznej prezentacji klas.

Język UML w modelowaniu systemów informatycznych

MASZYNA STANOWA. Maciej Patan. Instytut Sterowania i Systemów Informatycznych Uniwersytet Zielonogórski. Techniki modelowania programowania.

Tutorial prowadzi przez kolejne etapy tworzenia projektu począwszy od zdefiniowania przypadków użycia, a skończywszy na konfiguracji i uruchomieniu.

Model przypadków użycia - rola diagramów aktywności Część 2 Wykładowca Dr inż. Zofia Kruczkiewicz

KATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH

Michał Adamczyk. Język UML

RAFAŁ KASPRZYK, copyright reserved

Diagramy zachowania. Diagramy struktury. przypadki użycia. Stanów. Przeglądu interakcji widoku interakcji (ang. interaction overview)

Programowanie współbieżne Wykład 2. Iwona Kochańska

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

Mechanizmy pracy równoległej. Jarosław Kuchta

Oprogramowanie o wysokiej jakości to oprogramowanie spełniające następujące kryteria:

Przepływy danych. Oracle Designer: Modelowanie przepływów danych. Diagramy przepływów danych (1) Diagramy przepływów danych (2)

Świat rzeczywisty i jego model

Inżynieria Oprogramowania

miejsca przejścia, łuki i żetony

Modelowanie diagramów klas w języku UML. Łukasz Gorzel @stud.umk.pl 7 marca 2014

Projektowanie i wdrażanie systemów informatycznych (materiały do wykładu cz. II)

Sieci Petriego. Sieć Petriego

Projektowanie Scalonych Systemów Wbudowanych VERILOG

UML (Unified Modeling Language jest to sposób formalnego opisu modeli reprezentujących projekty informatyczne.

Diagramy klas. WYKŁAD Piotr Ciskowski

Wprowadzenie do programowania współbieżnego

APIO. W4 ZDARZENIA BIZNESOWE. ZALEŻNOŚCI MIĘDZY FUNKCJAMI. ELEMENTY DEFINICJI PROCESU. DIAGRAM ZALEŻNOŚCI FUNKCJI.

LABORATORIUM 4. Po co mi to, przecież wiem, co system ma robić? - czyli o diagramach UML. DIAGRAM CZYNNOŚCI (Activity Diagram)

INŻYNIERIA OPROGRAMOWANIA. laboratorium

Tryby komunikacji między procesami w standardzie Message Passing Interface. Piotr Stasiak Krzysztof Materla

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

Analiza i projektowanie obiektowe 2017/2018. Wykład 3: Model wiedzy dziedzinowej

KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA

4. Procesy pojęcia podstawowe

Wstęp do programowania 2

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram czynności. Materiały dla studenta

SEGMENT TCP CZ. II. Suma kontrolna (ang. Checksum) liczona dla danych jak i nagłówka, weryfikowana po stronie odbiorczej

Zagadnienia Semestr IV Inżynieria Oprogramowania WSZiB

Referencyjny model OSI. 3 listopada 2014 Mirosław Juszczak 37

Podstawy języka UML2 w realnych projektach

Język UML w modelowaniu systemów informatycznych

Grupy pytań na egzamin inżynierski na kierunku Informatyka

5. Model komunikujących się procesów, komunikaty

PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH 2010/2011 MGR DOROTA MIROWSKA

Podstawy modelowania w języku UML

Transkrypt:

czas Dynamiczne aspekty systemu Interakcja - zachowanie polegające na wymianie komunikatów między obiektami w pewnym (ustalonym) otoczeniu, w pewnym (ściśle określonym) celu Komunikat - specyfikacja łączności między obiektami, uwzględniająca zlecenia wykonania określonych czynności Interakcja jest wykorzystywana do modelowania dynamiki kooperacji reprezentujących zestawy obiektów odgrywających specyficzne role, współdziałających w celu wywołania pewnego zachowania, niemożliwego do zrealizowania w pojedynkę Każda interakcja może być modelowana na 2 sposoby, podkreślając: kolejność komunikatów w czasie lub następstwa komunikatów w otoczeniu pewnej organizacji strukturalnej obiektów Inżynieria oprogramowania (Wyk. 4) Slajd 2 z 29 Diagramy interakcji Diagramy przebiegu Diagram interakcji - obrazuje interakcję jako zbiór obiektów i związków między nimi, w tym też komunikaty, które obiekty przekazują między sobą; zawierają na ogół obiekty, wiązania oraz komunikaty; cel: modelowanie przepływu sterowania Diagram współpracy, komunikacji, kooperacji Diagram przebiegu (ang. sequence) - (ang. collaboration) - uwypukla związki strukturalne pomiędzy obiektami (organizacja strukturalna) wysyłającymi i odbierającymi komunikaty; graficznie jest to zestaw wierzchołków i krawędzi uwypukla kolejność komunikatów w czasie; ma postać tabeli, w której obiekty są ułożone wzdłuż osi X a komunikaty wzdłuż osi Y, uporządkowane wg czasu ich wysyłania nacisk na związki strukturalne między egzemplarzami uczestniczącymi w interakcji nacisk na sposób przekazywania komunikatów w miarę ich pojawiania się oraz komunikaty przesyłane między nimi szczególnie przydatne w kontekście wygodniejsze do przedstawiania złożonych scenariusza przypadków użycia iteracji i rozgałęzień wygodniejsze do przedstawiania stosowane przy wielu współbieżnych przepływach sterowania prostych iteracji i rozgałęzień Linia życia obiektów - pionowe przerywane kreski reprezentujące czas istnienia obiektów (zwykle obiekty żyją przez cały czas trwania interakcji, wpp od odebrania komunikatu stereotypowego <<create>> aż do otrzymania <<destroy>>) Ośrodek sterowania (ang. focus of control) - podłużny, cienki prostokąt reprezentujący okres wykonywania przez obiekt akcji - osobiście lub przez procedury podrzędne; zagnieżdżenia sterowania (np. wywołania rekurencyjne lub wywołania własnych operacji) oznaczane są za pomocą dodatkowego prostokąta ośrodka sterowania umieszczonego na prawo od jego przodka Inżynieria oprogramowania (Wyk. 4) Slajd 3 z 29 Inżynieria oprogramowania (Wyk. 4) Slajd 4 z 29 Rodzaje komunikatów (do wersji UML 1.5) Rodzaje komunikatów (UML 2.0) Prosty - powoduje jedynie przekazanie sterowania od obiektu do obiektu; na danym etapie modelowania nie są istotne szczegóły tego przekazania Synchroniczny - obiekt wysyłający komunikat oczekuje na odpowiedź zwrotną i dopiero po jej otrzymaniu przechodzi do dalszych działań; zwykle reprezentuje wywołanie proceduralne Powrót - oznacza powrót z wywołania procedury; może być pomijany (i najczęściej jest), gdyż jest nieuchronną konsekwencją wywołania Asynchroniczny - po wysłaniu komunikatu obiekt kontynuuje swoje działania bez oczekiwania na odpowiedź Znaleziony - jeżeli nadawca nie jest znany w obrębie danego fragmentu Utracony - jeżeli odbiorca komunikatu nie jest znany w obrębie danego fragmentu Inżynieria oprogramowania (Wyk. 4) Slajd 5 z 29 Inżynieria oprogramowania (Wyk. 4) Slajd 6 z 29

Diagram przebiegu - przykład (1) Iteracja (do wersji UML 1.5) Stosowana w celu zobrazowania ciągu powtarzających się komunikatów Zaznaczana na diagramie wyrażeniem iteracyjnym przed nazwą komunikatu: * - ( sama gwiazdka - liczba powtórzeń nie jest określona) * [i:=1..n] W sytuacji gdy iteracja dotyczy kilku komunikatów, obejmowane one są w ramkę i wyrażenie iteracyjne podawane jest w lewym górnym rogu Inżynieria oprogramowania (Wyk. 4) Slajd 7 z 29 Inżynieria oprogramowania (Wyk. 4) Slajd 8 z 29 Ramki (UML 2.0) Rozgałęzienia Alt - alternatywa; wykonywany jest ten fragment, przy którym spełniony jest warunek Opt - opcjonalny; wykonywany jeśli spełniony jest warunek Par - współbieżność; wszystkie fragmenty wykonywane współbieżnie Loop - iteracja; warunek określa podstawę iteracji Ref - odwołanie; stanowi referencję do innej interakcji; przykrywa linie życia Critical (region) - obszar krytyczny; fragment może mieć tylko jeden wątek uruchomiony w danej chwili Neg, Break, Assert, Consider... Wykonanie komunikatu uzależnione jest od spełnienia warunku logicznego; na diagramie oznaczane w postaci klauzuli (np. [x>0]) przed numerem komunikatu Postać wyrażenia nie jest sprecyzowana, może to być dowolne wyrażenie logiczne, którego wartość jest wyznaczana w momencie wysyłania komunikatu Nie wszystkie narzędzia umożliwiają wykorzystanie rozgałęzień Inżynieria oprogramowania (Wyk. 4) Slajd 9 z 29 Inżynieria oprogramowania (Wyk. 4) Slajd 10 z 29 Diagram przebiegu - przykład (2) Diagramy współpracy a : Abonent podniesionosłuchawkę ustalsygnałzgłoszenia() * wybierzcyfrę(c) wybieranienumeru : Centrala {wybieranienumeru.czas<30 sekund} budujpołączenie(a,b) b : Abonent Cechy wyróżniające: występowanie ścieżek - dodajemy stereotypy ścieżki (np. local, parameter, global,...) do drugiego końca wiązania ciągi komunikatów - aby wskazać kolejność komunikatu w czasie, poprzedzany jest on numerem w ciągu; zagnieżdżenia obrazuje się za pomocą notacji Deweya (1, 1.1, 1.2, 2,...) połącz(a) <<create>> połącz(a, b) r : Rozmowa dzwoń() podniesionosłuchawkę połącz(b) Po nawiązaniu połączenia abonenci a i b mogą rozmawiać Inżynieria oprogramowania (Wyk. 4) Slajd 11 z 29 Inżynieria oprogramowania (Wyk. 4) Slajd 12 z 29

: Uczelnia Diagram współpracy - przykład 2: dodajstudenta(s) r: Rekrutacja 1: <<create>> 3: zapisz() 3.1: podajplan() <<local>> {self} s : Student zapisany=nie 3.4: <<become>> s : Student zapisany=tak 3.2: dodaj(s) 3.3: dodaj(s) w1 : Wykład w2 : Wykład {association} {association} k :Klient {transient} <<create>> : Transakcja wybierzakcje(a,d,o) zatwierdzono <<destroy>> Równoważność znaczeniowa (przykład) Diagram przebiegu ustalwart(d, 1.2) ustalwart(a, AB ) p: ODBCProxy <<local>> k :Klient : Transakcja {transient} Diagram współpracy 1: <<create>> 2: wybierzakcje(a,d,o) 3: <<destroy>> <<global>> p: ODBCProxy 2.1: ustalwart(d, 1.2) 2.2: ustalwart(a, AB ) Inżynieria oprogramowania (Wyk. 4) Slajd 13 z 29 Inżynieria oprogramowania (Wyk. 4) Slajd 14 z 29 Diagram przeglądu interakcji (UML 2.0) Diagram czasowy (UML 2.0) Połączenie notacji diagramów przebiegu z notacją diagramów czynności diagram ma strukturę diagramu czynności, przy czym zamiast elementów czynności występują elementy interaktywne z d. przebiegu (lub całe diagramy przebiegu) Zastosowanie: modelowanie systemu na wysokim poziomie abstrakcji; przedstawienie połączeń pomiędzy scenariuszami modelowanego systemu Modelowanie wielu przebiegów czasowych Wykorzystuje dwa rodzaje linii czasu (obie rosną wzdłuż osi X): linia wartości (ang. value lifeline) wskazuje wartość jaką przyjmuje rozpatrywany parametr obiektu (wartość określana tylko za pomocą tekstu) linia stanu (ang. state lifeline) wskazuje stan obiektu wyrażony za pomocą wartości dyskretnych; odpowiadają im poziomy (różne amplitudy) linii Przykł. d. przeglądu inter. [K. J.] Inżynieria oprogramowania (Wyk. 4) Slajd 15 z 29 Przykładowe d. czasowe [K. J.] Inżynieria oprogramowania (Wyk. 4) Slajd 16 z 29 Maszyny stanowe - podstawowe pojęcia Diagram stanów (zmiany stanów) Maszyna stanowa - określa ciąg stanów przyjmowanych przez obiekt w odpowiedzi na zdarzenia zachodzące w czasie jego życia, a także reakcje na te zdarzenia; bardzo przydatne, gdy bieżące zachowanie obiektu zależy od jego przeszłości Zdarzenie - specyfikacja zjawiska, które zachodzi w czasie i przestrzeni; jest bodźcem, który może uruchomić przejście pomiędzy stanami Stan - okoliczność lub sytuacja, w jakiej się obiekt znajduje, kiedy spełnia jakiś warunek, wykonuje jakąś czynność lub czeka na jakieś zdarzenie; zwykle obiekt pozostaje w pewnym stanie przez skończony czas Przejście - związek między dwoma stanami; wskazuje, że obiekt znajdujący się w pierwszym stanie wykona pewne akcje i przejdzie do drugiego stanu, o ile zajdzie określone zdarzenie i będą spełnione określone warunki Akcja - wykonywalna niepodzielna procedura obliczeniowa prowadząca do zmiany stanu systemu lub do przekazania wartości Inżynieria oprogramowania (Wyk. 4) Slajd 17 z 29 Inżynieria oprogramowania (Wyk. 4) Slajd 18 z 29

Rodzaje stanów Składniki stanów Prosty (zwykły) - nie posiada wewnętrznej struktury Początkowy - pseudostan oznaczający punkt startowy - miejsce rozpoczęcia działania maszyny stanowej lub podstanu Finalny - pseudostan oznaczający punkt końcowy Złożony sekwencyjny - złożony z jednego lub więcej podstanów, z których tylko jeden jest aktywny, gdy aktywny jest stan złożony Złożony współbieżny - podzielony na dwa lub więcej współbieżnych podstanów; wszystkie podstany są jednocześnie aktywne, gdy aktywny jest stan złożony (jako całość) - odróżnia poszczególne stany (nie może zawierać dwukropka); może też być stan bez nazwy - anonimowy Akcje wejściowe i wyjściowe - wykonywane odpowiednio przy wejściu do stanu i przy wyjściu z niego Przejścia wewnętrzne - realizowane bez zmiany stanów Podstany - zagnieżdżona struktura stanu, obejmująca podstany rozłączne (aktywne sekwencyjne) lub współbieżne (aktywne równoległe) Zdarzenia odroczone - lista zdarzeń, które nie są w tym stanie obsługiwane, są odkładane i umieszczane w kolejce, po czym są obsługiwane w innym stanie Nazwę stanu podaje się w formie rzeczownika lub wyrażenia rzeczownikowego pochodzącego ze słownictwa modelowanego systemu Inżynieria oprogramowania (Wyk. 4) Slajd 19 z 29 Inżynieria oprogramowania (Wyk. 4) Slajd 20 z 29 Składniki przejść Zdarzenia uruchamiające zdarzenie_uruchamiające [warunek_dozoru] / akcja Stan źródłowy - gdy obiekt jest w stanie źródłowym i nastąpi zdarzenie uruchamiające, a warunek dozoru (o ile istnieje) jest spełniony, przejście może być uruchomione; do czasu aż przejście nie zostanie uruchomione, obiekt pozostaje w stanie źródłowym Akcja - wykonywalna niepodzielna procedura obliczeniowa, która może mieć bezpośredni wpływ na obiekt będący właścicielem maszyny stanowej i pośredni wpływ na inne obiekty znajdujące się w jego zasięgu może to być wywołanie operacji (obiektu lub innych dostępnych obiektów), utworzenie lub zniszczenie obiektu oraz wysłanie sygnału do obiektu nie może być przerwana przez zdarzenie - zawsze jest wykonywana w całości Stan docelowy - stan obiektu po zakończeniu przejścia Inżynieria oprogramowania (Wyk. 4) Slajd 21 z 29 Zdarzenie uruchamiające (ang. event trigger)- zdarzenie oznaczające, że przejście może nastąpić ( sygnał, wywołane operacji, upływ czasu i zmiana stanu) sygnał lub wywołanie może mieć parametry, których wartości są dostępne w ramach przejścia przejścia automatyczne (bez zdarzenia uruchamiającego) - przejścia (tzw. zakończeniowe) uruchamiane są natychmiast po zakończeniu czynności w stanie źródłowym zdarzenia czasowe: after(okres_czasu) np.after(3 miesiące), after(1 godzina) when(moment_czasu) np. when(31.12), when (godzina 22.00) Faktura Inżynieria oprogramowania (Wyk. 4) Slajd 22 z 29 Składniki przejść (2) Złożone elementy stanów i przejść Warunek dozoru (ang. guard condition) - wyrażenie logiczne, którego wartość jest wyznaczana w chwili otrzymania zdarzenia uruchamiającego i spełnienie go warunkuje dokonanie przejścia obrazowany w postaci wyrażenia logicznego w nawiasach kwadratowych tuż za zdarzeniem uruchamiającym można określić wiele przejść z tego samego źródła i z tym samym zdarzeniem uruchamiającym o ile warunki nadzoru się nie nakładają zdarzenie uruchamiające jest ignorowane, gdy żadne przejście przez nie inicjowane nie może dość do skutku warunek dozoru może występować bez zdarzenia uruchamiającego => zmiana wartości wyrażenia skutkuje umożliwieniem przejścia Inżynieria oprogramowania (Wyk. 4) Slajd 23 z 29 Akcje wejściowe (entry) i wyjściowe (exit) - wykonywane zawsze, gdy przyjmowany / opuszczany jest stan; w zasadzie nie mogą mieć argumentów ani warunków dozoru Przejścia wewnętrzne - do zdarzeń obsługiwanych bez wyjścia ze stanu; ilekroć zachodzi zdarzenie to skojarzona z nim akcja jest realizowana bez opuszczania stanu (nie są wykonywane akcje wyjściowe i wejściowe) Śledzenie entry / ustawtryb(szuka) exit / ustawtryb(nieszuka) nowycel / celownik.rozpoznaj() do / śledźcel autotest / defer Czynności - będąc w jakimś stanie obiekt może realizować pewne zadania aż do chwili zajścia zdarzenia; słowo kluczowe do służy do wskazania prac wykonywanych w danym stanie od chwili zakończenia akcji wejściowej (może to być uruchomienie innej maszyny stanowej lub ciąg akcji, rozdzielonych średnikami) Zdarzenia odroczone - lista zdarzeń, których zajście w stanie jest odroczone do czasu, aż stan, w którym nie są odroczone, się uaktywni - dopiero wtedy te zdarzenia powodują przejścia, jakby właśnie zaszły; zdarzenia takie oznacza się specjalnym rodzajem akcji defer Inżynieria oprogramowania (Wyk. 4) Slajd 24 z 29

Podstany sekwencyjne Podstany współbieżne Podstany sekwencyjne dzielą przestrzeń stanów stanu złożonego na stany kartaw rozłączne Przejście od źródła znajdującego się na zewnątrz może prowadzić do stanu złożonego (wtedy musi być określony stan początkowy) anulowano lub bezpośrednio do jednego z jego podstanów kon ser Niezależnie od przyjętego rozwiązania akcja wuj wejściowa stanu złożonego jest realizowana Zagnieżdżona sekwencyjna maszyna stanowa może mieć co najwyżej jeden stan początkowy i Serwis jeden stan końcowy Aby zapamiętać aktualny podstan obiektu po opuszczeniu używamy stanów wznowienia (płytkie i głębokie) H H* Obsługa Walidacja Wybieranie Drukowanie Realizacja entry / odczytajkartę exit / wysuńkartę [kontynuacja] [not kontynuacja] Umożliwiają tworzenie dwu lub więcej maszyn stanowych, działających równolegle w ramach jednego obiektu Czynności podstanów współbieżnych przebiegają równolegle i ostatecznie każda z nich osiąga swój stan końcowy; jeżeli jeden dotrze do swego stanu końca wcześniej to czeka na pozostałe i dopiero wtedy następuje połączenie przepływu sterowania Zagnieżdżona współbieżna maszyna stanowa nie ma jako całość ani stanu początkowego ani końcowego; natomiast mogą je mieć składowe podstany sekwencyjne Konserwacja Testowanie kon ser wuj Testowanie urządzeń Przyjmowanie zleceń naciśniętoklawisz Autodiagnoza Wykonywanie poleceń Inżynieria oprogramowania (Wyk. 4) Slajd 25 z 29 Inżynieria oprogramowania (Wyk. 4) Slajd 26 z 29 Diagramy stanów Diagram stanów - przykład (ścieżka zatrudnienia pracownika) Przedstawiają maszyny stanowe z uwypukleniem przepływu sterowania między stanami; pokazują jak zachowanie obiektów zależy od kolejności zachodzących zdarzeń Zawierają: stany zwykłe (proste) i złożone przejścia ze zdarzeniami i akcjami Najczęściej wykorzystywane do modelowania obiektów reaktywnych (sterowanych zdarzeniami - ang. event-driven) zachowanie obiektów reaktywnych jest najlepiej charakteryzowane przez ciąg odpowiedzi na zdarzenia wywołane w jego otoczeniu, przy czym obiekt taki jest zwykle bezczynny do chwili zajścia zdarzenia reakcja na konkretne zdarzenie najczęściej zależy od wcześniejszych zdarzeń nacisk kładziony jest na stany stabilne, zdarzenia uruchamiające przejścia i akcje wykonywane po każdej zmianie stanu Inżynieria oprogramowania (Wyk. 4) Slajd 27 z 29 Inżynieria oprogramowania (Wyk. 4) Slajd 28 z 29 Diagram stanów - przykład (2) (analizator składniowy języka bezkontekstowego) Akceptuje komunikaty w postaci: < napis_1 > napis_2 ; gdzie napis_1 - znacznik a napis_2 - treść komunikatu Inżynieria oprogramowania (Wyk. 4) Slajd 29 z 29