Odpowiedź zależy od granicy systemu#

Baza danych nie jest automatycznie aktorem ani automatycznie elementem wewnętrznym. W diagramie przypadków użycia aktorem może być dowolna rola lub zewnętrzny system, który wchodzi w interakcję z systemem objętym granicą. Jeśli baza danych jest częścią modelowanego rozwiązania, zwykle nie przedstawia się jej jako aktora. Jeśli jest niezależną, zewnętrzną usługą, z którą system współpracuje, może być aktorem.

Zewnętrzna usługa danych znajduje się poza granicą Systemu raportowego i uczestniczy w przypadku Pobierz dane.
Baza może być aktorem, gdy jest zewnętrznym uczestnikiem wobec modelowanego systemu.

Diagram modeluje system raportowy, który korzysta z usługi danych poza własną granicą. Gdyby zakresem diagramu była cała aplikacja obejmująca tę bazę, rola mogłaby zmienić się na wewnętrzny element, a nie aktora. To zakres modelu, nie technologia bazy, decyduje o klasyfikacji.

Baza jako wewnętrzny element systemu#

Jeżeli baza jest wdrażana, utrzymywana i zarządzana jako część systemu, jej użycie zwykle należy opisać jako wewnętrzny mechanizm realizacji przypadku użycia. Na diagramie przypadków użycia może wystarczyć cel użytkownika, na przykład „Wygeneruj raport”; zapis „Zapisz rekord” jest krokiem technicznym, niekoniecznie osobnym celem aktora.

Jeśli pytanie dotyczy tego, które usługi systemu korzystają z bazy, wybierz diagram komponentów lub wdrożenia. Diagram przypadków użycia nie jest schematem infrastruktury, a dodanie bazy jako aktora może błędnie sugerować, że to ona ma samodzielny cel wobec systemu.

Baza jako system zewnętrzny#

Baza lub usługa danych może być aktorem, gdy ma własną granicę odpowiedzialności i system modelowany wchodzi z nią w istotną interakcję. Przykłady to zewnętrzna hurtownia danych, zarządzana usługa dostawcy albo system źródłowy udostępniający dane. W nazwie użyj roli lub nazwy systemu, nie abstrakcyjnego „serwera” bez wyjaśnienia.

Pokaż aktora zewnętrznego tylko wtedy, gdy interakcja jest ważna dla zakresu i celu diagramu. Jeśli relacja jest wyłącznie wewnętrznym szczegółem implementacji, diagram komponentów będzie czytelniejszy. Oddziel aktora „system bazodanowy” od wewnętrznego magazynu danych, jeśli pierwszy dostarcza usługę, a drugi jest pojęciem domenowym.

Ustal granicę przed rysowaniem#

Zadaj sobie pytania:

  1. Jaki system lub podsystem opisuje diagram?
  2. Czy baza znajduje się wewnątrz tej granicy i podlega odpowiedzialności tego systemu?
  3. Czy baza samodzielnie współdziała z systemem, czy jest tylko pasywnym zasobem używanym przez jego komponenty?
  4. Czy odbiorcy potrzebują informacji o celu aktora, czy raczej o wdrożeniu i przechowywaniu danych?
  5. Czy modelujesz konkretny produkt, usługę dostawcy czy abstrakcyjny zasób danych?

Odpowiedzi mogą się różnić w modelu logicznym, architekturze technicznej i diagramie wdrożenia. Jeden system zewnętrzny może być aktorem w diagramie przypadków użycia, komponentem w diagramie architektury i węzłem w diagramie wdrożenia — każdy widok opisuje inny aspekt.

Typowe błędy#

  • Każdy element poza kodem nazwany aktorem. Aktor powinien uczestniczyć w interakcji z modelowanym systemem.
  • Baza wewnętrzna pokazana jako użytkownik. Pasywna baza zwykle nie inicjuje celów i nie jest aktorem w takim zakresie.
  • Granica przemilczana. Bez nazwy i zakresu systemu klasyfikacja pozostaje niejasna.
  • Detal infrastruktury dodany do diagramu celów. Użyj diagramu komponentów lub wdrożenia, gdy chodzi o technologię.
  • Nazwa „baza” bez roli. Określ, czy to zewnętrzna usługa, źródło danych, czy magazyn wewnętrzny.
  • Jedna klasyfikacja dla wszystkich diagramów. Ten sam element może pełnić różne role w zależności od zakresu widoku.

Podsumowanie#

Baza danych jest aktorem tylko wtedy, gdy jest zewnętrznym uczestnikiem wobec wyraźnie określonej granicy systemu. Wewnętrzna baza jest zwykle mechanizmem realizacji, który lepiej pokazać na diagramie komponentów lub wdrożenia. Zanim narysujesz aktora, nazwij system i ustal, kto odpowiada za bazę.