Partycjonowanie zdarzeń
Partycjonowanie zdarzeń to łatwa do zastosowania technika analizy systemów , która pomaga analitykowi uporządkować wymagania dotyczące dużych systemów w zbiór mniejszych, prostszych, minimalnie połączonych, łatwiejszych do zrozumienia „minisystemów” / przypadków użycia .
Przegląd
Podejście do partycjonowania zdarzeń zostało wyjaśnione przez Stephena M. McMenamina i Johna F. Palmera w Essential Systems Analysis . Krótka wersja podejścia jest opisana w artykule dotyczącym diagramów przepływu danych (DFD). Bardziej kompletne omówienie znajduje się w Just Enough Structured Analysis Edwarda Yourdona . Opis koncentruje się na wykorzystaniu techniki do tworzenia diagramów przepływu danych, ale może być również wykorzystany do identyfikacji przypadków użycia .
Założeniem partycjonowania zdarzeń jest to, że istnieją systemy reagujące na zdarzenia zewnętrzne: identyfikuj, co dzieje się w środowisku biznesowym, co wymaga zaplanowanych reakcji, a następnie definiuj i buduj systemy reagujące zgodnie z regułami biznesowymi. W szczególności istnieje system biznesowy do obsługi żądań klientów. Klient, w żargonie Unified Modeling Language (UML), jest „ aktorem ”.
Tematy dotyczące partycjonowania zdarzeń
Aktor → Zdarzenie → Wykryj → Zareaguj
Metoda obejmuje następujące kroki.
- 1. Zidentyfikuj systemy zewnętrzne poprzez burzę mózgów na liście „ aktorów ” (systemów zewnętrznych), które są źródłami zdarzeń zewnętrznych. Jeśli uznasz, że grafika jest pomocna, utwórz diagram kontekstowy przedstawiający aktorów spoza badanego systemu oraz przepływy/sygnały między nimi.
- 2. Postaw się na miejscu „aktora” (lub pracując z przedstawicielami aktorów), zrób burzę mózgów na liście „ zdarzeń zewnętrznych ” / „wyzwalaczy”, na które system ma zaplanowaną reakcję. (Zauważ, że system nie może inicjować zewnętrznych ; tylko aktor może).
-
3. Określ, co umożliwi systemowi wykrywanie zdarzeń zewnętrznych:
- nadejście jednej lub więcej danych ( ewentualnie w formie wiadomości)
- nadejście jednego lub więcej punktów w czasie (zwanych przez M&P zdarzeniami „temporalnymi” i odróżnianymi przez nich od zdarzeń zewnętrznych)
- 4. Zidentyfikuj planowane reakcje , które system może wykonać, gdy wystąpią zdarzenia. To odpowiedź(e)/przypadek(y) użycia umożliwią systemowi osiągnięcie jego celów.
Technika została rozszerzona o zdarzenia „niebędące zdarzeniami” przez Paula T. Warda i Stephena J. Mellora w opracowaniu strukturalnym dla systemów czasu rzeczywistego: podstawowe techniki modelowania .
„Ponieważ terminatorzy [aktorzy] są z definicji poza granicami wysiłku budowania systemu reprezentowanego przez model, realizatorzy nie mogą dowolnie modyfikować technologii terminatora [aktora], aby poprawić jej niezawodność. Zamiast tego muszą zbudować odpowiedzi na terminator [aktor] aktora] do podstawowego modelu systemu. Użytecznym podejściem do modelowania odpowiedzi na problemy terminatora [aktora] jest zbudowanie listy „normalnych” zdarzeń, a następnie zadanie dla każdego zdarzenia pytania: „Czy system musi zareagować, jeśli to zdarzenie nie zachodzi zgodnie z oczekiwaniami? „[podkreślenie dodane]
Notacja słownika danych
Do opisu składu i struktury danych można zastosować notację słownikową w stylu Yourdona/DeMarco .
| Symbol | Oznaczający |
|---|---|
| = | „zawiera”, „jest” lub „składa się z” |
| + | „i”, „jak również” lub „razem z” ( nie arytmetyczne „plus”) |
| [ x ; y ; z ] | „wybierz tylko jeden z x , y lub z ”. Do oddzielenia pozycji na liście można użyć średnika ( ;) lub pionowej kreski (|). |
|
m { x } n lub m: n { x } lub |
„od m do n iteracji x ”. Jeśli m lub n nie jest określone, dolna lub górna granica jest po prostu „nieznana” lub „nieokreślona”. Wielowymiarowe tablice można określić przez zagnieżdżanie, np. 10 { 10 { x } 10 } 10 definiuje dwuwymiarową macierz złożoną z 10 wierszy i 10 kolumn. |
| ( x ) | „opcjonalnie x ”. Jest to równoważne 0 { x } 1 lub 0: 1 { x } lub . |
| @ | prefiks dla identyfikatora w iteracji. Na przykład w {@i+@j+x} i oraz j są identyfikatorami. |
| * ... * | Wszystko pomiędzy pojedynczymi gwiazdkami jest traktowane jako komentarz. Na elementu danych komentarz może zawierać znaczniki typu „zakres:”, „limity:”, „precyzja:”, „jednostka:” czy „wartości:”. |
struktury kontrolne programowania strukturalnego :
- „+” może odwzorować „sekwencję” instrukcji (chociaż niekoniecznie tak jest)
- „[|]” można odwzorować na „wybór” ( warunki , instrukcje przełączania )
- „{}”, „()” można odwzorować na „iterację” ( pętla zliczania , pętla przed testem , pętla w środku testu, pętla po teście i pętla nieskończona )
Uwaga. Zdefiniowanymi pozycjami mogą być „istotne” (np. klucz do pokoju), jak również „dane” (np. data i godzina przyjazdu).
Identyfikacja wymagań i ich przyczyny
Informacja o zdarzeniu-odpowiedzi może być przechwycona w tabeli. Zdarzenie jest raison d'être dla odpowiedzi, która zapewnia „ identyfikowalność ” od reakcji do środowiska.
| 1. Aktor | 2. Zewnętrzne zdarzenie/wyzwalacz | 3. Wykryty przez | 4. Odpowiedzi / Przypadki użycia |
|---|---|---|---|
| Gość | Gość prosi o pokój określonego typu, na określoną datę przyjazdu, datę wyjazdu, w określonej cenie itp. |
prośba o rezerwację + (zatwierdzenie płatności) + (*zewnętrzny system rezerwacji* potwierdzenie rezerwacji) |
Zarezerwuj pokój (może obejmować rezerwację gwarantowaną, rezerwację w alternatywnym hotelu, rezerwację z listy oczekujących) |
| Gość | Gość prosi o anulowanie rezerwacji pokoju. | żądanie anulowania | Anulować rezerwację |
| Gość | Gość przyjeżdża do hotelu. |
wiadomość o przybyciu = * * = [nazwisko gościa ; numer rezerwacji] |
Zamelduj się Gość |
| Czas / Harmonogram | Gość nie przybywa do hotelu. [To jest wydarzenie „niebędące wydarzeniem”.] | 23:00 (czasu lokalnego) [Zdarzenie „niebędące zdarzeniem” jest wykrywane przez nadejście punktu w czasie, terminu ostatecznego.] |
Utwórz rachunek gościa, zaktualizuj rezerwację |
| Gość | Gość prosi o wymeldowanie się z hotelu. |
prośba o wymeldowanie = * * = [nazwisko gościa ; numer pokoju] |
Utwórz rachunek za gościa, zaktualizuj obłożenie pokoju |
| Czas / Harmonogram | Gość nie wymeldowuje się z hotelu. [To jest wydarzenie „niebędące wydarzeniem”.] | 11:00 (czasu lokalnego) [Zdarzenie „niebędące zdarzeniem” jest wykrywane przez nadejście punktu w czasie, terminu ostatecznego.] | Utwórz rachunek gościa |
| Gość | Gość oferuje zapłatę rachunku. |
środek płatniczy = * * = [gotówka ; sprawdzać ; karta kredytowa ; karta debetowa] + (identyfikator gościa) |
Zaakceptuj płatność gościa |
| Czas / Harmonogram | Czas na sporządzenie raportu o zajętości pokoju za poprzednią noc. | 8:00 (czasu lokalnego) | Raport o zajętości pokoju |
| Kierownik hotelu | Kierownik hotelu prosi o raport o zajętości pokoju. | żądanie raportu o zajętości | Raport o zajętości pokoju |
| Alarm dymu / CO | Alarm wykrywa dym. | komunikat o alarmie dymnym | Zgłoś alarm dymu |
| Alarm dymu / CO | Alarm wykrywa CO (tlenek węgla). | Komunikat alarmowy CO | Zgłoś alarm CO |
Definiowanie wymagań
Takie podejście pomaga analitykowi rozłożyć system na mini-systemy „o niewielkich rozmiarach”, wykorzystując zdarzenia, które wymagają zaplanowanej reakcji. Poziom szczegółowości każdej odpowiedzi jest na poziomie „podstawowych przypadków użycia ”. Każda planowana odpowiedź może być modelowana za pomocą notacji DFD lub jako pojedynczy przypadek użycia za pomocą notacji diagramu przypadków użycia.
Podstawowy przepływ w ramach procesu lub przypadku użycia można zwykle opisać w stosunkowo niewielkiej liczbie kroków, często mniej niż dwadzieścia lub trzydzieści, prawdopodobnie używając czegoś w rodzaju „ strukturalnego języka angielskiego ”. Idealnie byłoby, gdyby wszystkie kroki były widoczne jednocześnie (często strona lub mniej). Celem jest zmniejszenie jednego z zagrożeń związanych z pamięcią krótkotrwałą , a mianowicie zapominaniem tego, co nie jest od razu widoczne („co z oczu, to z głowy”).
Alternatywnie, używając notacji ustrukturyzowanych technik, analityk mógłby stworzyć „ diagram Nassi-Shneidermana ”. W języku UML przypadek użycia można modelować za pomocą diagramu czynności , diagramu sekwencji lub diagramu komunikacji . Może to być problematyczne, jeśli istnieje wiele złożonych scenariuszy przypadku użycia; analityk może chcieć modelować wszystkie lub większość scenariuszy.
Złożoność a fragmentacja
Jeśli odpowiedź jest długa lub złożona (tj. więcej niż strona tekstu), analityk może rozłożyć („wykluczyć” lub deduplikować ) na mniejsze „drugorzędne przypadki użycia”, aby główny przypadek użycia „nadrzędnego” był mniejszy i prostszy. Te wtórne przypadki użycia mogą również okazać się wielokrotnego użytku. diagramie przypadków użycia UML byłyby one rysowane jako rozszerzone lub włączone przypadki użycia, które są powiązane z jednym lub kilkoma podstawowymi przypadkami użycia).
Opisując przypadek użycia, analityk może również odkryć „ reguły biznesowe ”. Niektórzy analitycy sugerują przechwycenie reguł biznesowych w osobnym dokumencie przy użyciu języka ograniczeń obiektowych lub innej formalnej notacji . Następnie, gdy reguła biznesowa musi być przestrzegana w przypadku użycia, analityk odwołuje się do niej. Minimalizuje to liczbę powtórzeń w ramach specyfikacji, ale grozi fragmentacją specyfikacji. Jedną z technik, która może zmniejszyć to napięcie, jest użycie hiperłączy w dokumencie specyfikacji.
To redukcjonistyczne podejście nieco kontrastuje z podejściem opartym na myśleniu systemowym , reprezentowanym przez metodologię systemów miękkich Petera Checklanda .
Oprócz wymagań funkcjonalnych ujętych w opisie przypadku użycia, analityk może uwzględnić takie wymagania niefunkcjonalne , jak czas reakcji, zdolność uczenia się itp.
Zobacz też
Linki zewnętrzne
- Partycjonowanie zdarzeń Strukturalna analiza wiki