Graficzne systemy interakcyjne - za i przeciw

Zagadnienia związane z projektowaniem interakcji w systemach komputerowych poruszaliśmy już w poprzednim odcinku, mówiącym o technikach projektowania systemów komunikujących się z użytkownikami za pośrednictwem terminali tekstowych. Takie mechanizmy interakcji są dziś stale jeszcze dominujące w dużych systemach klasy host/terminal obsługujących bazy danych. Dla takich systemów ograniczeniem w zastosowaniu bardziej wyrafinowanych metod interakcji są m.in. koszty stacji graficznych, zwykle dużo droższych od terminali tekstowych. Tworzenie warstwy dialogu z użytkownikiem dla aplikacji graficznych jest zadaniem znacznie trudniejszym i bardziej pracochłonnym niż projektowanie ekranowych formularzy tekstowych.

Problemy dotyczą w pierwszym rzędzie kwestii technicznych. Programowanie graficznej interakcji intensywnie wykorzystuje techniki obiektowe, jest ukierunkowane na obsługę zdarzeń i ogólnie rzecz biorąc w istotny sposób różni się od tradycyjnego liniowo-strukturalnego podejścia. Mimo ogólnego zainteresowania tego typu zagadnieniami, nie ma zbyt wielu zespołów projektowych, dla których programowanie obiektowe i graficzne techniki interakcji byłyby podstawowymi, naturalnymi środkami przy tworzeniu dużych systemów informatycznych.

Pokonanie trudności technicznych związanych z technikami graficznej interakcji nie rozwiązuje jednak znacznie poważniejszego problemu, jakim jest faktyczny brak uznanych standardów metod projektowania i specyfikowania aplikacji graficznych. Zadanie to jest znacznie trudniejsze niż specyfikacja i projektowanie aplikacji tekstowych. Różnica między tymi dwoma stylami interakcji nie polega bowiem jedynie na odmiennym sposobie prezentowania danych. Aplikacje tekstowe same decydują o tym, jakie dane i w jakiej kolejności zostaną wyświetlone i ograniczają zbiór wykonywanych funkcji do wąskiego, "jedynie słusznego" w danym momencie zestawu. Ścieżka wykonania w takiej aplikacji jest deterministyczna, w niewielkim stopniu kształtowana przez decyzje użytkownika. Dla odmiany aplikacje graficzne charakteryzują się swobodą pracy i oddaniem inicjatywy w dialogu użytkownikowi, co wprowadza do nich elementy niedeterminizmu. Niedeterminizm w aplikacjach graficznych realizowany jest zwykle poprzez podejście obiektowe, nierozerwalnie związane z graficznymi środowiskami interakcyjnymi. Komunikację z obiektami dialogowymi zapewni obsługa zdarzeń, kojarząca akcje użytkownika (ruch myszki, naciśnięcie klawisza, dotknięcie ekranu dotykowego) ze związanymi z obiektami metodami ich obsługi. Krótko mówiąc - zastosowanie graficznych metod interakcji to kłopoty zarówno dla projektantów, jak i dla programistów. Mając tę świadomość wypada przedstawić powody, dla których warto jednak decydować się na tworzenie aplikacji graficznych.

Powód pierwszy - oczekiwania użytkowników. W biurach coraz większą popularnością cieszy się środowisko MS Windows. Rośnie więc rzesza potencjalnych użytkowników systemów informatycznych, rozpieszczanych przez znakomite aplikacje biurowe, takie jak procesory tekstów, arkusze kalkulacyjne, poczta elektroniczna czy "gadżety" w rodzaju terminarzy, notesów telefonicznych i edytorów graficznych. Kolejną sprawą jest integracja aplikacji dająca bogate możliwości wymiany i współdzielenia danych między programami. Integracja za pomocą mechanizmów takich jak DDE czy OLE sprawia, że każdy nowy element środowiska wzmacnia jednocześnie siłę i użyteczność pozostałych aplikacji. Do dobrego łatwo się przyzwyczaić, nie należy się więc dziwić, jeśli podobnych możliwości użytkownicy oczekują od powstających systemów informatycznych.

