Projektowanie interakcji (systemy OLTP)

W ramach naszego cyklu mówiliśmy o technikach za pomocą których analitycy i projektanci podają specyfikacje, dane systemu i określają funkcje operujące na tych danych. Wspomnieliśmy o technikach których zadaniem jest przetworzenie informacji, uzyskiwanej od użytkowników, na w miarę formalną specyfikację modułów powstającego systemu. Dziś powiemy o trzecim istotnym składniku każdego systemu informatycznego - o jego warstwie interakcyjnej.

W ramach naszego cyklu mówiliśmy o technikach za pomocą których analitycy i projektanci podają specyfikacje, dane systemu i określają funkcje operujące na tych danych. Wspomnieliśmy o technikach których zadaniem jest przetworzenie informacji, uzyskiwanej od użytkowników, na w miarę formalną specyfikację modułów powstającego systemu. Dziś powiemy o trzecim istotnym składniku każdego systemu informatycznego - o jego warstwie interakcyjnej.

Problemy związane z projektowaniem interakcji

Zdecydowana większość systemów powstających w organizacjach zajmujących się produkcją oprogramowania lub przetwarzaniem danych, to systemy obsługiwane interakcyjnie, a nie wsadowo. Nic więc dziwnego, że interfejs graficzny traktowany jest przez projektantów systemów z coraz większą powagą. Świadczy o tym choćby olbrzymie bogactwo graficznych środowisk interakcyjnych i skala inwestycji podejmowanych w tej dziedzinie przez najpoważniejsze firmy informatyczne takie jak: Microsoft, Apple, Xerox, czy laboratoria zajmujące się "wirtualną rzeczywistością" (virtual reality). Nie dzieje się tak bez powodu. Jeśli przyjrzymy się przyczynom niepowodzeń w przemyśle informatycznym, okaże się, że poważny odsetek systemów jest odrzucany przez użytkowników, nawet mimo formalnej zgodności z przyjętą początkowo specyfikacją. Systemy "strategiczne", których beneficjentem jest zwykle szczebel kierowniczy w organizacji, mogą powodować znaczące obciążenie nowymi obowiązkami szeregowych pracowników. Zostają oni zmuszeni do skrupulatnego wprowadzania różnorodnych danych, rejestracji korespondencji czy uważnego wypełniania komputerowych formularzy, nie mając jednocześnie żadnych oczywistych korzyści z systemu. Praca końcowych użytkowników systemu niekoniecznie ulega uproszczeniu, za to wymaga spędzania długich godzin przed ekranem komputera. Pojawia się wówczas niebezpieczeństwo milczącego oporu wobec nowych, zautomatyzowanych procedur pracy. Przydatność systemu, w którym dane są nieaktualne, nieprawdziwe, albo niekompletne staje się wielce problematyczna. Niechęć użytkowników do korzystania z systemów komputerowych bywa zapewne w wielu wypadkach uzasadniona. Większość pracowników przyzwyczajona jest do określonego warsztatu pracy (np. standardowych dokumentów, formularzy), organizacji pracy (kolejność wykonywanych czynności, urządzenia na jakich się je wykonuje) i organizacji informacji (np. określony sposób segregacji dokumentów). Nieuwzględnienie tych przyzwyczajeń, przez projektantów systemu informatycznego, stawia użytkownika przed koniecznością poznania nie tylko "technicznych" aspektów korzystania z systemu, takich jak układ klawiatury, sposób korzystania z drukarki. Radykalna zmiana procedur pracy sprawia, że użytkownik, być może ekspert w swoim zawodzie, musi się tego zawodu uczyć na nowo. Opór użytkowników jest w takich sytuacjach zrozumiały. Oczywiście rzadko możliwe i sensowne jest powielanie wszystkich elementów "ręcznych" metod pracy w systemie zautomatyzowanym. Nie należy jednak mylić tego co jest konieczne z punktu widzenia automatyzacji przetwarzania danych, z błędami wynikającymi z niezrozumienia specyficznych potrzeb użytkownika.

Osnucie struktur dialogowych wokół struktury bazy danych - jakże częste w systemach interakcyjnych - jest podstawowym błędem popełnianym przy projektowaniu dialogu z użytkownikiem. Struktura danych (reprezentowana np. na modelu danych) zapewnia optymalną organizację informacji z punktu widzenia relacyjnych systemów baz danych. Taka organizacja burzy jednak postać pierwotnych dokumentów stanowiących naturalny "środek wyrazu" dla użytkownika. Język prezentowany przez system komputerowy bywa często niezrozumiały, zbyt techniczny, używający nieintuicyjnych pojęć, nieadekwatny do zadań realizowanych przez użytkowników za pomocą komputera.

Osobnym problemem jest właściwa struktura listy poleceń - menu - pozwalającej uruchamiać funkcje systemu. Często zdarza się, że bezmyślne klasyfikowanie funkcji systemu w coraz to inne logiczne grupy, daje w efekcie drzewa menu o skomplikowanej, wielopoziomowej budowie, skutecznie utrudniającej wykonanie najprostszych czynności przez operatorów.

Projektowanie interakcji w systemach OLTP

