Podręcznik

Opisy scenariuszy i dokładne modele (słowniki) dziedziny nie dostarczają kompletu informacji dla zaprojektowania i zaimplementowania systemu. Wiemy jaka jest logika aplikacji (scenariusze) oraz jakie dane podlegają przetwarzaniu i wizualizacji (model dziedziny), ale nie wiemy, w jaki sposób te dane będą konkretnie wizualizowane. Dlatego też, najczęściej konieczne jest zdefiniowanie wyglądu elementów interfejsu użytkownika. Definicja ta może być wykonana na rożnym poziomie szczegółowości. W najprostszym przypadku może to być tzw. szkielet interfejsu użytkownika (ang. wireframe), który polega na naszkicowaniu prostymi kreskami układu elementów ekranowych (okienka z zawartymi w nich polami, przyciskami itp.). Jeśli potrzebna jest bardziej dokładna definicja, wykonujemy tzw. makietę interfejsu użytkownika (ang. mockup). Najbardziej dokładny jest prototyp interfejsu użytkownika (ang. UI prototype), który często wykonywany jest w docelowym narzędziu, w którym będzie implementowany cały system.

Tworzenie prototypu ma na celu łatwiejsze zrozumienie zasad realizacji funkcjonalności oraz przedstawienie propozycji sposobu interakcji pomiędzy użytkownikami i systemem. Prototyp opiera się na modelu statycznym wymagań (słownik dziedziny, model interfejsu użytkownika) i służy do zobrazowania modelu dynamicznego (przypadki użycia, scenariusze) z uwzględnieniem cech systemu oprogramowania (wymagania jakościowe). Prototypy pozwalają zilustrować ciągi stanów interfejsu użytkownika, które w dalszej części tego rozdziału będą nazywane scenami. Powiązanie scen z krokami scenariuszy przypadków użycia daje w wyniku scenopisy. Scenopis przedstawia ważne elementy systemu charakterystyczne dla kroków scenariusza przypadku użycia – swego rodzaju „komiks”.

3.1 Projektowanie graficznego interfejsu użytkownika

Graficzny interfejs użytkownika jest sposobem prezentacji informacji przez komputer oraz interakcji z użytkownikiem. Interfejs graficzny został po raz pierwszy opracowany przez firmę Xerox w latach 70. XX wieku. Podczas projektowania serii komputerów Alto, zespół kierowany przez Merzougi Wilbertsa zaproponował i zrealizował nowy paradygmat interakcji z użytkownikiem. Paradygmat ten nazwano  skrótem WIMP (windows, icons, menus, pointers). Wszyscy wielcy producenci komputerów, zainspirowani osiągnięciami firmy Xerox, rozpoczęli prace nad stworzeniem własnych rozwiązań interfejsów graficznych użytkownika. Dzięki tym działaniom GUI stało się dostępne dla wszystkich korzystających z komputerów.

W przypadku interakcyjnych systemów oprogramowania dla zastosowań biznesowych i domowych graficzne interfejsy użytkownika są obecnie normą. Głównymi zaletami tych interfejsów są:

• Łatwość nauki obsługi i łatwość użytkowania. Użytkownicy bez doświadczeń z komputerami mogą nauczyć się używania interfejsu w ciągu krótkiego szkolenia.
• Nawigacja między oknami. Użytkownik ma kilka ekranów (okien) do interakcji z systemem. Dzięki temu może przejść od jednego zadania do innego bez utraty oglądu informacji przygotowanej w trakcie pierwszego zadania.
• Szybkość interakcji. Pełny ekran daje dostęp do wszystkich informacji na nim zawartych.

Obecnie miliony ludzi posługują się przeglądarkami WWW, które przetwarzają język definicji stron (HTML) w postaci tekstowych znaczników (tagów) na graficzny interfejs użytkownika. Na stronie WWW można umieścić zarówno przyciski, pola, formularze oraz tabele, jak i obiekty multimedialne dające dostęp do dźwięków, nagrań, filmów i ekranów rzeczywistości wirtualnej. Ze względu na powszechną dostępność przeglądarek WWW oraz siłę rozwiązań webowych i związane z nimi możliwości przetwarzania, coraz więcej interfejsów użytkownika ma postać interfejsów WWW. Dzięki realizacji idei hiperłączy (linków), graficzny interfejs użytkownika uzyskał możliwość automatycznej nawigacji między różnymi oknami systemu oprogramowania. Powszechne na stronach WWW odnośniki znajdują także zastosowanie w systemach desktopowych, umożliwiając użytkownikowi swobodne poruszanie po zasobach systemu.