Powód drugi - efektywność pracy. Wśród wielu "zawodowych informatyków" można jeszcze dziś spotkać się z pobłażliwym traktowaniem intuicyjnych mechanizmów obsługi oferowanych przez środowiska graficzne. Tymczasem są one praktyczną odpowiedzią na poważny problem, jakim jest odrzucanie gotowych systemów przez końcowych użytkowników. Efektem pionierskich prac prowadzonych w tej dziedzinie w latach 70. przez laboratoria PARC XEROX w Palo Alto był system biurowy! System STAR zawierał większość wykorzystywanych dziś w graficznej interakcji mechanizmów - piktogramy, obiektowe potraktowanie dokumentów tworzonych przez aplikacje, okna, obsługę za pomocą myszki i metaforę prezentacji, zwaną "metaforą biurka" (desktop metaphor).

Dziś wiadomo już, że graficzne metody prezentacji danych zwiększają możliwości przekazu informacji. Preferencja gestu, stanowiącego naturalny środek ekspresji człowieka w interakcji daje użytkownikom wrażenie swobody i panowania nad aplikacją. Dzięki temu wykorzystują oni programy w sposób bardziej innowacyjny i efektywny. Przyjazność mechanizmów obsługi i efektowna prezentacja sprawia, że wielu użytkowników aplikacji graficznych zwyczajnie lubi wykorzystywane przez siebie programy. Taki emocjonalny związek ma oczywiście pozytywny wpływ na efekty pracy użytkowników.

Powód trzeci - łatwość wdrożenia. W ocenie kosztów systemów informatycznych często pomija się koszty związane z koniecznością przeszkolenia użytkowników i spadkiem ich wydajności w początkowej fazie eksploatacji systemu. Dla systemu uciążliwego w obsłudze mogą to być koszty znaczące. Dlatego ważną z punktu widzenia inwestorów cechą oprogramowania jest łatwość jego wdrożenia. Tę łatwość osiągają aplikacje graficzne poprzez zachowanie standardów obsługi określonych dla danego środowiska. Takim standardem jest np. norma Common User Access firmy IBM zastosowana w MS Windows, Presentation Manager i OSF Motif. Standardy sprawiają, że znając dwie aplikacje, użytkownik doskonale potrafi zrealizować podstawowe funkcje trzeciej, takie jak mechanizmy edycji, drukowanie, zarządzanie dokumentami, system pomocy. Stosunkowo łatwo jest mu się też nauczyć mechanizmów specyficznych, dzięki standardom interakcji takim jak idiom obiekt-akcja, zasady zaznaczania (selekcji) obiektów, standardowe obiekty dialogowe, typowe akcje myszki, itp.

Powód czwarty - systemy wspomagające tworzenie aplikacji graficznych. Dziś rynek oferuje wiele profesjonalnych narzędzi znakomicie ułatwiających tworzenie aplikacji graficznych. Są nimi biblioteki klas obiektów dialogowych, "programy do składania" aplikacji graficznych, czy wreszcie zintegrowane pakiety do projektowania i konstrukcji aplikacji graficznych. W zależności od potrzeb, skali projektu i posiadanych zasobów, twórcy oprogramowania mogą zaopatrzyć się w narzędzia eliminujące wiele problemów, związanych z tworzeniem graficznych systemów interakcyjnych.

Problemem pozostaje jednak nieadekwatność klasycznych technik projektowania do zadań związanych z graficznymi programami interakcyjnymi. Oto niektóre propozycje technik wykraczające nieco poza ramy klasycznych strukturalnych metodyk projektowania.

Metafory

Podstawową sprawą w aplikacji graficznej jest wybór metafory prezentacji determinującej sposób prezentacji i mechanizmy obsługi. Właściwie dobrana metafora pozwala na wykorzystanie intuicji i umiejętności wcześniej nabytych przez użytkownika do obsługi programu. Najbardziej popularna "metafora biurka" utożsamia ekran z blatem biurka, zbiory z dokumentami, katalogi z teczkami na dokumenty i dyski z szafkami. W czystej metaforze biurka nie ma w ogóle pojęcia "uruchamiania programu". Zamiast tego występuje pojęcie otwierania dokumentu. Do systemu operacyjnego należy skojarzenie typu dokumentu z właściwą dla niego aplikacją. Otwarte dokumenty prezentowane są w okienkach, które tak jak kartki na biurku można dowolnie przemieszczać po ekranie. Ta metafora wydaje się szczególnie przydatna dla aplikacji biurowych.

