[ Pobierz całość w formacie PDF ]

da z nich może wymagać wielu ruchów użytkownika końcowego. Każdy z nich jest nadal jest
pojedynczym krokiem w przypadku użycia. Liczba ruchów lub kliknięć myszą potrzebnych do
osiągnięcia celu jest kwestią projektu interfejsu użytkownika, a nie kwestią wymagań. Przesunię-
cie obiektu lub zmiana jego koloru nie jest algorytmem w matematycznym, a nawet potocznym
tego słowa znaczeniu  to jest atomowa operacja. Jeśli nie ma biznesowej potrzeby, by grupować
takie operacje, to każda z nich jest osobną komendą i w rzeczywistości nie potrzebujemy przy-
padków użycia. Użytkownik nie wykonuje sekwencji zadań w celu osiągnięcia jakiegoś celu w kon-
tekście. Każde polecenie sprowadza się do prymitywnej operacji na samym obiekcie dziedziny
i sam wzorzec MVC ze swoją metaforą bezpośredniej manipulacji wystarczy do wykonania pracy.
Jeśli zdecydujemy się skorzystać z przypadków użycia w celu uchwycenia wejścia do systemu
zdominowanego przez atomowe operacje, możemy uzyskać setki przypadków użycia opisujących
oczywiste scenariusze.
7.7.1. Klasyczne programowanie obiektowe:
architektury atomowych zdarzeń
Jednym ze sposobów na wyjaśnienie sukcesu programowania obiektowego jest to, że umożliwiło
ono wykorzystanie graficznych interfejsów użytkownika i myszy. Te style interakcji człowieka
z komputerem zdobyły naszą wyobraz
nię i doprowadziły do tego, że użytkownicy zaczęli uważać
komputery za towarzyszy podczas rozwiązywania problemów, a nie za odległych podwykonawców.
Ludzkie zadowolenie z natychmiastowej informacji zwrotnej, szybkość (lub przynajmniej złu-
dzenie szybkości) uzyskania rozwiązania i przypominające  ludzkie zachowania interfejsów
w Xerox PARC utorowały drogę dla wpływów Smalltalka na świat.
Związek między zaangażowaniem użytkowników i Smalltalkiem w szczególności lub pro-
gramowaniem obiektowym w ogóle jest więcej niż przypadkowy. Istnieje ciągłość reprezentacji
prowadząca od modelu mentalnego świata użytkownika końcowego, poprzez interfejs graficzny,
do struktury obiektów należących do interfejsu. Koncepcja jest taka, że użytkownik manipuluje
elementami interfejsu użytkownika w sposób, który skłania go do myślenia, że bezpośrednio mani-
puluje obiektami w programie  lub, jeszcze lepiej, obiektami świata rzeczywistego reprezento-
wanymi przez te obiekty programowe. Umieszczenie towaru w koszyku w księgarni internetowej
daje użytkownikowi końcowemu, przynajmniej metaforycznie, poczucie prawdziwych zakupów
z koszykiem. Zjawisko to czasami jest nazywane metaforą bezpośredniej manipulacji (Laurel 1993).
Kup książkę Poleć książkę
7.8. Testowanie użyteczności 197
W dalszej części książki omówimy architekturę Model-View-Controller-User (podrozdział 8.1)
jako najpopularniejszy sposób tworzenia iluzji obsługi tej metafory.
Aby coś zrobić na interfejsie GUI z bezpośrednią manipulacją, najpierw wybieramy obiekt
(na przykład książkę), a następnie manipulujemy nim (umieszczamy w koszyku). Wydaje się
niezręczne, aby zamiast tego najpierw powiedzieć:  Chcę kupić książkę , a następnie ją wybrać.
Jest tak dlatego, że przed faktycznym podjęciem decyzji o realizacji zakupu najpierw myślimy
o książce. Prawdopodobnie nie odwiedzilibyśmy strony, gdybyśmy mieli rozstrzygać o tym, czy
chcemy kupić książkę. Ten styl interakcji określa się jako rzeczownik-czasownik: najpierw wy-
bieramy rzeczownik (książkę), a następnie akcję (zakup).
Zwróćmy uwagę na ścisłe powiązanie z naszą architekturą, która zawiera część czym-system-jest
(książki) oraz co-system-robi (takie przypadki użycia jak: zakup książki, wyszukiwanie wcześniej-
szych wydań książki oraz odczytywanie recenzji książki).
Metafora rzeczownik-czasownik prowadzi do interfejsów, które przeprowadzają użytkowni-
ka przez sekwencję ekranów lub kontekstów. Kiedy wybieramy książkę, znajdujemy się w kon-
tekście myślenia o tej książce. Książka ma fizyczną reprezentację na ekranie (zdjęcie okładki,
ISBN lub tytuł i autor), która wypełnia nasz umysł. Procesy świadomości w naszym umyśle kon-
centrują się na tym obiekcie. Jest wiele czynności, które możemy zrobić z tym obiektem, a proces
myślenia prowadzi nas do miejsca, w którym chcemy być. Dopiero wtedy  wykonujemy ko-
mendę . Ta  komenda jest poleceniem w rodzaju  włóż tę książkę do koszyka z zakupami . Na
większości interfejsów graficznych będziemy odtwarzać ten scenariusz przez naciśnięcie przycisku
oznaczonego etykietÄ…  Dodaj do koszyka .
Oznacza to, że obiekt na ekranie (książka) jest jak obiekt w programie, a na ekranie widzimy,
jak możemy manipulować tym obiektem w sposób, który ma sens biznesowy (umieścić go w ko-
szyku, pobrać recenzje itp.). Są to w istocie funkcje członkowskie wykonywane na tym obiekcie.
Klient pracuje i wywołuje polecenia  w niezwykle skonkretyzowanym kontekście: tzn. na tym
obiekcie. Obiekt staje się interpreterem poleceń  jest zdolny do wykonania jednej prymitywnej
operacji na raz.
Z kolei ten styl interakcji prowadzi do stylu architektury, którą w tej książce nazywamy ar-
chitekturą zdarzeń atomowych. Taki styl koncentruje się na obiektach oraz tym, co możemy z nimi
zrobić, a nie na  scenariuszach , które istnieją w retrospekcji jako zbiór tych zdarzeń i komend.
Kontekst możemy przyjąć za pewnik. Dokładniej skupiamy się na rolach, jakie obiekty mogą
spełniać w bieżącej sytuacji (choć książka może służyć za stoper do drzwi, kupując książkę online,
koncentrujemy się na innej roli). Dajemy użytkownikom wybór, pozwalając im na interakcję z pro-
gramami w sposób Agile: w danym momencie mogą dokonać jednego wyboru. Gdybyśmy za-
miast tego skupili się na scenariuszu, mielibyśmy główny plan, który wykluczałby wybieranie
różnych książek w różnej kolejności oraz eliminowałby opcję użytkownika do zmiany kursu w do-
wolnej chwili (żeby zapomnieć bieżącą książkę i przejść do innej albo  wyjąć książkę z koszyka na
zakupy).
7.8. Testowanie użyteczności
Testy użyteczności skupiają się na interakcji pomiędzy użytkownikiem końcowym a systemem.
Ich celem jest zapewnienie, aby typowi użytkownicy końcowi, którzy mieszczą się w typowych
profilach użytkowników mogli osiągnąć to, co chcą osiągnąć. Przeprowadzenie dobrych testów
użyteczności wymaga umiejętności specjalnie wyszkolonych i doświadczonych testerów. Specjaliści
w dziedzinie interakcji z użytkownikami wykonują takie testy, dając użytkownikom końcowym
Kup książkę Poleć książkę
198 Rozdział 7. Co system robi: funkcje systemu
przykładowe ćwiczenia lub zadania do wykonania, i monitorują interakcje pomiędzy użytkow-
nikiem końcowym a planowanym systemem. Dokładnie notują, które ekrany są wykorzystywane
w przypadku użycia oraz jakie interakcje zachodzą między użytkownikiem a systemem. Tego ro-
dzaju test w kontekście architektury sprawdza, czy uchwyciliśmy model mentalny użytkownika
końcowego.
Firmy zbyt często odkładają testy użyteczności do czasu ukończenia prac rozwojowych nad
oprogramowaniem, traktując je jak testy akceptacyjne. W tym momencie jest już za póz
no. Jeśli [ Pobierz całość w formacie PDF ]

zanotowane.pl

doc.pisz.pl

pdf.pisz.pl

domowewypieki.keep.pl