Proiectarea Componentei de Interactiune cu Factorul Uman (interfetei utilizator)

Proiectarea Componentei de Interactiune cu Factorul Uman (interfetei utilizator)

Interfata Utilizator (IU)

Interfata uilizator necesita o examinare detaliata atat in faza analizei cat si a proiectarii.

In OOD, IU refera la proiectarea formatelor ferestrelor si rapoartelor. Prototipizarea este utilizata pentru a ajuta la selectia si dezvoltarea mecanismelor de interactiune. Unele companii considera important de a proiecta portiuni ale IU paralel cu faza analizei Aplicarea unei strategii sistematice suportate de prototipizare este vitala in acest domeniu.

De ce - Interfata Utilizator

Aceasta componenta se refera la modul in care factorul uman va comanda sistemul si modul in care sistemul va furniza informatii utilizatorului.

Deciziile de proiectare vor afecta utilizatorul, vor afecta pozitiv sau negativ emotiile si perceptiile sale mentale. Ele pot provoca:

teama, exasperare, stangacie, jena

plictiseala

creativitate, bucurie

3. Strategia

3.1 Clasificarea utilizatorilor

Se recomanda a se apela si la un specialist in studiul interactiunilor umane si in testarea acestora. Se vor studia viitorii utilizatori ai sistemului, urmarindu-i cum isi desfasoara activitatea si nici o bariera contractuala sau sociala nu trebuie stea in calea acestui studiu, deoarece sistemul va afecta in bine sau in rau vietile de zi cu zi ale acestora.

A se urmari:

ce probleme anume vor utilizatorii sa rezolve

ce utilitare li se pot furniza pentru a-i ajuta

cum pot fi ele realizate fara a-i obstructiona in activitatea lor

Utilizatorii pot fi clasificati dupa urmatoarele criterii:

nivelul de indemanare: incepator, ocazional, intermediar, avansat

nivelul organizational: executiv, conducere, supervizor, functionar

dupa apartenenta la diferite grupuri: conducere, client

3.2 Descrierea utilizatorilor

Pentru fiecare categorie de utilizatori din pasul anterior, se considera urmatoarele:

-profesiunea

-scopul

-caracteristici (varsta, educatie, restrictii)

-factori critici de succes (ce ii place, ce ii displace)

-nivelul de indemanare

-scenariul de lucru

Exemplu

-profesiunea Analist

-scopul: Execut o munca de analiza. Dati-mi un utilitar care sa ma ajute sa fiu mai eficient.

-caracteristici:

varsta Am 42 ani

educatie Am absolvit colegiul

restrictii Nu-mi plac caracterele foarte mici; orice caracter sub 9 puncte este prea mic pentru mine

-factori critici de succes:

-doresc ca utilitarul pe care il realizati sa nu tina cont de modul efectiv in care efectuez analiza.

-doresc ca utilitarul sa captureze ideile si modificarile in timp real.

-doresc sa documentez orice parte a modelului in orice moment. Consider ca aceste informatii sunt la fel de importante ca si cerintele insesi.

-doresc un utilitar amuzant.

-nivelul de indemanare: avansat

-scenariul de lucru:

-identific clasele si obiectele principale

-identific structurile principale

-adaug Atribute si Servicii pe masura ce-mi vin in minte dar nu vreau sa fie vizibile in model decat mult mai tarziu.

-verific modelul

-listez modelul si documentatia sa.

3.3 Proiectarea ierarhiei comenzilor

Pentru aceasta, se recomanda:

daca ierarhia comenzilor trebuie sa se integreze intr-un sistem de interactiuni deja existent, acesta trebuie mai intai studiat.

stabilirea unei ierahii initiale de comenzi care poate fi prezentata utilizatorilor in mai multe moduri:

-o serie de ecrane meniu

-o bara meniu

-o serie de imagini (icons)

Se poate incepe cu urmatoarea ierarhie de baza a comenzilor (Serviciilor):

File Edit Format Calculate Monitor Window

rafinarea ierarhiei comenzilor prin:

-ordonarea serviciilor din fiecare ramura a ierarhiei:

cele mai frecvente Servicii sa apara primele in lista

in ordinea logica in care trebuie sa se execute

-latimea si adancimea ierarhiei: evitarea supraincarcarii memoriei pe termen scurt a factorului uman. Dr. Miller in "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information" raporteaza faptul ca memoria pe termen scurt a factorului uman pare a fi limitata la aproximativ 5 pana la 9 elemente de informatii la un moment dat. Intr-o lucrare ulterioara, el a reconsiderat acest subiect, afirmand ca mai corect decat a vedea aceasta limitare ca 7 plus sau minus 2 este de a considera 3 grupuri formate fiecare din maximum 3 elemente.