Organizajca dialogu z użytkownikiem w interakcyjnych systemach przetwarzania transakcyjnego (OLTP) jest technicznie stosunkowo prosta. Możemy się tu oprzeć na katalogu transakcji powstałym przy zastosowaniu techniki analizy funkcyjnej (patrz numer 38 CW). Podstawowym budulcem interakcji są fragmenty specyfikacji dialogu związane z poszczególnymi transakcjami interakcyjnymi. Dla każdej takiej transakcji możemy stworzyć prosty diagram prezentujący scenariusz wymiany informacji między człowiekiem a maszyną. Pokazuje on kiedy system wymaga wprowadzenia danych, kiedy wyświetlane są informacje oraz przejście między formatkami (wybór opcji menu) zależy od zajścia jakiegoś dodatkowego warunku. Nasz przykładowy diagram (rys. 1) ukazuje scenariusz dialogu z użytkownikiem dotyczący wprowadzania zamówienia do komputerowego systemu wspomagającego sprzedaż towarów. Grube strzałki oznaczają momenty wymiany danych pomiędzy systemem komputerowym a użytkownikiem - wczytywanie (strzałki skierowane w prawo) i wyświetlanie danych (skierowane w lewo). Symbol w kształcie rombu określa moment, w którym możliwe są różne wersje dialogu, w zależności od zajścia pewnych warunków.

Przykładowy diagram pokazuje następujacy scenariusz dialogu:

1. Użytkownik podaje numer klienta.

2. Jeśli klient jest niezarejestrowany, to

2.1 następuje uzupełnienie pozostałych danych o kliencie.

3. Następnie dane o kliencie są wyświetlane (dla weryfikacji).

4. Następuje wpisanie nagłówka (data, numer) zamówienia i

5. Wpisanie kolejnych jego pozycji.

Transakcje interakcyjne można teraz pogrupować w logiczne grupy (rys. 2). W pierwszej chwili można się kierować wynikami analizy funkcyjnej, grupując transakcje zgodnie z implementowanymi przez nie funkcjami systemu, wyodrębnionymi w trakcie analizy funkcyjnej. Te można następnie pogrupować w menu wyższego poziomu.

Taką pierwszą przymiarkę należy następnie zweryfikować, najlepiej w czasie sesji z użytkownikiem. Bardzo rzadko to, co jest naturalne i oczywiste dla programisty, czy analityka, jest równie oczywiste dla użytkownika. Tylko wraz z użytkownikiem jesteśmy w stanie "dostroić" warstwę interakcyjną programu tak, aby najczęściej wykorzystywane funkcje dostępne były najłatwiej oraz aby operacje, które często wykonuje się razem były możliwie blisko siebie w hierarchii menu. Dobrze jeśli taki diagram można zilustrować prototypem - makietą systemu. Można wówczas weryfikować z użytkownikiem zarówno projekt dialogu, zastosowaną terminologię i mechanizmy obsługi, kolorystykę, sposób wyświetlania na ekranie ważnych komunikatów i układ pól.

Graficzne systemy interakcyjne

Znacznie trudniejszym zadaniem jest zaprojektowanie aplikacji wykorzystującej graficzne techniki interakcji - obiekty dialogowe, mysz, ekran dotykowy i mechanizmy interakcji bezpośredniej (direct manipulation).

Aplikacje graficzne są dzisiaj, dzięki aplikacjom systemu , coraz częściej wykorzystywane w systemach automatyzacji prac biurowych. Powoduje to z jednej strony wzrost wymagań co do "przyjazności" systemów komputerowych, również tych tworzonych "pod klucz", z drugiej zaś standard interakcji zachowywany przez aplikacje MS Windows znakomicie ułatwia opanowanie nowych produktów, radykalnie skracając czas potrzebny na wyszkolenie użytkowników. Dlatego graficzne systemy interakcyjne (GUI) pojawiają się coraz częściej nie tylko w "konfekcji" programowej (procesory tekstów, arkusze kalkulacyjne). Są one dziś podstawowym mechanizmem wykorzystywanym dla aplikacji klienckich w poważnych systemach o architekturze klient/serwer.

Graficzne programy interakcyjne z trudem poddawały się dotychczas rygorowi uporządkowanego procesu produkcyjnego. Sposoby ich projektowania więcej miały w sobie żywiołowego eksperymentowania niż z inżynierskiej dyscypliny. Działo się tak z racji dużej swobody, jaką dają one użytkownikom w wyborze kolejności i sposobu realizacji poszczególnych zadań oraz ze względu na ciągłe poszukiwania optymalnej prezentacji i mechanizmów interakcji przez twórców tych systemów. Wiele mówiło się i pisało o psychologicznych aspektach prezentacji, doborze metafor, intuicyjności różnych mechanizmów obsługi, brakowało jednak rzetelnych kryteriów jakościowych i technik analizy pozwalających w miarę pewnie stworzyć właściwy dla danej klasy użytkowników produkt. W chwili "okrzepnięcia" koncepcji związanych z architekturą klient/serwer, w której aplikacje graficzne grają kluczową rolę, brak sensownych metod projektowania stał się jednak problemem.

W następnym odcinku przedstawimy koncepcje projektowania systemów, związane z graficzną interakcją i omówimy metody projektowania powstałe dla architektury klient-serwer.


TOP 200