Mapowania wychodzące poza notację UML

Język UML jest notacją, o której wiele mówi się, ale jej zakres używania nie jest oczywisty. Diagramów jest zwyczajnie zbyt wiele. Oczywiste jest to, że mimo bogactwa notacji, w projektach nie stosuje się ich wszystkich. Stosując zasadę, że modelujemy tylko istotne rzeczy, sam też tak nie robię. Do modelowania wspomnianych istotnych rzeczy dobieram odpowiednie diagramy.

Na stronie diagramy UML opublikowałem linki do technik UML, które stosuję najczęściej. A są nimi:

• diagram przypadków użycia,
• diagram pakietów,
• diagram klas,
• diagram aktywności,
• diagram maszyny stanowej,
• diagram sekwencji,
• diagram komponentów.

Dodatkowo dochodzą wymagania i inne notacje, które także są stosowane w projektach. Są to najczęściej ArchiMate oraz BPMN. W tym artykule opiszę, jak łączę UML z otoczeniem.

UML a wymagania na system

Do uszczegółowienia modeli UML wymaganiami używam mapowania opartego o relację realizacji.  Wymagania przypisuję przede wszystkim do przypadków użycia. Często, zwłaszcza jeśli chodzi o wymagania niefunkcjonalne takich jak bezpieczeństwo czy wydajność to wymaganie przypisuje do komponentu.

Warto wspomnieć o tym, że bardzo często przypadki użycia mapuje na komponenty, także relacją realizacji tak by wiadomo było w jakim module podsystemie dany przypadek użycia się znajduje. Natomiast w przedsięwzięciach, w których nie ma przypadków użycia, staram się mapować wymagania bezpośrednio na komponent – najlepiej ten który wskazuje moduł aplikacji.

UML a procesy biznesowe

Tu sytuacja jest bardzo prosta. Do każdej aktywności (czynności) z procesu biznesowego przypisuje jeden lub więcej przypadków użycia. Stosuję relację trace. W ten oto sposób wiem jakie funkcje opisane przez przypadki użycia będą wykorzystywane w danym kroku.

Gdy zaistnieje potrzeba, by pokazać jaka aplikacja albo moduł aplikacji jest wykorzystywany w czasie realizacji kroku w procesie biznesowym, mapuje komponent relacją trace z aktywnością procesu biznesowego.

UML a Archimate

Jeśli chodzi o notację ArchiMate to z punktu widzenia notacji UML istotna jest warstwa aplikacji. Zasadniczo zarówno język UML jak i wspominania warstwa opisują, na różnym poziomie abstrakcji, ten sam aspekt – strukturę aplikacji oraz jej powiązania. Z tego też powodu zazwyczaj ograniczam się do mapowania relacją trace takich elementów jak: komponent na komponent aplikacji oraz przypadek użycia na usługę aplikacji. To drugie mapowanie przewinęło się w tekście Mapowania wychodzące poza architekturę korporacyjną.

Jeśli w realizowanym przedsięwzięciu struktury danych opisane są za pomocą klas to można je, analogicznie jak to zostało opisane wcześniej, zmapować relacją trace klasę z obiektem danych.

Podsumowanie

Staram się budować tak sieć powiązań pomiędzy notacjami by dodana relacja wskazywała na uszczegółowienie albo uogólnienie. Tym samym mając procesy biznesowe, na podstawie modelu, jestem w stanie określić funkcje aplikacji jakie są wykorzystywane w danej czynności biznesowej. Wchodząc w szczegóły przypadku użycia, mogę poznać detaliczny opis działania aplikacji. W drugą stronę idąc od przypadku użycia mogę dowiedzieć się w jakich krokach jest używana dana funkcja aplikacji albo jakiej usługi aplikacyjnej jest składnikiem. Jak widać z powyższego nie mapuje „wszystkiego ze wszystkim”, gdyż koszt utrzymania takich modeli jest olbrzymi a efekt niezbyt duży.

Sponsorem artykułu jest mój: kurs z podstaw modelowania w języku UML