Exemplu:

In acest exemplu, meniul Window este format din 3 grupuri (loturi) de maximum 3 submeniuri.

Window

----- ----- ------

Send To back

Collapse

Zoom

----- ----- ------

Redraw Screen

Stack Window

----- ----- ------

Model Control

Model Critique

Model Template

----- ----- ------

-minimizarea numarului de pasi, de actiuni (apasari ale butonului mouse, combinatii de chei) pe care trebuie sa le efectueze utilizatorul pentru a-si indeplini sarcinile.

3.4 Proiectarea detaliata a interactiunilor

Interactiunile cu factorul uman pot fi proiectate pe baza urmatoarelor criterii:

consistenta: se recomanda utilizarea unor termeni consistenti si actiuni consistente.

numar mic de pasi- trebuie sa se minimizeze numarul de actiuni pe care trebuie sa le indeplineasca utilizatorul

evitarea aerului mort"- "dead air aer mort este un termen semnificand faptul ca utilizatorul nu trebuie lasat singur, fara nici un semnal, atunci cand trebuie sa astepte ca sistemul sa execute o actiune. Utilizatorului trebuie sa i se semnaleze:

-faptul ca sistemul executa o actiune

-cat din actiunea respectiva s-a realizat

undo: se recomanda a se furniza acest serviciu sistemului, datorita erorilor utilizatorului.

Timpul si efortul de invatare: trebuie sa fie scurt. }n general, utilizatorii nu vor citi documentatia. Se recomanda a se furniza referinte on-line.

Prezentarea interfetei: Factorul uman utilizeaza un software care este placut si amuzant.

3.5 Prototipizarea

Un bun punct de start este de a se folosi ca model un software deja existent cu o interfata bine realizata. Daca exemplul ales face parte din domeniul problemei, este cu atat mai bine. Se considera meniurile, submeniurile si prescurtarile deja existente. Se folosesc utilitare pentru prototipizari vizuale sau generatoare de aplicatii. Se recomanda realizarea mai multor prototipuri care vor fi puse la dispozitia utilizatorilor, urmarindu-le reactiile in timp ce le folosesc.

3.6 Proiectarea claselor pentru Interfata Utilizator

Pentru a proiecta clasele pentru interfata utilizator se incepe prin a organiza interactiunile cu factorul uman in ferestre si componente:

Exemplu:

Window

0,m

1

Field SensorAlarmWindow SensorStatusWindow

Graphic

Selector

Ferestre si componente

Exemplu:

OOARoot

OOAWindow

OOAClassWindow

OOAConditionWindow

OOACritiqueWindow

OOADocumentWindow

OOADrawingWindow

OOAFilterWindow

OOAModelControlWindow

OOAStrategyWindow

OOATemplateWindow

Fiecare clasa contine definitia pentru: menu-bar, pull-down menu, si pop-up menu pentru o fereastra. Fiecare clasa defineste Serviciile necesare pentru a crea meniurile, pentru a evidentia un element selectat si pentru a invoca raspunsul corespunzator. Fiecare clasa este raspunzatoare pentru prezentarea informatiei in interiorul ei si incapsuleaza toate informatiile pentru dialog.

3.7 Exemplu - Sistemul-Senzor de monitorizare

1. Clasificarea utilizatorilor:

Sunt Fred. Doresc sa am controlul asupra senzorilor. Doresc sa-i adaug, sa-i initializez, sa le controlez operatiile, comutandu-i intre starile on, off, standby.

Scenariul de lucru: Doresc sa adaug un senzor doresc sa initializez un senzor doresc sa setez starea senzorului cu on sistemul raporteaza conditie de alarma corectez datele problemei.

Proiectarea ierarhiei comenzilor:

File Edit Initialize State Style

Add . Off Font .

Change.. Standby Icon Size .

Delete.. On

PDC    =Problem Domain Component

TMC     =Task Management Component

DMC    =Data Management Component

SensorWindow 2

Coordinates

SensorAlarmWindow SensorItem

Position

Display Menu InvokeItem

InvokeMenuAction

0,m

1

SensorAlarmItem

InvokeItem

SensorStatusWindow

DisplayMenu

InvokeMenuAction

0,m

2

SensorGraphicItem    1. Sensor-PDC 3. Sensor-TMC

AlarmDevice Task

InvokeItem    AlarmEvent TaskCoordinator

Building

2 CriticalSensor

Sensor

Sensor-DMC