Aby poddać projekt graficznego interfejsu ocenie, należy stworzyć jego wizualizację. Tworzenie projektów graficznych interfejsów na papierze jest bardzo niewygodne. Dlatego też współcześnie w powszechnym użyciu są różnego rodzaju narzędzia do projektowania interfejsu użytkownika. Z uwagi na popularność interfejsów WWW, wiele narzędzi tego typu stanowi aplikacje WWW. Przykład takiej aplikacji (Figma) widzimy na rysunku 3.1. Pozwala ona na projektowanie szczegółowego wyglądu interfejsu użytkownika na poziomie makiety. Możliwe jest również symulowanie działania systemu poprzez możliwość nawigacji między projektowanymi ekranami. Ułatwia to znacznie komunikację z użytkownikiem oraz z zespołem implementującym system.

Rysunek 3.1: Przykład systemu do projektowania interfejsów WWW - Figma

W przypadku konieczności prototypowania bardziej zaawansowanych interfejsów, wykorzystuje się specjalne zestawy narzędziowe, w skrócie zwane UIDS (ang. user-interface developement system). Narzędzia te często wyposażone są w biblioteki gotowych składników i obiektów, z których można budować okna, systemu menu, mechanizmy interakcji z urządzeniami, komunikaty o błędach, polecenia i wiele innych elementów interaktywnego środowiska. Generatory interfejsów są systemami graficznego projektowania ekranów, w ramach których komponenty interfejsu wybierane są z przybornika i umieszczane w interfejsie.

Wsparcie projektowania graficznego interfejsu użytkownika może być realizowane w różnych typach narzędzi wspomagających proces wytwórczy oprogramowania. Mogą to być odpowiednie moduły dostępne w ramach zintegrowanych środowisk programistycznych, takich jak NetBeans czy Microsoft Visual Studio. Mamy również możliwość skorzystania z szerokiego wyboru narzędzi desktop, dedykowanych do projektowania interfejsów użytkownika. Proste szkielety interfejsu użytkownika pozwalają również projektować narzędzia do modelowania takie jak np. Enterprise Architect czy Visual Paradigm.

3.2 Tworzenie scenopisów i prototypów

Warto zauważyć, że wybrany stan interfejsu użytkownika stanowi swego rodzaju scenę. Poszczególne kroki scenariuszy przypadków użycia mogą powodować przejście do kolejnej sceny, czyli np. wyświetlenie kolejnego okienka. Takie sekwencje scen możemy nazwać scenopisami (ang. storyboard). Wiele narzędzi do projektowania interfejsu użytkownika pozwala na rysowanie scenopisów, a nawet na animację ich wykonania. Przykład scenopisu dla przypadku użycia przedstawia rysunek 3.2. Numery na diagramie odpowiadają numerom kroków w scenariuszach tego przypadku użycia.

Rysunek 3.2: Przykładowy scenopis

Aby zachować spójność, scenopis powinien być oznaczony nazwą przypadku użycia z opcjonalnie wyróżnionymi krokami scenariuszy. Zasadniczą część scenopisu stanowią „zdjęcia ekranu”, czyli jego sceny, oraz przejścia między nimi. Scena przedstawia stan systemu w kroku scenariusza, który definiuje ważne z punktu widzenia interfejsu użytkownika elementy (tutaj: ekran początkowy i kroki 2, 6 i 5a). Dla interfejsu graficznego są to okna, dla tekstowego interfejsu – stan konsoli, dla interfejsu dźwiękowego – opis dźwięku. Przejście między scenami odpowiada krokowi scenariusza, który opisuje operacje wykonane przez aktora i powodujące zmianę sceny (tutaj: kroki 1, 3 i 6a). Przejście zwykle wyzwalane jest przez użycie pewnego elementu sceny (np. naciśnięcie przycisku „Dodaj”) i oznaczone strzałką, prowadzącą z wybranego elementu jednej sceny do kolejnej sceny.

Aby wykorzystać wszystkie możliwości scenopisu, można wykonać połączenie scenariusza z reprezentacją graficzną. Taka forma może okazać się bardziej zrozumiała zarówno dla twórców oprogramowania, jak i dla przyszłych użytkowników, którzy niekoniecznie posiadają wiedzę techniczną. Rysunek 3.3 przedstawia przykładową notację scenopisu w takiej formie. Scenopis zawiera nazwę przypadku użycia z opcjonalnie wyróżnionym scenariuszem. Dzięki temu łatwo zidentyfikować dany scenopis. Sceny, podobnie jak poprzednio, przedstawiają stan systemu w kroku scenariusza, który definiuje ważne z punktu widzenia interfejsu użytkownika elementy (dla przedstawionego przypadku, kroki 1, 2 i 4).

