„Jeden dzień z życia wiewiórki” czyli od modelowania procesów do zaprojektowania zautomatyzowanego systemu rozliczania majątku trwałego „Belka-1.0” (część 2)
Podsumowanie poprzedniej serii
В wykorzystaliśmy domenę „bajkową” inspirowaną przykładami studiowania diagramów UML na podstawie bajkowych wątków (patrz np. [1]). Przed przystąpieniem do modelowania zgodziliśmy się na wykorzystanie niektórych elementów Diagramu aktywności i zaczęliśmy formułować umowę dotyczącą modelowania. Biorąc pod uwagę te uzgodnienia, w I etapie opisaliśmy proces w postaci Diagramów czynności, a w II etapie zidentyfikowaliśmy etapy procesu, dla których wymagana jest (i możliwa) automatyzacja.
Przypomnę, że zamierzamy zautomatyzować czynność rozliczania wartości materialnych, która powstaje w tych procesach.
...
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 Sałtanie, jego chwalebnym i potężnym synu, księciu Gwidonie Saltanowiczu i pięknej księżniczce łabędzi”, )
W tym przykładzie używam środowiska Enterprise Architect z australijskiej firmy. [2], oraz w ramach szkoleń korzystam [3].
Przypomnę, że procesy są różne, możesz zapoznać się np. [4] i [5].
Zobacz [6, 7], aby uzyskać szczegółowe informacje na temat zastosowanych podejść do modelowania i projektowania.
Aby zapoznać się z pełną specyfikacją UML, zobacz [8].
Jesteśmy teraz gotowi do przejścia do kolejnych kroków i rozpoczęcia projektowania funkcji systemu oraz jego wewnętrznej organizacji. Numeracja rysunków będzie kontynuowana.
Etap 3. Zautomatyzowanemu krokowi należy przypisać funkcję lub funkcje systemu
Opracowywany zautomatyzowany system (AS) jest przeznaczony do ścisłego rejestrowania orzechów, pamiętasz? Dla każdego wyróżnionego kroku (patrz Rysunek 3, Rysunek 4 ), które zautomatyzujemy, zapiszemy wymaganie funkcjonalne, używając czegoś w rodzaju tej konstrukcji „System musi być w stanie…” i opracujemy diagram przypadków użycia. Teraz właściwie uzupełniamy naszą umowę modelarską o nowe zasady. Wyjaśnię, jakich elementów użyjemy.
Pomiędzy „Rolą użytkownika” a „Funkcją” wykorzystamy zależność „Powiązanie” (Rysunek 5), co oznacza, że użytkownik z tą rolą może pełnić tę funkcję.
Rysunek 5. Używanie relacji typu asocjacji
Od „Funkcji” do „Wymagania” narysujemy link „Implementacja” (Rysunek 6), aby pokazać, że to wymaganie zostanie zaimplementowane przez te funkcje, relacja może być „wiele do wielu”, tj. jedna funkcja może być zaangażowana we wdrażanie kilku wymagań, a do wdrożenia wymagania może być potrzebna więcej niż jedna funkcja.
Rysunek 6. Korzystanie z relacji implementacji
Jeżeli jedna funkcja wymaga do wykonania jakiejś innej funkcji, a bądźmy pewni, zastosujemy połączenie „Zależność” ze stereotypem „Zawiera” – inkluzja (Rysunek 7). Jeśli wykonanie dodatkowej funkcji jest wymagane pod pewnymi warunkami, wówczas użyjemy połączenia „Zależność” ze stereotypem „Rozszerz” - rozszerzeniem. Wszystko jest bardzo łatwe do zapamiętania: „Uwzględnij” – ZAWSZE, a „Rozszerz” – CZASAMI.
Rysunek 7. Używanie łącza typu „Zależność (włącz)”
W rezultacie nasz diagram będzie wyglądał mniej więcej tak (Rysunek 8).
Rysunek 8. Diagram przypadków użycia (model funkcjonalny AS)
Dodatkowo diagram przypadków użycia służy do modelowania ról użytkowników (Rysunek 9).
Rysunek 9. Diagram przypadków użycia (role użytkowników AS)
Etap 4. Opiszmy wewnętrzną organizację AS za pomocą diagramu klas
Korzystając z informacji o artefaktach wejściowych i wyjściowych naszego procesu (patrz Diagramy aktywności – Rysunek 2, Rysunek 3, Rysunek 4), opracujemy diagram klas. Posłużymy się elementami modelowania „Klasa” i różnego rodzaju relacjami między nimi.
Aby pokazać relację „całość-część”, użyjemy relacji typu „Agregacja” (Rysunek 10): orzech to całość, a łupiny i jądro to części.
Rysunek 10. Relacja część-całość
W rezultacie fragment naszego diagramu będzie wyglądał mniej więcej tak (Rysunek 11). Klasy są oznaczone kolorem, który podkreśliliśmy bezpośrednio w tekstowym opisie procesu.
Rysunek 11. Diagram klas
Diagram klas posłużył również do modelowania innych artefaktów – nie tylko tych, które będą istotne dla modelu koncepcyjnego zautomatyzowanego procesu inwentaryzacji, ale związanych ze środowiskiem wykonawczym – środowiskiem (Rysunek 12) i procesami „sąsiednimi” (Rysunek 13) które mogą mieć wpływ na zautomatyzowany proces, ale nie są jeszcze w centrum naszej uwagi (zakładamy, że system będzie się rozwijał i te informacje będą przydatne).
Rysunek 12. Diagram klas (środowisko)
Relacja dziedziczenia pokazuje uogólnienie różnych budynków, klas „podrzędnych”, w uogólnionej klasie „rodzic” „Budynek”.
Rysunek 13. Diagram klas (więcej informacji o artefaktach)
„Reakcja na sytuację” zależy od „Danych kontroli wizualnej”. Dla kilku relacji zależności stereotyp „śledzenia” służy do pokazania śledzenia klas, które nie są wyraźnie wskazane w opisie procesu, ale które są niezbędne do jego automatyzacji, do klas, których instancje są dokładnie wskazane w naszym opisie.
Etap 5. Przeanalizujmy notatki na ścieżce „Zasady biznesowe”.
Jak określono zasady (patrz rysunek 2 ):
- konieczność podzielenia jednego z kroków na 2 części, druga część zaczyna być wykonywana tylko pod pewnymi warunkami;
- wyznaczenie określonego urzędnika do prowadzenia księgowości orzechów;
- technika (biały kolor elementów), która wskazuje, że pierwiastek nie został wyraźnie wymieniony w opisie procesu.
Należy zauważyć, że przy opracowywaniu diagramów stosowaliśmy już wszystkie te zasady.
Uwagi końcowe
Przeszliśmy więc przez 5 etapów i zbudowaliśmy 3 rodzaje diagramów. Dodam jeszcze jedną uwagę dotyczącą organizacji naszych modeli w środowisku modelarskim. Istnieje wiele frameworków, które pomagają ustrukturyzować opracowywane przez nas modele, ale nie jest to tematem tego artykułu, więc ograniczymy się do następującego prostego zestawu pakietów do uporządkowanego utrzymania naszego projektu: Proces biznesowy, Model funkcjonalny, Artefakty, uczestnicy i środowisko (ryc. 14).
Rysunek 14. Struktura pakietów projektów
W ten sposób opracowaliśmy spójne modele opisujące system rozliczania aktywów rzeczowych z różnych perspektyw: model zautomatyzowanego procesu biznesowego, model funkcjonalny oraz model organizacji wewnętrznej systemu na poziomie koncepcyjnym.
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.
- Specyfikacja ujednoliconego języka modelowania OMG (OMG UML). Wersja 2.5.1. [Zasoby elektroniczne] Tryb dostępu: Internet:
Źródło: www.habr.com