ObjectServer    Sistemul de monitorizare senzori-Interfata utilizator expandata

Proiectarea Componentei de Coordonare a Taskurilor

Taskul este un alt nume pentru proces. Executia concurenta a mai multor taskuri se numeste multi-tasking.

Taskurile multiple sunt necesare in unele cazuri:

pentru sistemele pentru achizitie de date

pentru anumite interfete utilizator- acele care au multiple ferestre selectate pentru intrare

pentru sistemele multi-user

pentru arhitecturi multi-subsistem

pentru cazul mai multor taskuri si un singur procesor. Un task trebuie sa coordoneze si sa comunice cu alte taskuri in timpul executiei. Asemenea taskuri se executa prin partajarea timpului procesor, creind iluzia ca se executa in paralel.

pentru arhitecturile multi-procesor

Taskurile separa actiunile care trebuie sa aiba loc in paralel. Aceasta comportare concurenta poate fi implementata pe procesoare separate sau poate fi simulata pe un singur procesor in conjunctie cu un sistem de operare multitasking. O alternativa este de a considera un program secvential ciclic. Dupa executarea fiecarei parti de program el verifica ce s-a intamplat cat timp a fost ocupat raspunzand corespunzator.

O abordare neeficienta ar fi de a intercala comportari concurente intr-un singur program secvential, rezultand un program foarte mare si necesitand teste la fiecare cateva linii de cod, teste care sa verifice intrarea datelor sau diverse cereri. Rezultatul: cod-spaghetti. Utilizarea taskurilor va simplifica proiectarea si implementarea actiunilor concurente.

Strategia

Scopul acestei strategii este de a identifica si de a proiecta taskurile si Serviciile incluse in fiecare task:

identificarea taskurilor determinate de evenimente (taskuri responsabile pentru comunicarea cu un dispozitiv, una sau mai multe ferestre pe ecran, un alt task, sub-sistem sau procesor. Taskul poate fi proiectat pentru a se declansa la un anumit eveniment, deseori semnaland aparitia unor date).

identificarea taskurilor determinate de ceas (aceste taskuri se declanseaza la anumite intervale de timp).

identificarea taskurilor prioritare si critice(E posibil ca unele Servicii sa fie de prioritate maxima. Acestea trebuie izolate intr-un task separat de prioritate mare. Alte Servicii sunt de mica prioritate, iar altele sunt critice)

identificarea unui task coordonator (acest task coordoneaza executarea celorlalte taskuri)

definirea fiecarui task:

numele taskului si o scurta descriere

adauga fiecarui Serviciu identificat un nume de task. Fiecare Serviciu este mapat unui task.

specifica daca taskul este coordonat de eveniment (si indica evenimentul respectiv) sau ceas (indica intervalul de timp la care se declanseaza)

specifica modul de comunicare (de unde isi ia intrarea si unde trimite rezultatele)

Paragrafele anterioare pot fi rezumate prin urmatoarea schema privin componenta de coordonare a taskurilor:

TaskCoordinator

Coordinate

0,m

1

Task

Name

Description

Priority

ServicesIncluded

CoordinatesBy

CommunicatesVia

Initialize

Start

Standby

Terminate

in care fiecare task este definit cu urmatoarele:

Nume

Descriere

Prioritate

Servicii incluse

Coordonat de

Comunica prin

Exemplu: Sistemul de monitorizare senzori

2. Sensor-HIC 1. Sensor-PDC 3 TaskCoordinator 3 4. Sensor-DMC

SensorAlarmItem AlarmDevice ObjectServer

SensorAlarmWindow AlarmEvent

SensorGraphicItem Building Coordinate

SensorStatusWindow CriticalSensor

SensorWindow Sensor

0,m

1

Task

ID

Name

Description

Priority

ServicesIncluded

CoordinatesBy

CommunicatesVia

Initialize

Start

Standby

Terminate

3

Task1

Nume: SensorReader

Descriere: Acest task este responsabil pentru citirea senzorului la intervalul specificat

Servicii incluse: Sensor.Sample

Prioritate: medie

Coordonat de: coordonat de ceas, la un interval de 100 ms.

Comunica prin: -primeste valori din linia de intrare (de la un senzor)

-trimite valori catre cutia postala RawData

Task2

Nume: CriticalSensorReader

Descriere: Acest task este responsabil pentru citirea senzorului critic la intervalul si toleranta specificate.

Servicii incluse: CriticalSensor.Sample

Prioritate: mare

Coordonat de: coordonat de ceas, la un interval de 25 ms.

Comunica prin: -primeste valori din linia de intrare (de la un senzor critic)

