Na świeżo po sprawdzaniu egzaminów z inżynierii oprogramowania pisanych przez studentów (a więc tych, którzy właśnie uczą się modelować systemy), pozwolę sobie wysnuć wnioski na temat najczęściej spotykanych problemów przy use case’ach i uogólnić je na resztę populacji. Przed Tobą Top 5 trudności początkujących adeptów opisywania przypadków użycia. Czytaj i sprawdzaj 🙂
System vs. świat rzeczywisty
Podczas opisywania przypadków użycia niektórym trudno odróżnić perspektywę systemu i świata rzeczywistego. Często warunkami zajścia jakiegoś PU jest to, że aktor „chce” albo czegoś „potrzebuje”. Na razie jednak niestety interfejsy nie czytają w myślach. Nadal zwyczajowo musimy coś wybrać, kliknąć czy wpisać. W opisach pojawiają się także stwierdzenia, że ktoś nie wyraził zgody (choć system nie przewiduje jej udzielenia) lub coś się nie odbyło z powodu złej pogody.
Wyobraź sobie, że siedzisz w środku… procesora. Nie widzisz użytkowników – ich min, chęci, niechęci i planów, ani pogody. Dostajesz komunikat z zewnątrz tylko wtedy, kiedy ktoś wprowadzi dane klikając coś czy wpisując. Dostajesz sygnał na wejście, korzystasz z odpowiedniej procedury (reguł PU) i dajesz coś na wyjście systemu – działasz (dodajesz, edytujesz, usuwasz) a do informowania użytkowników o wynikach masz do dyspozycji interfejs (wyświetlanie).
Perspektywa użytkownika vs. pseudokod
Osobom, które przerabiały już programowanie i pisanie algorytmów, sprawia czasem trudność pamiętanie, że kroki PU to nie pseudokod. Opisują sposób sortowania, przetwarzanie danych i zapisywanie do bazy.
Przypadek użycia to usługa świadczona przez system jego użytkownikowi (nie obchodzi nas tutaj jak to system robi, ale co robi dla użytkownika). Spróbujmy zatem wyobrazić sobie, że przypatrujemy się z boku współpracy człowieka i oprogramowania. Widzimy, co jest wyświetlane na ekranie, widzimy też, jakimi czynnościami człowiek przekazuje komunikaty do systemu. I na tym polega opis kroków – „Użytkownik wybiera/wpisuje …”, „System wyświetla …”. Poza wyświetlaniem, system wykonuje też masę innych działań, ale te są widoczne dla użytkownika jako komunikaty informacyjne lub poprzez swoje skutki. Użytkownik nie wie więc, że system zapisał coś do bazy, ale widzi, że nowa pozycja pojawiła się na przeglądanej liście.
Szczegół vs. ogół
Duża część ludzi nie lubi rozwlekłego pisania. Widać to też w opisach PU. „Podajemy dane”, „Wyświetla się lista zamówień”. Do wykonania systemu potrzebujemy jednak nieco więcej szczegółów. Jakie dane wpisujemy? Konkretnie, po kolei – jakie mają formaty, jakie wartości domyślne? Co się pojawia na liście zamówień? Numer i data? A może jeszcze nazwa zamawiającego, jego miasto zamieszkania? Może rabat udzielany na produkt? Spróbuj przygotować ten formularz i listę bez dalszych informacji 😉
Projektowanie interfejsu
Często pojawiają się w opisach zdanie na kształt „Użytkownik wybiera z dolnego selecta drugą pozycję i klika w prawy górny zielony przycisk, co powoduje wysłanie wiadomości do administratora”. W ten sposób nie dajemy pola do popisu projektantom UX (usability). A jeśli takowych nie mamy, kręcimy bat na samych siebie, bo przy każdej zmianie formatki, koloru czy położenia przycisku, nasz opis staje się nieaktualny. Lepiej skupić się na wprowadzanych danych i ogólnym sposobie działania.
Sens
Kiedy projektujemy interakcję z systemem, warto zadać sobie pytanie: „czy to dobrze, że robimy to w taki sposób?”. Może się okazać, że ponowne logowanie, wpisywanie danych, które można pozyskać z kontekstu, konieczność wykonania czynności, która nie posuwa do przodu w osiągnięciu celu przypadku użycia, wcale nie ułatwia ludziom życia (jak przecież informatyzacja powinna). Wyobraź sobie, że sam wykonujesz czynność, wg zaprojektowanego przez Ciebie schematu. Często, kilkadziesiąt razy dziennie. I jak? Przyjemnie?
