„Jeden dzień z życia wiewiórki” czyli od modelowania procesów do zaprojektowania zautomatyzowanego systemu rozliczania majątku trwałego „Belka-1.0” (część 1)
Co ma z tym wspólnego „wiewiórka”?
Od razu wyjaśnię, co ma z tym wspólnego „wiewiórka”. Natknąwszy się w Internecie na ciekawe projekty do nauki języka UML opartego na tematyce zapożyczonej z bajek (np. [1]), postanowiłem także przygotować podobny przykład dla moich uczniów, aby na początek mogli uczyć się tylko trzech typów diagramów: diagramu aktywności, diagramu przypadków użycia i diagramu klas. Celowo nie tłumaczę nazw diagramów na język rosyjski, aby uniknąć sporów o „trudności w tłumaczeniu”. Wyjaśnię do czego to służy nieco później. W tym przykładzie używam frameworku Enterprise Architect australijskiej firmy [2] – dobre narzędzie za rozsądną cenę. I w ramach swoich treningów wykorzystuję [3], dobre darmowe narzędzie do projektowania obiektowego, które obsługuje standardy UML2.0 i BPMN, bez zbędnych bajerów pod względem możliwości wizualnych, ale w zupełności wystarczające do nauki podstaw języka.
Zamierzamy zautomatyzować powstającą w tych procesach czynność rozliczania majątku materialnego.
...
Wyspa na morzu leży (E1, E2)
Grad na wyspach stoi (E3, E1)
Ze złotymi kopułami kościołów (E4)
Z wieżami i ogrodami; (E5, E6)
Świerk rośnie przed pałacem, (E7, E8)
A pod nim jest kryształowy dom; (E9)
Mieszka tam wiewiórka, oswojona, (A1)
Tak, co za artysta! (A1)
Wiewiórka śpiewa piosenki (P1, A1)
Tak, gryzie wszystkie orzechy, (P2)
A orzechy nie są proste, (C1)
Wszystkie muszle są złote, (C2)
Jądra czystego szmaragdu; (C3)
Słudzy pilnują wiewiórki, (P3, A2)
Służcie jej jako słudzy różnego rodzaju (P4)
I przydzielono urzędnika (A3)
Ścisłe zestawienie wiadomości o orzechach; (P5, C1)
Oddaje honor swojej armii; (P6, A4)
Z muszli wylewa się monetę, (P7, C2, C4)
Niech krążą po świecie; (P8)
Dziewczęta rzucają szmaragdem (P9, A5, C3)
W spiżarniach, ale pod korcem; (E10, E11)
...
(A.S. Puszkin „Opowieść o carze Saltanie, jego chwalebnym i potężnym bohaterze, księciu Guidonie Saltanowiczu i pięknej księżniczce Łabędzi”, — Swoją drogą, od koncepcji do publikacji minęło 10 lat!)
Trochę o kodach zapisanych po prawej stronie linii. „A” (od „Aktor”) oznacza, że w wierszu znajdują się informacje o uczestniku procesu. „C” (od „Klasa”) – informacja o obiektach klasy, które są przetwarzane podczas wykonywania procesów. „E” (od „Środowisko”) – informacja o obiektach klas charakteryzujących środowisko wykonywania procesów. „P” (od „Proces”) – informacja o samych procesach.
Notabene, dokładna definicja procesu również pretenduje do bycia powodem sporów metodologicznych, choćby ze względu na fakt, że istnieją różne procesy: biznesowy, produkcyjny, technologiczny itp. i tak dalej. (można dowiedzieć się np. [4] i [5]). Aby uniknąć kontrowersji, ustalmy to Interesuje nas proces z punktu widzenia jego powtarzalności w czasie i konieczności automatyzacji, tj. przeniesienie realizacji dowolnej części operacji procesowych do zautomatyzowanego systemu.
Uwagi dotyczące korzystania z diagramu aktywności
Zacznijmy modelować nasz proces i wykorzystajmy do tego diagram aktywności. Na początek wyjaśnię, w jaki sposób powyższe kody zostaną wykorzystane w modelu. Łatwiej to wyjaśnić na przykładzie graficznym, ale jednocześnie przeanalizujemy niektóre (prawie wszystkie potrzebne) elementy diagramu aktywności.
Przeanalizujmy następujący fragment:
...
Wiewiórka śpiewa piosenki (P1, A1)
Tak, gryzie wszystkie orzechy, (P2)
A orzechy nie są proste, (C1)
Wszystkie muszle są złote, (C2)
Jądra czystego szmaragdu; (C3)
...
Mamy dwa etapy procesu P1 i P2, uczestnika A1 oraz obiekty trzech różnych klas: do kroku wprowadzany jest obiekt klasy C1, w wyniku działania tego kroku P2 naszego procesu wyprowadzane są obiekty klas C3 i C2. proces. Na diagramie używamy następujących elementów modelujących.
Fragment naszego procesu można przedstawić mniej więcej tak (Rysunek 1).
Rysunek 1. Fragment diagramu aktywności
Aby uporządkować przestrzeń i ustrukturyzować diagram aktywności, zastosujemy podejście niestandardowe, z punktu widzenia klasycznego zastosowania notacji UML. Ale jest ku temu kilka powodów. W pierwszej kolejności tuż przed rozpoczęciem modelowania skompilujemy tzw umowa modelowa, w którym rejestrujemy wszystkie cechy stosowania notacji. Po drugie, podejście to zostało wielokrotnie z powodzeniem zastosowane na etapie modelowania biznesowego w rzeczywistych projektach tworzenia systemów oprogramowania, a wyniki zostały zapisane przez nasz niewielki zespół autorów w odpowiednim obiekcie autorskim [6], a także wykorzystane w podręczniku szkoleniowym [7]. XNUMX]. W przypadku diagramu aktywności definiujemy, że struktura pola diagramu opiera się na „torach pływania”. Nazwa ścieżki będzie odpowiadać rodzajowi elementów wykresu, które zostaną umieszczone na tej ścieżce.
„Artefakty wejściowe i wyjściowe”: Ta ścieżka będzie zawierać elementy Obiekty - obiekty, które są używane lub są wynikiem wykonania jakiegoś etapu procesu.
„Etapy procesu”: Tutaj będziemy umieszczać elementy Aktywności – działania uczestników procesu.
"Uczestnicy": ścieżkę dla elementów, które będą wyznaczać role wykonawców akcji w naszym procesie, dla nich użyjemy tego samego elementu modelującego Obiekt - obiekt, ale dodamy do niego stereotyp „Aktora”.
Następny utwór się nazywa „Zasady biznesowe” i na tej ścieżce umieścimy w formie tekstowej zasady wykonywania poszczególnych etapów procesu i w tym celu wykorzystamy element modelujący Notatka - notatka.
Zatrzymamy się tutaj, chociaż ścieżkę też moglibyśmy wykorzystać "Narzędzia" zbieranie informacji o poziomie automatyzacji procesów. Ścieżka też może się przydać „Stanowiska i podziały uczestników”można go wykorzystać do powiązania ról ze stanowiskami i działami uczestników procesu.
Wszystko, co właśnie opisałem, jest fragmentem konwencje modelarskie, ta część umowy dotyczy zasad organizacji jednego diagramu i w związku z tym zasad jego pisania i czytania.
"Przepis"
Rozważmy teraz opcję konkretnego modelowania systemu z diagramu aktywności. To tylko jedna z opcji, zaznaczam, że oczywiście nie jedyna. Diagram aktywności zainteresuje nas z punktu widzenia jego roli w przejściu od modelowania procesów do projektowania zautomatyzowanego systemu. Aby to zrobić, będziemy przestrzegać zaleceń metodologicznych - swego rodzaju przepisu składającego się tylko z pięciu etapów i przewidującego opracowanie tylko trzech rodzajów diagramów. Korzystanie z tej receptury pomoże nam uzyskać sformalizowany opis procesu, który chcemy zautomatyzować i zebrać dane do projektowania systemu. A dla studentów na początku nauki UML jest to swego rodzaju ratunek, który nie pozwoli im utonąć w całej różnorodności środków i technik wizualnych, które można znaleźć w UML i nowoczesnych narzędziach do modelowania.
Oto sam przepis, a następnie postępuj zgodnie ze schematami zbudowanymi dla naszego „bajkowego” obszaru tematycznego.
Etap 1. Proces opisujemy w formie diagramu aktywności. W przypadku procesu składającego się z więcej niż 10 kroków sensowne jest zastosowanie zasady dekompozycji etapów procesu, aby poprawić czytelność diagramu.
Etap 2. Wybierz, co można zautomatyzować (kroki można na przykład zaznaczyć na schemacie).
Etap 3. Zautomatyzowanemu krokowi należy przypisać funkcję lub funkcje systemu (relacja może być wiele do wielu), narysuj diagram przypadków użycia. To są funkcje naszego systemu.
Etap 4. Opiszmy wewnętrzną organizację AS za pomocą diagramu klas - Klasa. Ścieżka „Obiekty wejściowe i wyjściowe (dokumenty)” na diagramie aktywności jest podstawą do zbudowania modelu obiektowego i modelu relacji encji.
Etap 5. Przeanalizujmy notatki na ścieżce „Zasady biznesowe”.dostarczają różnego rodzaju ograniczeń i warunków, które stopniowo przekształcają się w wymagania niefunkcjonalne.
Powstały zestaw diagramów (Aktywność, Przypadek użycia, Klasa) daje nam sformalizowany opis w dość ścisłej notacji, tj. ma jednoznaczną lekturę. Teraz możesz opracowywać specyfikacje techniczne, wyjaśniać specyfikacje wymagań itp.
Zacznijmy modelować.
Etap 1. Opisz proces w formie diagramu aktywności
Przypomnę, że strukturę pola diagramu tworzyliśmy w oparciu o „pływające” pasy, przy czym każdy tor zawiera elementy tego samego typu (Rysunek 2). Oprócz opisanych powyżej elementów diagramu wykorzystamy dodatkowe elementy, opiszemy je.
Decyzja (Decyzja) oznacza na diagramie punkt rozgałęzienia naszego procesu, a łączenie wątków (Merge) – punkt ich ponownego zjednoczenia. Warunki przejścia są zapisane w nawiasach kwadratowych przy przejściach.
Pomiędzy dwoma synchronizatorami (Fork) pokażemy równoległe gałęzie procesów.
Nasz proces może mieć tylko jeden początek – jeden punkt wejścia (Początkowy). Może jednak istnieć kilka uzupełnień (ostatecznych), ale nie w przypadku naszego konkretnego diagramu.
Strzałek jest dość dużo, przy dużej liczbie elementów i połączeń można najpierw zidentyfikować etapy procesu, a następnie dokonać dekompozycji tych etapów. Ale dla jasności chciałbym pokazać nasz „bajkowy” proces w całości na jednym schemacie, choć oczywiście musimy zadbać o to, aby strzałki „nie sklejały się”, byłoby możliwe dokładne prześledzenie tego, co jest połączone do czego.
Rysunek 2. Diagram aktywności – ogólny widok procesu
Ponieważ w wersach poetyckich pominięto pewne szczegóły procesu, należało je przywrócić, ukazują je elementy na białym tle. Szczegóły te obejmują etap przesyłania/odbioru do przechowywania i przetwarzania oraz kilka artefaktów wejściowych i wyjściowych. Warto zauważyć, że ten krok również nie ujawnia w pełni procesu, ponieważ musielibyśmy osobno wyznaczyć etap transmisji i etap odbioru, a nawet dodać osobny krok dla powłok, a także pomyśleć, że najpierw wszystkie te wartości materialne powinny być gdzieś tymczasowo przechowywane itp. i tak dalej.
Zauważmy też, że bez odpowiedzi pozostaje pytanie o pochodzenie orzechów – skąd się one biorą i jak trafiają do wiewiórki? I to pytanie (zaznaczone czerwoną czcionką w notatce - element Notatka) wymaga osobnego opracowania! Tak właśnie działa analityk – zbiera informacje krok po kroku, wyciąga wnioski i otrzymuje „ok” lub „nie” od ekspertów merytorycznych – osób bardzo ważnych i po prostu niezastąpionych na etapie modelowania biznesowego przy tworzeniu systemów.
Należy również zauważyć, że etap procesu P5 składa się z dwóch części.
Rozłożymy każdą część i rozważymy ją bardziej szczegółowo (ryc. 3, ryc. 4), ponieważ czynności wykonywane w ramach poszczególnych etapów zostaną zautomatyzowane.
Rysunek 3. Diagram aktywności – szczegóły (część 1)
Rysunek 4. Diagram aktywności – szczegóły (część 2)
Etap 2. Wybierz, co można zautomatyzować
Kroki, które należy zautomatyzować, są wyróżnione kolorem na diagramach (patrz Rysunek 3, Rysunek 4).
Wszystkie te czynności wykonuje jeden uczestnik procesu – Urzędnik:
- Wpisuje do wyciągu informację o masie orzecha;
- Wprowadza informację o przeniesieniu nakrętki do wyciągu;
- Rejestruje fakt przekształcenia orzecha w łupinę i jądro;
- Wprowadza do wyciągu informację o jądrze orzecha;
- Wprowadza do listy informacje o łupinach orzechów.
Analiza wykonanej pracy. Co dalej?
Wykonaliśmy więc dużo pracy przygotowawczej: zebraliśmy informacje o procesie, który zamierzamy zautomatyzować; zaczęto dochodzić do porozumienia w sprawie modelowania (na razie tylko w zakresie wykorzystania diagramu aktywności); przeprowadził symulację procesu, a nawet rozłożył kilka jego etapów; Zidentyfikowaliśmy etapy procesu, które zautomatyzujemy. Jesteśmy już gotowi, aby przejść do kolejnych kroków i rozpocząć projektowanie funkcjonalności systemu oraz organizacji wewnętrznej.
Jak wiadomo teoria bez praktyki jest niczym. Zdecydowanie powinieneś spróbować „modelowania” własnymi rękami, jest to również przydatne do zrozumienia proponowanego podejścia. Można na przykład pracować w środowisku modelowania [3]. Rozłożyliśmy tylko część etapów ogólnego diagramu procesu (patrz rysunek 2). W ramach praktycznego zadania możesz zostać poproszony o powtórzenie wszystkich diagramów w środowisku Modelio i wykonanie dekompozycji kroku „Przesłanie/Odbiór w celu przechowywania i przetwarzania”.
Nie rozważamy jeszcze pracy w konkretnych środowiskach modelarskich, ale może to stać się tematem niezależnych artykułów i recenzji.
W drugiej części artykułu przeanalizujemy techniki modelowania i projektowania niezbędne na etapach 3-5, wykorzystamy diagramy przypadków użycia i klas UML. Ciąg dalszy nastąpi.
Lista źródeł
- Witryna „UML2.ru”. Forum społeczności analityków. Sekcja ogólna. Przykłady. Przykłady bajek w postaci diagramów UML. [Zasoby elektroniczne] Tryb dostępu: Internet:
- Witryna firmy Sparx Systems. [Zasoby elektroniczne] Tryb dostępu: Internet:
- stronie Modelio. [Zasoby elektroniczne] Tryb dostępu: Internet:
- Wielki słownik encyklopedyczny. Proces (interpretacja). [Zasoby elektroniczne] Tryb dostępu: Internet:
- Serwis "Organizacja efektywnego zarządzania". Blog. Nagłówek „Zarządzanie procesami biznesowymi”. Definicja procesu biznesowego. [Zasoby elektroniczne] Tryb dostępu: Internet:
- Zaświadczenie nr 18249 o rejestracji i zdeponowaniu produktu będącego wynikiem działalności intelektualnej. Alfimov R.V., Zolotukhina E.B., Krasnikova SA. Rękopis pomocy dydaktycznej pt. „Modelowanie przedmiotu z wykorzystaniem Enterprise Architect” // 2011.
- Zolotukhina EB, Vishnya A.S., Krasnikova S.A. Modelowanie procesów biznesowych. - M.: KURS, NITs INFRA-M, EBS Znanium.com. — 2017 r.
Źródło: www.habr.com