Diagram przypadków użycia

Właśnie w ramach powrotu do aktywności zawodowej pomagam mężowi zaplanować nową aplikację. Nie będę bezpośrednio brać udziału w jej powstawaniu, bo to nie moja technologia (C#), ale jeśli chodzi o projektowanie, to wiadomo, co dwie głowy to nie jedna.

Ja projektując aplikację zaczynam od przemyślenia jej od trony jej funkcjonalności. Wczuwam się w rolę użytkownika i próbuję ustalić czego on potrzebuje i jak to powinno funkcjonować. Jednym słowem projektuję funkcjonalność i interfejs. Nie znam lepszego narzędzia do tworzenia takiego projektu niż UMLowy diagram przypadków użycia (diagram PU) w połączeniu ze scenariuszami (ewentualnie uzupełniony o diagram pakietów i diagram komponentów), szczególnie jeśli w tworzeniu aplikacji bierze udział więcej niż jedna osoba. A nawet jeśli nad projektem pracuję sama to taki diagram pozwala mi go dobrze zaplanować i trzymać się tego planu. A poza tym jest świetnym remedium na sklerozę.

Nie będę zamieszczać opisów poszczególnych elementów wchodzących w skład diagramu PU, gdyż takie podstawowe informacje bez trudu można znaleźć w sieci (garść linków znajdziesz na końcu tego artykułu). Podzielę się za to swoimi przemyśleniami na temat tworzenia takich diagramów.

Żeby stworzyć dobry diagram PU trzeba sobie uczciwie odpowiedzieć na kilka podstawowych pytań. Bez tego trudno będzie w ogóle zacząć.

• Kto (lub co) będzie korzystał(o) z projektowanej aplikacji? Na tej podstawie należy ustalić listę aktorów, pamiętając, że aktorem jest ktoś lub coś spoza systemu, wchodzący w interakcję z systemem. Watro uporządkować aktorów przez wyznaczenie ról bardziej ogólnych i bardziej szczegółowych.
• Jaką funkcjonalność chcemy stworzyć? A właściwie to pytanie powinno brzmieć Jakich działań oczekują lub wymagają od systemu aktorzy?. Każda funkcjonalność systemu będzie stanowić osobny przypadek użycia (PU). Należy pamiętać, że PU reprezentuje sekwencję akcji (w odpowiedzi na interakcję aktora z systemem) realizowanych przez system, w efekcie których do aktora dostarczane są obserwowalne rezultaty. Dobrze zaprojektowany PU opisuje pojedyncze, dobrze określone i możliwie niepodzielne zachowanie systemu lub jego części. Ponadto opisuje ciąg zdarzeń tak, że jest on zrozumiały dla laika i umożliwia zrozumienie działania systemu.
  Żeby nie utknąć w gąszczu PU najlepiej jest przyjrzeć się krytycznie stworzonym PU a następnie spróbować wydzielić powtarzające się fragmenty działań i utwórz z nich nowe PU. Podobnie do osobnych PU należy wydzielić warianty działań, które rozszerzają główne ciągi zdarzeń.
• Jak bardzo szczegółowy diagram jest nam potrzebny? W tej kwestii mamy właściwie wolną rękę, wszystko zależy od tego do czego będzie służył diagram. Możemy ograniczyć się do bardzo uproszczonego diagramu umieszczając szczegóły w scenariuszu. Jest to wygodne jeśli diagram ma służyć omówieniu podstawowych funkcjonalności z klientem. W następnym kroku uogólnione przypadki użycia można rozbić na dodatkowe diagramy. Zamiast tego można najpierw stworzyć diagram pakietów i dla każdego pakietu tworzyć diagram przypadków użycia. Oczywiście nie jest poważnym błędem umieszczenie bardziej szczegółowej struktury przypadków użycia na jednym diagramie, choć może to zaciemniać obraz całości i utrudniać analizę. Przy tworzeniu bardziej rozbudowanych diagramów PU trzeba tylko wystrzegać się takich błędów jak na przykład ilustrowanie sekwencji czynności za pomocą przypadków użycia (do tego służą diagramy sekwencji albo aktywności).

Obiecana garść linków:

• Opis diagramu PU w Wikipedii
• Obiecująca, mimo iż w budowie, strona napisana w oparciu o WIki
• Opis elementów diagramów w pigułce
• Obszerne omówienie diagramu PU (i nie tylko)
• Opis diagramu PU na stronie Internet Maker
• Zwięzły opis cech charakterystycznych dobrego diagramu PU