W poprzednim wpisie opisałem modelowanie przypadków użycia (Use Case) w oparciu o Structured Scenarios. Dzisiaj uzupełnimy ten przykład w taki sposób, aby przypadku użycia opisujące daną funkcjonalność wzbogacić o szereg aspektów technicznych, których zamodelowanie jest niezbędne dla wytworzenia oprogramowania wysokiej jakości.

Logowanie zdarzeń

Model domeny logów

Na pierwszy ogień spróbujmy zidentyfikować i zamodelować logi jakie w naszym systemie będą odkładane. Poniższy diagram klas prezentuje klasę Log po której dziedziczą pozostałe typy logów zawierające specyficzne atrybuty:

Log Techniczny – zawiera komplet informacji technicznych umożliwiających diagnozę i śledzenie działania aplikacji na najniższym poziomie. Szczególnie przydatny na środowiskach innych niż produkcja.

Log Audytu – zawiera informacje biznesowe pozwalające osobie przeglądającej dzienniki zdarzeń zrozumieć działanie wykonywanych przez system operacji. Prawidłowo zamodelowane logi audytu powinny dawać możliwość dokładnego prześledzenia i skorelowania każdego obsłużonego requestu. W naszym przykładzie identyfikatorem korelacji jest atrybut przechowujący identyfikatorZdarzeniaInicjującego. W zależności od systemu, może być konieczność zapewnienia wyższego poziomu bezpieczeństwa odkładanym dziennikom zdarzeń, dlatego już na etapie wytwarzania oprogramowania warto zadbać o zapewnienie integralności odkładanych logów. O ile przy logach technicznych nie ma to sensu, o tyle dla logów audytu warto rozważyć implementację podpisu elektronicznego pod skrótem z poprzedniego logu (hashPoprzedniegoLogu). Pamiętajmy, że wytwarzamy oprogramowanie zwinnie, dlatego zapewnienie tak wysokiego poziomu bezpieczeństwa logów powinno być wprost zdefiniowane przez Product Owera (PO), a nie przez zespół wytwórczy, który akurat wpadł na taki pomysł i uznał, że należy taką implementację wykonać.

Log Danych Osobowych – zawiera informacje pozwalające jednoznacznie zidentyfikować moment pozyskania lub udostępnienia danych osobowych. Powinien zawierać pełne i szczegółowe metadane opisujące dane osobowe, ale sam w sobie nie powinien ich zawierać. Czyli na przykład w logu danych osobowych możemy znaleźć informacje, że dla danego identyfikatora XYZ, zostały pozyskane następujące dane osobowe: imię, nazwisko, adres e-mail oraz numer telefonu.

Modelowanie logów audytu

Posiadając w miarę generyczny model logów zdarzeń, warto uzupełnić przygotowany w poprzednim wpisie przypadek użycia (UC.UiA.0001) o konkretne logi audytu. W tym celu tworzymy nowy diagram klas reprezentujący logiczny model danych w domenie logów (przeciągamy UC.UiA.0001 Logowanie na diagram jako Link), a następnie znajdujemy klasę LogAudytu i przeciągamy ją na utworzony przed chwilą diagram wybierając ustawienia Instance (Object) tak jak na rysunku poniżej:

Następnie zaznaczamy utworzony obiekt logu audytu i wpisujemy jego nazwę (Properties > Name): LA.MUiA.0001 – krok 3. Teraz mając oba artefakty (UC oraz instancję logu audytu) na diagramie, linkujemy je relacją Dependency. Możemy przystąpić do wpisywania konkretnych wartości (Properties > Run States)jakie powinny odłożyć się podczas realizacji kroku 3 wspomnianego przypadku użycia:

Po zidentyfikowaniu i opisaniu wszystkich potencjalnych logów audytu, diagram powinien wyglądać następująco:

Do kompletnego zamodelowania logów, brakuje jeszcze tylko uzupełnienia kroków przypadku użycia o nowo powstałe instancje logów audytu. Dodanie odnośników realizujemy ustawiając kursor w kolumnie Results i z menu prawego przycisku myszy wybierając Insert context reference:

W wyświetlonym oknie wybieramy odpowiedni log audytu:

Finalnie powinniśmy otrzymać następujący wygląd przypadku użycia UC.UiA.0001 Logowanie:

We wcześniejszych wpisach przedstawiłem:

• Modelowanie przypadków użycia (use case)

W następnych wpisach będę chciał przedstawić kolejno:

• Modelowanie komunikatów oraz innych obiektów takich jak np. okna GUI
• Modelowanie interfejsów i mapowanie UC na operacje
• Wywołanie operacji na diagramach sekwencji
• Przygotowanie modelu architektury i jej widoku wdrożeniowego w wariancie HA
• Generowanie definicji operacji REST (Swagger) na podstawie zamodelowanego interfejsu