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:

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 wymagania
UML a wymagania

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.

uml a proces biznesowy
UML a proces biznesowy

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ą.

uml a notacja archimate
UML a Archimate

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 
Podobne wpisy
Modelowanie infrastruktury w języku UML – diagram wdrożenia w praktyce

Modele mają za zadanie pokazać rzeczywistość w sposób uproszczony, w którym uwypuklamy interesującą nasz cechę. Projektując nowe lub zmieniając istniejące więcej

Architektura systemów

Obserwując zmiany na rynku zauważyłem, że rola architektury systemów (architektury oprogramowania) rośnie. Dziś w wielu organizacjach myśli nie tylko a więcej

Mapowania wychodzące poza architekturę korporacyjną

Dwa tygodnie temu w poście poście Moje ulubione perspektywy w architekturze korporacyjnej przedstawiłem kilka diagramów opisujących architekturę korporacyjną z różnych perspektyw. więcej

Wymagania biznesowe a wymagania systemowe

Wiele się mówi o potrzebie identyfikacji celów projektowych, celów organizacji a także o potrzebie identyfikacji wymagań biznesowych oraz systemowych. Wszystko po więcej

Reklama
MODESTO - licencje Enterprise Architect

2 komentarze dla “Mapowania wychodzące poza notację UML”

  1. Mapowanie elementów różnych notacji bywa kontrowersyjnym tematem / pomysłem. Niemniej, użycie relacji Trace (w nowej wersji EA, Trace dziedziczy z Dependedncy; kiedyś z Abstraction, jesli dobrze pamiętam?) jest 'jakimś’ wyjściem. Niemniej, czy nie wystarczy zbudować nawigacji pomiedzy perspektywami na bazie np. Navigation Cell’s w EA? Zawsze obawiam się tego, co wyniknie z takiego powiązania 'wszystkiego ze wszystkim’. Wiem, że to w praktyce jest wygodne, ale czy uzasadnia dość skomplikowany metamodel, łączący ze sobą różne notacje jak w przypadku UML i Archimate? Tak prowokacyjnie tylko pytam 🙂

    1. Navigation Cell pomaga zarządzać widokami (diagramami) i się między nimi przemieszczać. Mapowania są pomocne przy raportowaniu i analizach złożoności albo choćby wpływu zmiany na aplikacje i jej komponenty.

Zostaw komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Scroll to Top