-trimite valaori catre cutia postala RawData

Task3

Nume: InteractionCoordinator

Descriere: Acest task este responsabil pentru intercatiunea cu utilizatorul, initializarea senzorului si compararea pragurilor.

Servicii incluse: Sensor.Initialize

Sensor.MonitorForAlarmCondition

Prioritate: mica

Coordonat de: coordonat de eveniment:

evenimentul intercatiunii cu utilizatorul

sosirea unei date in cutia postala RawData

Comunica prin: -primeste valori din bufferul de interactiune cu utilizatorul sau

din cutia postala RawData

PDC =Problem Domain Component

HIC =Human Interaction Component

DMC =Data Management Component

Proiectarea Componentei de Coordonare (Gestiune) a Datelor

Componenta de coordonare a datelor furnizeaza infrastructura pentru depozitarea si regasirea obiectelor dintr-un sistem de coordonare a datelor.

Exista trei abordari majore pentru coordonarea datelor:

coordonarea datelor utilizand fisiere

sistem de coordonare a datelor prin baze de date relationale. Din categoria sistemelor de gestiune a bazelor de date relationale enumeram: dBASE, FOXBASE, FOXPRO, ORACLE, INGRES, INFORMIX, DB2, CAMPUS, ACCESS. Un astfel de sistem coordoneaza datele printr-un numar de tabele, fiecare avand un nume. Fiecare coloana are un nume si contine o singura valoare (atomica). Fiecare rand reprezinta un set de valori in tabel. Randurile sunt unic identificabile. Una sau mai multe coloane pot fi definite drept chei primare-unicul identificator pentru fiecare rand din tabel. Una sau mai multe coloane pot fi definite drept chei externe (straine) pentru a facilita accesul la randurile corespunzatoare din alt tabel. Tabelele si coloanele pot fi reorganizate pentru a reduce redundanta datelor si deci numarul de pasi pentru modificarea consistenta a datelor. Aceasta reorganizare poarta numele de normalizare. Gradul de eliminare a redundantei datelor e definit ca "forme normale".

sistem de coordonare a datelor prin baze de date orientate obiect

Sistemele de gestiune a bazelor de date orientate-obiect reprezinta o tehnologie inca in curs de implementare. Primele produse comerciale au aparut in 1986. Exista 2 mari abordari:

-produsele relationale extinse

-produsele limbajelor de programare extinse orientate-obiect

Produsele relationale extinse extind sistemele de gestiune a bazelor de date relationale, adaugand tipuri de date abstracte, mecanismul de mostenire si cateva Servicii pentru crearea si manipularea Claselor si Obiectelor.

Produsele limbajelor de programare extinse orientate-obiect extind un limbaj de programare orientat-obiect cu sintaxa si capabilitati de gestiune a Obiectelor intr-o baza de date.

Proiectarea componentei de coordonare a datelor consta in proiectarea machetelor de date si a Serviciilor corespunzatoare.

Proiectarea machetelor datelor se realizeaza functie de abordarea aleasa, din cele trei expuse mai sus, pentru coordonarea datelor.

Definirea Serviciilor corespunzatoare consta in adaugarea unui Atribut si Serviciu fiecarei Clase&Obiect careia ii corespund Obiecte ce trebuie memorate. In acest fel un Obiect trebuie sa stie singur cum sa se inregistreze. Un Obiect trebuie sa stie ce fisier (tabel) trebuie sa deschida, cum sa pozitioneze fisierul pe inregistrarea corecta, cum sa regaseasca vechi valori, si cum sa se actualizeze. Se defineste o Clasa&Obiect, ObiectServer, cu Servicii pentru:

a semnala fiecarui Obiect sa se salveze (in fisier)

a regasi Obiecte inregistrate (cautari, creari si initializari de Obiecte)

Exemplu- Sistemul de monitorizare senzori

2. Sensor-HIC 1. Sensor-PDC 3 Sensor-TMC 3 4. Sensor-DMC

SensorAlarmItem AlarmDevice Task ObjectServer

SensorAlarmWindow AlarmEvent TaskCoordinator

SensorGraphicItem Building

SensorStatusWindow CriticalSensor

SensorWindow Sensor

Gestiunea datelor pentru acest sistem- prin fisiere.

Se va utiliza pentru fiecare Clasa&Obiect cate un fisier pentru inregistrarea valorilor Atributelor.

Fisiere:

Alarm_Device_File

Alarm_Event_File

Building-File

Sensor_File

cu un camp SensorType (cu valorile "Sensor" sau "CriticalSensor