Interfata Om-Masina - Aplicatie [PDF]

Zitiervorschau

UNIVERSITATEA POLITEHNICA BUCURESTI FACULTATEA DE AUTOMATICA SI CALCULATOARE

PROIECT INTERFATA OM MASINA

AB 352

2006

Cuprinsul proiectului: 1.

2.

3.

4.

Introducere a. Scurta introducere IOM b. Prezentarea pe scurt a temei si a motivarii alegerii ei c. Prezentarea mediilor ce vor fi folosite cu argumente Analiza a. Analiza functionala a aplicatiei – ce se doreste, si ce anume va fi implementat b. Analiza modului de implementare i. Diagrame de clase ii. Design iii. Use case-uri iv. Module c. Analiza costuri/timp de implementare d. Analiza generala dezvoltare proiect – time line Dezvoltare a. Descrierea detaliata a claselor-modelelor cu exemple semnificative b. Justificari ale alegerii metodelor de implementare c. Dezvoltare help Testare

1. Introducere a) Interfata om masina Interactiunea om-calculator (Human-Computer Interaction – HCI) este stiinta care se ocupa cu proiectarea, evaluarea si implementarea sistemelor de calcul interactive destinate uzului uman, si cu studiul fenomenelor importante existente în acest context. Din perspectiva stiintei calculatoarelor, accesul este pus pe interactiune ; mai precis se refera la interactiunea uneia sau mai multor persoane cu una sau mai multe masini de calcul. Luând în considerare notiunea de masina, putem avea de-a face în locul clasicelor statii de lucru cu masini de calcul încorporate (embedded), ca parti ale bordurilor avioanelor sau ale obisnuitelor cuptoare cu microunde. Tehnicile de proiectare a interfetelor acestor dispozitive sunt similare celor de proiectare a interfetelor grafice utilizator ale unei statii de lucru. Interfaţa utilizatorului reprezintă partea vizibilă a sistemului, prin intermediul ei putându-se introduce informaţii, comenzi şi modele (de altfel este singura componentă a sistemului cu care utilizatorul intră în contact). O interfaţă de utilizator performantă este flexibilă, consistentă, simplă şi adaptabilă. Pentru a lucra cu un sistem, utilizatorii terbuie sa fie capabili sa controleze sistemul si sa aiba acces la starile sistemului. Termenul de „USER INTERFACE” (Interfata Utilizator) este folosit in special in sistemele computerizate sau electronic. Ea este de fapt un „layer” care separa omul de masina pe care o opereaza. Designul unei astfel de interfete afecteaza cantitatea de efort pe care userul trebuie sa o consume pentru a introduce date in sistem si sa interpreteze iesirea sistemului, si cat de mult dureaza sa invete sa-l utilizeze. Concluzionând, interfata utilizator este partea unei aplicatii software care permite utilizatorului: sa interactioneze cu calculatorul sa-si îndeplineasca îndatoririle sau sarcinile ce-i sunt cerute (task). Utilizabilitatea este gradul cu care se masoara cat de mult se mapeaza interfata unui sistem cu psihologia si fiziologia userului, asta ducand la gradul sistemului de eficienta si satisfactie. Interfetele om masina au aparut odata cu masinile dar referindu-ne strict la interfetele cu sistemele de calcul, etapele dezvoltarii lor, in functie de tipul dominant de comunicare au fost trei mari categorii: - Batch interface, 1945 – 1968 - Comand-line interface, 1969-1983

-

Interfete grafice, din 1983 pana astazi.

Interfaţa în linie de comandă Avantaje:  Permite scrierea clară şi explicită a comenzilor, cu toţi parametrii bine definiţi  Oferă flexibilitate în utilizare  Comunicarea cu sistemul de operare se face rapid şi eficient Dezavantaje:  Operatorul trebuie să cunoască bine comenzile şi efectele lor  Este mai greu de utilizat de către neprofesionişti Interfaţa grafică Avantaje:  Este intuitivă şi uşor de folosit  Poate fi utilizată şi de către neprofesionişti  Creează un mediu de lucru ordonat  Permite crearea şi utilizarea de aplicaţii de complexe, precum şi integrarea acestora în medii de lucru unitare Dezavantaje:  Anumite operaţii legate, de exemplu, de configurarea sistemului pot să nu fie accesibile din meniurile şi ferestrele interfeţei grafice  Interfaţa ascunde anumite detalii legate de preluarea şi execuţia comenzilor  Foloseşte mai multe resurse şi este mai puţin flexibilă decât interfaţa în linie de comandă Filmele din domeniul fictiunii ne prezinta urmatoarea posibila in dezvoltarea interfetelor, si anume cele neuronale, in care omul nu va mai folosi echipamente de control, ci va actiona totul prin puterea gandului. -