Rysunek 3.3: Notacja scenopisu powiązanego ze scenariuszem

Taka ilustracja scenariuszy przypadków użycia daje pełny obraz przejścia przez wszystkie kroki scenariusza przypadku użycia. Dla każdego przypadku użycia może być zdefiniowanych tyle scenopisów, ile jest scenariuszy. Często jednak tworzy się jeden scenopis dla scenariusza głównego. Dla scenariuszy alternatywnych można rozwinąć główny scenopis o alternatywne ścieżki – podobnie jak w przypadku diagramów czynności, gdzie warunki przejścia do alternatywnego scenariusza oznaczane są na rozgałęzionych strzałkach. Różnica polega na przedstawieniu w scenopisie niektórych akcji jako strzałki (przejścia między scenami). Na diagramie czynności wszystkie akcje przedstawiane są jako elipsy.

Z punktu widzenia całego procesu inżynierii oprogramowania, tworzenie scenopisów jest podstawą dla procesu prototypowania. Prototyp jest początkową wersją systemu oprogramowania, która służy do prezentacji założeń i wypróbowania wariantów projektu. Ogólnie można powiedzieć, że prototyp służy do coraz lepszego poznawania problemu i jego możliwych rozwiązań. Szybkie stworzenie prototypu umożliwia panowanie nad kosztami i umożliwia eksperymentowanie wspólnie z przyszłymi użytkownikami już we wczesnych fazach procesu wytwarzania oprogramowania. Istnieją dwa rodzaje prototypowania: zamknięte (z porzuceniem) i otwarte (ewolucyjne).

Prototyp zamknięty służy tylko do ogólnego przedstawienia wymagań stawianych systemowi oprogramowania – jest prototypem jednokrotnego użycia. Po jego wykorzystaniu wyrzuca się go, a ostateczną wersję oprogramowania tworzy się od podstaw innymi metodami. Dzięki takiemu podejściu można w łatwy sposób, po ocenie i potrzebnych modyfikacjach, udoskonalić i zatwierdzić wymagania oprogramowania. Ocena prototypu inspiruje opracowywanie szczegółowej specyfikacji wymagań.

Prototyp otwarty pomaga nie tylko w fazie analizowania, ale także w fazie projektowania i jest podstawą implementacji ostatecznej postaci oprogramowania. Dzięki takiemu podejściu prototyp jest wielokrotnie używany poprzez przedstawianie użytkownikowi kolejnych niekompletnych wersji systemu. Realizacja najlepiej rozpoznanych i najważniejszych wymagań, a następnie ich ocenianie, modyfikowanie i uzupełnianie o nowe dobrze rozpoznane funkcjonalności sprawia, że wymagania użytkowników stają się jasne i w pełni odzwierciedlone w tworzonym oprogramowaniu.

W podejmowaniu decyzji, jaki typ prototypu stworzyć, należy brać pod uwagę kilka istotnych kwestii związanych z jakością specyfikacji wymagań:

• W przypadku kiedy wymagania są znane i stabilne, lepiej stworzyć prototyp wielokrotnego użycia. Pozwoli to na wczesne rozpoczęcie prac związanych z wytworzeniem ostatecznej wersji oprogramowania.
• Kiedy wymagania są niejasne, lub kiedy występują w nich sprzeczności, prototyp jednokrotnego użycia będzie bezpieczniejszą alternatywą. Ostateczna wersja oprogramowania nie będzie obarczona błędami spowodowanymi złą specyfikacją wymagań.

Inne ważne rozróżnienie między tymi podejściami leży w zarządzaniu jakością systemów. Czas życia prototypów porzucanych jest z definicji krótki. W czasie jego budowania musi istnieć możliwość wprowadzenia bardzo szybkich zmian, nie jest natomiast wymagana zdatność do długoterminowej pielęgnacji. Mała efektywność i niezawodność są akceptowane w wypadku prototypu porzucanego, jeśli spełnia on swą podstawową funkcję pomocy w rozpoznawaniu i prezentacji wymagań. Prototypy, które ewoluują w kierunku gotowych systemów, powinny być budowane zgodnie z takimi samymi standardami firmowymi jak inne oprogramowanie. Powinny mieć prężną architekturę, która umożliwi ich wieloletnią pielęgnację.