Projektowanie oprogramowania czasu rzeczywistego Systemy czasu rzeczywistego Komputery

Projektowanie oprogramowania czasu rzeczywistego Systemy czasu rzeczywistego Komputery są obecnie używane do sterowania rozmaitymi systemami, począwszy od maszyn domowych do całych hal produkcyjnych. Te komputery bezpośrednio porozumiewają się z urządzeniami sprzętowymi. Ich oprogramowanie jest wbudowanym systemem czasu rzeczywistego, który musi reagować na zdarzenia powodowane przez sprzęt i wysyłać sygnały sterujące w odpowiedzi na te zdarzenia. 1

Definicje System czasu rzeczywistego jest systemem oprogramowania, którego poprawne działanie zależy od wyników przez niego wytwarzanych i czasu potrzebnego do ich wytworzenia. Tolerancyjnym systemem czasu rzeczywistego jest system, którego działanie jest tylko gorsze, jeśli wyniki nie są dostępne zgodnie z ustalonymi wymaganiami czasowymi. Wymagający system czasu rzeczywistego to system, którego działanie jest niepoprawne, jeśli wyniki nie są tworzone zgodnie z ustalonymi wymaganiami czasowymi. 2

System czasu rzeczywistego jako system bodziec-reakcja Na podstawie otrzymanego bodźca system musi wygenerować odpowiednią reakcję. Zachowanie systemu czasu rzeczywistego można więc zdefiniować przez wyliczenie bodźców, które może otrzymać, skojarzonych z nimi odpowiedzi oraz czasu, w którym należy je utworzyć. Podział bodźców: ◦ bodźce okresowe pojawiają się w przewidywanych odstępach czasu, ◦ bodźce nieokresowe pojawiają się nieregularnie. 3

Architektura systemu czasu rzeczywistego System czasu rzeczywistego musi reagować na bodźce pojawiające się w różnych chwilach. Jego architektura musi więc być tak skonstruowana, aby sterowanie było przekazywane do odpowiedniej procedury obsługi natychmiast po pojawieniu się bodźca. Systemy czasu rzeczywistego zwykle projektowane są jako zbiór współbieżnych, współpracujących procesów. Zadaniem części systemu czasu rzeczywistego, zwanego modułem wykonawczym, jest zarządzanie tymi procesami. 4

Uniwersalny model systemu czasu rzeczywistego Detektor Detektor System sterujący czasu rzeczywistego Efektor 5

Uniwersalny model architektoniczny q Z każdym rodzajem detektora zarządzania detektorem. kojarzy się proces q Procesy obliczające wyznaczają oczekiwaną odpowiedź na bodźce otrzymane przez system. q Procesy sterowania efektorami zarządzają działaniem efektorów. q Ten model umożliwia szybkie odbieranie danych od detektorów (zanim będą gotowe następne dane wejściowe), późniejsze ich przetwarzanie i reagowanie przez efektory. 6

Procesy sterujące detektorami i efektorami Detektor Efektor Reakcja Bodziec Sterowanie detektorem Procesor danych Sterowanie efektorem 7

Wymogi dot. projektowania systemu q Część procesu projektowania systemu polega na podjęciu decyzji, które udogodnienia systemu będą zaimplementowane przez oprogramowanie, a które przez sprzęt. q Ograniczenia czasowe lub inne wymagania mogą oznaczać, że niektóre funkcje systemu, takie jak przetwarzanie sygnałów, muszą być zaimplementowane w postaci specjalnie zbudowanego sprzętu. q Proces projektowania systemu może więc zarówno obejmować projektowanie specjalnego sprzętu, jak i projektowanie oprogramowania czasu rzeczywistego. 8

Czynności procesu projektowania q Zidentyfikuj bodźce, które system musi przetwarzać oraz skojarzone z nimi reakcje. q Dla każdego bodźca i związanej z nim reakcji zidentyfikuj wymagania czasowe, które dotyczą przetwarzania zarówno bodźca, jak i reakcji. q Pogrupuj bodźce i reakcje w kilku procesach współbieżnych. Dobrym modelem uniwersalnej architektury takiego systemu jest skojarzenie jednego procesu z każdą klasą bodźców i reakcji. 10

Czynności procesu projektowania c. d. q Dla każdego bodźca i reakcji zaprojektuj algorytmy do przeprowadzania koniecznych obliczeń. Te projekty algorytmów często trzeba opracować w dość wczesnej fazie procesu, aby poznać ilość przetwarzania i czas potrzebny do wykonania tych obliczeń. q Zaprojektuj system szeregujący, który zapewni, że procesy będą uruchamiane w chwili wystarczającej do spełnienia ograniczeń czasowych. q Zintegruj system pod kontrolą modułu wykonawczego. 11

Uwagi dot. ograniczeń czasowych i projektowania obiektowego q Systemy czasu rzeczywistego muszą spełniać postawione im ograniczenia czasowe, a zatem zastosowanie strategii projektowych, które powodują dodatkowe narzuty implementacyjne, byłoby niepraktyczne w wypadku wymagających systemów czasu rzeczywistego. q Projektowanie obiektowe oznacza na przykład ukrywanie informacji o reprezentacji danych i dostęp do atrybutów za pośrednictwem operacji zdefiniowanych na obiektach. Prowadzi to nieuchronnie do narzutów i utraty efektywności. 12

Wykorzystanie modelu maszyny stanowej q W modelu stanowym systemu zakłada się, że w każdej chwili system jest w jednym z wielu swoich stanów. q Po wystąpieniu bodźca może nastąpić przejście do innego stanu. q Np. system sterujący zaworem może na przykład zmienić stan z „zawór otwarty” na „zawór zamknięty” po otrzymaniu polecenia operatora (bodźca). 13

Model maszyny stanowej kuchenki mikrofalowej Pełna moc do: ustaw moc = 600 Oczekiwanie do: wyświetlaj godzinę Połowa mocy Działanie Liczba Stoper Pełna moc Ustawienie czasu Połowa mocy do: odczytaj liczbę exit: ustaw czas Połowa mocy do: ustaw moc = 300 Stoper Otworzono drzwiczki Zamknięto drzwiczki Niegotowy do: wyświetlaj „Czekam” do: podgrzewanie Początek Gotowy do: wyświetlaj „Gotowy” Zatrzymaj Oczekiwanie do: wyświetlaj godzinę Otworzono drzwiczki 14

Programowanie czasu rzeczywistego q Język programowania użyty do implementacji systemu czasu rzeczywistego również może mieć wpływ na projekt. q Wymagające systemy czasu rzeczywistego wciąż często programuje się w asemblerze, aby sprostać limitom czasowym. q Można skorzystać także z języków programowania systemowego takich jak C, które dają efektywny kod. q Zaleta języków programowania systemowego polega na tym, że umożliwiają tworzenie efektywnego kodu. Taki język nie obejmuje jednak żadnych konstrukcji do obsługi współbieżności albo zarządzania zasobami współdzielonymi. 15

Problemy z Javą Java nie nadaje się do programowania wymagających systemów czasu rzeczywistego lub systemów, w których procesy mają ścisłe limity czasowe. Oto zasadnicze problemy z zastosowaniem Javy jako języka programowania czasu rzeczywistego: Nie można określić czasu, w którym wątki powinny działać. q Odśmiecanie podlega sterowaniu – może rozpocząć się w dowolnym czasie. q Nie ma możliwości odczytu długości kolejek związanych ze współdzielonymi zasobami. q Implementacja maszyny wirtualnej Javy jest inna na każdym komputerze. q Język nie przewiduje szczegółowej analizy wykorzystania procesora i pamięci w czasie wykonania. q 16

Moduły wykonawcze czasu rzeczywistego q Moduł wykonawczy czasu rzeczywistego jest odpowiednikiem systemu operacyjnego w komputerze ogólnego przeznaczenia. q Zarządza procesami i przydziałem zasobów systemu czasu rzeczywistego. q Uruchamia i zatrzymuje procesy, aby reagować na bodźce. q Przydziela pamięć i zasoby procesora. q Nie obejmuje jednak bardziej złożonych udogodnień systemu operacyjnego, np. zarządzania plikami. 17 14

Zbiór komponentów modułu wykonawczego q Zegar czasu rzeczywistego. q q Procedura obsługi przerwań. q q Odpowiada za znajdowanie procesów, które można wykonać, i wybór jednego z nich, który będzie wykonywany. Menedżer zasobów. q q Zarządza nieokresowymi żądaniami usług. Moduł szeregujący. q q Udostępnia informacje niezbędne do okresowego. szeregowania procesów. Przydziela procesowi wybranemu do wykonywania odpowiednie zasoby procesora i pamięć. Dyspozytor. q Odpowiada za rozpoczęcie wykonywania procesu. 18

Informacje o szeregowaniu Zegar czasu rzeczywistego Moduł szeregujący Procedura obsługi przerwań Informacje o zasobach wymaganych przez procesy Procesy czekające na zasoby Menedżer zasobów Proces gotowy Lista procesów gotowych Lista dostępnych zasobów Zwolnione zasoby Dyspozytor Lista procesorów Proces wykonywany Rys. Komponenty modułu wykonawczego systemu czasu rzeczywistego 19

Systemy zapewniające ciągłą obsługę q Systemy zapewniające ciągłą obsługę (np. telekomunikacja, monitoring) mogą posiadać pewne udogodnienia modułu wykonawczego. q Menedżer q Odpowiada za dynamiczną rekonfigurację sprzętu systemu. Bez zatrzymywania systemu można wyłączyć z użycia pewne moduły sprzętowe lub rozszerzyć system o nowy sprzęt. q Menedżer q konfiguracji. awarii. Odpowiada za wykrywania awarii sprzętu i oprogramowania oraz podjęcie odpowiednich działań zmierzających do odtworzenia stanu po awariach. 20

Poziom priorytetu i obsługa sytuacji wyjątkowych q Bodźce przetwarzane przez systemy czasu rzeczywistego mają zwykle różne poziomy priorytetu. q. W wypadku niektórych bodźców, takich jak te związane z sytuacjami wyjątkowymi, ważne jest, aby zakończyć ich przetwarzanie w ściśle ustalonym czasie. Inne procesy można bezpiecznie opóźnić, gdy obsługi wymaga bardziej krytyczny proces. 21

Poziomy priorytetu procesów Moduły wykonawcze są zdolne do zarządzania co najmniej dwoma poziomami priorytetu procesów: q Poziom przerwania oznacza najwyższy priorytet. Nadaje się go procesom, które wymagają bardzo szybkiej reakcji. Jednym z nich jest proces zegara czasu rzeczywistego. q Poziom zegarowy jest nadawany procesom okresowym. 22

Zarządzanie procesami q Zarządzanie procesami w module wykonawczym czasu rzeczywistego polega na zarządzaniu zbiorem procesów współbieżnych, który jest częścią systemu czasu rzeczywistego. q Menedżer procesów musi wybrać proces do wykonania, przydzielić dla niego pamięć i zasoby procesora oraz rozpocząć jego wykonywanie na procesorze. 24

Akcje modułu wykonawczego niezbędne do uruchomienia procesu Moduł szeregujący Menedżer zasobów Dyspozytor Wybierz proces do wykonania Przydziel pamięć i procesor Rozpocznij wykonywanie na dostępnym procesorze 25

Moduł szeregujący q Przegląda listę procesów okresowych i wybiera proces do wykonania. q Wybór zależy od priorytetu, okresu, oczekiwanego czasu wykonania i limitu poszczególnych procesów gotowych. q Czasem po jednym tyknięciu zegara trzeba wykonać dwa procesy z różnymi limitami czasowymi. q W takiej sytuacji jeden z nich musi być opóźniony, jednak najwyżej na tyle, aby jego zakończenie przed upływem limitu czasowego było możliwe. 26

Strategie szeregowania q Szeregowanie q Gdy wybrano proces do wykonywania, działa on aż do zakończenia swojej pracy lub do chwili zablokowania z jakiegoś powodu, np. oczekiwania na dane wejściowe. q Szeregowanie q bez wywłaszczenia. z wywłaszczeniem. Działanie procesu może być przerwane, jeśli trzeba obsłużyć proces o wyższym priorytecie. 27

Systemy monitorowania i sterowania q Systemy monitorowania i sterowania są ważna klasą systemów czasu rzeczywistego. q Sprawdzają stan detektorów dostarczających informacje o środowisku systemu i wykonują akcje zależne od odczytów z tych detektorów. q Systemy monitorowania podejmują działania, gdy detektory wykryją jakąś wyjątkową wartość. q Systemy sterowania ustawicznie sterują sprzętowymi efektorami zależnie od wartości związanych z nimi detektorów. 28

Przykład systemu antywłamaniowego q q q Ten system korzysta z różnych rodzajów detektorów. Gdy detektor wykrywa obecność intruza, system automatycznie dzwoni do pobliskiego posterunku policji i za pomocą syntezatora mowy informuje o miejscu wywołania alarmu. System alarmowy zwykle jest zasilany z sieci, ale ma też zapasowe akumulatory. Ten system jest „tolerancyjnym” systemem czasu rzeczywistego, który nie ma dużych wymagań czasowych. Detektory nie muszą wykrywać bardzo szybko następujących zdarzeń, trzeba je więc odpytywać najwyżej dwa razy na sekundę. 29

Projektowanie systemu antywłamaniowego q Projektowanie rozpoczyna się od rozpoznania bodźców nieokresowych działających na system i skojarzonych z nimi odpowiedzi. q Następnym krokiem procesu projektowania jest rozważenie ograniczeń czasowych związanych z każdym bodźcem i skojarzoną z nim reakcją. q Kolejnym krokiem jest przydział funkcji systemu do procesów współbieżnych. 30

Dwie klasy bodźców q Zanik q zasilania Jest zgłaszany przez układ monitorujący napięcie. Wymagana odpowiedzią jest przełączenie na zasilanie zapasowe przez wysłanie sygnału do urządzenia przełączającego zasilanie. q Wtargnięcie intruza q Reakcją na ten bodziec jest wyznaczenie numeru pokoju, w którym znajduje się aktywny detektor, zadzwonienie na policję, uruchomienie syntezatora mowy do obsługi telefonu oraz włączenie syreny i świateł w okolicach włamania. 31

Wymagania czasowe stawiane bodźcom i reakcji Bodziec/reakcja Wymagania czasowe Przerwanie zaniku zasilania Alarm drzwiowy Przełączenie na zasilanie zapasowe musi być ukończone po najwyżej 50 ms Każdy detektor drzwiowy musi być odpytywany dwa razy na sekundę Alarm okienny Każdy detektor okienny musi być odpytywany dwa razy na sekundę Detektor ruchu Każdy detektor ruchu powinien być odpytywany dwa razy na sekundę Sygnał dźwiękowy musi być włączony po upływie najwyżej 1 sekundy od alarmu wywołanego przez detektor Włączenie świateł Światła powinny być włączone po upływie najwyżej 1/2 sekundy od alarmu wywołanego przez detektor Komunikacja Wezwanie policji przez telefon należy rozpocząć po upływie najwyżej 2 sekund od alarmu wywołanego przez detektor Syntezator mowy Komunikat z syntezatora powinien być dostępny po upływie najwyżej 4 sekund od alarmu wywołanego przez detektor 32

400 Hz 60 Hz Proces detektorów ruchu 100 Hz Proces detektorów drzwiowych Stan detektorów Proces detektorów okiennych Stan detektorów 560 Hz Proces monitorowania budynku Przerwanie braku zasilania Proces przełączania zasilania Kontroler budynku System alarmowy Proces komunikacyjny Numer pokoju Proces systemu alarmowego System alarmowy Numer pokoju Komunikat alarmowy System alarmowy Proces sygnalizacji dźwiękowej Proces sterowania światłami Numer pokoju Proces syntezatora mowy 33 Rys. Architektura procesowa systemu antywłamaniowego