Interfetele au doua componente principale: input (intrarea) – care in echipamentele din tehnologia informatiei sunt tablete, taste, butoane, microfoane, camere video etc output (iesirea) – ecrane text&imagine, difuzoare, echipamente de control mecanic etc.

b) Tema de proiect Tema acestui proiect este: Aplicatie de management al proceselor din Windows (ce procese ruleaza, ale caror aplicatii sunt, terminarea proceselor, ascunderea unor procese) De fapt ne propunem sa realizam o aplicatie asemanatoare Task Managerului din Windows, care sa cuprinda toate componentele binecunoscute : afisarea aplicatiilor si proceselor care ruleaza la un moment dat, gradul de solicitare al CPU, optiunile de

inchidere/blocare a unui proces selectat, optiunea de minimizare/maxmizare a ferestrei unei aplicatii anume. Am ales aceasta tema tocmai pentru gradul de interactivitate marit cu sistemul de operare Windows (care ar fi si scopul acestui curs) dar si cu userul caruia ii da posibilitatea de a gestiona aplicatiile din sistem.

c) Prezentarea mediilor folosite (argumente) Pentru realizarea acestui proiect am folosit mediul de programare Visual Studio 6.0, oarecum impus. Am ales limbajul VB pentru ca este mai apropiat de ideea de VISUAL urmarita de limbajele ulterioare, si pentru ca ne era mai cunoscut.

2. Analiza a)Analiza functionala -

Aplicatia se doreste a fi capabila sa: vizualizeze o lista a proceselor active; prezinte proprietatile proceselor active; sa poata inchide/bloca un proces selectat; sa poata ascunde un proces; sa poata minimiza/maximiza ferestrele aplicatiilor.

Pe langa aceste cerinte, ne-am hotarat sa implementam in plus urmatoarele functionalitati: - aplicatia va afisa tipul de procesor si proprietatile acestuia; - va afisa grafic gradul de incarcare a procesorului; - va afisa grafic gradul de incarcare a memoriei; - va afisa proprietatile memoriei ram; - va afisa incarcarea CPU pentru fiecare aplicatie activa; - va afisa clasele si Handle-urile fiecarei aplicatii active; - va afisa toate subclasele aplicatiilor active si caracteristicele lor principale Pe langa aceste cerinte pe care ne-am propus sa le atingem, la final aplicatia noastra va trebui sa indeplineasca unele standarde , cum ar fi: Portabilitate: Aplicatia trebuie sa ruleze pe orice sistem de operare Windows si de aceea trebuie sa contina rutinele necesare pentru a suporta diferentele majore care au facut trecerea la sistemele de operare NT (Windows 2000,XP,2003 etc). Utilizabilitate: Aplicatia trebuie sa fie cat mai light (dimensiune mica), cat mai usor de folosit, sa nu consume multe resurse, preferabil sa contina un singur executabil si sa nu aiba cerinte software sau hardware speciale, altceva decat sistemul de operare si un sistem pe care acel sistem sa poata functiona. Fiabilitate: Aplicatia trebuie sa fie bug free (asta se va rezolva in limita de timp acordata pentru implementare).

b)Modul de implementare Pentru implementarea aplicatiei se va face o diviziune clara a cerintelor , ce se va rasfrange si asupra modului de lucru in mediul de programare. Functionalitatile majore vor fi urmatoarele: -

Prezentare grafica si proprietati Gestiune procese (hide, close etc) Vizualizare CPU/Process Vizualizare proprietati extinse pentru aplicatiile care ruleaza

