De exemplu, un televizor-om este un sistem complet procedural: toate sarcinile pe care o reprezintă pentru el sunt descrise în termeni de "program", "luminozitate", "contrast" "și așa mai departe.
Pentru ca utilizatorul să planifice și să prezică cel puțin parțial comportamentul sistemului, trebuie să știe cum este aranjat și cum funcționează. Și pentru că sistemul este aranjat, nu este ușor, este necesar să se inventeze o simplificată și nu corespunde realității, arhitectura sa, dar este descris în termeni ușor de înțeles pentru utilizator. Există și un alt mod de a interacționa cu sistemul procedural: printr-o legendă. Legenda este bună prin faptul că oferă utilizatorului sentimentul că înțelege perfect dispozitivul sistemului - în timp ce urmează instrucțiunile. Dezavantajul legendei este că este imposibil să se adere la ea întotdeauna și în tot. Același lucru - conform legendei - obiecte încep să se comporte în diferite situații în moduri diferite, deoarece acestea corespund diferitelor tipuri de obiecte în sistem. Un exemplu tipic al unei legende este conceptul de pictogramă (pictogramă, pictogramă) în Windows. Pictogramele din browser se comportă diferit decât unele pictograme de pe desktop, și nu deloc ca pictogramele din panoul de control.
Utilizatorul sistemului procedural adesea nu știe exact cum a obținut rezultatul dorit din el și nu-și poate reproduce mereu acțiunile de la prima dată. Apăsați pe butoanele - și ieșiți. Cum? Și cine știe.
Principiul conștiinței limitate. Sistemul de dispozitive ar trebui să fie ascuns de utilizator, astfel încât să nu-i ciocănească capul cu fapte "inutile" și să nu-i dea posibilitatea să strică sistemul. În plus, cea mai mare parte a sistemului nu poate fi documentată sau rămâne în stadiul documentației tehnice, a cărei vânzare poate fi făcută ocazional și câștigă. Și cel mai important, utilizatorul care nu are voie să cunoască secret va veni la dezvoltator pentru orice corecție a sistemului și din nou să plătească pentru upgrade.
Principiul aptitudinilor garantate. Utilizatorul nu trebuie să știe nimic special pentru a începe să lucreze cu sistemul procedural. Prin urmare, interacțiunea cu sistemul procedural se bazează, de regulă, pe abilitățile deja existente sau pe abilitățile foarte simple.
Principiul procedurilor care se suprapun. Mijloacele de integrare (aplicarea în comun) a procedurilor în sine în sistemele procedurale sunt slab dezvoltate. În consecință, situația inevitabilă în cazul în care o clasă de sarcini tipice de utilizator rezolvate cu ajutorul unui grup de proceduri (comenzilor) pentru, o altă clasă de probleme - cu ajutorul altor grupuri, dar sarcina este mai puțin similar cu proba, cu atât mai dificil să dau seama ce proceduri și în ce succesiune de a utiliza , pentru ao rezolva. Concluzie: trebuie să organizăm procedurile în sine pentru ca, cu ajutorul lor sau cu ajutorul suprapunerii lor (aplicarea succesivă asupra aceluiași obiect), a fost posibilă rezolvarea oricărei probleme. Acest lucru este impracticabil, iar dorința de a acoperi oportunitățile oferite de cât mai mult spațiu posibil duce la două caracteristici caracteristice ale sistemului. În primul rând, există o mulțime de proceduri (butoane, pârghii, elemente de meniu) în el. În al doilea rând, trebuie rezolvate multe sarcini: prin aplicarea consecventă a mai multor alte soluții, folosind doar o parte din proprietățile lor. Este, de obicei, mai ușor să convingeți utilizatorul că soluția terminată îl va potrivi, decât să caute o soluție care să-l satisfacă într-adevăr.
Principiul delegării responsabilității. Întrucât utilizatorul nu are nicio idee despre ce se întâmplă de fapt atunci când începe procedura următoare a sistemului, numai dezvoltatorul procedurii poate garanta calitatea conversiilor produse. Dacă procedurile sunt prea complicate, în afară de a monitoriza dacă acestea încalcă orice standard, este mai ușor să uiți de ea și să creați propria dvs. Acesta este, de exemplu, formatul fișierelor .doc: o structură a cărei validitate este verificată prin neadecvarea oricărei documentații, ci prin trecerea prin sistemul procedural care le-a generat.
În plus, utilizatorul sistemului procedural într-un anumit sens devine obișnuit cu iresponsabilitatea. Orice impact asupra sistemului trebuie să se înconjoare - și anunțat - tot felul de avertismente, cum ar fi „Sunteți sigur că doriți să faceți așa și că semnele tipice ale unui sistem procedural - o abundență de cereri de confirmare a acțiunii selectate Uneori există o confirmare dublă :. Pentru primul“ Sunteți sigur ?., „urmat de“ Sunteți sigur că într-adevăr „responsabil pentru sistemul - un dezvoltator - este necesară într-un astfel de mod de a sărbători punctele de control ale sistemului la care deplasează responsabilitatea rezultatelor de utilizator, utilizator preferat. e să fie incertă - atât mai puține șanse ca va strica nimic.
Corolar 1. Este evident că direcția principală de dezvoltare a sistemelor de tratare este de a crea un set mai complet și echilibrat de soluții pentru un număr tot mai mare de domenii de aplicare. Nu întâmplător cuvântul „utilitate“ (utilitate) pentru a se referi la programul de utilizator a fost în astfel de sisteme se înlocuiește cu „cerere“ (cerere). De obicei, în plus față de mijloacele de rezolvare a clasei principale de probleme, astfel de sisteme au o sursă de oportunități „pentru toate ocaziile“ (conform principiului procedurilor suprapuse). Este deosebit de incomod să se utilizeze un astfel de stoc tăiat. De multe ori, atunci când un calculator coexistă mai multe sisteme procedurale, cum ar fi CorelDraw, PhotoShop, MS Office, și așa mai departe. E. Sub Windows unul, înlocuirea pieselor între ele (până la o pierdere de funcționalitate), fără nici un rezultat, „mânca“ resursele de calculator și dezordine spațiul.
Corolarul 2. Dialogul dintre mașină și utilizator în sistemul procedural se bazează pe activitatea mașinii. Acest lucru și tot felul de „maestru“, și ponturile, și coroana creației - un clip care bate capul pe ecran și declanșează utilizatorul la diverse acțiuni care fără ea ar fi crezut. Faptul este că organizarea procedurală a sistemului om-mașină suprimă inițiativa. În primul rând, în conformitate cu principiul delegării responsabilității, în cazul în care prescripția spune că pentru a obține proprietățile dorite ale obiectului care aveți nevoie pentru a efectua 18 echipe, ele sunt și ar trebui să fie făcut, mai degrabă decât cele trei care par a fi adecvate, dar nicăieri nu spune că acest lucru, de asemenea, este posibil. Să ne amintim, de asemenea, despre incertitudinea în care ar trebui să rămână utilizatorul. În al doilea rând, nimeni, cu excepția, probabil, dezvoltatorii, nu știe ce se va întâmpla cu obiectul de impactul acestor trei echipe. Conform principiului conștiinței limitate, utilizatorul nu știe decât o legendă și ar trebui să fie respectat în orice caz. În al treilea rând, sistemul, care constă aproape în întregime din soluții gata, nu implică faptul că înainte de a ridica probleme nerezolvate.
Articole similare
-
1C-Bitrix24 »în cutie, crearea portalului intern al companiei, portal intranet, cumpărați sistemul
-
Cum se pornește instalarea sistemelor de încălzire și alimentare cu apă
Trimiteți-le prietenilor: