Home - Rasfoiesc.com
Educatie Sanatate Inginerie Business Familie Hobby Legal
Doar rabdarea si perseverenta in invatare aduce rezultate bune. stiinta, numere naturale, teoreme, multimi, calcule, ecuatii, sisteme


Biologie Chimie Didactica Fizica Geografie Informatica
Istorie Literatura Matematica Psihologie

Informatica


Index » educatie » Informatica
» Proiectarea Componentei de Interactiune cu Factorul Uman (interfetei utilizator)


Proiectarea Componentei de Interactiune cu Factorul Uman (interfetei utilizator)




Proiectarea Componentei de Interactiune cu Factorul Uman  (interfetei utilizator)

1.  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.

2.   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:

1)    cele mai frecvente Servicii sa apara primele in lista

2)    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


                                     

1

                       


                        Graphic


  1       


                                    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

2          SensorWindow                                                                       2

            Coordinates


            SensorAlarmWindow                                     SensorItem

                                                                                    Position

            Display           Menu                                                   InvokeItem

            InvokeMenuAction


                  0,m


                            1


            SensorAlarmItem





            InvokeItem


SensorStatusWindow


DisplayMenu

InvokeMenuAction

   0,m


                                                                                                            2

              1                                           

                                                           

SensorGraphicItem                             1. Sensor-PDC            3. Sensor-TMC

                                                            AlarmDevice              Task

InvokeItem                                          AlarmEvent                TaskCoordinator

                                                            Building

2                                       2                 CriticalSensor

                                                            Sensor

4.     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:

1.     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).

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

3.     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)

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

5.     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                                      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:

1)     evenimentul intercatiunii cu utilizatorul

2)     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:

1)    a semnala fiecarui Obiect sa se salveze (in fisier)

2)    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)







Politica de confidentialitate


Copyright © 2019 - Toate drepturile rezervate

Informatica


Access
Adobe photoshop
Autocad
Baze de date
C
Calculatoare
Corel draw
Excel
Foxpro
Html
Internet
Java
Linux
Mathcad
Matlab
Outlook
Pascal
Php
Powerpoint
Retele calculatoare
Sql
Windows
Word


ContArt
UTILIZAREA TEHNOLOGIEI INFORMATIEI IN VIATA DE ZI CU ZI
Utilitarele Debug si Turbo Debugger
PROIECT INFORMATICA - COMERTUL ELECTRONIC
SISTEME DE OPERARE
WORD si WINDOWS - SUBIECTE
Invarianti in descrierea modelului obiect de sistem
Descrierea pachetului de programe TURBO-ASSEMBLER
CALCULAREA NOTELOR STANDARDIZATE z cu SPSS
Inteligenta Artificiala