piątek, 9 listopada 2012

Kompletność modelu użycia

use case
Model użycia (use case model) w wielkim skrócie służy do przedstawienia funkcjonalności rozwiązania poprzez zastosowanie przypadków użycia, aktorów oraz relacji pomiędzy nimi.
Z reguły początkujący analitycy dysponują przynajmniej teoretyczną wiedzą o regułach tworzenia modelu użycia. Wraz z każdym zrealizowanym projektem umiejętności te rosną, ale mimo to dostarczany model użycia często nie jest idealny. Warto zatem pokusić się o stworzenie krótkiego podsumowania w tym zakresie.




Obszary funkcjonalne

Tworząc model użycia dobrą praktyką jest wydzielenie obszarów funkcjonalnych. Nawet prosta aplikacja może realizować funkcjonalności w kilku obszarach.

Takimi obszarami mogą być na przykład:
  • Obsługa wprowadzania danych,
  • Obsługa generowania raportów,
  • Administracja, itd.

Podział na obszary funkcjonalne może wynikać z podziału systemu na podsystemy, ale nie musi. Bywa, że wyspecyfikowane przez analityka obszary stanowią bazę dla programistów, na podstawie której dzielą się pracą czy specyfikują określone komponenty. Ewentualny błąd w fazie analizy polegający na nieprawidłowym określeniu obszarów funkcjonalnych może skutkować później utrudnieniami w utrzymaniu kodu aplikacji. Gdyby się okazało, że dwie podobne funkcjonalności są realizowane w dwóch różnych obszarach funkcjonalnych, to mogą być one implementowane przez dwóch różnych programistów. Kod napisany przez nich może się znacząco różnić. Gdyby obie funkcjonalności znalazły się w jednym obszarze, wówczas jeden programista ma szansę zastosować odpowiednie mechanizmy w kodzie, które służą uspójnieniu na przykład poprzez wykorzystanie odpowiednich wzorców projektowych.

Technicznie w modelu Enterprise Architect obszar funkcjonalny może odpowiadać pakietowi. Taki pakiet ze względu na czytelność można opatrzyć stereotypem <<Obszar>> lub <<Obszar funkcjonalny>>.
Każdy z takich pakietów może zawierać jeden lub więcej diagramów przypadków użycia oraz katalog przypadków użycia, czyli elementów typu use case.

Wskazówki do identyfikacji przypadków użycia

Gdy obszary funkcjonalne zostały już zidentyfikowane kolejnymi krokami są:
  • zidentyfikowanie przypadków użycia,
  • odpowiednie nazwanie przypadków użycia.
Każda funkcja realizowana przez aplikację, w której bierze udział jakiś aktor powinna znaleźć swoje odzwierciedlenie jako przypadek użycia.
Jeśli chodzi o nazewnictwo przypadków użycia, to istnieją dwie konwencje:
  • tryb rozkazujący, np. "Dodaj nowy tytuł",
  • rzeczownik odczasownikowy, np. "Dodanie nowego tytułu".
Wybór konwencji zależy od ustaleń projektowych. Wybraną konwencję należy jednak bezwzględnie stosować, aby utrzymać porządek w modelu.

Model aktorów

Należy pamiętać, że model użycia oprócz przypadków użycia powinien zawierać również model aktorów.
Częstym błędem jest potraktowanie modelu aktorów po macoszemu. Mam na myśli traktowanie aktorów jako dodatek do modelu przypadków użycia.

Opracowanie odpowiedniego modelu aktorów pozwala spojrzeć na funkcjonalność systemu z punktu widzenia określonego typu użytkownika. Poza tym odpowiednia identyfikacja aktorów może się przełożyć na opracowanie modelu uprawnień w tworzonej aplikacji.

Dobrą praktyką, którą warto stosować, jest wydzielenie katalogu aktorów w osobnym pakiecie np. o nazwie 'Aktorzy'.

W pakiecie tym powinien znaleźć się diagram aktorów. Diagram ten może zawierać relacje pomiędzy aktorami takie jak Generalization.
Aby umieścić na diagramie przypadków użycia aktorów z tego katalogu wystarczy przeciągnąć go na diagram z okna Project Browser. Dzięki temu ten sam aktor może występować na wielu diagramach, redukując w modelu ilość elementów typu Actor opisujących tę samą rolę lub funkcję.
Każdy aktor powinien być opatrzony opisem, który precyzuje jakie akcje aktor wykonuje w systemie, można również zawrzeć ograniczenia, czyli opisać akcje, których aktor nie wykonuje.

Opisywany system, którego dotyczą przypadki użycia nie jest aktorem. Aktorem mogą być użytkownicy i systemy zewnętrzne, które wchodzą w interakcje z systemem.

Przykładowa struktura modelu użycia

Poniższy rysunek przedstawia przykładową strukturę modelu użycia zawierającą katalog aktorów oraz podział przypadków użycia na obszary funkcjonalne.
Przykładowa struktura pakietowa modelu użycia

Relacje pomiędzy przypadkami użycia

usecase diagram

Elementy modelu użycia wchodzą ze sobą w relacje, które zostały opisane w specyfikacji notacji UML. Pomiędzy aktorem a przypadkiem użycia stosuje się relację Association. Możliwe relacje pomiędzy przypadkami użycia to:
  • Generalization/Specialization,
  • Include,
  • Extend.
Dodatkowo, poza specyfikacją UML w EA dostępne są inne relacje, które można traktować jako swoiste rozszerzenie standardu UML:
  • Invokes,
  • Precedes.
Pierwsza z nich (invokes) oznacza, że jeden przypadek użycia wywołuje inny. Można stosować tę relację na przykład w odniesieniu do funkcjonalności implementowanych jako usługi SOA.
Druga (precedes), oznacza, że w odróżnieniu od extend, czy include przebieg jednego przypadku musi się zakończyć przed rozpoczęciem przebiegu drugiego przypadku.

Nic nie stoi na przeszkodzie, aby przypadki użycia łączyć odpowiednimi relacjami również z innymi typami elementów, np. z wymaganiami, czy klasami z modelu domeny.
Dobrą praktyką jest, gdy dla wszystkich wymagań funkcjonalnych istnieją mapowania z przypadkami użycia przy użyciu relacji Realization.

Cechy przypadku użycia

Opis przypadku użycia powinien zawierać przynajmniej następujące cechy:
  • Unikalny identyfikator.
  • Nazwa przypadku użycia.
  • Opis przypadku użycia - krótka informacja w języku zrozumiałym przez użytkownika biznesowego.
  • Warunki początkowe - co musi być spełnione, żeby akcja mogła się wydarzyć.
  • Przebieg główny - lista kroków, których sekwencyjne wykonanie warunkuje osiągnięcie stanu opisanego przez warunki końcowe; przebieg ten opisuje najbardziej typowe wykorzystanie funkcjonalności opisanej przez przypadek.
  • Przebieg(i) alternatywne - lista kroków, których sekwencyjne wykonanie również warunkuje osiągnięcie stanu opisanego przez warunki końcowe, jednak różni się od typowego przebiegu (głównego); przebieg taki stanowi "odgałęzienie" od przebiegu głównego.
  • Sytuacje wyjątkowe -  opis sytuacji, gdy na skutek określonego warunku nie jest możliwe osiągniecie stanu końcowego przebiegu głównego. Wystąpienie sytuacji wyjątkowej często kończy się wyświetleniem komunikatu o błędzie, kończy przebieg i nie zachodzą warunki końcowe.
  • Warunki końcowe - co się wydarzy, gdy akcja zakończy się pomyślnie.
Dodatkowo dla przypadku użycia można zdefiniować zestaw reguł biznesowych, które są wykorzystywane w określonych krokach przebiegów. Ponadto istnieje również szereg innych cech, którym są przypisywane wartości domyślne podczas tworzenia przypadku użycia, takie jak złożoność, status, wersja, autor itd. Atrybuty te mogą być wykorzystywane do śledzenia cyklu życia przypadku lub wyceny złożoności oprogramowania.

Przebiegi przypadku użycia

Pełny opis przypadku użycia powinien zawierać przebieg główny, może być tylko jeden przebieg główny. Przebiegi alternatywne i sytuacje wyjątkowe nie są wymagane. Mogą być przypadki użycia, w których jest opisany tylko przebieg główny, ale warto, aby upewnić się, czy nie istnieje żadna okoliczność, która może w sprawić, że nie zawsze będzie możliwe przejście do następnego kroku.  Na przykład jeden krok może być sformułowany następująco "System wyświetla listę znalezionych tytułów", a następny krok "Użytkownik wybiera tytuł z listy". Zadajmy sobie pytanie: Co ma się wydarzyć, jeśli system zwróci pustą listę tytułów? Użytkownik nie będzie mógł niczego wybrać, typowa sytuacja opisywana w przebiegu głównym wówczas nie zaistnieje, potrzebny jest przebieg alternatywny.
Przypadek użycia powinien uwzględniać tego sytuacje i opisywać w jaki sposób powinna przebiegać interakcja pomiędzy systemem a użytkownikiem.

Kroki przebiegów najczęściej opisują akcje wykonywane naprzemiennie przez aktora i system.
Ale błędem jest narzucanie wymogu, że kroki muszą być wykonywane naprzemiennie. Nie zawsze jest możliwa zgodność z taką zasadą.

Przebiegi są zwane również scenariuszami. Termin scenariusz rodzi słuszne skojarzenia ze scenariuszem filmowym.
Dobrą praktyką jest, aby przebieg nie miał zbyt wielu kroków. Powiedzmy - maksymalnie 10. Choć nie należy traktować tego jako sztywną regułę. Gdy kroków jest zbyt wiele, należy zastanowić się, czy przypadek nie powinien zostać rozbity na dwa lub więcej przypadków użycia.

Można się umówić, że przebiegi, czy scenariusze nie są opisywane tekstowo, tylko za pomocą diagramów aktywności lub interakcji.
Dobrą praktyką jest jednak unikanie redundancji opisu, czyli dla tego samego przypadku użycia nie stosujemy jednocześnie opisu tekstowego, jak i diagramu.

Technicznie w programie Enterprise Architect od wersji 8.0 możliwe jest stosowanie tzw. Structured Scenarios, które pozwalają na stworzenie czytelnej listy kroków wraz z przejściami pomiędzy różnymi scenariuszami. Czyli np. krok 4 przebiegu głównego może zawierać krok 4a, który oznacza, że gdy spełniony zostaje określony warunek (opisany słowem "Jeżeli..."), wówczas następuje uruchomienie przebiegu alternatywnego lub sytuacji wyjątkowej. Z przebiegu alternatywnego może nastąpić w którymś z kolejnych kroków powrót do przebiegu głównego.
Z sytuacji wyjątkowej powrót do przebiegu głównego jest traktowany jako błąd modelowania. Podobnie nie ma również możliwości przejścia z jednego przebiegu alternatywnego do innego przebiegu alternatywnego. Program Enterprise Architect uniemożliwia tego typu sytuacje.
Gdyby zaszła potrzeba wywołania jednego przebiegu alternatywnego w drugim przebiegu alternatywnym, wówczas jest to sygnał, że taki przypadek użycia należy rozbić na dwa osobne i powiązać je przy użyciu odpowiedniej relacji.

Scenariusz opisany za pomocą Structured Scenarios umożliwia automatyczne wygenerowanie jednego lub kilku rodzajów diagramów, które mogą być aktualizowane w oparciu o zmiany opisu przebiegów.

