Modelowanie systemów

Modelowanie systemów polega na przedstawianiu procesów, wymagań, struktury i zachowania rozwiązań IT za pomocą uzgodnionych notacji oraz diagramów. Na początku warto sprawdzić, czy celem jest analiza procesu biznesowego, opis architektury, czy dokumentowanie wymagań, a następnie dobrać odpowiednią notację i poziom szczegółowości. Przykładowo proces obsługi zgłoszenia można rozpisać na diagramie aktywności, a zależności między systemami pokazać na diagramie kontekstu.
Jeśli chcesz przećwiczyć to krok po kroku, zobacz: Modelowanie w UML.

UML i C4 służą do opisu systemów, ale rozwiązują nieco inne problemy: UML daje szeroki zestaw diagramów do modelowania struktury, dynamiki i wymagań, a C4 upraszcza komunikację architektoniczną na poziomach kontekstu, kontenerów i komponentów. W praktyce warto sprawdzić, czy odbiorcy potrzebują formalnego modelu analitycznego, czy czytelnej wizualizacji architektury dla zespołów technicznych i interesariuszy. Przykładowo diagram komponentów UML dobrze wspiera analizę relacji wewnątrz systemu, natomiast model kontenerów C4 szybciej pokazuje podział na aplikacje, bazy danych i interfejsy.
To jedno z zagadnień omawianych podczas szkolenia: Modelowanie systemów w podejściu C4.

Modelowanie w Enterprise Architect obejmuje budowanie struktury projektu, pracę na diagramach, organizowanie pakietów, wersjonowanie modeli oraz generowanie dokumentacji projektowej. Warto zacząć od uporządkowania repozytorium, nazewnictwa elementów, wzorców modeli i zasad usuwania lub modyfikowania artefaktów, bo to ogranicza błędy w pracy zespołowej. Przykładem może być projekt, w którym analitycy utrzymują osobne pakiety dla wymagań, procesów i architektury, a następnie generują z nich spójną dokumentację.
Wersję warsztatową (z konfiguracją i przykładami) znajdziesz w programie szkolenia: Efektywne modelowanie w Enterprise Architect.

Dobór diagramów UML zależy od tego, czy trzeba opisać funkcje systemu, strukturę danych, interakcje czy cykl życia obiektów. Najpierw należy ustalić, które pytania mają rozstrzygać modele: przypadki użycia porządkują wymagania funkcjonalne, diagramy klas opisują pojęcia i relacje, diagramy sekwencji pokazują przebieg interakcji, a diagramy stanów odwzorowują zmiany statusów. Przykładowo dla procesu obsługi zamówienia można połączyć przypadki użycia z diagramem sekwencji i diagramem stanów dokumentu.
Ten temat przerabiamy praktycznie na szkoleniu: Modelowanie w UML – poziom zaawansowany.

Process Mining to podejście oparte na danych zdarzeniowych, które odtwarza rzeczywisty przebieg procesów i pozwala analizować warianty, opóźnienia oraz odchylenia od modelu referencyjnego. Przed zastosowaniem tej metody trzeba sprawdzić jakość logów, identyfikatory spraw, znaczniki czasu i dostępność danych o zasobach, ponieważ to one decydują o wiarygodności wyników. Przykładem jest analiza procesu zakupowego, w której mapa procesu ujawnia dodatkowe ścieżki akceptacji i wąskie gardła niewidoczne w dokumentacji opisowej.
Dokładnie ten zestaw narzędzi i workflow ćwiczymy podczas szkolenia: Process Mining Essentials.

Najczęstsze błędy w modelowaniu systemów to mieszanie poziomów abstrakcji, niespójne nazewnictwo, zbyt duża liczba elementów na diagramie oraz brak powiązania modeli z wymaganiami i dokumentacją. W praktyce warto weryfikować cel każdego diagramu, stosować jednolite reguły dekompozycji, kontrolować relacje między artefaktami i regularnie przeglądać modele pod kątem czytelności dla zespołu. Przykładem błędu jest umieszczenie szczegółów implementacyjnych na diagramie kontekstu, który powinien pokazywać wyłącznie granice systemu i jego otoczenie.
To jedno z zagadnień omawianych podczas szkolenia: Modelowanie systemów w podejściu C4.