Inna metafora to np. metafora kołonotatnika, zastosowana po raz pierwszy w systemie HyperCard na komputerach Macintosh. Informacja podzielona jest na kartki mieszczące się w całości na ekranie komputera. Jeśli informacji jest zbyt wiele jak na jedną kartkę - zamiast pojedynczej kartki mamy cały ich stos, który można przeglądać strona po stronie. Funkcje programu uruchamiane są przez obiekty dialogowe - przyciski, "zakładki" - rozmieszczone na kartkach kołonotatnika. Upraszcza to radykalnie mechanizmy obsługi programów, czyniąc je łatwymi w obsłudze, zwłaszcza dla niewprawnego użytkownika. Nawigacja w stosie kartek nie musi być liniowa. Informacja wyświetlona na kartach może być aktywna i pełnić rolę odsyłaczy do innych kart lub stosów kart. Sprawia to, że metafora kołonotatnika jest, przy całej swej prostocie obsługi, potężnym mechanizmem do prezentacji skomplikowanych zbiorów informacji o nieliniowej strukturze (takich jak encyklopedia).

Standardy

Standardy konstrukcji aplikacji graficznych były przez długie lata jedynym wsparciem dla zespołów projektowych. Każdemu poważnemu systemowi interakcyjnemu, będącemu środowiskiem działania wielu aplikacji towarzyszy zbiór norm, określających sposób konstrukcji obiektów dialogowych oraz standardy opcji menu i akcji programu. Porządkująca rola tych norm jest na pewno nie do przecenienia. Wypływającą z nich podstawową korzyścią jest ułatwienie użytkownikom poznawania nowych aplikacji.

Niestety, standardy takie jak wymieniona wcześniej norma CUA nie zawierają w zasadzie wskazówek metodycznych, pozwalających na określenie najwłaściwszej prezentacji danych aplikacji. Jeśli aplikacja nie ma łatwo identyfikowalnego zasadniczego dokumentu na którym działa, zasady zawarte w normach nie na wiele się przydają. Niewiele też mówią nt. implementowania mechanizmów interakcji bezpośredniej (direct manipulation) pozwalających użytkownikom działać na danych aplikacji bez pośrednictwa standardowych obiektów dialogowych. Interakcja bezpośrednia pozwala dopiero w pełni wykorzystać możliwości środowisk graficznych. Dlatego oprócz standardów potrzebne są techniki pozwalające wyspecyfikować model interakcji najbardziej adekwatny dla potrzeb użytkownika.

Analiza zadań i modelowanie obiektów użytkownika

W wyniku praktycznego zastosowania w dziedzinie komunikacji człowiek-komputer rezultatów psychologii kognitywnej powstały takie techniki projektowania dialogu, jak analiza zadań (task analysis), modelowanie obiektów użytkownika i modelowanie obiektów dialogowych. Są to techniki nowe, nie tak okrzepłe jak klasyczne modelowanie danych czy analiza funkcyjna. Wydaje się jednak, że dla pewnej klasy aplikacji (np. systemy klient/serwer) mogą wyprzeć techniki tradycyjne. Są stosunkowo proste, szybko prowadzą do rezultatu w postaci prototypu aplikacji, a co najważniejsze są świetnie dostosowane do mechanizmów interakcji graficznej.