10 komentarzy:

  1. W cechach przypadków użycia oprócz warunków wstępnych i końcowych dodał bym sekcję opisującą zdarzenie inicjujące. Można powiedzieć, że jest to opis wyzwalacza uruchamiającego przypadek użycia.

    OdpowiedzUsuń
  2. Czy w scenariuszach należy uwzględniać zachowanie przyszłego systemu? Chodzi mi o to, czy pisać ogólnie o czynnościach jakie użytkownik ma wykonać (np. użytkownik przegląda zlecenie) czy pisać czynności, które determinuje sam system (np. użytkownik z listy zleceń otwiera i przegląda zlecenie). Pytanie czy pisać tak szczegółowo? jakim sposobem on to zlecenie otworzy? (bo ma w systemie kilka możliwości)
    Dzięki za pomoc

    OdpowiedzUsuń
    Odpowiedzi
    1. Według niektórych przypadki użycia można podzielić na biznesowe (business use case) i systemowe (system use case). Czyli tak samo, jak całą analizę można podzielić na biznesową i systemową.
      Biznesowe przypadki użycia służą do opisu procesów biznesowych i można je zastosować alternatywnie zamiast diagramów BPMN, gdzie przebieg PU może być opisany w postaci kroków lub diagramu aktywności.
      W przypadku biznesowego przypadku użycia pisałbym o czynnościach, które wykonuje użytkownik, czyli np. "użytkownik przegląda zlecenie".
      Jeśli to systemowy przypadek użycia, to pisałbym "użytkownik z listy zleceń otwiera i przegląda zlecenie".
      Dzięki takiemu podejściu możemy najpierw ustalić przebieg procesu na wyższym poziomie ogólności. A potem przejść do projektowania systemu, który ma wspierać taki proces biznesowy. Czyli, inaczej mówiąc, najpierw zgadzamy się, że w określonym kroku procesu użytkownik powinien przejrzeć zlecenie. Jak już to ustalimy, to przechodzimy do ustalenia sposobu, w jaki on to zlecenie otworzy. Przy czym możemy od razu zaprojektować dla użytkownika kilka tych sposobów tworząc przebiegi alternatywne.

      Usuń
  3. Ten komentarz został usunięty przez administratora bloga.

    OdpowiedzUsuń
  4. Nastukałem ponad setkę bloczków "Requierement". Pogrupowałem je w pakiety. Ponazywałem. Fajnie to wygląda dopiero gdy tą pracę kategoryzacyjną wykonałem. Jednak chciałbym aby każde wymaganie otrzymało jakiś swój identyfikator. Tak jak u Pana w artykule widać UC001, UC002...., ponieważ chciałbym potem tworzyć linki do UC030 (i posługiwać się w rozmowach identyfikatorem a nie nazwą). Czy można to nadawanie identyfikatorów jakoś zautomatyzować?

    OdpowiedzUsuń
  5. W mojej dotychczasowej praktyce nazwy klas czy przypadków użycia powinny być unikalne (np. w ramach pakietu). EA tego nie pilnuje. W tym artykule jest mowa o unikalnym identyfikatorze (jak rozumiem technicznym) i o nazwie (gdzie nie wspomniano już o unikalności). Poproszę o komentarz.

    OdpowiedzUsuń
    Odpowiedzi
    1. W EA nie ma osobnego pola na identyfikator. Dostępne są: "Name" oraz "Alias". W związku zwykle w jednym z tych pól (lub w obydwu) umieszcza się zarówno identyfikator, jak i nazwę.
      Identyfikator w polu "Name" ma jeszcze tę zaletę, że elementy w pakiecie są domyślnie sortowane po nazwie.
      Identyfikatory można nadawać w zależności od preferencji: albo wpisywać ręcznie i samemu dbać o unikalność, albo skorzystać automatycznego nadawania przez EA.
      Aby EA sam nadawał identyfikatory i inkrementował licznik należy skonfigurować liczniki wybierając z menu Settings -> Auto Names and Counters.

      Usuń
    2. 1. Czy zgadzasz się z opinią, że nazwy UC i klas powinny być unikalne w ramach pakietu ?
      2. Czemu EA tego nie pilnuje lub nie ostrzega.?
      Autoinkrementacja zapewnia formalną unikalność ale umożliwia popełnienie błędów merytorycznych (o które łatwo w wypadku gdy tematem zajmuje się kilka osób niezależnie) np. w nazwach klas "001 Osoba" i "045 Osoba".

      Usuń
    3. Nazwy artefaktów, takich jak UC i klasy powinny być unikalne co najmniej w ramach pakietu. Często przyjmuje się, że powinny być unikalne w ramach całego rozwiązania.
      EA posiada jedynie mechanizmy, które ułatwiają zachowanie unikalności. Jednakże zasady unikalności nazw w przypadku, gdy model tworzony jest przez wiele osób, powinny być określone w ramach projektu.
      Konsekwencją wprowadzenia projektowych zasad zarządzania wymaganiami może być również wprowadzenie projektowych metod weryfikacji zgodności z tymi regułami. Patrz wpis: http://eablogpl.blogspot.com/2013/10/weryfikacja-regul-projektowych-w-ea.html

      Usuń
    4. Bardzo dziękuję za udzielone odpowiedzi.
      Rzeczywiście wprowadzenie reguł projektowych (których jeszcze się nie nauczyłem) mogły być remedium na przedstawione problemy.
      Dodatkowo chciałbym podziękować za całokształt.
      Zgłębiam EA i treści tej witryny są dla mnie niesłychanie cenne.
      Pozdrawiam, Adam Łukasiewicz

      Usuń