Pentru ca aplicatia nu necesita acest lucru, nu va fi puternic directionata OOP, dar va contine totusi niste clase care sa: - contina metode pentru controalele grafice (CResize) - contina metode de lucru cu procesorul (clsCPUUsage) - metode si proprietati specifice fisierelor (mclsFileProperties) - metode de aflare/gestiune a proceselor (clsPDHQuery) - metode pentru gestionarea memoriei (clsCPUUsageNT) Pentru a da o forma aplicatiei, trebuie precizate cazurile de utilizare (use case – urile), din care va rezulta un design si apoi o arhitectura in limbajul de programare. Un caz de utilizare specifica o parte a comportarii unui sistem. CASE1: Userul va porni aplicatia si va putea vizualiza fara a mai efectua nici o alta operatiune proprietatile procesorului, memoriei si gradul de incarcare al acestora. Din aceasta fereastra, va exista posibilitatea lansarii oricarei alte functionalitati. CASE2: Userul va porni aplicatia si va alege modul de vizualizare a consumului CPU per process. O noua fereastra se va deschide si va afisa acest lucru intr-un tabel cu numele aplicatiilor si rata CPU pentru fiecare. Informatiile trebuie sa se autoreactualizeze in mod automat la un interval foarte mic de timp. CASE3: Userul va alege modul de control. O noua fereastra se va deschide si ii va prezenta in detaliu toate procesele, clasele din care aceste procese fac parte, PID, Handle, subclase, subprocese, proprietati extinse. Va avea disponibile comenzile de: stop, resume, close, refresh, show, hide, minimize, maximize. CASE4: Userul va alege modul de proprietati extinse, si intr-o fereastra noua va putea vizualiza pentru fiecare aplicatie, date legate de executabil si/sau de toate fisierele DLL apelate de acest executabil. In concluzie aplicatia va contine 4 forme, una main si 3 child care se vor lansa individual, fara a inchide forma main. In plus, pe langa clasele si formele specificate, vor exista module de functii necesare pentru fiecare functionalitate. Pentru a putea reutiliza codul pe viitor, metodele vor fi grupate in module de metode statice de acelasi tip sau familie de functionalitati.

Formele: 1)FormaMain va contine: - liste de proprietati procesor/memorie - controale grafice pentru afisarea incarcarilor - timere pentru refresh separat pentru elementele grafice - controale de unde pot fi afisate formele urmatoare 2)Forma CPU/Process - Un tabel in care pe prima coloana vor fi afisate numele proceselor - Pe a doua coloana CPU cost - Un timer care face refresh la date cu o viteza mare, avand in vedere ca costul CPU se modifica cu frecventa foarte mare 3)Forma Process Extended Properties: - Doua liste : una pentru procese, alta pentru proprietati - Subprocesele vor fi afisate cu un tree control - Va exista posbilitatea de refresh manual al tree-ului 4)Forma Process control - Tot doua liste pentru procese si subprocese - Un context meniu din care se pot selecta operatiunile de baza

c)Analiza cost/timp de implementare In aceasta analiza se vor lua in calcul toate costurile de design, scriere cod si testare si se vor calcula in ore-om luandu-se in considerare ca implementatorii sunt developeri medii. Design – se vor calcula costurile pentru fiecare forma in parte ( avem 4 forme, una main si alte 3 child): nr

Descriere

Ore-om

1

Analiza cerinte pentru design si schita

0.5

2

Creare controale, asezare, denumire, dimensiuni etc

0.5

3

Proprietati generale ale formei

0.5

4

Implemetare functionalitati de baza

0.5

5

Testare forma

0.5

6

TOTAL ORE-OM

2.5

Total = 2.5 ore X 4 forme = 10 ore + 2 ore research pentru metodele grafice = 12 ore

Scriere cod nr 1 2 3 4

Descriere Analiza cerinte pentri implementare Scrierea metodelor si claselor necesare fiecarei functionalitati Testarea metodelor prin implementare lor in GUI TOTAL ORE-OM

Ore-om 0.5 4 0.5 5

Total 5 ore X 5 functionalitati majore = 25 ore Testare Testarea se va face pe toate functionalitatile, la diferite grade de incarcare a sistemului si pe diferite configuratii software/hardware/SO. Timpul total alocat pentru testare este de 5 ore. => Timp total pentru dezvoltarea proiectului= 42 ore.

d) Analiza generala dezvoltare proiect - Time line La acest proiect vor lucra 3 persoane, FA, AB si AR. FA se va ocupa de crearea claselor si a metodelor functionale AB se va ocupa de designul formelor si implementarea functionalitatilor de baza ale GUI AR se va ocupa de research pentru dezvoltare controale grafice si testare Time line-ul pentru proiect va fi urmatorul: (Se tine seama de faptul ca analiza este deja finalizata – se discuta doar time -line pentru implementare)

Who FA AB AR

0 Func Cpu Form cpu Research

2 F ctr T CPU

4 Fun ctr F prop T ctr

6 F main T prop

10 Fun p Grafic T main

15

20 Fun m

24

T funct

T final

T final

Asa cum se observa, procesul va dura 24 de ore, datorita faptului ca nu se poate lucra la acelasi lucru in acelasi timp. AR va incepe cu etapa de research , deoarece la inceputul proiectului nu exista nimic de testat, apoi va trece la testarea modulelor implementate. AB va incepe cu implementarea formelor child, deoarece cea main are mai intai nevoie de research.

