Dzień z życia wiewiórki” lub od modelowania procesów do projektowania zautomatyzowanego systemu ewidencji wartości materialnych „Wiewiórka-1.0” (Część 2)
Krótka treść poprzedniego odcinka
W Wykorzystaliśmy bajkowy obszar przedmiotowy, inspirowani przykładami studiowania diagramów UML na podstawie fabuł bajek (zob. na przykład, [1]). Przed rozpoczęciem modelowania uzgodniliśmy użycie niektórych elementów diagramu Activity i zaczęliśmy formułować porozumienie dotyczące modelowania. Z uwzględnieniem tych ustaleń, na etapie 1 opisaliśmy proces w postaci diagramów Activity, a na etapie 2 wyodrębniliśmy kroki procesu, dla których wymagana jest (i możliwa) automatyzacja.
Przypominam, że chcemy zautomatyzować działalność związaną z ewidencją wartości materialnych, która pojawia się 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 wspaniałym i potężnym synu księciu Gwidonie Saltanowiczu oraz o pięknej księżniczce Łabędzi”, )
W tym przykładzie korzystam z środowiska Enterprise Architect firmy Sparx Systems z Australii. [2], a w ramach zajęć edukacyjnych stosuję [3].
Przypominam, że procesy są różne, można się zapoznać na przykład, [4] i [5].
Więcej o stosowanych podejściach do modelowania i projektowania zob. [6, 7].
Pełną specyfikację UML można znaleźć w. [8].
Teraz jesteśmy gotowi przejść do kolejnych etapów i rozpocząć projektowanie funkcji systemu oraz jego wewnętrznej organizacji. Numeracja rysunków będzie kontynuowana.
Etap 3. Krok, który ma być zautomatyzowany, należy przypisać do funkcji lub funkcji systemu
Opracowywany zautomatyzowany system (ZS) jest przeznaczony do prowadzenia ścisłej ewidencji orzechów, pamiętasz? Dla każdego wyodrębnionego kroku (zob. Rysunek 3, Rysunek 4 ), który będziemy automatyzować, zapiszemy wymaganie funkcjonalne, stosując mniej więcej taką konstrukcję „W systemie powinna być zrealizowana możliwość ...” i opracujemy diagram Use-case. Obecnie właściwie uzupełniamy nasze porozumienie dotyczące modelowania nowymi zasadami. Wyjaśnię, jakie elementy będziemy stosować.
Między „Rolą użytkownika” a „Funkcją” będziemy stosować związek „Asocjacja” (Rysunek 5), co oznacza, że dla użytkownika z daną rolą dostępne jest wykonywanie danej funkcji.
Rysunek 5. Wykorzystanie połączenia typu „Asocjacja”
Od „Funkcji” do „Wymagania” przeprowadzimy połączenie „Realizacja” (Rysunek 6), aby pokazać, że to wymaganie będzie realizowane przez te funkcje; relacja może być także „wiele-do-wielu”, tzn. jedna funkcja może uczestniczyć w realizacji wielu wymagań, a do zrealizowania wymogu może być potrzebnych więcej niż jedna funkcja.
Rysunek 6. Wykorzystanie połączenia typu „Realizacja”
Jeśli jedna funkcja wymaga, aby inna funkcja została zrealizowana, i to obowiązkowo, użyjemy połączenia „Zależność” ze stereotypem „Include” – włączenie (Rysunek 7). Jeśli natomiast realizacja dodatkowej funkcji jest wymagana w określonych warunkach, użyjemy połączenia „Zależność” ze stereotypem „Extend” – rozszerzenie. To bardzo łatwe do zapamiętania: „Include” – ZAWSZE, a „Extend” – CZASAMI.
Rysunek 7. Wykorzystanie połączenia typu „Zależność (włączenie)”
W rezultacie nasza diagram będzie wyglądał mniej więcej tak (Rysunek 8).
Rysunek 8. Diagram Use-case (model funkcjonalny AS)
Ponadto, diagram Use-case jest używany do modelowania ról użytkowników (Rysunek 9).
Rysunek 9. Diagram Use-case (role użytkowników AS)
Etap 4. Opiszemy wewnętrzną organizację AS przy pomocy diagramu klas
Wykorzystując informacje o wejściowych i wyjściowych artefaktach naszego procesu (zob. diagramy Activity – Rysunek 2, Rysunek 3, Rysunek 4), opracujemy diagram klas. Użyjemy modelujących elementów „Klasa” oraz różnych rodzajów połączeń między nimi.
Aby pokazać relację „całość-część”, użyjemy połączenia typu „Agregacja” (Rysunek 10): orzech jest całością, a skorupki i rdzeń to części.
Rysunek 10. Relacja „całość-część”
W rezultacie fragment naszej diagramu będzie wyglądał mniej więcej tak (Rysunek 11). Kolorem zaznaczone są klasy, które wyróżniliśmy w bezpośrednim opisie procesu.
Rysunek 11. Diagram klas
Diagram klasów był również używany do modelowania innych artefaktów – nie tylko tych, które mają związek z koncepcyjnym modelem automatyzowanego procesu ewidencji wartości materialnych, ale również związanych z środowiskiem wykonawczym – otoczeniem (Rysunek 12) oraz „sąsiednimi” procesami (Rysunek 13), które mogą wpływać na automatyzowany proces, ale obecnie nie są w centrum naszej uwagi (zakładamy, że system będzie się rozwijał, a te informacje będą przydatne).
Rysunek 12. Diagram klas (otoczenie)
Związek dziedziczenia pokazuje uogólnienie różnych konstrukcji, „klasy potomne”, pod uogólnioną „klasą rodzicielską” „Budowla”.
Rysunek 13. Diagram klas (dodatkowe informacje o artefaktach)
„Reakcja na sytuację” zależy od „Danych wizualnej kontroli”. Dla kilku związków zależności używany jest stereotyp „trace”, aby pokazać śledzenie klas, które nie zostały wyraźnie oznaczone w opisie procesu, ale które są niezbędne do jego automatyzacji, do klas, na które wzmianka jest w naszym opisie.
Etap 5. Przeanalizujemy notatki na ścieżce «Zasady biznesowe»
Zasady były wskazane (patrz Rysunek 2 ):
- konieczność podziału jednego z kroków na 2 części, druga część zaczyna być realizowana tylko w określonych warunkach;
- przeznaczenie do ewidencji orzechów konkretnego pracownika;
- technika techniczna (biały kolor elementów), która wskazuje, że element nie został wyraźnie określony w opisie procesu.
Należy zauważyć, że wszystkie te zasady już wykorzystaliśmy przy tworzeniu diagramów.
Uwagi końcowe
Przeszliśmy przez 5 etapów i zbudowaliśmy 3 rodzaje diagramów. Dodam jeszcze krótki komentarz na temat organizacji naszych modeli w środowisku modelowania. Istnieje wiele ram, które pomagają strukturalizować opracowywane modele, ale to nie jest temat tego artykułu, dlatego ograniczymy się do prostego zestawu pakietów dla uporządkowanego prowadzenia naszego projektu: Proces biznesowy, Model funkcjonalny, Artefakty, Uczestnicy i Otoczenie (Rysunek 14).
Rysunek 14. Struktura pakietów projektu
Opracowaliśmy zatem zgodne modele opisujące system zarządzania zasobami materialnymi z różnych perspektyw: model automatyzowanego procesu biznesowego, model funkcjonalny oraz model wewnętrznej organizacji systemu na poziomie koncepcyjnym.
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.
- OMG Unified Modeling Language (OMG UML) Specyfikacja. Wersja 2.5.1. [Zasób elektroniczny] Dostęp: Internet:
Źródło: habr.com
