„Jeden dzień z życia wiewiórki” lub od modelowania procesów do projektowania zautomatyzowanego systemu ewidencji wartości materialnych „Wiewiórka-1.0” (Część 1)
Co ma wspólnego z „wiewiórką”?
Od razu wyjaśnię, co ma wspólnego z „wiewiórką”. Znalazłszy w sieci zabawne projekty do nauki UML oparte na tematyce zaczerpniętej z fabuł bajek (na przykład, [1]), postanowiłam także przygotować podobny przykład dla moich studentów, aby początkowo mogli poznać trzy rodzaje diagramów: Diagram Aktywności, Diagram Przypadków Użycia i Diagram Klas. Celowo nie tłumaczę nazw diagramów na język rosyjski, aby uniknąć sporów o „trudności w tłumaczeniu”. Wyjaśnię, co jest do czego, nieco później. W tym przykładzie korzystam ze środowiska Enterprise Architect od australijskiej firmy [2] – dobrego narzędzia w rozsądnej cenie. A w ramach zajęć dydaktycznych używam [3], niezłego darmowego narzędzia do projektowania obiektowego, które obsługuje standardy UML2.0 i BPMN, bez zbędnych bajerów w zakresie możliwości graficznych, ale całkowicie wystarczające do nauki podstaw języka.
Zamierzamy zautomatyzować działania związane z ewidencją wartości materialnych, które zachodzą w tych procesach.
…
Wyspa na morzu leży, (E1, E2)
Gród na wyspie stoi (E3, E1)
Z złotogłowymi cerkwiami, (E4)
Z teremami i ogrodami; (E5, E6)
Świerk rośnie przed pałacem, (E7, E8)
A pod nim kryształowy dom; (E9)
Wiewiórka tam żyje oswojona, (A1)
I jaka figlarka! (A1)
Wiewiórka piosenki śpiewa, (P1, A1)
I orzechy wszystko zjada, (P2)
A orzechy nie byle jakie, (C1)
Wszystkie skorupy złote, (C2)
Jądra czysty szmaragd; (C3)
Słudzy wiewiórkę strzegą, (P3, A2)
Służą jej różnorodna służba (P4)
I przydzielono diakona z porządkiem (A3)
Ścisłe liczenie orzechów wieszczy; (P5, C1)
Oddaje jej wojsko cześć; (P6, A4)
Ze skorupek leją monetę, (P7, C2, C4)
I wpuszczają w obieg na całym świecie; (P8)
Dziewczyny sypią szmaragd (P9, A5, C3)
Do spichlerzy, a pod pojemnik; (E10, E11)
…
(A.S. Puszkina "Bajka o carze Saltanie, o jego sławnym i potężnym bohaterskim synu księciu Gwidonie Saltanowiczu oraz o pięknej księżniczce Łabędziu", — 10 lat od pomysłu do publikacji, nawiasem mówiąc!)
Kilka słów o kodach, które są napisane po prawej stronie wierszy. „A” (od „Actor”) oznacza, że w wierszu znajduje się informacja o uczestniku procesu. „C” (od „Class”) – informacje o obiektach klas, które są przetwarzane w trakcie realizacji procesów. „E” (od „Environment”) – informacje o obiektach klas, które charakteryzują środowisko realizacji procesów. „P” (od „Process”) – informacje o samych procesach.
Zresztą, dokładna definicja procesu również może stać się przyczyną sporów metodologicznych, chociażby dlatego, że procesy mogą być różne: biznesowe, produkcyjne, technologiczne itd. (można zapoznać się na przykład, [4] i [5]). Aby uniknąć polemiki, umówmy się, że proces interesuje nas z punktu widzenia jego powtarzalności w czasie oraz potrzeby automatyzacji, tzn. przeniesienia realizacji jakiejkolwiek części operacji procesu na zautomatyzowany system.
Notatki dotyczące zastosowania diagramu Activity
Przystąpimy do modelowania naszego procesu i skorzystamy w tym celu z diagramu Activity. Na początek wyjaśnię, jak wyżej wymienione kody będą wykorzystywane w modelu. Łatwiej jest wyjaśnić na przykładzie graficznym, a przy okazji omówimy niektóre (prawie wszystkie potrzebne nam) elementy diagramu Activity.
Przeanalizujmy następny fragment:
…
Wiewiórka piosenki śpiewa, (P1, A1)
I orzechy wszystko zjada, (P2)
A orzechy nie byle jakie, (C1)
Wszystkie skorupy złote, (C2)
Jądra czysty szmaragd; (C3)
…
Mamy dwa kroki procesu P1 i P2, uczestnika A1 oraz obiekty trzech różnych klas: obiekt klasy C1 wchodzi do kroku, a obiekty klas C2 i C3 są uzyskiwane na wyjściu jako efekt działalności tego kroku P2 naszego procesu. Do diagramu użyjemy następujących elementów modelujących.
Fragment naszego procesu można przedstawić mniej więcej tak (Rysunek 1).
Rysunek 1. Fragment diagramu Activity
Aby zorganizować przestrzeń i ustrukturyzować diagram Activity, zastosujemy nieco nienormatywne podejście w klasycznym ujęciu notacji UML. Ale są na to pewne powody. Po pierwsze, na początek modelowania sporządzimy tak zwane, porozumienie w zakresie modelowania, w którym zobaczymy wszystkie cechy korzystania z notacji. Po drugie, podejście to zostało wielokrotnie pomyślnie zastosowane na etapie modelowania biznesowego w rzeczywistych projektach tworzenia systemów programowych, a wyniki zostały udokumentowane przez nasz mały zespół autorski w odpowiednim obiekcie praw autorskich [6], a także wykorzystane w podręczniku [7]. Dla diagramu aktywności zdefiniujemy, że pole diagramu zorganizujemy za pomocą „pływających” ścieżek – Swim lanes. Nazwa ścieżki będzie odpowiadała typowi elementów diagramu, które zostaną umieszczone na tej ścieżce.
„Wejściowe i wyjściowe artefakty”: na tej ścieżce będą znajdować się elementy Objects – obiekty, które są używane lub są wynikiem wykonania pewnego kroku procesu.
„Kroki procesu”: tutaj umieścimy elementy Activity – działania uczestników procesu.
„Uczestnicy”: ścieżka dla elementów, które będą oznaczać role wykonawców działań w naszym procesie; dla nich użyjemy tego samego elementu modelującego Object – obiekt, ale dodamy mu stereotyp „Actor”.
Następna ścieżka nazywa się „Zasady biznesowe” i na tej ścieżce umieścimy w formie tekstowej zasady wykonywania kroków procesu, a do tego użyjemy elementu modelującego Note – notatka.
Zatrzymamy się tutaj, chociaż dodatkowo można by jeszcze użyć ścieżki „Narzędzia” do zbierania informacji o poziomie automatyzacji procesu. Może przydać się również ścieżka „Stanowiska i jednostki uczestników”, można jej użyć do powiązania ról z stanowiskami i jednostkami uczestników procesu.
Wszystko, co właśnie opisałam, to fragment porozumienia dotyczącego modelowania, ta część porozumienia dotyczy zasad organizacji jednego diagramu oraz zasad jego pisania i czytania.
„Przepis”
Teraz rozważmy przykład modelowania systemu właśnie z diagramu aktywności. To tylko jedna z opcji, zaznaczam, że nie jest to jedyna. Diagram Activity będzie nas interesował z punktu widzenia jego roli w przejściu od modelowania procesu do projektowania zautomatyzowanego systemu. W tym celu będziemy się trzymać zaleceń metodycznych – swoistego przepisu, który składa się z pięciu etapów i przewiduje opracowanie trzech rodzajów diagramów. Zastosowanie tego przepisu pomoże uzyskać sformalizowany opis procesu, który chcemy zautomatyzować, oraz zgromadzić dane potrzebne do projektowania systemu. A dla studentów na początku nauki UML to swoisty koło ratunkowe, które nie pozwoli im utonąć w różnorodności środków przedstawiania i technik, które są w UML i nowoczesnych narzędziach modelowania.
Oto właściwie sam przepis, a następnie pojawiają się diagramy stworzone dla naszej "baśniowej" dziedziny tematycznej.
Etap 1. Opisujemy proces w formie diagramu Activity. W przypadku procesu, w którym wyróżniono ponad 10 kroków, warto zastosować zasadę dekompozycji kroków procesu, aby poprawić czytelność diagramu.
Etap 2. Wydzielamy to, co można zautomatyzować (kroki mogą być na przykład wyróżnione na diagramie).
Etap 3. Krok, który ma być zautomatyzowany, należy przypisać do funkcji lub funkcji systemu (relacja może być wiele-do-wielu), rysujemy diagram Use-case. To są funkcje naszego systemu.
Etap 4. Opiszemy wewnętrzną organizację AS przy pomocy diagramu klas – Class. Ścieżka «Obiekty wejściowe i wyjściowe (dokumenty)» na diagramie Activity jest podstawą do budowania modelu obiektowego i modelu encja-relacja.
Etap 5. Przeanalizujemy notatki na ścieżce «Zasady biznesowe», dają one różnego rodzaju ograniczenia i warunki, stopniowo przekształcając się w wymagania niefunkcjonalne.
Otrzymany zbiór diagramów (Activity, Use-case, Class) daje nam sformalizowany opis w dość rygorystycznej notacji, tzn. ma jednoznaczne odczytanie. Teraz można opracować specyfikację techniczną, wyjaśniać wymagania itd.
Zacznijmy modelowanie.
Etap 1. Opisujemy proces w formie diagramu Activity
Przypomnę, że pole diagramu została uporządkowane za pomocą „pływających” torów, na każdym torze znajdują się elementy tego samego rodzaju (Rysunek 2). Poza opisanymi powyżej elementami diagramu użyjemy dodatkowych, które teraz opiszemy.
Decyzja (Decision) oznacza na diagramie punkt rozwidlenia naszego procesu, a złączenie przepływów (Merge) – punkt ich połączenia. Warunki przejścia są zapisane w kwadratowych nawiasach na przejściach.
Pomiędzy dwoma synchronizatorami (Fork) pokażemy równoległe gałęzie procesu.
Nasz proces może mieć tylko jeden początek – jeden punkt wejścia (Initial). Natomiast zakończeń (Final) może być kilka, ale nie w naszym konkretnym diagramie.
Strzałek powstaje dość dużo, przy dużej liczbie elementów i powiązań można najpierw wydzielić etapy procesu, a potem już przeprowadzać dekompozycję tych etapów. Ale nasz „baśniowy” proces chciałbym dla przejrzystości pokazać w całości na jednym diagramie, przy tym oczywiście należy dążyć do tego, aby strzałki „się nie sklejały”, żeby można było dokładnie śledzić, co z czym jest powiązane.
Rysunek 2. Diagram aktywności – ogólny widok procesu
Ponieważ w wersach wiersza niektóre szczegóły procesu zostały pominięte, trzeba je było uzupełnić, są pokazane jako elementy z białym tłem. Szczegóły te obejmują krok „Przekazania/przyjęcia do przechowania i przetwarzania” oraz kilka wejściowych i wyjściowych artefaktów. Warto zauważyć, że ten krok także nie w pełni opisuje proces, ponieważ musielibyśmy osobno oznaczyć krok przekazania i krok przyjęcia, a także dla muszli dodać osobny krok, a także domyślić się, że wszystkie te materialne wartości muszą gdzieś tymczasowo być przechowywane itd.
Zwróćmy też uwagę, że na razie pozostaje bez odpowiedzi pytanie o pochodzenie orzechów – skąd się biorą i jak trafiają do wiewiórki? I to pytanie (wyróżnione czerwoną czcionką w przypisie – element Notatka) wymaga osobnego opracowania! Tak pracuje analityk – zbierając informacje po kawałku, formułując przypuszczenia i uzyskując „okej” lub „nie-okej” od ekspertów z danej dziedziny – osób niezwykle ważnych i po prostu niezastąpionych na etapie modelowania biznesowego przy tworzeniu systemów.
Zwróćmy również uwagę, że krok procesu P5 składa się z dwóch części.
Każdą część dekompozycjonujemy i omawiamy szczegółowo (Rysunek 3, Rysunek 4), ponieważ działania podejmowane w ramach tych kroków będą zautomatyzowane.
Rysunek 3. Diagram aktywności – szczegółowe rozbicie (część 1)
Rysunek 4. Diagram aktywności – szczegółowe rozbicie (część 2)
Etap 2. Wydzielamy to, co można zautomatyzować
Kroki przeznaczone do automatyzacji na diagramach wyróżniono kolorem (patrz Rysunek 3, Rysunek 4).
Wszystkie zadania wykonuje jeden uczestnik procesu – Diak rozkazujący:
- Wprowadza informacje o wadze orzecha do arkusza;
- Wprowadza informacje o przekazaniu orzecha do arkusza;
- Dokumentuje fakt przekształcenia orzecha w skorupki i rdzeń;
- Wprowadza informacje o rdzeniu orzecha do arkusza;
- Wprowadza informacje o skorkach orzecha do arkusza.
Analiza wykonanej pracy. Co dalej?
Zrealizowaliśmy dużą część przygotowawczą: zebraliśmy informacje o procesie, który zamierzamy zautomatyzować; zaczęliśmy tworzyć umowę modelowania (na razie tylko w zakresie wykorzystania diagramu aktywności); przeprowadziliśmy modelowanie procesu i dokonaliśmy dekompozycji kilku jego kroków; wyróżniliśmy kroki procesu, które zamierzamy zautomatyzować. Teraz możemy przejść do następnych etapów i rozpocząć projektowanie funkcji systemu oraz jego wewnętrznej organizacji.
Jak wiadomo, teoria bez praktyki jest niczym. Należy koniecznie spróbować "modelowania" we własnym zakresie, to korzystne dla zrozumienia zaproponowanego podejścia. Na przykład, można pracować w środowisku modelowania [3]. Zdekomponowaliśmy tylko część kroków diagramu ogólnego procesu (patrz Rysunek 2). Jako zadanie praktyczne można zaproponować powtórzenie wszystkich diagramów w środowisku Modelio i dokonanie dekompozycji kroku „Przekazanie/przyjęcie do przechowania i przetwarzania”.
Pracę w konkretnych środowiskach modelowania na razie pomijamy, ale może to być przedmiotem oddzielnych artykułów i przeglądów.
W drugiej części artykułu omówimy techniki modelowania i projektowania, które będą niezbędne w etapach 3-5, będziemy stosować diagramy UML Use-case i Class. Ciąg dalszy nastąpi.
Lista źródeł
- Strona „UML2.ru”. Forum Społeczności Analityków. Sekcja ogólna. Przykłady. Przykłady bajek, przedstawionych w formie diagramów UML. [Źródło elektroniczne] Tryb dostępu: Internet:
- Strona Sparx Systems. [Zasób elektroniczny] Dostęp: Internet:
- Strona Modelio. [Źródło elektroniczne] Tryb dostępu: Internet:
- Wielki Słownik Encyklopedyczny. Proces (interpretacja). [Zasób elektroniczny] Tryb dostępu: Internet:
- Strona „Organizacja efektywnego zarządzania”. Blog. Kategoria „Zarządzanie procesami biznesowymi”. Definicja procesu biznesowego. [Zasób elektroniczny] Tryb dostępu: Internet:
- Świadectwo nr 18249 o rejestracji i depozycie utworu wynikającego z działalności intelektualnej. Alfimow R.W., Złotuchina E.B., Krasnikowa S.A. Rękopis podręcznika zatytułowanego „Modelowanie obszaru tematycznego przy użyciu Enterprise Architect” // 2011 r.
- Złotuchina E.B., Wiśnia A.S., Krasnikowa S.A. Modelowanie procesów biznesowych. — M.: KURS, Naukowe Centrum INFRA-M, EBS Znanium.com. — 2017.
Źródło: habr.com