Analiza zadań jest techniką, której głównym celem jest zapewnienie funkcjonalności aplikacji, realizującej koncepcyjny model czynności wytworzony przez użytkownika. Dlatego wychodzi się w niej od opisania profilu użytkownika. W analizie zadań pyta się o to kim są użytkownicy, jaki jest ich stopień obycia z technologią komputerową, jakie czynności wykonują w ramach objętej automatyzacją części swojej pracy i jakie obiekty są podmiotem tych czynności. Podmioty czynności użytkowników stają się dobrymi kandydatami na główne obiekty dialogowe aplikacji. Są to często odpowiedniki dokumentów, "dotykalnych" obiektów, organizacji czy osób. Obiekty istotne dla użytkownika można reprezentować na diagramach o notacji podobnej do modeli danych. Mają one - podobnie jak encje - swoje atrybuty, można też modelować zachodzące między nimi związki. Obiekty te różnią sę jednak w istotny sposób od encji z modelu danych. Mogą zawierać grupy powtarzających się atrybutów (np. obiekt opisujący wykładowcę w firmie szkoleniowej, mógłby mieć listę prowadzonych przez niego zajęć). Mogą reprezentować grupy obiektów, nie występujące raczej na modelach danych. Na przykład katalog kursów proponowanych słuchaczom - pełnoprawny obiekt użytkownika, z punktu widzenia modelowania danych jest zbiorem encji "Typ Kursu". Wreszcie typowym rodzajem związków w modelach obiektów użytkownika będą niepożądane z punktu widzenia konstrukcji bazy danych, związki wiele-do-wielu.

Model obiektów jest dobrym materiałem do stworzenia - poprzez rozwikłanie związków wiele-do-wielu i normalizację - ostatecznego modelu danych. Jeśli model danych stworzono wcześniej, to możemy go wykorzystać, jako punkt odniesienia i źródło atrybutów. Taka sytuacja często wystąpi w systemach o architekturze klient/serwer. W takich systemach często spotykamy się z ustabilizowaną strukturą bazy danych (modelu danych), podczas gdy aplikacje klienta budowane są stopniowo. Model danych wykorzystywany jest do konstrukcji zapytań SQLowych, stanowiących odwołania aplikacji klienta do serwera.

Modelowanie obiektów dialogowych

Po skonstruowaniu i weryfikacji modelu danych projektanci mogą zabrać się do konkretnej pracy. Każda encja na modelu danych to potencjalnie jedno okno. Funkcje dostępne w konstruowanym formularzu muszą odpowiadać zestawowi czynności wykonywanych przez użytkowników na danym obiekcie. Funkcje uruchamiane są przez odpowiednie obiekty dialogowe. Część funkcji wymaga przygotowania zlecenia dla serwera i wysłanie go "po sieci".

Nie da się w systemach graficznych stworzyć tak prostego modelu dialogu jak w aplikacjach tekstowych. Można jednak zaproponować możliwe ścieżki "do..." i "...od" każdego obiektu dialogowego. Zestaw takich ścieżek tworzy swego rodzaju graf nawigacji, pozwalający ocenić stopień komplikacji programu i łatwość dostępu do często używanych jego funkcji.

Analiza funkcyjna i modelowanie obiektów użytkownika służą do wyodrębnienia obiektów dialogowych w taki sposób, aby odpowiadały one intuicjom użytkownika co do przedmiotu działania aplikacji. Ostatnim elementem składającym się na aplikację graficzną jest prezentacja - sposób wyświetlania obiektów na ekranie i przyjęty standard obiektów służących do manipulacji danymi. Ten element znakomicie regulowany jest przez wszelkiego rodzaju normy dotyczące graficznej interakcji. Efektywność i utrzymanie standardów dotyczących interakcji zapewniają techniki obiektowe, takie jak tworzenie hierarchii klas obiektów dialogowych, w których klasy stanowiące elementy hierarchii dziedziczą podstawowe elementy dotyczące wyglądu i funkcjonalności od klas nadrzędnych (stojących wyżej w hierarchii). Techniki obiektowe, to jednak dopiero przyszłość metodyk strukturalnych. Podejmowane są co prawda próby stworzenia standardów notacji i technik pracy dla obiektowej analizy i projektowania, nie są one jeszcze na tryle ugruntowane, aby stanowić solidną podstawę dla pracy dużych zespołów projektowych.

Wszystkie rysunki wykonane zostały z wykorzystaniem systemu Systems Engineer for Client/Server firmy LBMS.