Przykład systemu sterowania q System antywłamaniowy jest systemem monitorowania, a nie systemem sterowania, ponieważ nie zawiera efektorów będących pod bezpośrednim wpływem stanu detektorów. q Przykładem systemu sterowania jest system sterowania ogrzewaniem w budynku. q Monitoruje on detektory temperatury w różnych pokojach budynku oraz włącza i wyłącza grzejniki w zależności od aktualnej temperatury i ustawienia termostatów w pokojach. 36

Architektura procesowa systemu sterowania temperaturą 500 Hz Proces detektora Stan detektora 500 Hz Proces termostatu 500 Hz Polecenie przełączenia Numer pokoju Proces sterowania grzejnikiem Proces termostatu Proces sterowania piecem 37

Systemy gromadzenia danych q Systemy gromadzenia danych stanowią kolejną klasę systemów czasu rzeczywistego, mających zwykle uniwersalny model architektoniczny. q Takie systemy zbierają od detektorów późniejszego przetwarzania i analizy. dane do 38

System zbierający dane od detektorów monitorujących promieniowanie neutronowe w reaktorze atomowym q q q Dane z detektorów są umieszczane w buforze; następnie są z niego pobierane i przetwarzane. W rezultacie na ekranie operatora jest wyświetlane średnie natężenie promieniowania. Każdy detektor ma swój proces, który zmienia dane analogowe o natężeniu promieniowania neutronowego na sygnał cyfrowy. Następnie przekazuje to natężenie promieniowania oraz swój identyfikator do bufora danych. Proces odpowiedzialny za przetwarzanie danych pobiera dane z tego bufora, przetwarza je i przekazuje do procesu wyświetlającego w celu pokazania na konsoli operatora. 39

Architektura systemu monitorującego promieniowanie Detektory (każdy przepływ danych to stan detektora) Identyfikator i stan detektora Proces detektora Bufor z danymi z detektorów Wyznaczone natężenie promieniowania Przetwarzanie danych Wyświetlacz 40

Wzajemne wykluczanie W systemach czasu rzeczywistego, które gromadzą i przetwarzają dane, czasy wykonywania i okresy procesów gromadzących oraz przetwarzających mogą być nierówne. q W większości systemów gromadzenia danych neutralizacja tych różnic szybkości polega na zastosowaniu bufora cyklicznego. q Oczywiście należy zaimplementować wzajemne wykluczanie, aby procesy producentów i konsumentów nie miały w buforze dostępu do tego samego elementu w tym samym czasie. q System musi również zadbać o to, żeby producent nie mógł dodać informacji do pełnego bufora i żeby konsument nie pobrał informacji z pustego bufora. q 41

Bufor cykliczny do gromadzenia danych Proces producenta Proces konsumenta 42

Główne tezy System czasu rzeczywistego to system oprogramowania, który musi reagować na zdarzenia w czasie rzeczywistym. Jego poprawność nie zależy tylko od wytwarzanych wyników, ale także od czasu ich wytworzenia. q Uniwersalny model architektury systemu czasu rzeczywistego przewiduje skojarzenie procesu z każdą klasą detektorów i efektorów. Mogą być potrzebne także inne procesy koordynujące. q Projektowanie architektoniczne systemu czasu rzeczywistego polega zwykle na nadaniu systemowi struktury zbioru oddziałujących na siebie procesów współbieżnych. q Moduł wykonawczy czasu rzeczywistego odpowiada za zarządzanie procesami i zasobami. Zawsze obejmuje moduł szeregujący, który jest komponentem podejmującym decyzje o tym, który proces ma się wykonywać. Decyzje o szeregowaniu są podejmowane na podstawie priorytetów procesów. q 45

Główne tezy c. d. Systemy monitorowania i sterowania okresowego odpytują zbiór detektorów, które dostarczają informacje ze środowiska systemu. Takie systemy przez wydawanie poleceń efektorom wykonują akcje, które zależą od odczytów detektorów. q Systemy gromadzenia danych są zwykle zgodne z modelem producent-konsument. Proces producenta wkłada dane do bufora cyklicznego, skąd są pobierane do wykorzystania przez konsumenta. Również bufor jest implementowany jako proces, co umożliwia wyeliminowanie konfliktów między producentem, a konsumentem. q Chociaż Java ma udogodnienia do realizacji współbieżności, nie nadaje się do tworzenia krytycznych systemów czasu rzeczywistego. Java nie obejmuje udogodnień do sterowania wykonaniem. Nie ma tez możliwości analizowania czasowych aspektów zachowania programów Javy. q 46

Projektowanie z użyciem wielokrotnym Cele Znać korzyści wynikające z użycia wielokrotnego komponentów programowych oraz związane z nim kłopoty, które możesz napotkać; q Znać różne rozdaje komponentów, które można użyć wielokrotnie, oraz procesy projektowania z użyciem wielokrotnym; q Rozumieć pojęcie rodziny programów użytkowych i wiedzieć, dlaczego takie rodziny są efektywnym sposobem użycia wielokrotnego oprogramowania; q Wiedzieć, dlaczego wzorce są abstrakcjami wysokiego poziomu, które sprzyjają użyciu wielokrotnemu projektów w tworzeniu obiektowym. q 47

Używane wielokrotnie elementy oprogramowania Użycie wielokrotne systemów programów użytkowych. Użycie wielokrotne komponentów. Użycie wielokrotne funkcji. ◦ Można ponownie użyć cały system programów użytkowych przez włączenie go w niezmienionej postaci do innych systemów albo budowę rodziny programów użytkowych działających na różnych platformach lub dostosowanych do potrzeb konkretnych użytkowników. ◦ Można wielokrotnie używać komponentów programu użytkowego mających różne rozmiary, od podsystemów do pojedynczych obiektów. ◦ Można wielokrotnie użyć komponenty programowe, takie jak pojedyncze funkcje matematyczne. 48

Zalety użycia wielokrotnego Zwiększona niezawodność Zmniejszone zagrożenie procesu Efektywne wykorzystanie specjalistów Zgodność ze standardami Przyspieszone tworzenie 49

Wymagania stawiane projektowaniu i budowaniu oprogramowania z użyciem wielokrotnym Musi istnieć możliwość znalezienia odpowiedniego komponentu użycia wielokrotnego. Osoba ponownie używająca komponent musi być przekonana, że będzie on działał zgodnie ze specyfikacją i będzie niezawodny. Komponenty muszą mieć dokumentację, która pomoże osobie pragnącej je wykorzystać w zrozumieniu ich i zaadaptowaniu do nowych zastosowań. 50

Koszty i kłopoty Zwiększone Brak koszty pielęgnacji wspomagania narzędziowego Syndrom „nie wymyślono tutaj” Prowadzenie biblioteki komponentów Znajdowanie i adaptowanie komponentów użycia wielokrotnego 51

Generowanie Polega ono na umieszczaniu wielokrotnie używanej wiedzy w systemie generowania programów, który może posługiwać się językiem specyficznym dla dziedziny zastosowania. W opisie programu użytkowego w abstrakcyjny sposób określa się, które komponenty użycia wielokrotnego maja być wykorzystane, jak maja być połączone i jakie maja mieć parametry. Na podstawie tej informacji można wygenerować działający system oprogramowania. 52

Typy generatorów programów Generatory programów użytkowych do przetwarzania danych gospodarczych. Generatory analizatorów składniowych do przetwarzania języków. Generatory kodu w narzędziach CASE. 53

Użycie wielokrotne oparte na generatorze Opis programu użytkoweg o Generator programów Wiedza o dziedzinie zastosowania Wygenerowany program Baza danych 54

