Ca oricare dispozitiv tehnic, un computer face schimb de informații cu o persoană printr-un set de reguli specifice care sunt obligatorii atât pentru mașină, cât și pentru persoană. Aceste reguli sunt numite interfață în literatura de specialitate. Interfața poate fi de înțeles sau de neînțeles, prietenoasă sau nu. I se aplică multe adjective. Dar un lucru este constant: există și nu poți scăpa de el.
Interfață- acestea sunt regulile de interacțiune între sistemul de operare și utilizatori, precum și nivelurile învecinate din rețeaua de calculatoare. Tehnologia comunicării om-calculator depinde de interfață.
Interfață- Acesta este, în primul rând, un set de reguli. Ca orice reguli, acestea pot fi generalizate, colectate într-un „cod”, grupate după trasatura comuna. Astfel, am ajuns la conceptul de „tip de interfață” ca o combinație de moduri similare de interacțiune între oameni și computere. Putem propune următoarea clasificare schematică a diferitelor interfețe de comunicație om-calculator (Fig. 1.).
Tehnologia lotului. Din punct de vedere istoric, acest tip de tehnologie a apărut prima. A existat deja pe mașinile releu ale lui Sues și Zuse (Germania, 1937). Ideea sa este simplă: la intrarea calculatorului este furnizată o succesiune de simboluri, în care, după anumite reguli, este indicată succesiunea programelor lansate pentru execuție. După ce următorul program este executat, următorul este lansat și așa mai departe. Mașina, conform anumitor reguli, găsește comenzi și date pentru ea însăși. Această secvență poate fi, de exemplu, o bandă de hârtie perforată, un teanc de cărți perforate sau o secvență de apăsare a tastelor unei mașini de scris electrice (tip CONSUL). De asemenea, aparatul își trimite mesajele către un perforator, o unitate de imprimare alfanumerică (ADP) sau o bandă de mașină de scris.
O astfel de mașină este o „cutie neagră” (mai precis, un „dulap alb”), în care informațiile sunt furnizate în mod constant și care, de asemenea, „informează” în mod constant lumea despre starea sa. O persoană de aici are o influență redusă asupra funcționării mașinii - poate doar să întrerupă funcționarea mașinii, să schimbe programul și să pornească din nou computerul. Ulterior, când mașinile au devenit mai puternice și au putut deservi mai mulți utilizatori simultan, utilizatorii au așteptat pentru totdeauna ca: "Am trimis date către mașină. Aștept să răspundă. Și va răspunde deloc?" - a devenit, ca să spunem ușor, plictisitor. În plus, centrele de calculatoare, după ziare, au devenit al doilea „producător” major de deșeuri de hârtie. Prin urmare, odată cu apariția afișajelor alfanumerice, a început era tehnologiei cu adevărat ușor de utilizat - linia de comandă.
Interfață de comandă.
Interfața de comandă se numește așa deoarece în acest tip de interfață o persoană dă „comenzi” computerului, iar computerul le execută și dă rezultatul persoanei. Interfața de comandă este implementată sub formă de tehnologie batch și tehnologie de linie de comandă.
Cu această tehnologie, o tastatură este singura modalitate de a introduce informații de la o persoană pe un computer, iar computerul afișează informații persoanei folosind un afișaj alfanumeric (monitor). Această combinație (monitor + tastatură) a ajuns să fie numită terminal, sau consolă.
Comenzile sunt tastate pe linia de comandă. Linia de comandă este un simbol prompt și un dreptunghi care clipește - un cursor. Când apăsați o tastă, simbolurile apar în locația cursorului, iar cursorul însuși se deplasează la dreapta. Comanda se încheie prin apăsarea tastei Enter (sau Return), care apoi trece la începutul următoarei rânduri. Din această poziție computerul afișează rezultatele muncii sale pe monitor. Apoi procesul se repetă.
Tehnologia liniei de comandă a funcționat deja pe afișajele alfanumerice monocrome. Întrucât a fost posibil să se introducă doar litere, cifre și semne de punctuație, caracteristicile tehnice ale afișajului nu au fost semnificative. Un receptor de televiziune și chiar un tub de osciloscop ar putea fi folosite ca monitor.
Ambele tehnologii sunt implementate sub forma unei interfețe de comandă - comenzile sunt date mașinii ca intrare și aceasta, așa cum ar fi, „răspunde” la ele.
Fișierele text au devenit tipul predominant de fișiere atunci când lucrați cu interfața de comandă - ele și numai ele puteau fi create folosind tastatura. Perioada în care interfața de linie de comandă a fost cea mai utilizată a fost apariția sistemului de operare UNIX și apariția primelor computere personale pe opt biți cu sistemul de operare multiplatformă CP/M.
Interfață WIMP(Fereastră - fereastră, Imagine - imagine, Meniu - meniu, Pointer - pointer). O trăsătură caracteristică a acestui tip de interfață este că dialogul cu utilizatorul se realizează nu folosind comenzi, ci folosind imagini grafice - meniuri, ferestre și alte elemente. Deși comenzile sunt date mașinii în această interfață, aceasta se face „indirect”, prin imagini grafice. Ideea unei interfețe grafice a apărut la mijlocul anilor 70, când centru de cercetare Centrul de Cercetare Xerox Palo Alto (PARC) a dezvoltat conceptul de interfață vizuală. Condiția prealabilă pentru interfața grafică a fost reducerea timpului de reacție a computerului la o comandă, creșterea cantității de memorie RAM, precum și dezvoltarea bazei tehnice a computerelor. Baza hardware a conceptului, desigur, a fost apariția afișajelor alfanumerice pe computere, iar aceste afișaje aveau deja efecte precum „pâlpâirea” caracterelor, inversarea culorii (schimbarea conturului caracterelor albe pe fundal negru spre invers, adică caractere negre pe fundal alb ), caractere subliniate. Aceste efecte nu s-au extins la întregul ecran, ci doar la unul sau mai multe personaje. Următorul pas a fost crearea unui display color care să permită afișarea, împreună cu aceste efecte, a caracterelor în 16 culori pe un fundal cu o paletă (adică un set de culori) de 8 culori. După apariția afișajelor grafice, cu posibilitatea de a afișa orice imagini grafice sub formă de multe puncte pe un ecran de culori diferite, nu au existat limite ale imaginației în utilizarea ecranului! Primul sistem cu interfață grafică, 8010 Star Information System al grupului PARC, a apărut astfel cu patru luni înainte de lansarea primului computer IBM în 1981. Inițial, interfața vizuală a fost folosită doar în programe. Treptat, a început să treacă la sisteme de operare, utilizate mai întâi pe computerele Atari și Apple Macintosh, iar apoi pe computerele compatibile IBM.
Dintr-o vreme mai devreme, și influențat și de aceste concepte, a existat un proces de unificare a utilizării tastaturii și mouse-ului de către programele de aplicație. Fuziunea acestor două tendințe a condus la crearea unei interfețe cu utilizatorul cu care, cu timp și bani cheltuiți minim pentru recalificarea personalului, puteți lucra cu orice produs software. Această parte este dedicată unei descrieri a acestei interfețe, comună tuturor aplicațiilor și sistemelor de operare.
Interfața grafică cu utilizatorul a trecut prin două etape în timpul dezvoltării sale și este implementată la două niveluri de tehnologie: o interfață grafică simplă și o interfață WIMP „pură”.
În prima fază, GUI-ul a fost foarte asemănător cu tehnologia liniei de comandă. Diferențele față de tehnologia liniei de comandă au fost următoarele:
Ú La afișarea caracterelor, era permisă evidențierea unor caractere cu culoare, imagine inversă, subliniere și pâlpâire. Datorită acestui fapt, expresivitatea imaginii a crescut.
Ú În funcție de implementarea specifică a interfeței grafice, cursorul poate apărea nu numai ca un dreptunghi pâlpâit, ci și ca o zonă care acoperă mai multe caractere și chiar o parte a ecranului. Această zonă selectată diferă de alte părți neselectate (de obicei după culoare).
Ú Apăsarea tastei Enter nu execută întotdeauna comanda și trece la linia următoare. Reacția la apăsarea oricărei taste depinde în mare măsură de locul în care se afla cursorul pe ecran.
Ú Pe lângă tasta Enter, tastele de control „gri” ale cursorului au devenit din ce în ce mai folosite pe tastatură (a se vedea secțiunea despre tastatură din numărul 3 al acestei serii.)
Ú Deja în această ediție a interfeței grafice au început să fie utilizate manipulatoare (cum ar fi mouse, trackball etc. - vezi Figura A.4.) Acestea au făcut posibilă selectarea rapidă a părții dorite a ecranului și mutarea cursorului .
Pentru a rezuma, putem cita următoarele caracteristici distinctive ale acestei interfețe:
Ú Selectarea zonelor ecranului.
Ú Redefiniți tastele de la tastatură în funcție de context.
Ú Utilizarea manipulatoarelor și a tastelor gri de la tastatură pentru a controla cursorul.
Ú Utilizarea pe scară largă a monitoarelor color.
Apariția acestui tip de interfață coincide cu utilizarea pe scară largă a operațiunii sisteme MS-DOS. Ea a fost cea care a introdus această interfață în masă, datorită căreia anii 80 au fost marcați de îmbunătățirea acestui tip de interfață, îmbunătățirea caracteristicilor de afișare a caracterelor și a altor parametri ai monitorului.
Un exemplu tipic de utilizare a acestui tip de interfață este shell-ul de fișiere Nortron Commander și editorul de text Multi-Edit. Și editori de text Lexicon, ChiWriter și procesor de text Microsoft Word pentru Dos este un exemplu al modului în care această interfață s-a autodepășit.
A doua etapă în dezvoltarea interfeței grafice a fost interfața „pură” WIMP. Acest subtip de interfață se caracterizează prin următoarele caracteristici:
Ú Toate lucrările cu programe, fișiere și documente au loc în Windows - anumite părți ale ecranului conturate de un cadru.
Ú Toate programele, fișierele, documentele, dispozitivele și alte obiecte sunt prezentate sub formă de pictograme. Când sunt deschise, pictogramele se transformă în ferestre.
Ú Toate acțiunile cu obiecte sunt efectuate folosind meniul. Deși meniul a apărut în prima etapă a dezvoltării interfeței grafice, nu a avut un rol dominant în el, ci a servit doar ca o completare la linia de comandă. Într-o interfață WIMP pură, meniul devine elementul principal de control.
Ú Utilizarea pe scară largă a manipulatoarelor pentru a indica obiecte. Dispozitivul de indicare încetează să mai fie doar o jucărie - un plus la tastatură, dar devine principalul element de control. Folosind un manipulator, ei indică orice zonă a ecranului, ferestrei sau pictogramei, o selectează și abia apoi le controlează prin meniu sau folosind alte tehnologii.
Trebuie remarcat faptul că WIMP necesită un afișaj color raster cu Rezoluție înaltăși un manipulator. De asemenea, programele orientate către acest tip de interfață impun cerințe sporite asupra performanței computerului, capacitatea de memorie a acestuia, lățimea de bandă a magistralei etc. Cu toate acestea, acest tip de interfață este cel mai ușor de învățat și intuitiv. Prin urmare, acum interfața WIMP a devenit un standard de facto.
Un exemplu izbitor de programe GUI este sistem de operare Microsoft Windows.
MĂTASE- interfata (Vorbire - vorbire, Imagine - imagine, Limba - limbaj, Cunoastere - cunoastere). Acest tip de interfață este cel mai apropiat de forma obișnuită, umană de comunicare. În cadrul acestei interfețe există o „conversație” normală între o persoană și un computer. În același timp, computerul găsește comenzi pentru el însuși analizând vorbirea umană și găsind fraze cheie în ea. De asemenea, convertește rezultatul execuției comenzii într-o formă care poate fi citită de om. Acest tip de interfață este cel mai solicitant în ceea ce privește resursele hardware ale computerului și, prin urmare, este utilizat în principal în scopuri militare.
De la mijlocul anilor 90, după apariția plăcilor de sunet ieftine și utilizarea pe scară largă a tehnologiilor de recunoaștere a vorbirii, a apărut așa-numita interfață SILK „tehnologia vorbirii”. Cu această tehnologie, comenzile sunt date prin voce prin pronunțarea unor cuvinte speciale rezervate - comenzi.
Cuvintele trebuie pronunțate clar, în același ritm. Este necesară o pauză între cuvinte. Datorită subdezvoltării algoritmului de recunoaștere a vorbirii, astfel de sisteme necesită individualitate presetat pentru fiecare utilizator specific.
Tehnologia „Speech” este cea mai simplă implementare a interfeței SILK.
Tehnologia biometrică („Interfață imitativă”)
Această tehnologie a apărut la sfârșitul anilor 90 ai secolului al XX-lea și este încă în curs de dezvoltare la momentul scrierii. Pentru a controla computerul, se folosesc expresia facială a unei persoane, direcția privirii sale, dimensiunea pupilei și alte semne. Pentru a identifica utilizatorul, se utilizează un model al irisului ochilor săi, amprentele digitale și alte informații unice. Imaginile sunt citite de pe o cameră video digitală, iar apoi comenzile sunt extrase din această imagine folosind programe speciale de recunoaștere a modelelor. Este posibil ca această tehnologie să-și ia locul în produse softwareși aplicații în care este important să se identifice cu exactitate utilizatorul computerului.
De fiecare dată când porniți computerul, aveți de-a face cu interfața cu utilizatorul(User Interface, UI), care pare simplu și evident, dar industria a depus multă muncă pentru a face acest lucru. Să ne uităm înapoi la anii 1990, când computere desktop au devenit omniprezente și iată o cronologie a dezvoltării tehnologiilor UI. Să ne uităm, de asemenea, la modul în care instrumentele de programare UI au evoluat și ce sunt acestea astăzi. În tabel 1 prezintă o listă a principalelor sarcini ale dezvoltării UI, pe baza cărora a fost efectuată analiza diferitelor tehnologii de implementare a interfețelor utilizator, împărțite pe categorii. Fiecare dintre aceste categorii include tehnologii care rezolvă una sau mai multe probleme în aproximativ același mod.
Formulare de intrare legate de SGBD
Una dintre principalele categorii de instrumente de dezvoltare a UI constă în instrumente axate pe formulare de introducere a datelor legate de SGBD-urile relaționale. Esența acestei abordări este crearea unei interfețe de utilizare pentru aplicații prin construirea de formulare care afișează valorile câmpurilor bazei de date în controalele corespunzătoare: câmpuri de text, liste, casete de selectare, tabele etc. Setul de instrumente vă permite să navigați printr-un astfel de formular și să stabilească o legătură directă între managementul elementelor și datele din baza de date. Dezvoltatorul nu trebuie să-și facă griji cu privire la blocarea, transferul, transformarea și actualizarea datelor - atunci când utilizatorul, de exemplu, schimbă numărul de înregistrare într-un formular, câmpurile rămase sunt actualizate automat. În mod similar, dacă utilizatorul modifică valoarea într-un câmp asociat cu orice înregistrare din baza de date, această modificare este salvată instantaneu în acesta. Pentru a realiza acest lucru, nu trebuie să scrieți niciun cod special - doar declarați legarea unui control sau a unui întreg formular la o sursă de date. Astfel, suportul pentru legarea datelor în instrumentele din această categorie este unul dintre punctele forte ale acestei metode. Sarcinile de aspect și stil al interfeței de utilizare în astfel de medii sunt rezolvate cu ajutorul designerilor de formulare și API-urilor specializate orientate pe obiecte. Managerii de evenimente (care sunt metode implementate în limbajul de programare gazdă al mediului de dezvoltare) sunt furnizați de obicei pentru a controla comportamentul interfeței de utilizare, în timp ce expresiile (inclusiv expresiile regulate) sunt folosite pentru a controla valorile de intrare. Reprezentanții tipici ai acestei mari categorii de instrumente sunt Microsoft Access și Oracle Forms.
Manipulatorii de șabloane
Tehnologiile pentru construirea de interfețe cu utilizatorul bazate pe șabloane implementate în limbaje de marcare au fost utilizate pe scară largă încă de la mijlocul anilor 1990. Principalele beneficii ale șabloanelor sunt flexibilitatea și amploarea posibilităților de creare a interfețelor web dinamice, în special în ceea ce privește proiectarea structurii și aspectului. Inițial, aceste instrumente foloseau șabloane în care aspectul și structura interfeței de utilizator erau specificate folosind un limbaj de marcare, iar legarea datelor a fost realizată folosind blocuri mici dintr-un limbaj de nivel înalt (Java, C#, PHP, Python etc.). Acesta din urmă ar putea fi utilizat în combinație cu marcajele; de exemplu, prin încorporarea etichetelor de marcare într-o buclă Java, ar putea fi create elemente vizuale iterative precum tabele și liste. Necesitatea de a schimba frecvent sintaxa într-o pagină web a făcut dificilă dezvoltarea și corectarea codului pentru programatori, așa că în urmă cu aproximativ zece ani a început tranziția de la limbaje de nivel înalt la biblioteci specializate de etichete de marcare și limbaje de expresie create pentru web specific. tehnologii.
Etichetele de marcare au început să fie folosite pentru a implementa funcții tipice ale aplicațiilor web, iar expresiile au fost folosite pentru a accesa date și a apela funcții stocate în obiectele serverului. Reprezentant tipic Acest grup este tehnologia JavaServer Pages (JSP), a cărei bibliotecă de etichete, JSP Standard Tag Library, acceptă sarcini precum: manipularea documentelor XML, bucle, condiții, interogare DBMS (legare de date) și internaționalizare (formatarea datelor). Limbajul de expresie JSP-EL, care servește ca instrument de legare a datelor, oferă o notație convenabilă pentru lucrul cu obiectele și proprietățile aplicației.
Există o serie de instrumente de dezvoltare web asemănătoare cu JSP: pentru planificarea și definirea structurii (utiliză șabloane), pentru legarea datelor folosind un limbaj de expresie, iar comportamentul UI este specificat utilizând handlere de evenimente implementate folosind limbajul ECMAScript și interfața de programare Document Object. Model. Formatarea datelor este efectuată folosind biblioteci de etichete specializate; CSS (Cascading Style Sheets) este de obicei folosit pentru a stila aspectul. Reprezentanți populari ai acestei categorii de instrumente: ASP, PHP, Struts, WebWork, Struts2, Spring MVC, Spyce și Ruby on Rails.
Instrumente orientate pe obiecte și bazate pe evenimente
O proporție semnificativă de instrumente pentru crearea UI se bazează pe un model orientat pe obiecte. Aceste instrumente oferă în mod obișnuit o bibliotecă de elemente UI pre-construite, iar principalele lor avantaje sunt ușurința de a construi blocuri reutilizabile din componente simple și un proces intuitiv și flexibil pentru programarea comportamentului și a interacțiunii bazate pe handlere de evenimente. În aceste instrumente, toate sarcinile de dezvoltare a interfeței de utilizare sunt rezolvate folosind API-uri de obiecte specializate. Această categorie include medii: Visual Basic, MFC, AWT, Swing, SWT, Delphi, Google Web Toolkit, Cocoa Touch UIKit, Vaadin, etc. Acesta include și setul de instrumente Nokia Qt, care oferă o serie de concepte originale. În unele seturi de instrumente, toată complexitatea interacțiunii dintre elementele structurii UI este implementată folosind handlere de evenimente, iar în Qt pe lângă acestea există „semnale” și „slot”: un semnal este trimis de componenta UI ori de câte ori are loc un eveniment . eveniment specific. Un slot este o metodă numită ca răspuns la un semnal specific care poate fi asociat declarativ cu orice număr de sloturi și, invers, un slot poate primi atâtea semnale câte se dorește. Elementul care transmite semnalul „nu știe” care slot îl va primi. Astfel, elementele UI sunt slab cuplate prin conexiuni semnal la slot. Acest mecanism promovează utilizarea principiului încapsulării și oferă capacitatea de a defini declarativ comportamentul UI.
Hibrizi
Tehnologiile hibride sunt relativ noi în lumea dezvoltării UI de uz general - împreună cu șabloanele și limbajele de expresie, astfel de seturi de instrumente folosesc un API obiect. Un reprezentant tipic este JavaServer Faces: bibliotecile de etichete servesc pentru a descrie structura și aspectul, precum și pentru formatarea datelor; limbaj de expresie - pentru legarea elementelor și evenimentelor la obiectele serverului și codul aplicației; obiect API - pentru afișarea elementelor, gestionarea stării acestora, gestionarea evenimentelor și controlul intrărilor. Alte instrumente populare din această categorie sunt ASP.NET MVC, Apache Wicket, Apache Tapestry, Apache Click și ZK Framework.
Adobe Flex este similar din punct de vedere conceptual cu tehnologiile din această categorie, deoarece utilizează șabloane pentru structură și aspect, iar programarea se face în întregime în ActionScript. La fel ca Qt, Flex oferă un mecanism pentru rezolvarea problemelor legate de comportamentul de programare și legarea datelor.
Truse de instrumente declarative
Astfel de instrumente - cea mai nouă direcțieîn domeniul instrumentelor de dezvoltare a UI. Ei folosesc limbaje bazate pe XML și JSON (JavaScript Object Notation) pentru a specifica structura interfeței cu utilizatorul și folosesc în primul rând notația declarativă pentru alte sarcini de proiectare a UI. Spre deosebire de abordările hibride, concepute în principal pentru interfețe web, cele declarative sunt folosite și în dezvoltarea de aplicații native pentru platforme mobile și desktop.
API-ul interfeței cu utilizatorul Android este bazat pe evenimente, orientat pe obiecte, dar împreună cu cel principal, sistemul de operare are un API auxiliar bazat pe XML, care vă permite să declarați structura și aspectul interfeței cu utilizatorul, precum și să-i stilați elemente și gestionați proprietățile acestora. O descriere declarativă a interfeței arată mai clar structura acesteia și ajută la depanare; vă permite să schimbați aspectul fără recompilare; ajută la adaptarea la diferite platforme, dimensiuni ale ecranului și raporturi de aspect. Când creați interfețe de utilizator mai dinamice, puteți specifica și modifica structura elementelor în mod programatic utilizând API-uri obiect, dar legarea de date nu este acceptată. Există, totuși, Android-Binding - o soluție open source terță parte care vă permite să legați elementele UI la modelele de date.
Puteți crea UI pentru programe Windows și aplicații Internet bogate funcțional bazate, respectiv, pe tehnologiile Windows Platform Foundation și Microsoft Silverlight, folosind un alt dicționar XML - eXtensible Application Markup Language (XAML). Vă permite să definiți structura, aspectul și stilul interfeței de utilizare și, spre deosebire de limbajul de marcare Android, acceptă legarea datelor și capacitatea de a gestiona evenimente.
Nokia recomandă dezvoltatorilor Qt Quick, un set de instrumente multiplatformă pentru desktop, mobile și sisteme de operare încorporate care acceptă QML (un limbaj de scripting declarativ bazat pe sintaxa JSON). Descrierea interfeței cu utilizatorul are o structură ierarhică, iar comportamentul este programat în ECMAScript. Aici, ca și în Qt obișnuit, mecanismul semnal-slot este suportat. Qt Quick acceptă capacitatea de a lega proprietățile elementelor UI la un model de date, precum și conceptul de mașină de stări, care vă permite să modelați grafic comportamentul interfeței.
Un alt exemplu este Enyo, un set de instrumente multiplatformă pentru crearea interfeței de utilizare în ECMAScript, în care structura interfeței este specificată declarativ, iar comportamentul este controlat de handlere de evenimente. Evenimentele sunt procesate în trei moduri: la nivelul componentelor individuale ale interfeței de utilizator, prin transmitere de la copil la părinte fără obligație directă și, de asemenea, prin difuzarea și abonarea la astfel de mesaje (de asemenea, fără legare directă). Cuplarea liberă a elementelor UI îmbunătățește capacitatea de a reutiliza și de a încapsula porțiuni mari ale interfeței. În esență, principalul punct forte al Enyo este modelul său de încapsulare, datorită căruia UI poate fi compusă din blocuri de construcție reutilizabile, autonome, cu interfețe definite. Acest model promovează abstractizarea și acoperă toate nivelurile arhitecturale ale UI. Proiectul Enyo lucrează la implementarea suportului pentru legarea datelor.
Setul de instrumente Eclipse XML Window este un alt set de instrumente care se concentrează pe descrierile declarative ale UI. Scopul inițial al creării sale a fost de a combina toate instrumentele de dezvoltare a UI în Eclipse, inclusiv SWT, JFace, Eclipse Forms și altele - toate elementele lor au cumva corespondență în XWT. Structura și aspectul interfeței de utilizare în XWT sunt specificate folosind un limbaj bazat pe XML, iar pentru legarea datelor (accesul la obiectele Java ale aplicației) este folosit un limbaj de expresie. Gestionarea evenimentelor este programată în Java, iar CSS este folosit pentru stilarea elementelor de interfață. Motorul de execuție a aplicației XWT este implementat ca un applet Java și un element ActiveX, ceea ce înseamnă că poate rula în aproape orice browser.
Există multe instrumente similare în această categorie: în AmpleSDK, de exemplu, XUL este folosit ca limbaj de descriere a UI, funcțiile ECMAScript sunt folosite pentru programarea comportamentului dinamic, CSS este folosit pentru stil. Setul de instrumente Dojo definește interfața în mod declarativ și oferă o gamă largă de elemente pre-construite, stocare de obiecte pentru accesul la date și un handler de evenimente bazat pe ECMAScript cu un mecanism de publicare-abonare. Setul de instrumente acceptă internaționalizarea, un API bogat pentru interogarea datelor, modularizarea și moștenirea mai multor clase.
Truse de instrumente bazate pe modele
O parte semnificativă a tehnologiilor de dezvoltare a UI se bazează pe modele și limbaje specifice domeniului. Acestea sunt în principal modele de interfață, dar pot fi utilizate și modele de domenii. În ambele cazuri, modelul este necesar pentru a genera interfața cu utilizatorul în prealabil sau este interpretat în timpul execuției. Această clasă de tehnologii ridică nivelul de abstractizare, oferă metode sistematice îmbunătățite pentru proiectarea și implementarea interfețelor utilizator și oferă o infrastructură pentru automatizarea sarcinilor conexe. Cu toate acestea, potrivit unor cercetători, tehnologiile bazate pe modele nu oferă o modalitate universală de integrare a interfeței cu utilizatorul cu aplicația și încă nu există un acord asupra setului de modele optim pentru descrierea UI. Problema legării datelor nu a fost rezolvată, iar modelele nu au fost combinate pentru a rezolva alte probleme de dezvoltare a UI.
Analizând generații de abordări bazate pe modele pentru dezvoltarea interfeței de utilizare începând cu anii 1990, putem ajunge la concluzia că astăzi există o înțelegere general acceptată a nivelurilor de abstractizare și a tipurilor de modele potrivite pentru dezvoltarea interfețelor moderne cu utilizatorul, dar încă nu există un consens. (standarde) privind informațiile (semantice) care ar trebui să fie conținute diverse modele. Modelele de sarcini, dialogurile și prezentările pot fi considerate de bază: modelul de prezentare rezolvă problemele de structurare, planificare și stilizare; modelul de sarcină este responsabil pentru legarea la date - pentru fiecare sarcină sunt indicate interfața de utilizare și obiectele logice cu care să lucreze; modelul dialogului acoperă aspecte comportamentale. Un exemplu de model de sarcină este Concurrent-TaskTrees (CTT), care poate fi utilizat împreună cu limbajul MARIA, care implementează modelele UI rămase. CTT combinat cu MARIA oferă un set complet de instrumente bazat pe modele. O familie destul de mare de instrumente de modelare a interfeței de utilizare se bazează, de asemenea, pe UML, modele de relații entitate sau altele similare. Profilurile UML sunt utilizate pe scară largă în construirea de interfețe de utilizator pentru aplicații de afaceri. Există și alte instrumente care sunt utilizate în mod activ - de exemplu, WebRatio, UMLi, Intellium Virtual Enterprise și SOLoist.
Interfețe de utilizator generice
Un subset mic, dar semnificativ de tehnologii de interfață cu utilizatorul generează interfețe de utilizare bazate pe utilizator, date, sarcini sau alte tipuri de modele de aplicații. Interfața este generată pe baza modelului în întregime sau semi-automat. Modelele pot fi interpretate și în timpul execuției fără a fi folosite ca bază pentru generarea interfeței. În orice caz, datorită nivelului ridicat de automatizare a construcției UI, tehnologiile din această categorie economisesc timp dezvoltatorului și reduc numărul de erori, iar interfețele generate au o structură uniformă. Cu toate acestea, interfețele de utilizator generice nu sunt flexibile, au funcționalități limitate și un proces de generare imprevizibil. Cu toate acestea, cu o conexiune directă la modelul de domeniu, dezvoltarea aplicațiilor cu interfețe de utilizare generice este destul de posibilă. Există aproximativ o duzină de exemple în această categorie, conduse de modelul arhitectural folosit pe scară largă Naked Objects. Generarea automată a interfeței de utilizare poate fi utilizată cu succes în anumite domenii - de exemplu, în proiectarea casetelor de dialog și a interfețelor de utilizator pentru controlul de la distanță al sistemelor. Dezvoltare în continuare Cercetătorii văd această clasă de tehnologie în îmbunătățirea tehnicilor de modelare și în găsirea de noi modalități de a combina modele pentru a îmbunătăți confortul UI generat.
Tendințe și provocări
Figura prezintă cronologia apariției diverselor instrumente de dezvoltare a interfeței de utilizare, distribuția acestora pe categorii și domenii principale de aplicare și în tabel. Tabelul 2 arată modalitățile în care fiecare tehnologie rezolvă diverse probleme de dezvoltare a UI.
Dezvoltarea web în scopul dezvoltării tehnologiilor utilizate în mod obișnuit este caracterizată de două tendințe opuse. După tehnologiile bazate pe șabloane, au apărut seturile de instrumente cu API-uri orientate pe obiecte, care au fost de cele mai multe ori completate cu șabloane (în cazul abordărilor hibride) sau le-au înlocuit complet (GWT și Vaadin). În principiu, acest lucru este destul de logic, având în vedere superioritatea generală a limbajelor orientate pe obiecte față de limbajele șablon (moștenire, polimorfism, încapsulare, parametrizare, reutilizare etc.), necesitatea unor concepte și mecanisme mature pentru alcătuirea unei interfețe de utilizare extinse. structurile și „succesul istoric” al API-urilor orientate pe obiecte în era desktopului.
Este de remarcat faptul că, în comparație cu metodele imperative și orientate pe obiecte de formare a interfeței de utilizare, cele declarative au devenit mai utilizate astăzi - de exemplu, HTML, XML, XPath, CSS, JSON și notații similare devin frecvent utilizate. Majoritatea structurii UI este de obicei statică, astfel încât notațiile declarative fac o treabă grozavă de structurare, aspect și legare de date. Dar aspectele comportamentale ale interfeței de utilizator sunt încă implementate folosind paradigma clasică bazată pe evenimente, deși există excepții când sunt utilizate mijloace declarative.
O tendință vizibilă în dezvoltarea UI este concentrarea pe tehnologiile și platformele standard. XML și ECMAScript sunt mai populare astăzi ca niciodată, deși tehnologiile specializate, în special tehnologiile bazate pe modele, luptă activ pentru spațiu de locuit cu standarde tehnice mari.
Putem numi câteva probleme care așteaptă să fie rezolvate de furnizorii de instrumente de dezvoltare și cele necesare pentru a specifica arhitecturi multi-nivel. Interfețele de utilizator pentru aplicațiile de afaceri la scară largă constau adesea din sute de pagini sau mai multe, iar în astfel de cazuri este absolut necesară o imagine de ansamblu clară a arhitecturii sistemului. Există o nouă tehnică de modelare care rezolvă această problemă prin introducerea conceptului de capsulă, care asigură încapsularea strictă a fragmentelor de UI și vă permite să specificați arhitectura cu la diferite niveluri detalierea. Capsula are deja structura interna, care poate fi aplicat în mod constant recursiv la toate nivelurile inferioare ale componentelor UI. Dezvoltatorii Enyo și WebML încearcă să rezolve o problemă similară.
Flexibilitatea, extensibilitatea și amploarea suportului pentru instrumente sunt avantaje reale ale tehnologiilor obișnuite de dezvoltare a interfeței de utilizare, dar încă suferă de nivel scăzut abstracție și lipsă de expresivitate. Pe de altă parte, abordările bazate pe model ar trebui să evite moștenirea semanticii de la modelele UI de nivel scăzut, altfel modelele abstracte UI pot deveni la fel de complexe ca implementarea UI în sine. În loc să folosească cunoștințele domeniului UI și semantica modelului de aplicație, designerii UI trebuie să lucreze direct cu componente de nivel scăzut: casete de dialog, meniuri și handlere de evenimente.
Tehnologiile de dezvoltare a UI au o altă problemă serioasă asociată cu cerințele de adaptare pentru multe platforme țintă, caracteristică tuturor aplicațiilor interactive moderne. Din fericire, comunitatea orientată spre model a răspuns la timp - în 2003, a propus o arhitectură universală unificatoare pentru procesele, modelele și metodele utilizate în construirea de interfețe de utilizare multiplatformă.
Diversitatea actuală a dispozitivelor și platformelor de calcul amintește oarecum de era PC-urilor desktop de la sfârșitul anilor 90, cu abundența sa de instrumente oferite de diferiți furnizori pentru construirea de interfețe cu utilizatorul. Astăzi, HTML5 nu a rezolvat încă problema inconsistenței tehnologice din cauza suportului limitat pentru funcțiile hardware și interfețele de programare. În cele din urmă, așa cum este cazul multor probleme de inginerie software, dezvoltarea UI de astăzi necesită soluții care sunt clare și simple, dar necesită un efort incredibil din partea creatorilor lor pentru a le implementa.
Literatură
- P.P. Da Silva. Modele declarative de interfață cu utilizatorul și medii de dezvoltare: un sondaj. Proc. Interactive Systems: Design, Specification, and Verification, Springer, 2000, pp. 207-226.
- G. Meixner, F. Paterno, J. Vanderdonckt. Trecutul, prezentul și viitorul dezvoltării interfeței utilizator bazate pe modele // i-com. 2011. vol. 10, N3, R. 2-11.
- G. Mori, F. Paterno, C. Santoro. CTTE: Suport pentru dezvoltarea și analiza modelelor de sarcini pentru proiectarea sistemelor interactive // IEEE Trans. Software ing. 2002, voi. 28, N8, p. 797-813.
Zharko Mijajlovic([email protected]) - inginer senior, Dragan Milichev([email protected]) - Profesor asociat, Universitatea din Belgrad.
Zarko Mijailovic, Dragan Milicev, A Retrospective on User Interface Development Technology, IEEE Software, noiembrie/decembrie 2013, IEEE Computer Society. Toate drepturile rezervate. Retipărit cu permisiunea.
Kleshchev A.S., Gribova V.V. 25.03.2001
Interfața este importantă pentru orice sistem software și este componenta sa integrală, concentrată în primul rând pe utilizatorul final. Prin intermediul interfeței utilizatorul judecă programul aplicației ca întreg; Mai mult decât atât, utilizatorul ia adesea o decizie cu privire la utilizarea unui program de aplicație pe baza cât de convenabilă și de înțeleasă este pentru el interfața cu utilizatorul. În același timp, complexitatea proiectării și dezvoltării unei interfețe este destul de mare. Potrivit experților, în medie, acesta reprezintă mai mult de jumătate din timpul de implementare a proiectului. Este relevantă reducerea costurilor de dezvoltare și întreținere a sistemelor software sau de dezvoltare a instrumentelor software eficiente, unde eficiența este înțeleasă ca ușurință de dezvoltare, ușurință de întreținere și ușurință de utilizare a programului.
Una dintre modalitățile de reducere a costurilor de dezvoltare și întreținere a sistemelor software este disponibilitatea instrumentelor de generația a patra în setul de instrumente, care fac posibilă descrierea (specificarea) software-ului creat la un nivel înalt și apoi generarea automată a codului executabil conform la caietul de sarcini. Piața de software oferă o gamă largă de instrumente pentru dezvoltarea sa. Cu toate acestea, instrumentele disponibile sprijină dezvoltarea doar a unor componente ale interfeței cu utilizatorul folosind instrumente de generația a patra; restul componentelor sale sunt programate de dezvoltator, ceea ce crește semnificativ costurile, complexitatea dezvoltării și întreținerii.
Cercetările legate de dezvoltarea interfeței cu utilizatorul au început odată cu apariția operatorilor speciali I/O în limbaje de programare și au dus acum la apariția instrumentelor specializate pentru dezvoltarea interfeței.
Nu există o clasificare unică general acceptată a instrumentelor pentru dezvoltarea interfeței cu utilizatorul în literatură. Astfel, software-ul pentru dezvoltarea interfeței cu utilizatorul este împărțit în două grupe principale - instrumente pentru dezvoltarea interfeței cu utilizatorul (seturi de instrumente) și instrumente de dezvoltare a interfeței de nivel înalt (instrumente de dezvoltare de nivel superior). Instrumentele de dezvoltare a interfeței cu utilizatorul includ de obicei o bibliotecă de primitive ale componentelor de interfață (meniuri, butoane, bare de defilare etc.) și sunt destinate utilizării de către programatori. Instrumentele de proiectare a interfeței de nivel înalt pot fi utilizate de către non-programatori și sunt prevăzute cu un limbaj care permite specificarea funcțiilor de intrare/ieșire și definirea elementelor de interfață folosind tehnici de manipulare directă. Autorii includ constructori de dialog și UIMS (User Interface Management Systems - UIMS) ca astfel de instrumente. Pe lângă SUPI, unii autori folosesc termeni precum User Interface Development Systems (UIDS) - sisteme de dezvoltare a interfeței utilizator, User Interface Design Environment (UIDE) - mediu de dezvoltare a interfeței cu utilizatorul etc.
Instrumentele de dezvoltare a interfeței sunt împărțite în trei grupuri, care sunt definite după cum urmează. Primul grup include instrumente pentru a sprijini crearea unei interfețe prin scrierea codului - UIMS și Toolkits; în al doilea - instrumente interactive care vă permit să construiți o interfață din „spații” (butoane, meniuri, bare de defilare etc.) - Interface Builders; al treilea tip se bazează pe crearea unei interfețe prin legarea componentelor create separat - Arhitecturile componente.
După cum este menționat în terminologie această direcție nu a fost pe deplin format și este în prezent și subiect de cercetare. Cu toate acestea, în majoritatea lucrărilor, pentru a face referire la mijloace specializate Pentru a dezvolta o interfață, este dat termenul SUPI, care va fi folosit în această lucrare.
Instrumentele specializate de dezvoltare a interfeței simplifică dezvoltarea interfeței utilizator solicitând dezvoltatorului să specifice componentele interfeței cu utilizatorul folosind limbaje de specificații.
Există mai multe moduri principale de a specifica o interfață.
1. Limbaj, atunci când sunt folosite limbaje speciale pentru a specifica sintaxa interfeței (declarative, orientate pe obiecte, limbaje de evenimente etc.).
2. Specificația grafică se ocupă de definirea interfeței, de obicei prin instrumente de programare vizuală, demonstrații de programare și prin exemple. Această metodă acceptă o clasă limitată de interfețe.
3. Specificația interfeței, bazată pe o abordare orientată pe obiect, este asociată cu un principiu numit manipulare directă. Proprietatea sa principală este interacțiunea utilizatorului cu obiectele individuale și nu cu întregul sistem ca un întreg. Componentele tipice utilizate pentru manipularea obiectelor și a funcțiilor de control sunt manevrele, meniurile, zonele de dialog și butoanele de diferite tipuri.
4. Specificația interfeței conform specificației sarcinii aplicației. Aici interfața este creată automat conform specificațiilor semanticii sarcinii aplicației. Cu toate acestea, complexitatea descrierii interfeței face dificil ca sistemele care implementează această abordare să apară în curând.
Conceptul principal al UIMS este de a separa dezvoltarea interfeței cu utilizatorul de restul aplicației. În prezent, ideea de proiectare separată a interfeței și a aplicației este fie consacrată în definiția unui sistem de management al sistemului, fie este proprietatea sa principală.
Compoziția SUPI este definită ca un set de instrumente pentru etapa de dezvoltare și perioada de execuție. Instrumentele din stadiul de dezvoltare operează pe modele de interfață pentru a-și construi design-urile. Acestea pot fi împărțite în două grupuri: instrumente interactive, cum ar fi editorii de modele, și instrumente automate, cum ar fi un generator de formulare. Instrumentele de rulare folosesc un model de interfață pentru a sprijini activitățile utilizatorilor, cum ar fi colectarea și analiza datelor utilizate.
Funcțiile SUIS sunt de a facilita și de a facilita dezvoltarea și întreținerea interfeței cu utilizatorul, precum și de a gestiona interacțiunea dintre utilizator și programul de aplicație.
Comportamentul interfeței și al programului de aplicație este determinat de natura interacțiunii utilizatorului. Se pot distinge trei tipuri diferite de interacțiune: inițiativa dialogului aparține utilizatorului, programul de aplicație sau este mixtă.
Inițiativa de management al utilizatorilor. Acest tip de control înseamnă că interfața dă inițiativa utilizatorului (programul de aplicație este astfel proiectat) sau utilizatorul ia el însuși inițiativa, iar interfața acceptă această posibilitate (programul de aplicație este conceput astfel).
Inițiativa de gestionare a aplicațiilor. Acest tip de control înseamnă că, dacă programul de aplicație are nevoie de anumite informații, le solicită utilizatorului, utilizatorul este inclus în procesul de decizie atunci când este necesară introducerea datelor solicitate de sistem.
Inițiativă de management mixt. Acest tip de interacțiune combină cele două abordări anterioare, în care utilizatorul definește datele de intrare, dar dacă programul de aplicație are nevoie de date suplimentare pentru a o rezolva, le solicită utilizatorului.
Astfel, acum există un număr mare de instrumente de dezvoltare a interfeței care suportă diverse metode de implementare a acesteia. Cu toate acestea, nu există o clasificare unică general acceptată a instrumentelor propuse, ceea ce face dificilă compararea instrumentelor existente între ele și îngreunează selectarea unui anumit instrument de către utilizatori. Prin urmare, înainte de a începe să revizuim și să comparăm instrumentele, ar trebui să se răspundă la următoarele întrebări: instrumentele au instrumente de a patra generație pentru specificarea componentelor interfeței cu utilizatorul și cum susțin instrumentele de a patra generație dezvoltarea fiecărei componente a interfeței cu utilizatorul?
Importanța răspunsului la prima întrebare se datorează relevanței dezvoltării de instrumente care pot reduce costul dezvoltării și întreținerii aplicațiilor create cu ajutorul acestora. Soluția problemei este utilizarea limbajelor de generația a patra, care permit dezvoltatorului să specifice componentele software-ului la un nivel înalt și apoi să genereze automat codul executabil conform specificațiilor dezvoltatorului.
Pentru a răspunde la a doua întrebare, este necesar să se identifice componentele interfeței cu utilizatorul, adică acele aspecte prin care interfețele pot fi comparate între ele. Procedând astfel, vom adera la următoarele principii: 1) interfața cu utilizatorul trebuie să fie concentrată pe utilizatorul final și dezvoltată în conformitate cu cerințele acestuia; 2) interfața cu utilizatorul și programul de aplicație pentru care este destinată sunt dezvoltate separat.
Componentele unei interfețe cu utilizatorul sunt determinate de principiile evidențiate mai sus, precum și de funcțiile pe care le îndeplinește.
Prin definiție, de exemplu, în , o interfață de utilizator este menită să ofere interacțiune între un utilizator și un proces care îndeplinește o anumită sarcină - un program de aplicație. Obiectivele acestei interacțiuni sunt transferul de informații (date inițiale) de la utilizator la programul de aplicație, datele de ieșire (rezultatele programului) către utilizator. În conformitate cu funcția interfeței, este și o explicație a rezultatelor programului de aplicație, care până de curând era o trăsătură caracteristică doar interfețelor de sistem expert.
Orientarea către utilizatorul final înseamnă că interfața ar trebui să poată prezenta datele sursă și rezultatele într-o formă general acceptată într-un anumit domeniu, sau în funcție de categoriile de utilizatori și de dorințele acestora: grafică, tabelară, verbală și fiecare dintre ele. poate avea şi mai multe tipuri de reprezentări. Cu alte cuvinte, după cum s-a menționat în , pentru aceeași informație pot exista mesaje de transmitere diferite, formând o clasă de mesaje echivalente. În acest caz, există întotdeauna un sistem de mesaje de bază în care orice informație despre domeniul subiectului poate fi exprimată, înțeleasă și interpretată fără ambiguitate de către toți reprezentanții săi și la care se reduc toate mesajele utilizatorului. Un astfel de sistem de mesaje este un sistem de concepte de domeniu. În ceea ce privește un sistem de concepte, obiectele domeniului sunt denumite, se formulează afirmații că au anumite proprietăți și caracteristici care fac posibilă stabilirea asemănărilor și diferențelor obiectului în raport cu alte obiecte și, de asemenea, indică relațiile. în care obiectele sunt situate între ele. Astfel, o componentă a interfeței utilizator este descrierea informațiilor printr-un sistem de concepte de domeniu care definește funcția de interpretare a mesajelor.
După cum sa menționat mai sus, informațiile pentru utilizator pot fi prezentate sub formă de mesaje (verbale, grafice, tabelare), fiecare dintre ele putând primi diverse forme. Astfel, în interfață, mesajele care transmit aceleași informații utilizatorului și programului de aplicație sunt prezentate diferit: pentru utilizator, mesajele sunt formate într-o formă convenabilă pentru el sau acceptată în domeniul său de subiect; pentru programul de aplicație, mesajele sunt valorile variabilelor programului de aplicație. În mod evident, definirea unui set de variabile ale programului de aplicație se reduce la definirea numelor, a tipurilor și a modului de reprezentare a posibilelor lor valori.
Odată cu transmiterea mesajelor către utilizator în interfață, este necesar să se stabilească atribute care nu transmit informații, dar îi creează confort și comoditate; ele pot fi combinate sub termenul general design de interfață. Aceste atribute includ: locația mesajelor pe ecran, dimensiunea acestora, culoarea etc., precum și specificarea dispozitivelor fizice de intrare (tastatură, palete, intrare de vorbire, viziune computerizată etc.) și de ieșire (monitor, sunet, ieșire fotografică). și etc.). Astfel, o parte integrantă a interfeței cu utilizatorul, indisolubil legată de transmiterea mesajelor, este definirea formei mesajelor.
Interfața trebuie să convertească informațiile introduse de utilizator, prezentate sub formă de mesaje pe înțelesul lui, în valorile variabilelor programului de aplicație, precum și în valorile variabilelor programului de aplicație, care sunt rezultatele muncii sale în mesaje către utilizator. Pentru a converti informațiile către utilizator în diverse mesaje ca parte a interfeței, este necesară o unitate inteligentă de asistență pentru utilizator, care monitorizează posibilele erori, generează explicații și gestionează sistemul de ajutor.
Orice interacțiune între două sau mai multe obiecte (în acest caz, utilizatorul și interfața) respectă întotdeauna anumite reguli. Regulile de interacțiune dintre utilizator și interfață trebuie, de asemenea, definite în interfață. Aceste reguli trebuie să specifice succesiunea tranzițiilor de la o stare la alta. În consecință, interacțiunea interfeței cu utilizatorul trebuie să conțină reguli pentru schimbul de mesaje (în acest caz, acestea sunt acțiunile utilizatorului și interfața pentru a gestiona datele și rezultatele inițiale).
Astfel, interfața de utilizator include:
sistem de mesaje de bază (sistem de concepte de domeniu);
sistem de mesaje pentru utilizator;
sistem de mesaje pentru programul de aplicație;
mijloace pentru a asigura confortul și confortul utilizatorului;
mijloace de sprijin inteligent pentru utilizatori;
mijloace pentru gestionarea interacțiunii cu utilizatorul și a interfeței.
Să ne uităm la modul în care dezvoltarea fiecărei componente a interfeței cu utilizatorul este susținută de instrumente de generația a patra.
Suportul pentru descrierea unui sistem de concepte este propus în . Conform specificației sistemului de concept, pentru care se propune un limbaj specializat, mesajele sunt generate automat, prezentate verbal printr-o varietate de meniuri și ferestre în cascadă. Dezavantajul acestei specificații este că structura sistemului de concepte de domeniu este limitată la o reprezentare ierarhică, iar descrierea acesteia este realizată într-un limbaj specializat în mod batch.
Lucrările sugerează, de asemenea, începerea designului interfeței cu modelarea sarcinii și a domeniului subiectului. Pentru a face acest lucru, utilizatorului i se cere să descrie enunțul problemei într-un limbaj informal, din care sunt extrase automat conceptele domeniului și acțiunile cu acestea. Următorii pași sunt formalizarea enunțului de problemă rezultat prin separarea elementelor inutile, organizarea claselor de elemente selectate, specificarea domeniului și tipurile valorilor lor permise și acțiuni asupra acestora pentru a crea un model cu drepturi depline al domeniului subiectului. Ca avantaje ale acestei metode de extragere a sarcinilor, autorii indică o reducere a gradului de neînțelegere între dezvoltator și utilizator, implicarea utilizatorului în proiect încă de la începutul implementării acestuia și construirea unui cadru pentru modelul sarcinii și modelul domeniului. Cu toate acestea, posibilitatea utilizării acestei abordări pentru rezolvarea problemelor cu un model complex al domeniului de studiu, care are un volum mare și o structură complexă a sistemului de concepte necesare rezolvării problemei, oferind utilizatorului suport intelectual, este discutabilă, deoarece cadrul și elementele modelului (termeni și concepte) sunt identificate pe baza unei descrieri informale a sarcinilor utilizatorului. Experiența noastră în proiectarea sistemelor complexe, de exemplu, sistemul expert „Consultant-2” și, în special, interfața acestuia, a arătat că procesul de formare a unui sistem de concepte, fără îndoială, ar trebui să fie efectuat cu participarea activă a unor specialişti calificaţi în domeniu pe baza unei analize anterioare serioase a acesteia în scopul formalizării ulterioare. Prin urmare, instrumentele de proiectare a interfeței ar trebui să fie orientate mai degrabă către designerul de interfață decât către utilizatorul final.
Seturile de instrumente oferă biblioteci de elemente de interfață utilizate în dialog, cum ar fi panouri de dialog, formulare, diverse tipuri de meniuri, reprezentarea ierarhiei de date sub forma unei structuri de ramificare etc. În același timp, dezvoltatorul are nu numai posibilitatea de a selecta elementele de interfață necesare, ci și capacitatea de a organiza complexe complexe din primitivele de bază propuse folosind programarea vizuală și orientată pe obiecte. Cu toate acestea, este dificil să vorbim despre suport pentru proiectarea interfeței, deoarece bibliotecile propuse reflectă o opinie destul de arbitrară despre standardele elementelor de interfață, fără a folosi specificul aplicațiilor pentru care utilizarea bibliotecilor este justificată.
Trebuie remarcat faptul că toate seturile de instrumente existente nu au instrumente speciale pentru proiectarea unei interfețe de utilizator pe baza componentelor sale. Prin urmare, designerii de interfețe sunt forțați să proiecteze toate părțile sale împreună, fără a separa în mod explicit o componentă de alta, deși proiectarea diferitelor componente necesită utilizarea diferitelor tipuri de concepte și niveluri de abstractizare. Tehnologia de dezvoltare a unei interfețe folosind aceste mijloace este organizată în așa fel încât dezvoltatorul selectează un element de interfață și „încordează” conținutul interfeței pe acesta și nu invers; în conformitate cu structura și conținutul (sistem de concepte). ), sunt propuse forme de prezentare a acestuia (eventual generate automat). Dezvoltând astfel interfața, dezvoltatorul acesteia trebuie să ajusteze structura și conținutul datelor sursă la formele oferite în instrument.
Pentru datele sursă prezentate grafic, există multe pachete de grafică vectorială și raster disponibile. Pachetele grafice vă permit doar să creați imagini, dar nu au mijloacele de a conecta descrieri grafice și verbale (conectând un sistem de concepte și un sistem de mesaje), prin urmare această parte interfața trebuie programată. Trebuie reamintit că vorbim de instrumente de generația a patra care vă permit să specificați interfața la un nivel înalt.
Se încearcă conectarea sistemului de concepte și a sistemului de mesaje. În acest scop, setul de instrumente are o bază de date care stochează informații despre elementele de interfață care sunt mai convenabile pentru a reprezenta anumite tipuri de date. Pe baza acestei baze de date, dezvoltatorul poate atribui primitive elementelor sau grupurilor de date și apoi poate genera automat un prototip de interfață. Această abordare este convenabilă pentru reprezentarea verbală a datelor, dar reprezentarea grafică depinde de domeniul subiectului, astfel încât în acest caz primitivele oferite în baza de date nu pot fi folosite pentru a genera mesaje.
Toate clasele de instrumente acceptă o varietate de opțiuni pentru setarea parametrilor de confort al interfeței folosind programarea vizuală și orientată pe obiecte, permițându-vă să setați locația elementelor de interfață pe ecranul monitorului, culoarea, textura, dimensiunea acestora etc., în funcție de cerințele utilizatorului , psihologie și ergonomie, precum și determină dispozitivele fizice de intrare/ieșire.
Pentru organizarea interacțiunii dintre utilizator și interfață este momentan necunoscută caracteristici speciale, care ar permite dezvoltatorului la nivel de specificație să determine acțiunile utilizatorului de a gestiona datele sursă, astfel încât dezvoltatorul trebuie să programeze această componentă a interfeței. În funcționare, setul de instrumente oferă dezvoltatorului capacitatea de a salva seturi de date sursă, de a le vizualiza și de a le edita pentru introducerea ulterioară.
Multe variabile și reprezentarea valorilor lor trebuie de obicei programate sau, ca și în cazul, sunt formate conform regulilor strict definite în trusa de instrumente.
În lucrare sunt prezentate instrumente pentru generarea de explicații ale rezultatelor unui sistem software. Pentru a face acest lucru, dezvoltatorilor de interfețe li se oferă un limbaj macro special în care pot descrie modelul de explicație. Cu toate acestea, acest limbaj permite să prezentați o explicație doar în formă verbală, are fonduri limitate privind formatarea textului explicativ și conține o restricție privind formatul rezultatelor sistemului software - numai sub formă de tupluri de relație. Multe alte sisteme de generare a explicațiilor sunt concentrate exclusiv pe sisteme expert, depind de un motor de inferență și necesită, de asemenea, includerea de cunoștințe suplimentare în baza de cunoștințe. Autorii propun instrumente pentru generarea automată a instrumentelor de ajutor pentru prezentarea unei baze de cunoștințe.
Interacțiunea dintre interfață și programul de aplicație nu este suportată la un nivel înalt, ci este programată de dezvoltator.
Așadar, scopul principal al SUIP este de a reduce costul creării și menținerii unei interfețe cu utilizatorul, care se realizează prin furnizarea de instrumente de nivel înalt pentru definirea interfeței și eliberând astfel dezvoltatorul de programarea la nivel scăzut. Instrumentele specializate existente nu suportă dezvoltarea tuturor componentelor interfeței la un nivel înalt; dezvoltatorii trebuie să programeze majoritatea componentelor sau sunt specificate rigid, ceea ce nu permite asigurarea principiului 1 la proiectarea interfeței. Acest lucru duce la creșterea semnificativă a costurilor pentru dezvoltarea și întreținerea interfeței.
Prin urmare, în prezent, munca de creare a unui sistem de control care să ofere suport la nivel înalt pentru toate etapele dezvoltării acestuia este urgentă.
Bibliografie
1. Myers B.A. și Rosson M.B. „Survey on User Interface Programming”, Proceedings SIGCHI’92: Human Factors in Computing Systems. Monterrey, CA, 3-7 mai 1992. P. 195-202.
2. Klimenko S., Urazmetov V. Interfețe grafice și instrumente pentru dezvoltarea lor // Mater. Conf.: Industria de programare – 96. www.uniyar.ac.ru/network/atm/forum/koi/if/prg/prg96/73/htm.
3. Puerta, A. R. Sprijinirea proiectării centrate pe utilizator a interfețelor adaptive utilizator prin modele de interfață. Primul atelier anual privind interfețele inteligente de utilizator în timp real pentru sprijinirea deciziilor și vizualizarea informațiilor, San–Francisco, ianuarie 1998. 10 p.
4. Brad A. Myers. O scurtă istorie a tehnologiei de interacțiune cu computerul uman // Interacțiunile ACM. Vol. 5, nr. 2. martie 1998. P. 44-54.
5. Lowgren J. Suport pentru proiectare bazată pe cunoștințe și managementul discursului în sistemele de management al interfeței cu utilizatorul. Legătura de studii în știință și tehnologie. Disertațiile nr. 239, 1989.
6. Puerta, A. R. și Maulsby, D. Management of Interface Design Knowledge cu MOBI–D. IUI97: International Conference on Intelligent User Interfaces, Orlando, ianuarie 1997, pp. 249–252.
7. Pressman R. S. Software Engineering: Practitioners Approach European 3d Rev. ed. McGraw–Hills Inc., 1994. 802 p.
8. Coates P., Vleimink I. Interfață „om-computer” / Trad. din engleza – M.: Mir, 1990.- 501 p.
9. Bruce A. Wooley Componenta explicație a sistemelor software. www.acm.org/crossroads/xrds5–1/explain.html.
10. Bauer F.L., Gooz G. Informatica. Curs introductiv: 2 ore /Trans. cu el. – M.: Mir, 1990. – Partea 1. – 336 p., ill.
11. Gribova V.V., Kleshchev A.S. Set de instrumente pentru dezvoltarea unei interfețe cu utilizatorul în sisteme experte // Produse și sisteme software. – 1999. – Nr. 1. – P. 30-34.
12. Puerta, A.R. Un mediu de dezvoltare a interfeței bazat pe model. IEEE Software, 14(4), iulie/august 1997, pp. 41–47.
13. Chernyakhovskaya M.Yu. Evaluarea sistemului de diagnostic medical „Consultant-2” pe baza materialului de arhivă de la mai multe clinici. – Vladivostok, 1989. – 30 p. (Prez. IAPU FEB RAS).
14. Skopin I.N. Dezvoltare de interfete pentru sisteme software // Informatica de sistem. – 1998. – Numărul 6. – P.123–173.
15. Foley, J., Kim, W.C., Kovacevic S., Murray, K., UIDE: An Intelligent User Interface Design Environment, în ACM Press, 1991.
Luni trecută am avut norocul să obțin un interviu ca Senior .Net Developer la o companie internațională. În timpul interviului, mi s-a cerut să susțin un test în care o serie de întrebări erau legate de .Net. În special, într-una dintre întrebări a fost necesar să se evalueze (adevărat/fals) o serie de afirmații, printre care s-au numărat următoarele:
În .Net, orice matrice de elemente, cum ar fi int, implementează IList în mod implicit, permițându-i să fie folosit ca o colecție într-o instrucțiune foreach.
Răspunzând rapid la această întrebare în sens negativ și scriind separat în margine. că foreach necesită o implementare nu a IList, ci a IEnumerable, am trecut la următoarea întrebare. Totuși, în drum spre casă am fost chinuit de întrebarea: matricea mai implementează această interfață sau nu?
Despre IList, mi-am amintit vag că această interfață îmi oferă un IEnumerable, un indexator și o proprietate Count care conține numărul de elemente ale colecției, precum și câteva proprietăți rar utilizate, cum ar fi IsFixedCollection(). Matricea are o proprietate Length pentru dimensiunea sa, iar Count în IEnumerable este o metodă de extensie din LINQ, care nu ar fi posibilă dacă metoda ar fi implementată într-o clasă. Astfel, s-a dovedit că matricea nu a putut implementa interfața IList, dar m-a bântuit un sentiment vag. Așa că în seara de după interviu, am decis să fac câteva cercetări.
Class System.Array
Deoarece nu aveam instalat Reflector.Net, tocmai am scris un scurt program în C# pentru a afla ce fel de interfețe sunt implementate de un tablou întreg.Var v = new int ( 1, 2, 3 ); var t = v.GetType(); var i = t.GetInterfaces(); foreach(var tp in i) Console.WriteLine(tp.Name);
Aici lista plina interfețe primite din fereastra consolei:
ICloneable IList ICollection IEnumerable IStructuralComparable IStructuralEquatable IList`1 ICollection`1 IEnumerable`1 IReadOnlyList`1 IReadOnlyCollection`1
Prin urmare, o matrice din .Net încă implementează interfața IList și versiunea sa generalizată IList<> .
Pentru a obține informații mai complete, am construit o diagramă a clasei System.Array.
Greșeala mea mi-a atras imediat atenția: Count nu era o proprietate a IList, ci a ICollection, interfața anterioară din lanțul de moștenire. Cu toate acestea, matricea în sine nu mai avea o astfel de proprietate, nici multe dintre celelalte proprietăți ale interfeței IList, deși celelalte proprietăți ale interfeței, IsFixedSize și IsReadOnly, au fost implementate. Cum este posibil acest lucru?
Totul se pune imediat pe loc când vă amintiți că în C# puteți implementa interfețe nu numai
implicit, dar și explicit. Știam despre această posibilitate din manuale, care dădeau un exemplu de astfel de implementare într-un caz. când clasa de bază conține deja o metodă cu același nume ca metoda interfeței. Am văzut și această funcție în ReSharper. Cu toate acestea, până acum nu am întâlnit în mod direct nevoia de a implementa explicit interfețele în propriile mele proiecte.
Compararea implementării explicite și implicite a interfețelor
Să comparăm aceste două tipuri de implementări de interfață:.| Criterii |
Implementare implicită |
Implementare explicită |
|---|---|---|
| Sintaxa de bază |
interfață ITest ( void DoTest(); ) clasă publică ImplicitTest: ITest ( public void DoTest() ( ) ) |
interfață ITest ( void DoTest(); ) clasă publică ExplicitTest: ITest ( void ITest.DoTest() ( ) ) |
| Vizibilitate |
Implementarea implicită a fost întotdeauna publică, astfel încât metodele și proprietățile pot fi accesate direct. var imp = new ImplicitTest(); imp.DoTest(); |
Implementarea explicită este întotdeauna privată. Pentru a obține acces la implementare, trebuie să turnați instanța de clasă la interfață (upcast la interfață). var exp = new ExplicitTest(); ((ITest)exp).DoTest(); |
| Polimorfie |
Implementarea implicită a unei interfețe poate fi virtuală, ceea ce permite ca această implementare să fie rescrisă în clase descendente. |
Implementarea explicită este întotdeauna statică. Nu poate fi suprascris (override) sau blocat (nou) în clasele descendente. Notă 1 |
| Clasă abstractă și implementare |
O implementare implicită poate fi abstractă și implementată numai într-o clasă descendentă. |
O implementare explicită nu poate fi abstractă, dar clasa în sine poate avea alte metode abstracte și poate fi ea însăși abstractă. Notă 2 |
Note:
Notă 1 - După cum s-a menționat pe bună dreptate în comentarii, implementarea poate fi suprascrisă prin implementarea explicită repetată a interfeței în clasa descendentă (vezi primul comentariu la articol).
Notă 2 - Unul dintre bloguri afirmă că o clasă în sine nu poate fi abstractă. Poate că acest lucru a fost adevărat pentru unele dintre versiunile anterioare ale compilatorului; în experimentele mele, am putut implementa interfața în mod explicit într-o clasă abstractă, fără probleme.
De ce avem nevoie de implementarea explicită a interfețelor?
Implementarea explicită a interfeței, conform MSDN, este necesară atunci când mai multe interfețe implementate de o clasă au o metodă cu aceeași semnătură. Această problemă este în general cunoscută în lumea vorbitoare de limbă engleză sub denumirea înfiorătoare de „diamantul mortal al morții”, care este tradus în rusă ca „problema diamantului”. Iată un exemplu de astfel de situație:/* Lista 1 */ interfață IJogger ( void Run(); ) interfață ISkier ( void Run(); ) sport de clasă publică: ISkier, IJogger ( public void Run() ( Console.WriteLine("Sunt sportiv, schior sau Jogger?"); ))
Apropo, acest exemplu este codul corect în C#, adică se compilează și rulează (corect), în timp ce metoda Run() este atât o metodă a clasei în sine, cât și o implementare a cât mai multe interfețe. În acest fel putem avea o implementare pentru diferite interfețe și pentru clasa în sine. Puteți verifica acest lucru cu următorul cod:
/* Listarea 2 */ var sp = new Athlete(); sp.Run(); (sp ca ISkier).Run(); (sp ca IJogger).Run();
Rezultatul executării acestui cod va fi „Sunt atlet, schior sau jogger?”, imprimat pe consolă de trei ori.
Aici putem folosi implementarea explicită a interfeței pentru a separa toate cele trei cazuri:
/* Lista 3 */ public class Sportsman ( public virtual void Run() ( Console.WriteLine("Sunt un sportiv"); ) ) public class Sportiv: Sportsman, ISkier, IJogger ( public override void Run() ( Console. WriteLine(„Sunt un sportiv”); ) void ISkier.Run() ( Console.WriteLine(„Sunt schior”); ) void IJogger.Run() ( Console.WriteLine(„Sunt un Jogger”); ) )
În acest caz, la executarea codului din Lista 2, vom vedea trei linii în consolă, „Sunt un atlet”, "Sunt schior"Și "Sunt un jogger".
Avantaje și dezavantaje ale diferitelor implementări de interfață
Vizibilitatea implementării și implementarea selectivă
După cum sa arătat deja mai sus, o implementare implicită nu diferă din punct de vedere sintactic de o metodă de clasă obișnuită (și dacă această metodă a fost deja definită în clasa strămoșilor, atunci în această sintaxă metoda va fi ascunsă în descendent și codul va fi compilat fără probleme avertismentul compilatorului despre ascunderea metodei.). Mai mult, este posibilă implementarea selectivă a metodelor individuale ale unei singure interfețe, fie explicit, fie implicit:/* Lista 4 */ cod de clasă publică ( public void Run() ( Console.WriteLine("Sunt o metodă de clasă"); ) ) interfață ICommand ( void Run(); void Execute(); ) public class CodeCommand: Code , ICommand ( // implementarea implicită a metodei interfeței // => implementare publică // ascunderea implicită a metodei clasei de bază (avertisment aici) public void Run() ( base.Run(); ) // implementare explicită a metodei interfeței // => private implementare void ICommand.Execute() () )
Acest lucru permite ca implementările metodelor individuale de interfață să fie utilizate ca metode native ale clasei și sunt accesibile, de exemplu, prin IntelliSense, spre deosebire de implementarea explicită a metodelor, care sunt private și vizibile numai după turnarea în interfața corespunzătoare.
Pe de altă parte, abilitatea de a implementa metode în mod privat vă permite să ascundeți o serie de metode de interfață în timp ce o implementați complet. Revenind la primul nostru exemplu cu matrice în .Net, puteți vedea că matricea ascunde, de exemplu, implementarea proprietății Count a interfeței ICollection, expunând această proprietate sub numele Length (probabil aceasta este o încercare de a menține compatibilitatea). cu C++ STL și Java). Astfel, putem ascunde anumite metode ale interfeței implementate și nu ascunde (=face publice) altele.
Problema aici este însă că, în multe cazuri, este complet imposibil de ghicit care interfețe sunt implementate „implicit” de o clasă, deoarece nici metodele, nici proprietățile acestor interfețe nu sunt vizibile în IntelliSense (exemplul System.Array este de asemenea instructiv aici). Singura modalitate de a identifica astfel de implementări este utilizarea reflectării, de exemplu folosind Object Browser din Visual Studio.
Refactorizarea interfeței
Deoarece implementarea implicită (publică) a unei interfețe nu diferă de implementarea unei metode publice a unei clase, în cazul refactorizării interfeței și eliminării oricărei metode publice din aceasta (de exemplu, la combinarea Run() și Execute () din interfața ICommand de mai sus într-o singură metodă Run( )) în toate implementările implicite, metoda va rămâne acces deschis, care va trebui foarte probabil să fie suportat chiar și după refactorizare, deoarece această metodă publică poate avea deja diferite dependențe în alte componente ale sistemului. Ca urmare a acestui fapt, principiul de programare „împotriva interfețelor, nu implementărilor” va fi încălcat, deoarece dependențele vor fi deja între implementări specifice (și în clase diferite, probabil diferite) ale fostei metode de interfață./* Lista 5 */ interfață IFingers ( void Thumb(); void IndexFinger(); // o metodă de interfață învechită // void MiddleFinger(); ) public class HumanPalm: IFingers ( public void Thumb() () public void IndexFinger( ) () // aici este o metodă publică „atârnată” public void MiddleFinger() () ) public class AnthropoidHand: IFingers ( void IFingers.Thumb() () void IFingers.IndexFinger() () // aici eroarea compilatorului void IFingers.MiddleFinger() () )
În cazul implementării private a interfețelor, toate clasele cu o implementare explicită a unei metode care nu mai există pur și simplu se vor opri din compilare, totuși, după eliminarea implementării care a devenit inutilă (sau refactorizarea ei în metoda noua) nu vom avea o metodă publică „extra” care să nu fie legată de nicio interfață. Desigur, poate fi necesar să se refactorizeze dependențele de interfața în sine, dar aici, prin macar, nu va exista nicio încălcare a principiului „program la interfețe, nu implementări”.
În ceea ce privește proprietățile, proprietățile (proprietățile) de interfață implementate implicit vă permit să le accesați prin metode accesorii (getter și setter) atât extern, cât și direct din clasa în sine, ceea ce poate duce la efecte inutile (de exemplu, validarea inutilă a datelor în timpul proprietăților de inițializare) .
/* Listarea 6 */ interfață IProperty ( int Amount ( get; set; ) ) public class ClassWithProperty: IProperty ( // implementare implicită, public public int Amount ( get; set; ) public ClassWithProperty() ( // invocarea internă a public setter Amount = 1000; ) ) public class ClassWithExplicitProperty: IProperty ( // implementare explicită, private int IProperty.Amount ( get; set; ) public ClassWithExplicitProperty() ( // invocarea internă nu este posibilă // eroare compilatorului aici Amount = 1000; ))
Când implementați în mod explicit proprietățile interfeței, aceste proprietăți rămân private și pentru a accesa trebuie să luați calea „lungă” și să declarați un câmp privat suplimentar prin care are loc inițializarea. Acest lucru are ca rezultat un cod mai curat, în care accesorii de proprietate sunt utilizați numai pentru acces extern.
Utilizarea tastării explicite a variabilelor locale și a câmpurilor de clasă
În cazul implementării explicite a interfețelor, trebuie să indicăm în mod explicit că nu lucrăm cu o instanță a unei clase, ci cu o instanță a unei interfețe. Astfel, de exemplu, devine imposibil să folosiți inferența de tip și să declarați variabile locale în C# folosind cuvântul de serviciu var. În schimb, trebuie să folosim o declarație explicită a tipului de interfață atunci când declarăm variabilele locale, precum și în semnătura metodei și în câmpurile de clasă.Astfel, pe de o parte, se pare că facem codul oarecum mai puțin flexibil (de exemplu, ReSharper sugerează întotdeauna utilizarea unei declarații cu var, dacă este posibil), dar evităm potențialele probleme asociate cu legarea la o anumită implementare pe măsură ce sistemul crește și codul său de volum. Acest punct poate părea controversat pentru mulți, dar în cazul în care mai multe persoane lucrează la un proiect și chiar în diferite părți ale lumii, folosirea tastării explicite poate fi foarte utilă, deoarece crește lizibilitatea codului și reduce costul. de a-l menţine.
Ca orice dispozitiv tehnic, un computer face schimb de informații cu o persoană printr-un set de anumite reguli care sunt obligatorii atât pentru mașină, cât și pentru persoană. Aceste reguli sunt numite interfață în literatura de specialitate. Interfața ar trebui să fie clară și neclară, prietenoasă și nu. I se aplică multe adjective. Dar un lucru este constant: există și nu poți scăpa de el.
Interfață- acestea sunt regulile de interacțiune între sistemul de operare și utilizatori, precum și nivelurile învecinate din rețeaua de calculatoare. Tehnologia comunicării om-calculator depinde de interfață.
Interfață- acesta este, în primul rând, un set de reguli. Ca orice reguli, ele pot fi generalizate, colectate într-un „cod” și grupate în funcție de o caracteristică comună. Cu toate acestea, am ajuns la conceptul de „tip de interfață” ca o uniune bazată pe asemănarea modalităților de interacțiune dintre oameni și computere. Putem propune următoarea clasificare schematică a diferitelor interfețe de comunicație om-calculator (Fig. 1.).
Tehnologia lotului. Din punct de vedere istoric, acest tip de tehnologie a apărut prima. A existat deja pe mașinile releu ale lui Sues și Zuse (Germania, 1937). Ideea sa este simplă: la intrarea calculatorului este furnizată o succesiune de simboluri, în care, după anumite reguli, este indicată succesiunea programelor lansate pentru execuție. După ce următorul program este executat, următorul este lansat și așa mai departe. Mașina, conform anumitor reguli, găsește comenzi și date pentru ea însăși. Această secvență poate fi, de exemplu, o bandă de hârtie perforată, un teanc de cărți perforate sau o secvență de apăsare a tastelor unei mașini de scris electrice (tip CONSUL). De asemenea, aparatul își trimite mesajele către un perforator, o unitate de imprimare alfanumerică (ADP) sau o bandă de mașină de scris.
O astfel de mașină este o „cutie neagră” (mai precis, un „dulap alb”), în care informațiile sunt furnizate în mod constant și care, de asemenea, „informează” în mod constant lumea despre starea sa. O persoană de aici are o influență redusă asupra funcționării mașinii - poate doar să întrerupă funcționarea mașinii, să schimbe programul și să pornească din nou computerul. Ulterior, când mașinile au devenit mai puternice și au putut deservi mai mulți utilizatori simultan, utilizatorii au așteptat pentru totdeauna ca: "Am trimis date către mașină. Aștept să răspundă. Și va răspunde deloc?" - ca să spunem ușor, a devenit necesar să mănânci. În plus, centrele de calculatoare, după ziare, au devenit al doilea „producător” major de deșeuri de hârtie. Din acest motiv, apariția afișajelor alfanumerice a inaugurat era tehnologiei cu adevărat ușor de utilizat - linia de comandă.
Interfață de comandă.
Interfața de comandă este de obicei numită astfel deoarece în acest tip de interfață o persoană dă „comenzi” computerului, iar computerul le execută și dă rezultatul persoanei. Interfața de comandă este implementată sub formă de tehnologie batch și tehnologie de linie de comandă.
Cu această tehnologie, o tastatură este singura modalitate de a introduce informații de la o persoană pe un computer, iar computerul afișează informații persoanei folosind un afișaj alfanumeric (monitor). Această combinație (monitor + tastatură) a ajuns să fie numită terminal, sau consolă.
Comenzile sunt tastate pe linia de comandă. Linia de comandă este un simbol prompt și un dreptunghi care clipește - un cursor.
Postat pe ref.rf
Când apăsați o tastă, simbolurile apar în locația cursorului, iar cursorul însuși se deplasează la dreapta. Comanda se încheie prin apăsarea tastei Enter (sau Return), care apoi trece la începutul următoarei rânduri. Din această poziție computerul afișează rezultatele muncii sale pe monitor. Apoi procesul se repetă.
Tehnologia liniei de comandă a funcționat deja pe afișajele alfanumerice monocrome. Întrucât a fost posibil să se introducă doar litere, cifre și semne de punctuație, caracteristicile tehnice ale afișajului nu au fost semnificative. Un receptor de televiziune și chiar un tub de osciloscop ar putea fi folosite ca monitor.
Ambele tehnologii sunt implementate sub forma unei interfețe de comandă - comenzile sunt date mașinii ca intrare și aceasta, așa cum ar fi, „răspunde” la ele.
Fișierele text au devenit tipul predominant de fișiere atunci când lucrați cu interfața de comandă - ele și numai ele puteau fi create folosind tastatura. Perioada în care interfața de linie de comandă a fost cea mai utilizată a fost apariția sistemului de operare UNIX și apariția primelor computere personale pe opt biți cu sistemul de operare multiplatformă CP/M.
Interfață WIMP(Fereastră - fereastră, Imagine - imagine, Meniu - meniu, Pointer - pointer). O trăsătură caracteristică a acestui tip de interfață este că dialogul cu utilizatorul se realizează nu folosind comenzi, ci folosind imagini grafice - meniuri, ferestre și alte elemente. Deși comenzile sunt date mașinii în această interfață, aceasta se face „indirect”, prin imagini grafice. Ideea unei interfețe grafice a apărut la mijlocul anilor 1970, când conceptul de interfață vizuală a fost dezvoltat la Centrul de Cercetare Xerox Palo Alto (PARC). Condiția prealabilă pentru interfața grafică a fost reducerea timpului de reacție a computerului la o comandă, creșterea cantității de memorie RAM, precum și dezvoltarea bazei tehnice a computerelor. Baza hardware a conceptului, desigur, a fost apariția afișajelor alfanumerice pe computere, iar aceste afișaje aveau deja efecte precum „pâlpâirea” caracterelor, inversarea culorii (schimbarea conturului caracterelor albe pe fundal negru spre invers, adică caractere negre pe fundal alb ), caractere subliniate. Aceste efecte nu s-au extins la întregul ecran, ci doar la unul sau mai multe personaje. Următorul pas a fost crearea unui display color care să permită afișarea, împreună cu aceste efecte, a caracterelor în 16 culori pe un fundal cu o paletă (adică un set de culori) de 8 culori. După apariția afișajelor grafice, cu posibilitatea de a afișa orice imagini grafice sub formă de multe puncte pe un ecran de culori diferite, nu au existat limite ale imaginației în utilizarea ecranului! Primul sistem cu interfață grafică, 8010 Star Information System al grupului PARC, a apărut astfel cu patru luni înainte de lansarea primului computer IBM în 1981. Inițial, interfața vizuală a fost folosită doar în programe. Treptat, a început să treacă la sisteme de operare, utilizate mai întâi pe computerele Atari și Apple Macintosh, iar apoi pe computerele compatibile IBM.
Dintr-o vreme mai devreme, și influențat și de aceste concepte, a existat un proces de unificare a utilizării tastaturii și mouse-ului de către programele de aplicație. Fuziunea acestor două tendințe a condus la crearea unei interfețe cu utilizatorul cu care, cu timp și bani cheltuiți minim pentru recalificarea personalului, puteți lucra cu orice produs software. Această parte este dedicată unei descrieri a acestei interfețe, comună tuturor aplicațiilor și sistemelor de operare.
Interfața grafică cu utilizatorul a trecut prin două etape în timpul dezvoltării sale și este implementată la două niveluri de tehnologie: o interfață grafică simplă și o interfață WIMP „pură”.
În prima fază, GUI-ul a fost foarte asemănător cu tehnologia liniei de comandă. Diferențele față de tehnologia liniei de comandă au fost următoarele:
Ú La afișarea caracterelor, era permisă evidențierea unor caractere cu culoare, imagine inversă, subliniere și pâlpâire. Datorită acestui fapt, expresivitatea imaginii a crescut.
Ú Luând în considerare dependența de o implementare specifică a interfeței grafice, cursorul poate apărea nu numai ca un dreptunghi pâlpâit, ci și ca o anumită zonă care acoperă mai multe caractere și chiar o parte a ecranului. Această zonă selectată diferă de alte părți neselectate (de obicei prin culoare).
Ú Apăsarea tastei Enter nu execută întotdeauna comanda și trece la linia următoare. Reacția la apăsarea oricărei taste depinde în mare măsură de locul în care se afla cursorul pe ecran.
Ú Pe lângă tasta Enter, tastele de control „gri” ale cursorului sunt din ce în ce mai folosite pe tastatură (a se vedea secțiunea despre tastatură din numărul 3 al acestei serii.)
Ú Deja în această ediție a interfeței grafice au început să fie utilizate manipulatoare (cum ar fi mouse, trackball etc. - vezi Figura A.4.) Acest lucru a făcut posibilă selectarea rapidă a părții dorite a ecranului și mutarea cursorului .
Pentru a rezuma, putem cita următoarele caracteristici distinctive ale acestei interfețe:
Ú Selectarea zonelor ecranului.
Ú Redefinirea tastelor de la tastatură în funcție de context.
Ú Utilizarea manipulatoarelor și a tastelor gri de la tastatură pentru a controla cursorul.
Ú Utilizarea pe scară largă a monitoarelor color.
Apariția acestui tip de interfață coincide cu utilizarea pe scară largă a sistemului de operare MS-DOS. Ea a fost cea care a introdus această interfață în masă, datorită căreia anii 80 au fost marcați de îmbunătățirea acestui tip de interfață, îmbunătățirea caracteristicilor de afișare a caracterelor și a altor parametri ai monitorului.
Un exemplu tipic de utilizare a acestui tip de interfață este shell-ul de fișiere Nortron Commander și editorul de text Multi-Edit. Iar editorii de text Lexicon, ChiWriter și procesorul de text Microsoft Word for Dos sunt exemple ale modului în care această interfață s-a autodepășit.
A doua etapă în dezvoltarea interfeței grafice a fost interfața „pură” WIMP. Acest subtip de interfață se caracterizează prin următoarele caracteristici:
Ú Toate lucrările cu programe, fișiere și documente au loc în ferestre - părți definite ale ecranului conturate de un cadru.
Ú Toate programele, fișierele, documentele, dispozitivele și alte obiecte sunt prezentate sub formă de pictograme. Când sunt deschise, pictogramele se transformă în ferestre.
Ú Toate acțiunile cu obiecte sunt implementate folosind meniul. Deși meniul a apărut în prima etapă a dezvoltării interfeței grafice, nu a avut un rol dominant în el, ci a servit doar ca o completare la linia de comandă. Într-o interfață WIMP pură, meniul devine elementul principal de control.
Ú Utilizarea pe scară largă a manipulatoarelor pentru a indica obiecte. Dispozitivul de indicare încetează să mai fie doar o jucărie - un plus la tastatură, dar devine principalul element de control. Folosind un manipulator, ei indică orice zonă a ecranului, ferestrei sau pictogramei, o selectează și abia apoi le controlează prin meniu sau folosind alte tehnologii.
Trebuie remarcat faptul că WIMP necesită un afișaj color raster de înaltă rezoluție și un dispozitiv de indicare pentru implementarea sa.
Postat pe ref.rf
De asemenea, programele orientate către acest tip de interfață impun cerințe sporite asupra performanței computerului, a capacității sale de memorie, a lățimii de bandă a magistralei etc. Mai mult, acest tip de interfață este cel mai ușor de învățat și intuitiv. Din acest motiv, interfața WIMP a devenit acum un standard de facto.
Un exemplu izbitor de programe cu interfață grafică este sistemul de operare Microsoft Windows.
MĂTASE- interfata (Vorbire - vorbire, Imagine - imagine, Limba - limbaj, Cunoastere - cunoastere). Acest tip de interfață este cel mai apropiat de forma obișnuită, umană de comunicare. În cadrul acestei interfețe există o „conversație” normală între o persoană și un computer. În același timp, computerul găsește comenzi pentru el însuși analizând vorbirea umană și găsind fraze cheie în ea. De asemenea, convertește rezultatul execuției comenzii într-o formă care poate fi citită de om. Acest tip de interfață este cel mai solicitant în ceea ce privește resursele hardware ale computerului și, prin urmare, este utilizat în principal în scopuri militare.
De la mijlocul anilor 90, după apariția plăcilor de sunet ieftine și utilizarea pe scară largă a tehnologiilor de recunoaștere a vorbirii, a apărut așa-numita interfață SILK „tehnologia vorbirii”. Cu această tehnologie, comenzile sunt date prin voce prin pronunțarea unor cuvinte speciale rezervate - comenzi.
Cuvintele trebuie pronunțate clar, în același ritm. Este necesară o pauză între cuvinte. Datorită subdezvoltării algoritmului de recunoaștere a vorbirii, astfel de sisteme necesită pre-ajustare individuală pentru fiecare utilizator specific.
Tehnologia „Speech” este cea mai simplă implementare a interfeței SILK.
Tehnologia biometrică („Interfață imitativă”)
Această tehnologie a apărut la sfârșitul anilor 90 ai secolului al XX-lea și este încă în curs de dezvoltare la momentul scrierii. Pentru a controla computerul, se folosesc expresia facială a unei persoane, direcția privirii sale, dimensiunea pupilei și alte semne. Pentru a identifica utilizatorul, se utilizează un model al irisului ochilor săi, amprentele digitale și alte informații unice. Imaginile sunt citite de pe o cameră video digitală, iar apoi comenzile sunt extrase din această imagine folosind programe speciale de recunoaștere a modelelor. Este posibil ca această tehnologie să-și găsească locul în produsele și aplicațiile software în care este important să se identifice cu exactitate utilizatorul computerului.