FA va incepe implementarea codului in aceeasi ordine cu AB, pentru ca AR sa poata testa functionalitatile in aceasi timp si pentru cod si pentru design pentru acelasi tip de functionalitate.

3. Dezvoltare Descrierea designului folosit Descrierea codului Dezvoltarea help/user manual(ghid pentru utilizator) Un ghid pentru utilizator, cunoscut si sub denumirea de manual, reprezinta un document cu specificatii tehnice conceput cu scopul de a acorda asistenta utilizatorilor finali ai unui anumit sistem. De obicei acesta este scris de un tehnical writer, cu toate ca poate fi conceput si de catre programatori, manageri de proiect sau de produs, sau chiar de alte persoane, mai ales in cadrul companiilor de mica anvergura. Majoritatea manualelor contin atat un text explicativ, cat si imagini asociate notiunilor descrise in partea de text. In cazul aplicatiilor pentru calculator se folosesc de obicei screenshoturi care exemplifica modul in care programul ar trebui sa arate , iar manualele pentru hardware includ diagrame simplificate. Limbajul folosit este unul pe intelesul tuturor utilizatorilor, pastrandu-se insa o nota formalitate. Principalele componente ale unui manual sunt:  Prefata, cuprinzand detaliile cu privire la documentatie si informatii despre cum am putea utiliza cel mai bine acest manual;  Cuprins  Ghid despre cum sa folosim principalele functii ale sistemului  Sectiunea de trubleshooting – cuprinde principalele erori pe care le-am putea intalni, precum si modul de solutionare al acestora  Sectiunea FAQ (Frequentely Asked Questions)  Detalii despre unde am putea gasi informatii suplimentare si detalii de contact  Glosarul sau, pentru licatii mai complexe, un Index

In cazul nostru , tinand cont ca relevanta acestei aplicatii se constituie intr-un proiect scolar, nu vom alcatui chiar un manual scortos sau foarte complex, ci mai degraba un Help in linii mari. Aplicatia se deschide facand dublu clic pe icon-ul intitulat „Proiect”. Se va deschide aplicatia noastra, care arata cam asa:

-

Se observa ca avem deja disponibile o serie de informatii, cum ar fi : gradul de utilizare al memoriei ram; gradul de utilizare al procesorului; tipul de procesor , frecventa, numarul de procesoare, etc. In continuare, in functie de ce operatie dorim sa facem, avem la dispozitie 3 butoane: Show Process CPU Show Handles and Classes Show Process Details

1) Daca facem click pe butonul Show Process CPU, se va deschide o a doua fereastra cu lista proceselor care ruleaza si procentul din CPU pe care il utilizeaza:

2) Daca apasam butonul Show Handles and Classes , se va deschide o noua fereastra in care sunt afisate handle-urile si clasele; totodata avem un meniu contextual care ne permite controlul handle-urilor: daca facem click dreapta pe oricare din handle-urile afisate, vom avea optiunile Show Window using ShowWindowAPI, Show Window using BringWindowToTop API, Maximize, Minimize, Restore, Hide, Close this window ce ne permit sa gestionam handle-urile.

-

3) Daca apasam butonul Show Process Details

4. Testare La finalizarea aplicaţiei, după ce s-au aplicat ultimele optimizari se impune intrarea în testare, procedură ce se ocupă cu testarea aplicaţiei în condiţii de maxime de exploatare. În cazul în care aplicaţia iese din parametri în timpul testării, se identifică problemele şi se revine în etapa de implentare, urmând ca procedura de testare să fie repetată integral după remedierea posibilelor probleme. Testarea se concentrează atât asupra logicii interne a programului, avându-se în vedere ca anumite elemente ale acestuia să fie parcurse, cât şi pe funcţionalitatea externă a sa, pe baza specificaţiilor. Se compară rezultatele efective obţinute după rularea programului cu seturi de date de test cu rezultatele scontate pe baza specificaţiilor. Intalnim mai multe metode de testare: - testarea funcţională (metoda cutiei negre): se aşteaptă să se confirme că fiecare funcţie este pe deplin realizată. Testele sunt elaborate pe baza specificaţiilor programului. Acesta este văzut ca o cutie neagră, a cărei comportare este determinată prin preluarea unor date de intrare - testarea structurală (metoda cutiei transparente): eşantioanele sunt astfel concepute incit să asigure testarea convingătoare a tuturor părţilor programului.

In cazul descoperirii unei erori este necesară o intoarcere la unul din paşii anteriori ai dezvoltarii proiectului.