Tworzenie komponentowe Tworzenie komponentowe albo komponentowa inżynieria oprogramowania pojawiła się we wczesnych latach dziewięćdziesiątych XX wieku w postaci podejścia do budowania systemów oprogramowania z użyciem wielokrotnym. Przyczyną jej powstania był zawód, że tworzenie obiektowe nie doprowadziło do szerokiego stosowania użycia wielokrotnego, jak się wcześniej spodziewano. Poszczególne klasy obiektów były zbyt szczegółowe i specyficzne. Musiały być dowiązane do programu użytkowego w czasie kompilacji lub konsolidacji systemu. Do ich wykorzystania była potrzebna szczegółowa wiedza, co zwykle oznaczało konieczność udostępnienia kodu źródłowego. Powodowało to trudne problemy ze sprzedażą komponentów na rynku. Wbrew wczesnym optymistycznym przewidywaniom nigdy nie powstał znaczący rynek pojedynczych obiektów. 55

Komponenty Postrzeganie komponentu jako dostawcy usług dotyczy dwóch istotnych charakterystyk komponentu użycia wielokrotnego: ◦ Komponent jest niezależnym wykonywalnym bytem. Kod źródłowy nie jest dostępny, a zatem komponentu nie kompiluje się z innymi komponentami systemu. ◦ Komponenty publikują swój interfejs. Wszystkie interakcje odbywają się przez ten interfejs. Interfejs komponentu jest zapisywany w kategoriach parametryzowanych operacji. Jego wewnętrzny stan nigdy nie jest ujawniany. 56

Interfejsy komponentu Interfejs wymagany Komponent Interfejs oferowany 57

Interfejsy komponentów Interfejs oferowany ◦ Definiuje się usługi komponent. oferowane przez ten Interfejs wymagany ◦ Określa się, jakie usługi muszą być dostępne w systemie używającym tego komponentu. Jeśli nie są one oferowane, to komponent nie będzie działał. 58

Komponent usług drukarskich Interfejs wymagany Komponent usług drukarskich Podaj. Plik. Opisu Interfejs oferowany Drukuj Podaj. Stan. Kolejki Interfejsdrukarki Usuń Przekaż Rejestruj Wyrejestruj 59

Poziomy abstrakcji komponentów Abstrakcja funkcyjna. ◦ Komponent jest implementacją jednej funkcji, np. matematycznej. Przypadkowe grupowanie. ◦ Komponent jest grupą luźno powiązanych bytów. Abstrakcja danych Abstrakcja grupowa. Abstrakcja systemowa. ◦ Komponent jest abstrakcją danych lub klasą obiektowego języka programowania. ◦ Komponent jest grupą powiązanych klas, które działają razem. ◦ Komponent jest całym samodzielnym systemem. 60

Tworzenie komponentowe można zintegrować z procesem budowania systemu przez dodanie specyficznych czynności związanych z użyciem wielokrotnym. Projektant systemu buduje projekt na wysokim poziomie abstrakcji i specyfikuje jego komponenty. Te specyfikacje służą do poszukiwania komponentów użycia wielokrotnego. Czynność tę można dodać na poziomie architektonicznym lub na poziomie bardziej szczegółowym. 61

Proces przypadkowego ponownego użycia komponentów Zaprojektuj architekturę systemu Wyspecyfikuj komponenty Poszukaj komponentów użycia wielokrotnego Przyłącz znalezione komponenty 62

Tworzenie z wielokrotnym użyciem Naszkicuj wymagania systemowe Projektowanie architektoniczne Poszukaj komponentów użycia wielokrotnego Na podstawie wyników poszukiwań zmień wymagania Zaprojektuj system korzystając z komponentów użycia wielokrotnego 63

Trudności przy tworzeniu komponentowym Kwestia pielęgnacji i ewolucji. Kod źródłowy komponentów jest zwykle dostępny. W takiej sytuacji, gdy program użytkowy wymaga modyfikacji, nie ma możliwości zmiany komponentu mającej na celu odzwierciedlenie tych wymagań. W tej fazie zmiana wymagań tak, by pasowały do istniejących komponentów, nie jest zwykle możliwa, gdyż program użytkowy już jest wykorzystywany. Trzeba więc dodatkowej pracy nad ponownym użyciem komponentów i w miarę upływu czasu powoduje to zwiększenie kosztów pielęgnacji. Tworzenie komponentowe umożliwia jednak szybsze dostarczanie oprogramowania, firmy mogą więc zaakceptować te wyższe koszty w odległej przyszłości. 64

Zręby programów użytkowych Zręby (lub zręby programów użytkowych) są projektami podsystemów składających się z kolekcji klas abstrakcyjnych i klas konkretnych oraz interfejsu między nimi. Poszczególne części systemu programów użytkowych implementuje się przez dodanie komponentów i opracowanie konkretnych implementacji klas abstrakcyjnych zrębu. Zręby rzadko są programami użytkowymi. 65

Klasy zrębów Zręby infrastruktury systemów. ◦ Wspomagają tworzenie infrastruktury systemów, takiej jak komunikacja, interfejsy użytkownika i kompilatory. Zręby integracji śródprogramów. ◦ Składają się ze zbioru standardów i związanych z nimi klas obiektów, które wspomagają komunikację komponentów i wymianę informacji. Zręby zastosowań przemysłowych. ◦ Dotyczą specyficznych dziedzin zastosowań, takich jak telekomunikacja lub finanse. 66

Rozszerzanie zrębów Rozszerzenie zrębu może polegać konkretnych klas, które dziedziczą klasach abstrakcyjnych zrębu. Dodatkowo zwrotnie. na dodaniu operacje po można zdefiniować funkcje wywołane Są to metody, które wywołuje się w odpowiedzi na zdarzenia rozpoznane przez zrąb. 67

Zrąb Model-Widok-Koordynator Po raz pierwszy przedstawiono go w latach osiemdziesiątych XX wieku jako podejście do projektowania GUI, który obejmuje wiele przedstawień obiektów i różne style interakcji z każdym z tych przedstawień. Zrąb MVC pomaga w prezentacji danych na różne sposoby i odrębne oddziaływanie z każdą z nich. Gdy dane są modyfikowane przez jedna prezentację, wszystkie inne są aktualizowane. 68

Zrąb Model-Widok-Koordynator Stan widoku Komunikaty o modyfikacji widoku Metody widoku Stan koordynatora Metody koordynatora Zapytania i aktualizacje modelu Modyfikacje modelu Stan modelu Metody modelu 69

Użycie wielokrotne produktów COTS Podejście produktów COTS (Commercial-Off-The. Shelf – komercyjne z półki) może być zastosowane do każdego komponentu oferowanego przez zewnętrznego dostawcę. Zwykle używa się go jednak tylko w wypadku produktów będących systemami oprogramowania. Od wielu lat wielokrotnie używano niektórych rodzajów systemów COTS. Systemy baz danych są chyba najlepszym tego przykładem. 70

Problemy z integracją systemów COTS Brak kontroli nad sterowaniem i efektywnością. Chociaż z opublikowanych interfejsów produktu może wynikać, że ma on wymagane udogodnienia, mogą być one niewłaściwie zaimplementowane lub mogą działać wolno. Kłopoty ze współdziałaniem systemów COTS. Skłonienie produktów COTS do współpracy jest czasem trudne, ponieważ każdy z nich przyjmuje inne założenia o tym, jak należy go używać. Brak panowania nad ewolucją systemu. Dostawcy produktów COTS podejmują własne decyzje o zmianach systemu w odpowiedzi na żądania rynku. Wspomaganie przez dostawców COTS. Zakres wspomagania oferowany przez dostawców COTS może być rozmaity. Są to systemy z półki, więc wspomaganie dostawcy jest szczególnie ważne, gdy pojawiają się kłopoty, ponieważ programiści nie mają dostępu do kodu źródłowego i szczegółowej dokumentacji systemu. 71

