Wprowadzenie
Pojęcie kontekstu projektu i diagram przypadków użycia jako narzędzie, nadal rodzi wiele pytań. Spowodowane jest to tym, że diagram przypadków użycia to najczęściej wykorzystywany diagram, najczęściej też “nielegalnie przeciążany” informacjami o architekturze wewnętrznej (związki ‘include’ i ‘extend’). Jest to także najbardziej abstrakcyjny diagram w notacji UML. Postanowiłem odpowiedź “publicznie” na pytanie, które w różnych formach, często pada w projektach, na szkoleniach i w mailach do mnie kierowanych. Przykład jednego z nich:
Mam pytanie, które dręczy mnie od jakiegoś czasu i teraz zmobilizowałam się by je zadać.
W artykule Jarosław Żeliński (9 października 2012) pisze Pan: “Inny System, jeżeli inicjuje akcję czyli żąda usługi także jest aktorem, ale System realizujący na nasze zlecenie jakieś usługi nie jest aktorem, jest tylko wywoływany, sam z siebie nie inicjuje żadnej akcji. On realizuje jakąś potrzebną nam funkcję.”
Natomiast w innych miejscach,np. w dokumentacji Generatora ofert dla Kancelarii Senatu (Jarosław Żeliński, 22 października 2019) , czy w Swojej książce ( ( s.31) obrazuje Pan zewnętrzny system oferujący usługę symbolem Aktora. Być może to zależy od kontekstu, ja jednak nie dostrzegam jakiegoś niuansu, czy może Pan wyjaśnić ten dylemat? I drugie pytanie.
W książce ( s.54, pierwszy akapit pod Rys.8.5) natknęłam się na zdanie : “Powyższy model to struktury danych dla “pojęć opisujących spotkania”. Można go sporządzić także w notacji obiektowej (UML), czyli diagramem klas, jednak tu dla uproszczenia pominięto tę wersję i pokazano model danych (model obiektowy ma inne zasady tworzenia i będzie opisany w dalszej części książki)”. O jaki model w notacji obiektowej (UML) chodzi? model dziedziny? (w dalsze części książki jest on opisany)
Byłabym wdzięczna za odpowiedź
na to pytanie (w zasadzie pytania) odpowiem z pomocą przykładu wraz z objaśnieniami.
Specyfikacja UML
Na początek kilka kluczowych pojęć z UML. Rozdział 18 Use Case w pierwszym akapicie informuje nas, że:
UseCases are a means to capture the requirements of systems, i.e., what systems are supposed to do. The key concepts specified in this clause are Actors, UseCases, and subjects. Each UseCase?s subject represents a system under consideration to which the UseCase applies. Users and any other systems that may interact with a subject are represented as Actors.
To znaczy, że: 1. Przypadki Użycia to sposób na uchwycenie [a nie pełne opisanie! przyp. autora] wymagań wobec systemu, tj. tego Co system ma zrobić. 2. Kluczowymi pojęciami są tu: Aktor, Przypadek Użycia i Przedmiot [system jako przedmiot opisu, przyp. autora]. 3. Przedmiot reprezentuje analizowany system, którego wykorzystanie [jego cel] reprezentuje Przypadek Użycia. 4. Użytkownicy i wszelkie inne systemy, które mogą wchodzić w interakcje z Przedmiotem [opisu], są reprezentowani [na diagramach przypadków użycia] jako Aktorzy. Bardzo ważnym słowem są tu interakcje. Akapit 18.1.3.1. tej specyfikacji:
A UseCase may apply to any number of subjects. When a UseCase applies to a subject, it specifies a set of behaviors performed by that subject, which yields an observable result that is of value for Actors or other stakeholders of the subject.
Czyli: Przypadek Użycia może dotyczyć (być powiązany z) dowolnej liczby Przedmiotów opisu (kontekstów). Jeżeli Przypadek Użycia jest skojarzony z określonym Przedmiotem, oznacza to, że określa jego zestaw zachowań, co z kolei daje (opisuje) obserwowalny wynik (efekt, produkt), który ma wartość dla określonych aktorów lub innych interesariuszy. Warto tu zwrócić uwagę na dwie rzeczy: Przypadek Użycia to abstrakcja reprezentują usługę rozumianą jako określony efekt, tak więc Fakturowane może być cechą wielu aplikacji w tym samym projekcie (np. i w CRM i W FK). Po drugie interesariuszem aplikacji może być, poza bezpośrednim użytkownikiem, każda osoba lub byt zależny nawet pośrednio, od danego Przedmiotu.
Wyjaśnienie na przykładzie
Poniżej opis prostego zintegrowanego systemu składającego się z trzech komponentów oraz przykłady trzech różnych kontekstów hipotetycznego projektu.
Model złożonego systemu
Na diagramie poniżej (UML, diagram komponentów) zobrazowano architekturę złożoną z trzech systemów: Użytkownik używa Systemu A, System A korzysta z usług (jest zależy od) Systemu B, System B korzysta z usług Systemu C. System C jest tu systemem niezależnym.
Powyższy złożony system może być przedmiotem kilku różnych projektów o różnych zakresach.
Trzy konteksty
Poniżej przykładowe zakresy projektów wyrażone z pomocą diagramów przypadków użycia.
(stereotypy ‘human’ i ‘application’ to często przyjmowana konwencja, nie są one częścią specyfikacji UML).
Powyższe trzy diagramy obrazują zakresy trzech odrębnych projektów. Są to trzy różne konteksty analizy i projektowania dla tego samego złożonego systemu jako całości. Aktor co do zasady (notacja UML) jest bytem zewnętrznym w stosunku do systemu będącego przedmiotem opisu (kontekstem projektu dokumentowania wymagań). Przypadki użycia to wyłącznie abstrakcje usług (w obiektowym paradygmacie z zasady na modelu przypadków użycia nie używamy związków ‘extend’ i ‘include’, uzasadniałem to w artykule Jarosław Żeliński (6 stycznia 2019)). Na diagramie przypadków użycia, związek między aktorem (który może być człowiekiem ‘human’, lub innym systemem ‘application’) a usługą, którą dla niego świadczy system będący przedmiotem opisu, jest asocjacja (linia ciągła). Jeżeli chcemy pokazać, że nasz System musi korzystać z usług innego zewnętrznego systemu (jest od niego zależny), to łączymy opisywany System i ten zewnętrzny (aktora) związkiem użycia (zależność: nasz system jest uzależniony od zewnętrznego) wskazującym na źródło uzależnienia.
UWAGA! Integracja z systemem zewnętrznym, który świadczy usługi, nie jest Przypadkiem Użycia systemu modelowanego!
Podsumowanie
Powyższe przykłady obrazują ważne pojęcie jakim jest kontekst projektu. Nie raz diagramy takie są nazywane (i słusznie) modelem zakresu projektu. Moga one być kontynuowane w trakcie realizacji projektu (nadzór autorski).
Można więc zobrazować także to, że nasz system (jego abstrakcja) będzie miał (lub już ma) znaną nam implementację. Wtedy korzystamy ze związku realizacji jak na przykładzie poniżej.
Na diagramie pokazano, że Systemem CRM który wdrożymy, będzie aplikacja wFirma.pl co pokazano związkiem realizacji (aplikacja wFirma.pl – komponent UML – realizuje wymagania na System CRM).
Powyższy diagram czytamy: Użytkownik (człowiek) korzysta z Systemu CRM w celu wystawiania Faktur i rejestrowania Zamówień (detale usług dokumentujemy osobno jako warunki początkowe i końcowe, scenariusze przypadków użycia i struktury dokumentów Faktura i Zamówienia, np. z pomocą diagramu struktur złożonych UML, co opisałem w Jarosław Żeliński (2 grudnia 2019)). Nasz system CRM korzysta z API oferowanego przez Główny Urząd Statystyczny (GUS) do pobierania danych firm na podstawie ich numeru NIP (to nie jest przypadek użycia naszego Systemu CRM, szczegóły tej integracji zawiera scenariusz przypadku użycia Zamówienia lub Faktury oraz opis aktora GUS). Wygląda to tak:
Dlaczego na diagramie aplikacja wFirma.pl to komponent a nie aktor UML? Aktor to abstrakcyjny byt poza systemem, mający z nim interakcję, więc pokazanie na diagramie przypadków użycia implementacji systemu (symbol) nie może być aktorem, bo związek abstrakcji i jej realizacji nie jest interakcją (realizacja i użycie to są zależności ale różne). [autokorekta 2020-03-18, 20:40].
Konstrukcje użyte w projekcie Generator Ofert opisałem i skomentowałem w Jarosław Żeliński (22 października 2019).
O tym, że Czas nie jest aktorem systemu pisałem tu: Jarosław Żeliński (27 listopada 2011).