Tworzenie komponentów użycia wielokrotnego Komponenty użycia wielokrotnego sa specjalnie budowane z istniejących komponentów, które ponownie wykorzystano w przypadkowy sposób. Różne cechy komponentu świadczą o jego zdatności do użycia wielokrotnego: ◦ komponent powinien odzwierciedlać stabilną abstrakcję dziedzinową ◦ komponent musi ukrywać sposób reprezentacji swoich danych i oferować operacje umożliwiające odczyt i aktualizację jego stanu ◦ komponent powinien być tak niezależny, jak to tylko jest możliwe ◦ wszystkie wyjątki powinny być częścią interfejsu komponentu. 72

Problemy W wielu obecnie dostępnych systemach istnieją duże fragmenty kodu, które implementują abstrakcje dziedzinowe, ale nie mogą być wykorzystane jako komponenty. Przyczyna leży w tym, że nie opakowano ich zgodnie z modelem z jasno określonymi interfejsami wymaganym i oferowanym. Uczynienie z nich komponentów użycia wielokrotnego zwykle wymaga zbudowania osłony. Osłona ukrywa złożoność schowanego kodu i oferuje zewnętrzne usługi. 73

Uzdatnianie komponentów Między zdatnością do użycia wielokrotnego a użytecznością komponentu występuje nieuchronny konflikt. Uzdatnienie komponentu do użycia wielokrotnego pociąga za sobą zaoferowanie bardzo ogólnego interfejsu z operacjami obsługującymi rozmaite sposoby użycia tego komponentu. Budowa użytecznego komponentu obejmuje zaoferowanie prostego, minimalnego interfejsu, który jest łatwy do zrozumienia. Zdatność do użycia wielokrotnego zwiększa złożoność, a zatem zmniejsza zrozumiałość komponentu. Inżynierom jest więc trudno zdecydować, kiedy i jak wielokrotnie używać komponentu. Projektanci komponentów użycia wielokrotnego muszą zatem wypracować kompromis między ogólnością a zrozumiałością. 74

Reusability enhancement process 75

Rodziny programów użytkowych Rodzina programów użytkowych albo linia produktów jest zbiorem powiązanych programów użytkowych, które mają wspólną architekturę charakterystyczną dla dziedziny. Poszczególne programy użytkowe są jednak na swój sposób wyspecjalizowane. Wspólny rdzeń rodziny programów użytkowych jest za każdym razem ponownie używany, gdy jest potrzebny nowy program użytkowy. Tworzenie nowego programu może polegać na napisaniu dodatkowych komponentów i adaptacji niektórych komponentów programu użytkowego tak, aby sprostać nowym oczekiwaniom. 76

Rodzaje specjalizacji rodziny programów użytkowych Specjalizacja platformowa. ◦ Polega na opracowaniu innych wersji programu użytkowego na różne platformy. Różne wersje programu mogą działać na przykład na platformy Windows NT, Solaris i Linux. Specjalizacja konfiguracyjna. ◦ Polega na opracowaniu innych wersji programu użytkowego do obsługi różnych urządzeń zewnętrznych. Specjalizacja funkcjonalna. ◦ Polega na opracowaniu innych wersji programu użytkowego dla klientów z różnymi wymaganiami. 77

Uniwersalny system inwentaryzacji zasobów Dostęp użytkownika User ccess Dostęp programowy Pr g access a Dodawanie Usuwanie Poszukiwanie Przeglądanie Administracja Raporty Opisy zasobów Specyfikacje ekranów Specyfikacje raportów Baza danych o zasobach 78

Systemy inwentaryzacyjne Takie systemy muszą oferować podstawowe udogodnienia, takie jak dodawanie zasobu do spisu, usunięcie zasobu ze spisu, przeglądanie i wyszukiwanie w spisie oraz tworzenie raportów. Można więc tak zaprojektować architekturę systemy inwentaryzacyjnego, aby stał się rodziną programów użytkowych, której każdy członek służy do obsługi innych rodzajów zasobów 79

Architektura Osiągnięcie znaczącej zdatności do użycia wielokrotnego wymaga zaprojektowania architektury, w której zasadnicze udogodnienia systemowe będą oddzielone od szczegółowej informacji o zasobach, które mają być inwentaryzowane i od dostępu użytkownika do tych informacji. Architektura może spełniać te wymagania dzięki zastosowaniu architektury warstwowej, w której warstwa szczegółów zawiera opisy zasobów, wyświetlane ekrany i tworzone raporty. Wyższe warstwy systemu korzystają z tych opisów i nie obejmują wpisanej na sztywno informacji o zasobach. Różne systemy inwentaryzacyjne powstają przez modyfikację tej warstwy opisowej. 80

System biblioteczny Dostęp użytkownika do biblioteki Dodawanie Usuwanie Poszukiwanie Przeglądanie Administracja Raporty Wypożyczenie. Użytkownicy Zwrot Opisy zasobów Specyfikacje ekranów Specyfikacje raportów Baza danych o zasobach 81

System biblioteczny Można również dodawać do systemu nową funkcjonalność przez wprowadzanie nowych modułów do warstw systemu. Dodano nowe udogodnienia do pożyczania i zwracania zasobów oraz do umożliwiania rejestracji użytkowników systemu. W tym wypadku nie jest potrzebny dostęp programowy, a najwyższa warstwa systemu musi obsługiwać jedynie dostęp do użytkownika. 82

Tworzenie członka rodziny Renegocjuj wymagania Wydobądź wymagania uczestników Wybierz najbardziej odpowiedniego członka rodziny Zaadaptuj istniejący system Dostarcz nowego członka rodziny 83

Tworzenie członka rodziny Określ wymagania uczestników Wybierz najbardziej odpowiedniego członka rodziny Renegocjuj Zaadoptuj Dostarcz wymagania istniejący system nowego członka rodziny 84

Wzorce projektowe Starając się ponownie użyć komponent wykonywalny, nie uchronimy się przed ograniczeniami wynikającymi ze szczegółowych decyzji projektowych, podjętych przez osoby implementujące ten komponent. Jeśli te decyzje projektowe nie są zgodne z przyjętymi przez nas szczegółowymi wymaganiami, to ponowne użycie komponentu jest niemożliwe albo prowadzi do istotnego zmniejszenia efektywności systemu. Jednym ze sposobów radzenia sobie z ta kwestią jest użycie wielokrotne bardziej abstrakcyjnych projektów, które nie obejmują szczegółów implementacyjnych. Obecnie to podejście do użycia wielokrotnego przybrało postać wzorców projektowych. 85

Elementy wzorca projektowego Nazwa Spełniająca funkcję znaczącego odsyłacza do wzorca. Opis rodzaju problemu, w którym opisuje się części rozwiązania projektowego, ich związki i zobowiązania. Wyjaśnienie konsekwencji zastosowania wzorca, tzn. wyników końcowych i niezbędnych kompromisów. 86

Wiele widoków 50 D 25 A C B A 0 BCD Przedmiot Obserwator 1 A : 40 B : 25 C : 15 D : 20 Obserwator 2 87

Przykład wzorca Obserwator Nazwa. ◦ Oddziela wyświetlanie stanu obiektu od samego obiektu. Opis problemu. Opis rozwiązania. ◦ W wielu przypadkach należy udostępnić wiele prezentacji pewnej informacji o stanie, np. prezentacji tabelarycznej i graficznej. ◦ Strukturę wzorca pokazano na rysunku. Są tam dwa obiekty abstrakcyjne: Przedmiot i Obserwator oraz dwa obiekty konkretne: Przedmiot. Konkretny i Obserwator. Konkretny, które dziedziczą atrybuty swoich obiektów abstrakcyjnych. Konsekwencje. ◦ Przedmiot zna jedynie abstrakcyjnego Obserwatora, ale nie zna szczegółów klasy konkretnej. Wzajemne uzależnienie tych obiektów jest więc minimalne. 88

Wzorzec Obserwator Przedmiot Podłącz (Obserwator) Odłącz (Obserwator) Informuj () Przedmiot konkretny Podaj. Stan () stan. Przedmiotu Obserwator for all o in obserwatorzy o -> Aktualizuj () Obserwator. Konkretny for all o in obserwatorzy o -> Aktualizuj () stan. Obserwatora= przedmiot -> Podaj. Stan ( stan. Obserwatora 89

Główne tezy Projektowanie z użyciem wielokrotnym polega na projektowaniu oprogramowania zgodnie z istniejącymi przykładami dobrych projektów i wykorzystaniu komponentów programowych tam, gdzie są potrzebne. Korzyści z użycia wielokrotnego to niższe koszty, szybsze tworzenie oprogramowania i mniej zagrożeń. Przez wykorzystanie wiedzy specjalistów do budowania komponentów użycia zwiększa się niezawodność systemu, a specjaliści są wydajniejsi. Tworząc komponentowo, polegamy na komponentach „czarnych skrzynkach” z jasno określonymi interfejsami wymaganym i oferowanym. Rodzaje komponentów, które można użyć wielokrotnie, obejmują funkcje, abstrakcje danych, zręby i całe systemy programów użytkowych. Użycie wielokrotne produktów COTS polega na wykorzystaniu wielkich systemów z półki. Takie systemy maja mnóstwo funkcjonalności. Ich użycie wielokrotnie może znacząco zmniejszyć koszty i czas tworzenia. 90

Główne tezy c. d. Komponenty programowe, które zaprojektowano z myślą o użyciu wielokrotnym, powinny być niezależne, odzwierciedlać stabilne abstrakcje dziedzinowe i oferować dostęp do swego stanu przez operacje interfejsu oraz nie obsługiwać samemu swoich wyjątków. Rodziny programów użytkowych zawierają powiązane programy użytkowe, które zbudowano na podstawie co najmniej jednego programu bazowego. Uniwersalny system jest adoptowany i specjalizowany tak, aby spełnił konkretne wymagania dotyczące funkcjonalności, docelowej platformy lub konfiguracji działania. Wzorce projektowe to abstrakcje wysokiego poziomu, będące dokumentacją udanych rozwiązań projektowych. Są podstawowym sposobem użycia wielokrotnego projektów w tworzeniu obiektowym. Opis wzorca powinien obejmować nazwę wzorca, opis problemu i rozwiązania oraz wyjaśnienie wyników i kompromisów związanych ze stosowaniem wzorca. 91

Projektowanie interfejsu użytkownika Cele Znać uniwersalne zasady projektowania, które powinni uwzględniać inżynierowie odpowiedzialni za projekt interfejsu użytkownika; Rozpoznawać pięć różnych sposobów interakcji z systemem oprogramowania; Znać różne sposoby przetwarzania informacji i wiedzieć, kiedy prezentacja graficzna jest właściwa; Rozumieć pewne podstawowe zasady projektowania wbudowanej w system pomocy dla użytkownika; Znać atrybuty użyteczności i proste podejścia do oceny interfejsu systemu. 92

Interfejs użytkownika Dobry projekt interfejsu użytkownika jest niezbędnym warunkiem prowadzenia systemu. Interfejs trudny w użyciu w najlepszym wypadku doprowadzi do wielu pomyłek użytkowników. W najgorszym wypadku użytkownicy po prostu odmówią używania systemu oprogramowania niezależnie od jego funkcjonalności. Jeśli informacja jest przedstawiona w sposób zagmatwany i mylący, użytkownicy muszą źle rozumieć znaczenie systemu. Mogą wykonać ciągi poleceń, które uszkodzą dane lub doprowadzą do awarii systemu. 93

Graficzny interfejs użytkownika Obecnie niemal wszyscy użytkownicy komputerów mają komputer osobisty, który oferuje interfejs graficzny użytkownika (GUI) obsługujący kolorowy ekran o dużej rozdzielczości i interakcje za pomocą myszy i klawiatury. 94

Właściwości interfejsu graficznego użytkownika Właściwości Opis Okna Wiele okien umożliwia jednoczesne wyświetlanie różnych informacji na ekranie użytkownika. Ikony reprezentują różne rodzaje informacji. W niektórych systemach odpowiadają plikom, a w innych – procesom. Menu Polecenie wybiera się z menu, a nie wpisuje w postaci instrukcji języka poleceń. Wskazywanie Urządzenie do wskazywania, takie jak mysz, służą do wyboru z menu i wskazywania potrzebnych elementów w oknie. Grafika samym Elementy graficzne można połączyć z tekstowymi na tym ekranie 95

Zalety GUI Są dość łatwe do nauczenia się i do użytkowania. Użytkownicy bez doświadczeń z komputerami mogą nauczyć się używania interfejsu w ciągu krótkiego szkolenia. Użytkownik ma kilka ekranów (okien) do interakcji z systemem. Można przejść od jednego zadania do innego bez utraty oglądu informacji przygotowanej w trakcie pierwszego zadania. Szybka interakcja za pomocą pełnego ekranu daje dostęp do każdego miejsca na ekranie. 96

Projektowanie interfejsu użytkownika Projektanci oprogramowania i programiści są zwykle kompetentnymi użytkownikami technologii, takich jak klasy biblioteki Swing w Javie albo HTML, które są podstawą implementacji interfejsu użytkownika. Zbyt rzadko jednak korzystają z tej technologii właściwie i tworzą nieeleganckie, nieodpowiednie i trudne w obsłudze interfejsy użytkownika. 97

Proces projektowania interfejsu użytkownika Zanalizuj i rozpoznaj czynności użytkownika Opracuj papierowy prototyp projektu Zaprojektuj prototyp Oceń projekt z użytkownikami Zbuduj dynamiczny prototyp obiektu Wykonywalny prototyp Oceń projekt z użytkownikami Zaimplementuj docelowy interfejs użytkownika 98

Zasady projektowania interfejsu użytkownika Projektanci interfejsu użytkownika muszą brać pod uwagę psychiczne i umysłowe zdolności osób używających oprogramowania. Ludzie mają ograniczoną pamięć krótką i robią błędy zwłaszcza wówczas, gdy muszą obsłużyć dużą ilość informacji lub są pod presją. Mają różne możliwości psychiczne. Projektując interfejsy użytkownika, wszystko wziąć pod uwagę. trzeba to 99

Zasady projektowania interfejsu użytkownika Zasada Zbliżenie do użytkownika Spójność Opis Interfejs powinien posługiwać się pojęciami i kategoriami wziętymi z doświadczeń osób, które najczęściej będą korzystać z systemu. Interfejs powinien być spójny, tzn. tam, gdzie to jest możliwe, podobne operacje powinny być wykonywane w ten sam sposób. Minimum Niespodzianek Użytkownicy nie powinni być zaskakiwani zachowaniem systemu. Możliwość wycofania Interfejs powinien obejmować mechanizmy, które umożliwiają użytkownikom wycofanie się z błędów. Porady dla Interfejs powinien przekazywać znaczące informacje zwrotne, gdy użytkownika dochodzi do błędów. Powinien też oferować pomoc, której treść zależy od kontekstu. Rozróżnianie użytkowników interfejs powinien oferować udogodnienia do interakcji dostosowane 100 do różnych rodzajów użytkowników systemu.

Omówienie zasad Z zasady zbliżenia do użytkownika wynika, że użytkownicy nie powinni być zmuszani do adaptowania się do interfejsu, gdyż tak łatwiej jest go zaimplementować. Interfejs powinien posługiwać się kategoriami znanymi użytkownikowi, a obiekty przetwarzane przez system powinny być bezpośrednio związane ze środowiskiem użytkownika. Zasada spójności interfejsu użytkownika oznacza, że polecenia systemu i menu powinny mieć ten sam format. Parametry poleceń powinny być zawsze przekazywane w ten sam sposób, a przestankowanie poleceń powinno być zawsze takie samo. Spójne interfejsy zmniejszają czas nauki. Spójność interfejsu w ramach grupy podsystemów jest równie istotna. Jeśli jest to możliwe, w różnych podsystemach polecenia o podobnym znaczeniu powinny być wyrażane w ten sam sposób. Błędy często wynikają z przypisania tym samym kombinacjom klawiszy, takim jak „ctrl-b”, różnych znaczeń w innych podsystemach. 101

Omówienie zasad ◦ Ten poziom spójności nosi nazwę spójności niskiego poziomu. Projektanci interfejsów zawsze powinni starać się go osiągnąć. Czasem jest również potrzebna spójność wyższego poziomu. Może zajść konieczność zapewnienia tych samych operacji (drukowania, kopiowania itd. ) na wszystkich rodzajach bytów systemowych. ◦ Zasada minimum niespodzianek jest właściwa, ponieważ użytkownicy irytują się, gdy system działa w nieoczekiwany sposób. ◦ Zasada możliwości wycofywania jest istotna, ponieważ użytkownicy nie uchronią się przed błędami przy korzystaniu z systemu. Projektant interfejsu powinien minimalizować wystąpienia błędów. 102

Interakcja z użytkownikiem Projektant komputerowego interfejsu użytkownika ma do czynienia z dwoma zasadniczymi zagadnieniami: ◦ Jak systemowi komputerowemu dostarczyć informacje od użytkownika? ◦ Jak przedstawić użytkownikowi informacje od systemu komputerowego? Spójny interfejs użytkownika musi integrować interakcję użytkownika i prezentację informacji. 103

Rodzaje interakcji Działanie Wybór bezpośrednie. z menu. Wypełnianie formularza. Język poleceń. Język naturalny. 104

Wady i zalety sposobów interakcji Sposób Interakcji Główne zalety Bezpośrednie działanie Szybka i intuicyjna interakcja Łatwe do nauczenia Wybór z menu Umożliwia uniknięcie błędów użytkownika Wymaga mało pisania Wypełnianie formularza Proste wprowadzenie danych Łatwe do nauczenia Solidny i elastyczny Język poleceń Język naturalny Dostępny dla przypadkowych użytkowników Łatwy do rozszerzenia Główne wady Przykład zastosowań Może być trudna do Gry wideo implementacji Systemy CAD Odpowiednie jedynie wówczas, gdy istnieje graficzne wyobrażenie czynności i obiektów Zbyt powolny dla doświadczonych Większość użytkowników systemów ogólnego Może być skomplikowany, gdy opcji menu jest dużo Zajmuje duży obszar ekranu Zarządzanie magazynem Przetwarzani kredytów dla ludności Trudny do nauczenia Systemy operacyjne Małe możliwości obsługi Systemy wydobywania błędów informacji bibliotecznych Wymaga więcej pisania Systemy rozkładów jazdy Systemy rozpoznające Systemy określania języki naturalne są zawodne informacji WWW 105

Różne interfejsy użytkownika Graficzny interfejs użytkownika Interfejs języka poleceń Interpreter języka poleceń Menedżer GUI System operacyjny 106

Prezentacja informacji Wszystkie systemy interakcyjne muszą zapewniać sposoby przedstawiania informacji użytkownikom. Prezentacja informacji może być po prostu bezpośrednim uwidocznieniem danych wejściowych (np. tekstu w procesorze tekstu) lub mieć formę graficzną. Dobrą praktyką programistyczną jest oddzielenie oprogramowania do prezentacji informacji od samej informacji. 107

Prezentacja informacji Informacja do wyświetlenia Oprogramowanie prezentacyjne Ekran 108

Model MCV interakcji z użytkownikiem Stan widoku Komunikaty o modyfikacji widoku Metody widoku Zapytania i aktualizacje modelu Stan koordynatora Działania użytkownika Metody koordynatora Modyfikacje modelu Stan modelu Metody modelu 109

Informacje statyczne i dynamiczne Informacja, która nie zmienia się w trakcie sesji, może być przedstawiona zarówno graficznie, jak i tekstowo. Prezentacja tekstowa zajmuje mniejszy obszar ekranu, ale nie może być czytana „na pierwszy rzut oka”. Informacja, która się nie zmienia, powinna być odróżniona od informacji dynamicznej za pomocą innego stylu wyświetlania. Wszystkie statyczne informacje mogą być wyświetlane na przykład za pomocą jednej czcionki lub uwydatnione za pomocą ustalonego koloru. Mogą być też zawsze skojarzone z tą samą ikoną. 110

Sposoby prezentacji informacji Czy użytkownik potrzebuje dokładnej informacji, czy tylko związków między różnymi wartościami danych? Jak szybko zmienia się ta informacja? Czy użytkownik musi natychmiast widzieć te zmiany? Czy użytkownik musi wykonywać pewne działania w odpowiedzi na zmianę informacji? Czy użytkownik ma oddziaływać na wyświetlaną informację przez interfejs bezpośredniego działania? Czy wyświetlana informacja jest tekstowa, czy numeryczna? Czy wartości względne są ważne? 111

Różne prezentacje informacji Styczeń Luty Marzec Kwiecień Maj Czerwiec 2842 2851 3164 2789 1273 2835 4000 3000 2000 1000 0 Styczeń Luty Marzec Kwiecień Maj Czerwiec 112

Tekst czy grafika? Prezentacja tekstowa zajmuje mniej miejsca Dynamicznie zmieniające się informacje niż graficzna. numeryczne najlepiej uwidacznia się za pomocą prezentacji graficznej. Ustawicznie zmieniające się wyświetlacze cyfrowe są mylące, ponieważ szybkie przyswajanie dokładnych informacji jest trudne. Ciągłe wyświetlacze analogowe umożliwiają zaobserwowanie wartości względnych. Gdy przedstawia się dokładna informację alfanumeryczną, grafika może służyć do wydobycia danych ukrytych w tle. Graficzne uwydatnianie może również służyć do zwrócenia uwagi użytkownika na zmiany we fragmentach obrazu. 113

Metody prezentacji dynamicznie zmieniającej się informacji numerycznej 1 4 2 0 10 20 3 114

Graficzne wyświetlanie danych pokazujące wartości względne Ciśnienie 0 100 200 Temperatura 300 400 0 25 50 75 100 115

Tekstowe uwydatnianie informacji alfanumerycznej ! Wybrana przez Ciebie nazwa pliku Jest już używana. Wybierz inną. R. 15 Projektowanie interfejsu użytkownika OK Anuluj 116

Kolor w projekcie interfejsu Za pomocą kolorów można ulepszyć interfejs, pomagając użytkownikom w zrozumieniu i panowaniu nad złożonością. Łatwo jest jednak nadużyć barw i stworzyć interfejsy użytkownika nieatrakcyjne graficznie i powodujące błędy. Projektanci interfejsu powinni przyjąć ogólną zasadę, że kolory należy stosować ostrożnie. 117

Jak należy korzystać z kolorów w interfejsach użytkownika? Ogranicz liczbę stosowanych kolorów i używaj ich ostrożnie. Zmiany kolorów używaj do oznaczenia zmiany stanu systemu. Skorzystaj z kodu kolorów, który pomoże użytkownikowi w realizacji zadań. Korzystaj Uważaj z kodu kolorów spójnie i rozsądnie. na związki między kolorami. 118

Pomoc dla użytkownika Komunikaty generowane przez system w odpowiedzi na działania użytkownika. System pomocy natychmiastowej. Dokumentacja dostępna w systemie. 119

Komunikaty o błędach Pierwsze wrażenie użytkownika w kontaktach z systemem zależy od komunikatów o błędach systemowych. Niedoświadczeni użytkownicy rozpoczynają pracę, popełniają błąd i natychmiast muszą zrozumieć komunikat o błędzie. Projektując komunikaty o błędach należy przewidzieć doświadczenie i przeszłość użytkowników. 120

Zagadnienia projektowe związane z redakcją komunikatów Zagadnienie Opis Kontekst System wspomagania użytkownika powinien brać pod uwagę aktualne działania użytkownika i dostosować swoje komunikaty do bieżącego kontekstu. W miarę zapoznawania się użytkownika z systemem, może on irytować się zbyt długimi „znaczącymi” komunikatami. Początkujący użytkownicy mają jednak trudności ze zrozumieniem krótkich i zwięzłych określeń problemów. System wspomagania użytkownika powinien więc móc wyświetlać oba rodzaje komunikatów, zależnie od stopnia świadomości użytkownika. Komunikaty powinny być dostosowane do umiejętności użytkownika oraz jego doświadczenia. Komunikaty dla różnych grup użytkowników można wyrazić na różne sposoby zależnie od znanej im terminologii. Komunikaty powinny być pozytywne, a nie negatywne. Nigdy nie powinny być złośliwe ani żartobliwe. O ile możliwe, projektant komunikatów powinien znać kulturę kraju, w którym system będzie sprzedawany. Między Europą, Azją i Ameryką występują rozmaite różnice kulturowe. Komunikat właściwy w jednym 121 kraju może być nie do zaakceptowania w innym. Doświadczenie Umiejętności Styl Kultura

Ekran do wprowadzania nazwiska pacjenta przez pielęgniarkę Wpisz nazwisko pacjenta i naciśnij OK Nazwisko pacjenta Kowalski J. OK Anuluj 122

Komunikaty o błędach napisane w kategoriach systemu i użytkownika Błąd nr 27 ? Wprowadzono niewłaściwy Identyfikator pacjenta OK Pacjent Kowalski J. nie jest zarejestrowany Naciśnij przycisk Pacjenci, aby zobaczyć listę zarejestrowanych pacjentów. Naciśnij przycisk Powtórz, aby ponownie wprowadzić nazwisko pacjenta Naciśnij przycisk Pomoc, aby otrzymać więcej informacji Anuluj Pacjenci Pomoc Powtórz Anuluj 123

Projektowanie systemu pomocy Gdy użytkownicy otrzymują komunikat o błędzie, którego nie rozumieją, odwołują się do systemu pomocy w poszukiwaniu informacji. Jest to przykład wołanie „Pomóżcie!”, oznaczającego „Pomocy, jestem w kłopotach!”. Innym rodzajem prośby o pomoc jest pytanie „Pomożecie? ”, oznaczające „Potrzebuję informacji”. Systemy pomocy powinny punktów wejściowych. mieć kilka różnych 124

Teksty systemu pomocy Powinny być przygotowane z udziałem specjalistów w dziedzinie zastosowania. Temat pomocy nie powinien być prostym odwzorowaniem podręcznika użytkownika, ponieważ ludzie inaczej czytają ekran niż kartki papieru. Tekst, jego układ i style powinny być starannie oznakowane, aby można je było czytać w dość małym oknie. 125

Systemy pomocy Można implementować jako zbiór powiązanych witryn WWW lub za pomocą uniwersalnego systemu hipertekstowego, który można integrować z programami użytkowymi. Hierarchię można łatwo przemierzać, wybierając części komunikatu oznaczone jako odsyłacze. Zaletą systemu WWW jest łatwość implementacji i brak wymagania jakiegokolwiek specjalnego oprogramowania. 126

Punkty wejściowe do systemu pomocy Wejście od góry Wejście z programu użytkowego Wejście z systemu komunikatów o błędach Sieć tematów pomocy 127

Okna systemu pomocy Tematy pomocy Przekazanie listu List można przekazać do innego użytkownika sieci przez naciśnięcie przycisku Przekazywanie w panelu sterowania. System poprosi o podanie nazwy użytkownika lub użytkowników, do których ten list ma być wysłany. więcej następny tematy Historia pomocy 1. 2. 3. 4. Poczta Wysyłanie listów Czytanie listów Przekazanie 128

Dokumentacja użytkownika nie jest ściśle częścią projektu interfejsu użytkownika. Dobrą praktyką jest jednak projektowanie pomocy natychmiastowej w połączeniu z dokumentacją papierową. Podręczniki systemu powinny obejmować szczegółową informację niż system pomocy. bardziej Należy je zaprojektować tak, aby mogły z nich korzystać różne klasy użytkowników systemu. 129

Rodzaje dokumentacji wspomagającej użytkownika Recenzenci systemu Opis funkcjonalny Opis usług Administratorzy systemu Podręcznik instalatora Jak zainstalować system ? Początkujący użytkownicy Przewodnik podstawowy Początki pracy Doświadczeni użytkownicy Podręcznik Opis udogodnień Administratorzy systemu Podręcznik administratora Działanie i pielęgnacja 130

Typy dokumentów Opis funkcjonalny ◦ Należy bardzo krótko opisać usługi oferowane przez system. Podręcznik instalatora ◦ Powinien obejmować szczegółowe informacje o instalacji systemu. Przewodnik podstawowy ◦ Powinien obejmować nieformalne wprowadzenie do systemu, w którym należy przedstawić jego „normalne” użycie. Podręcznik ◦ Powinien zawierać opis udogodnień systemu oraz ich wykorzystywania. Podręcznik administratora ◦ Powinien być dostarczony w wypadku niektórych rodzajów systemu. 131

Ocena interfejsu to proces szacowania użyteczności interfejsu i sprawdzenia, czy spełnia on wymagania użytkownika. Powinna więc być częścią normalnego procesu weryfikacji i zatwierdzania systemów oprogramowanych. Najlepiej jest, aby oceny dokonywano względem specyfikacji użyteczności ustalającej atrybuty użyteczności. 132

Atrybuty użyteczności Atrybut Opis Łatwość nauczenia Po jakim czasie nowy użytkownik efektywnie korzysta z systemu? Szybkość działania W jakim stopniu sprawność systemu odpowiada praktyce pracy użytkowników? Solidność Jak system znosi błędy użytkownika? Zdolność do wycofania Jak dobrze system radzi sobie z wycofywaniem wyników błędów do użytkowników? Zdolność do adaptacji Jak bardzo system jest związany z jednym modelem pracy? 133

Sposoby oceny interfejsu użytkownika Kwestionariusze z pytaniami o to, co o interfejsie myślą jego użytkownicy. Obserwowanie użytkowników przy pracy z systemem i „głośne myślenie” o tym, jak próbują korzystać z systemu w celu realizacji pewnego zadania. Krótkie filmy z typowym użyciem systemu. Umieszczanie w oprogramowaniu kodu, który służy do gromadzenia informacji o najczęściej używanych udogodnieniach systemu i najczęściej występujących błędach. 134

Główne tezy Proces projektowania interfejsu użytkownika powinien koncentrować się na użytkowniku. Interfejs powinien porozumiewać się z użytkownikiem za pomocą ich pojęć. Powinien być logiczny i spójny. Powinien zawierać tez udogodnienia pomagające użytkownikom w pracy z systemem i w wycofywaniu się z pomyłek. Sposoby interakcji z systemem oprogramowanym to m. in. Bezpośrednie działanie, wybór z menu, wypełnianie formularza, języki poleceń i język naturalny. Informacje należy wyświetlać graficznie, gdy chce się przedstawić trendy i wartości przybliżone. Wyświetlacze cyfrowe powinny być stosowane jedynie wówczas, gdy jest wymagana precyzja. W interfejsie użytkownika kolory należy używać oszczędnie i spójnie. Projektanci powinni brać pod uwagę, że znacząca liczba osób to daltoniści. 135

Główne tezy c. d. Systemy pomocy powinny oferować dwa rodzaje pomocy: Pomóżcie!, to znaczy „Pomóżcie! Jestem w kłopotach!” i „Pomożecie? ”, to znaczy „Pomożecie? Potrzebuję informacji”. Komunikaty obłędach nie powinny sugerować, że użytkownik jest winny. Powinny za to sugerować, jak naprawić błąd, i dawać odsyłacz do systemu pomocy. Dokumentacja użytkownika powinna obejmować przewodniki dla początkujących i podręczniki. Należy dostarczyć oddzielenie dokumenty dla administratora. Specyfikacja systemu powinna zawierać (tam gdzie to jest możliwe) ilościowe wartości atrybutów użyteczności. Proces oceny powinien polegać na weryfikacji systemu względem tych wymagań. 136