Ինչպես ցանկացած տեխնիկական սարք, համակարգիչը մարդու հետ շփվում է մի շարք հատուկ կանոնների միջոցով, որոնք պարտադիր են ինչպես մեքենայի, այնպես էլ անձի համար: Այս կանոնները համակարգչային գրականության մեջ կոչվում են միջերեսներ: Ինտերֆեյսը կարող է լինել պարզ և անհասկանալի, ընկերական և ոչ: Դրա հետ շատ ածականներ են գնում: Բայց մեկում նա մշտական է. նա կա, և դու ոչ մի տեղ չես կարող հեռանալ նրանից:
Ինտերֆեյս- սրանք են օպերացիոն համակարգի օգտատերերի հետ փոխգործակցության կանոնները, ինչպես նաև համակարգչային ցանցում հարևան մակարդակները: Մարդու և համակարգչի միջև կապի տեխնոլոգիան կախված է ինտերֆեյսից:
Ինտերֆեյսնախ և առաջ կանոնների մի շարք է: Ինչպես ցանկացած կանոն, դրանք կարող են ընդհանրացվել, հավաքվել «կոդով», խմբավորվել ըստ ընդհանուր հիմք. Այսպիսով, մենք հասանք «ինտերֆեյսի տիպ» հասկացությանը որպես մարդկանց և համակարգիչների փոխազդեցության ուղիների նմանության համակցություն։ Մենք կարող ենք առաջարկել մարդու և համակարգչի միջև հաղորդակցության տարբեր ինտերֆեյսերի հետևյալ սխեմատիկ դասակարգումը (նկ. 1.):
Փաթեթային տեխնոլոգիա.Պատմականորեն այս տեսակի տեխնոլոգիան առաջինն է հայտնվել: Այն արդեն գոյություն ուներ Սյուեսի և Զուսեի ռելե մեքենաների վրա (Գերմանիա, 1937): Դրա գաղափարը պարզ է. համակարգչի մուտքագրմանը տրամադրվում է նիշերի հաջորդականություն, որում, ըստ որոշակի կանոնների, նշվում է կատարման համար գործարկված ծրագրերի հաջորդականությունը: Հաջորդ ծրագրի կատարումից հետո գործարկվում է հաջորդը և այլն։ Մեքենան, ըստ որոշակի կանոնների, իր համար գտնում է հրամաններ և տվյալներ։ Այս հաջորդականությունը կարող է լինել, օրինակ, դակված ժապավենը, դակված քարտերի կույտ, էլեկտրական գրամեքենայի (CONSUL տիպի) ստեղները սեղմելու հաջորդականությունը։ Մեքենան նաև թողարկում է իր հաղորդագրությունները պերֆորատորի, այբբենական թվային տպիչի (ATsPU), գրամեքենայի ժապավենի վրա:
Նման մեքենան «սև արկղ» է (ավելի ճիշտ՝ «սպիտակ կաբինետ»), որի մեջ անընդհատ սնվում է տեղեկատվություն և որը նույնպես անընդհատ «տեղեկացնում» է աշխարհին իր վիճակի մասին։ Այստեղ մարդը քիչ ազդեցություն ունի մեքենայի աշխատանքի վրա. նա կարող է միայն կասեցնել մեքենայի աշխատանքը, փոխել ծրագիրը և նորից միացնել համակարգիչը: Այնուհետև, երբ մեքենաներն ավելի հզորացան և կարողացան սպասարկել միանգամից մի քանի օգտատերերի, օգտատերերի հավերժական ակնկալիքները, ինչպիսիք են. «Ես տվյալներ եմ ուղարկել սարքին: Սպասում եմ, որ նա պատասխանի: Եվ այն ընդհանրապես կպատասխանի՞»: - դարձավ, մեղմ ասած, նյարդայնացնող։ Բացի այդ, համակարգչային կենտրոնները, թերթերից հետո, դարձել են թղթի երկրորդ խոշորագույն «արտադրողը»։ Հետևաբար, ալֆանա-թվային էկրանների հայտնվելով, սկսվեց իսկապես օգտագործողի համար հարմար տեխնոլոգիայի՝ հրամանի տողի դարաշրջանը:
հրամանի ինտերֆեյս:
Հրամանի միջերեսն այդպես է կոչվում, քանի որ այս տեսակի ինտերֆեյսում մարդը «հրամաններ» է տալիս համակարգչին, իսկ համակարգիչը կատարում է դրանք և արդյունքը տալիս մարդուն։ Հրամանի միջերեսն իրականացվում է որպես խմբաքանակի տեխնոլոգիա և հրամանի տող տեխնոլոգիա:
Այս տեխնոլոգիայի միջոցով ստեղնաշարը ծառայում է որպես անձից համակարգիչ տեղեկատվություն մուտքագրելու միակ միջոցը, իսկ համակարգիչը տվյալ անձին հաղորդում է այբբենական էկրան (մոնիտոր) օգտագործելով: Այս համակցությունը (մոնիտոր + ստեղնաշար) հայտնի դարձավ որպես տերմինալ կամ կոնսոլ։
Հրամանները մուտքագրվում են հրամանի տողում: Հրամանի տողը հուշման նշան է և թարթող ուղղանկյուն՝ կուրսորը: Երբ ստեղնը սեղմվում է, նիշերը հայտնվում են կուրսորի դիրքում, և կուրսորն ինքը շարժվում է դեպի աջ: Հրամանը ավարտվում է Enter (կամ Վերադարձ.) ստեղնը սեղմելով, որից հետո կատարվում է անցում հաջորդ տողի սկզբին։ Հենց այս դիրքից էլ համակարգիչը ցուցադրում է իր աշխատանքի արդյունքները մոնիտորի վրա։ Այնուհետեւ գործընթացը կրկնվում է:
Հրամանի տողերի տեխնոլոգիան արդեն աշխատել է մոնոխրոմ այբբենական թվային էկրանների վրա: Քանի որ թույլատրվում էր մուտքագրել միայն տառեր, թվեր և կետադրական նշաններ, էկրանի տեխնիկական բնութագրերը նշանակալից չէին: Որպես մոնիտոր կարող են օգտագործվել հեռուստատեսային ընդունիչ և նույնիսկ օսցիլոսկոպի խողովակ:
Այս երկու տեխնոլոգիաներն էլ իրականացվում են հրամանի ինտերֆեյսի տեսքով. հրամանները տրվում են մեքենային որպես մուտքագրում, և այն, ինչպես ասվում է, «պատասխանում է» դրանց:
Տեքստային ֆայլերը դարձան ֆայլերի գերակշռող տեսակը հրամանի ինտերֆեյսի հետ աշխատելիս. դրանք և միայն դրանք կարող էին ստեղծվել ստեղնաշարի միջոցով: Հրամանի տողի ինտերֆեյսի ամենալայն օգտագործման ժամանակը UNIX օպերացիոն համակարգի ի հայտ գալն է և առաջին ութ բիթանոց անհատական համակարգիչների հայտնվելը CP/M բազմպլատֆորմ օպերացիոն համակարգով։
WIMP ինտերֆեյս(Պատուհան - պատուհան, Պատկեր - պատկեր, Մենյու - մենյու, Ցուցիչ - ցուցիչ): Այս տեսակի ինտերֆեյսի բնորոշ առանձնահատկությունն այն է, որ օգտագործողի հետ երկխոսությունն իրականացվում է ոչ թե հրամանների, այլ գրաֆիկական պատկերների՝ մենյուների, պատուհանների և այլ տարրերի օգնությամբ: Թեև այս ինտերֆեյսում հրամաններ են տրվում մեքենային, դա արվում է «ուղղակիորեն»՝ գրաֆիկական պատկերների միջոցով: Գրաֆիկական ինտերֆեյսի գաղափարը ծագել է 1970-ականների կեսերին, երբ հետազոտական կենտրոն Xerox Palo Alto հետազոտական կենտրոնը (PARC) մշակել է տեսողական ինտերֆեյսի հայեցակարգ: Գրաֆիկական ինտերֆեյսի նախապայմանն էր կրճատել համակարգչի արձագանքման ժամանակը հրամանին, ավելացնել RAM-ի քանակը, ինչպես նաև համակարգիչների տեխնիկական բազայի զարգացումը։ Հայեցակարգի ապարատային հիմքը, իհարկե, համակարգիչների վրա ալֆանա-թվային էկրանների հայտնվելն էր, և այդ էկրաններն արդեն ունեին այնպիսի էֆեկտներ, ինչպիսիք են նիշերի «թրթռումը», գույնի հակադարձումը (սև ֆոնի վրա սպիտակ նիշերի ոճը հակադարձելը, այսինքն. սև նիշեր սպիտակ ֆոնի վրա), ընդգծող նիշեր: Այս էֆեկտները չեն տարածվում ամբողջ էկրանի վրա, այլ միայն մեկ կամ մի քանի նիշերի վրա: Հաջորդ քայլը գունավոր էկրանի ստեղծումն էր, որը թույլ է տալիս այս էֆեկտների հետ մեկտեղ 16 գույներով սիմվոլներ ֆոնի վրա 8 գույների գունապնակով (այսինքն՝ գունային հավաքածու): Գրաֆիկական էկրանների հայտնվելուց հետո, տարբեր գույների էկրանի վրա բազմաթիվ կետերի տեսքով ցանկացած գրաֆիկական պատկեր ցուցադրելու ունակությամբ, էկրանն օգտագործելու երևակայության սահմաններ չկային: PARC-ի առաջին GUI համակարգը՝ 8010 Star Information System, այսպիսով հայտնվեց 1981 թվականին IBM-ի առաջին համակարգչի թողարկումից չորս ամիս առաջ։ Սկզբում տեսողական ինտերֆեյսը օգտագործվում էր միայն ծրագրերում։ Աստիճանաբար նա սկսեց անցնել օպերացիոն համակարգերին, որոնք օգտագործվում էին սկզբում Atari-ի և Apple Macintosh-ի, այնուհետև IBM-ի հետ համատեղելի համակարգիչների վրա:
Ավելի վաղ ժամանակներից, և նաև այս հասկացությունների ազդեցության տակ, տեղի է ունեցել կիրառական ծրագրերի կողմից ստեղնաշարի և մկնիկի օգտագործման միավորման գործընթաց: Այս երկու միտումների միաձուլումը հանգեցրել է օգտատերերի ինտերֆեյսի ստեղծմանը, որի օգնությամբ անձնակազմի վերապատրաստման վրա ծախսված նվազագույն ժամանակով և գումարով կարող եք աշխատել ցանկացած ծրագրային արտադրանքի հետ։ Այս ինտերֆեյսի նկարագրությունը, որը ընդհանուր է բոլոր հավելվածների և օպերացիոն համակարգերի համար, այս մասի թեման է:
Օգտագործողի գրաֆիկական ինտերֆեյսն իր մշակման ընթացքում անցել է երկու փուլով և իրականացվում է տեխնոլոգիայի երկու մակարդակով՝ պարզ գրաֆիկական ինտերֆեյս և «մաքուր» WIMP ինտերֆեյս։
Առաջին փուլում գրաֆիկական ինտերֆեյսը շատ նման էր հրամանի տողերի տեխնոլոգիային: Հրամանի տողի տեխնոլոգիայի տարբերությունները հետևյալն էին.
Ú Սիմվոլներ ցուցադրելիս թույլատրվում էր սիմվոլների մի մասն ընդգծել գունավոր, շրջված պատկերով, ընդգծված և թարթող: Դրա շնորհիվ պատկերի արտահայտչականությունը մեծացել է։
Ú Կախված գրաֆիկական ինտերֆեյսի կոնկրետ իրագործումից՝ կուրսորը կարող է ներկայացվել ոչ միայն թարթող ուղղանկյունով, այլև մի քանի նիշ և նույնիսկ էկրանի մի մաս ընդգրկող տարածքով: Այս ընտրված տարածքը տարբերվում է այլ, չընտրված մասերից (սովորաբար ըստ գույնի):
Ú Enter ստեղնը սեղմելը միշտ չէ, որ կատարում է հրամանը և անցնում հաջորդ տող: Ցանկացած ստեղն սեղմելու արձագանքը մեծապես կախված է նրանից, թե էկրանի որ մասում էր կուրսորը:
Ú Բացի Enter ստեղնից, ստեղնաշարի վրա աճում է «մոխրագույն» կուրսորային ստեղների օգտագործումը (տես ստեղնաշարի բաժինը այս շարքի 3-րդ համարում):
Ú Արդեն գրաֆիկական ինտերֆեյսի այս հրատարակության մեջ սկսեցին օգտագործվել մանիպուլյատորներ (օրինակ՝ մկնիկ, թրեքբոլ և այլն - տես Նկար Ա.4): Նրանք հնարավորություն տվեցին արագ ընտրել էկրանի ցանկալի հատվածը և շարժել կուրսորը: .
Ամփոփելով՝ մենք կարող ենք տալ այս ինտերֆեյսի հետևյալ տարբերակիչ հատկանիշները.
Ú Նշեք էկրանի տարածքները:
Ú Ստեղնաշարի ստեղների վերաիմաստավորում՝ կախված համատեքստից:
Ú Օգտագործելով մանիպուլյատորներ և ստեղնաշարի մոխրագույն ստեղներ՝ կուրսորը կառավարելու համար:
Ú Գունավոր մոնիտորների լայն օգտագործում:
Այս տեսակի ինտերֆեյսի տեսքը համընկնում է օպերացիոն լայնածավալ օգտագործման հետ MS-DOS համակարգեր. Նա էր, ով այս ինտերֆեյսը ներկայացրեց զանգվածներին, ինչի շնորհիվ 80-ականները նշանավորվեցին այս տեսակի ինտերֆեյսի բարելավմամբ, կերպարների ցուցադրման բնութագրերի բարելավմամբ և մոնիտորի այլ պարամետրերով:
Այս տեսակի ինտերֆեյսի օգտագործման բնորոշ օրինակ է Nortron Commander ֆայլի կեղևը և Multi-Edit տեքստային խմբագրիչը: Տեքստային խմբագրիչներ Lexicon, ChiWriter և բառի պրոցեսոր Microsoft Word Dos-ի համար օրինակներ են, թե ինչպես է այս ինտերֆեյսը գերազանցել իրեն:
Գրաֆիկական ինտերֆեյսի մշակման երկրորդ փուլը եղել է «մաքուր» WIMP ինտերֆեյսը:Ինտերֆեյսի այս ենթատեսակին բնորոշ են հետևյալ հատկանիշները.
Ú Ծրագրերի, ֆայլերի և փաստաթղթերի հետ բոլոր աշխատանքները կատարվում են պատուհաններում՝ էկրանի որոշակի հատվածներ, որոնք ուրվագծված են շրջանակով:
Ú Բոլոր ծրագրերը, ֆայլերը, փաստաթղթերը, սարքերը և այլ օբյեկտները ներկայացված են որպես պատկերակներ՝ պատկերակներ: Երբ բացվում է, պատկերակները վերածվում են պատուհանների:
Ú Օբյեկտների հետ բոլոր գործողությունները կատարվում են մենյուի միջոցով: Չնայած մենյուն հայտնվել է գրաֆիկական ինտերֆեյսի մշակման առաջին փուլում, այն չուներ գերիշխող նշանակություն, այլ ծառայում էր միայն որպես հրամանի տողի հավելում։ Մաքուր WIMP ինտերֆեյսում ընտրացանկը դառնում է կառավարման հիմնական տարրը:
Ú Մանիպուլյատորների լայնածավալ օգտագործում՝ առարկաները մատնանշելու համար: Մանիպուլյատորը դադարում է լինել պարզապես խաղալիք՝ ստեղնաշարի հավելում, բայց դառնում է կառավարման հիմնական տարրը: Մանիպուլյատորի օգնությամբ նրանք մատնացույց են անում էկրանի ցանկացած հատված, պատուհաններ կամ պատկերակներ, ընտրում են այն և միայն դրանից հետո մենյուի միջոցով կամ այլ տեխնոլոգիաների միջոցով կառավարում են դրանք։
Հարկ է նշել, որ WIMP-ն իր իրականացման համար պահանջում է գունավոր bitmap ցուցադրում բարձր լուծումև մանիպուլյատոր: Նաև այս տեսակի ինտերֆեյսի վրա ուղղված ծրագրերը մեծացնում են պահանջները համակարգչի աշխատանքի, հիշողության չափի, ավտոբուսի թողունակության և այլնի նկատմամբ: Այնուամենայնիվ, այս տեսակի ինտերֆեյսը ամենահեշտն է սովորելն ու ինտուիտիվը: Հետևաբար, այժմ WIMP - ինտերֆեյսը դարձել է դե ֆակտո ստանդարտ:
Գրաֆիկական ինտերֆեյս ունեցող ծրագրերի վառ օրինակ է օպերացիոն համակարգ Microsoft Windows.
ՄԵՏԱՔՍ- ինտերֆեյս (Խոսք - խոսք, Պատկեր - պատկեր, Լեզու - լեզու, Գիտելիք - գիտելիք): Այս տեսակի ինտերֆեյսը ամենամոտ է հաղորդակցության սովորական, մարդկային ձևին: Այս ինտերֆեյսի շրջանակներում նորմալ «զրույց» է տեղի ունենում մարդու եւ համակարգչի միջեւ։ Միաժամանակ, համակարգիչը իր համար հրամաններ է գտնում՝ վերլուծելով մարդկային խոսքը և գտնելով նրանում հիմնական արտահայտությունները։ Այն նաև փոխակերպում է հրամանի կատարման արդյունքը մարդու կողմից ընթեռնելի ձևի: Այս տեսակի ինտերֆեյսը ամենախստապահանջն է համակարգչի ապարատային ռեսուրսների նկատմամբ, և, հետևաբար, այն օգտագործվում է հիմնականում ռազմական նպատակներով:
90-ականների կեսերից, էժան ձայնային քարտերի հայտնվելուց և խոսքի ճանաչման տեխնոլոգիաների համատարած օգտագործումից հետո, հայտնվեց SILK ինտերֆեյսի այսպես կոչված «խոսքի տեխնոլոգիան»։ Այս տեխնոլոգիայով հրամանները տրվում են ձայնային՝ արտասանելով հատուկ վերապահված բառեր՝ հրամաններ։
Բառերը պետք է արտասանվեն հստակ, նույն արագությամբ: Բառերի միջև դադար է լինում։ Խոսքի ճանաչման ալգորիթմի թերզարգացման պատճառով նման համակարգերը պահանջում են անհատական նախադրումյուրաքանչյուր կոնկրետ օգտագործողի համար:
«Խոսքի» տեխնոլոգիան SILK ինտերֆեյսի ամենապարզ իրականացումն է:
Կենսաչափական տեխնոլոգիա («Mimic Interface»)
Այս տեխնոլոգիան առաջացել է 1990-ականների վերջին և դեռ մշակվում է այս գրելու պահին: Համակարգիչը կառավարելու համար օգտագործվում են մարդու դեմքի արտահայտությունը, հայացքի ուղղությունը, աշակերտի չափը և այլ նշաններ։ Օգտատիրոջ նույնականացման համար օգտագործվում է նրա աչքերի ծիածանաթաղանթի նախշը, մատնահետքերը և այլ յուրահատուկ տեղեկություններ։ Պատկերները կարդացվում են թվային տեսախցիկից, այնուհետև հրամաններ են հանվում այս պատկերից՝ օգտագործելով պատկերների ճանաչման հատուկ ծրագրեր: Այս տեխնոլոգիան, ամենայն հավանականությամբ, կզբաղեցնի իր տեղը ծրագրային արտադրանքև հավելվածներ, որտեղ կարևոր է ճշգրիտ նույնականացնել համակարգչի օգտագործողին:
Ամեն անգամ, երբ միացնում եք ձեր համակարգիչը, գործ ունեք օգտագործողի ինտերֆեյս(Օգտվողի ինտերֆեյս, UI), որը թվում է պարզ և ակնհայտ, բայց այն դարձնելու համար մեծ աշխատանք է ներդրվել ոլորտում: Եկեք հետ նայենք 1990-ականներին, երբ սեղանադիր համակարգիչներդարձել են ամենուր, և մենք կտանք UI տեխնոլոգիաների զարգացման ժամանակագրությունը: Նկատի ունեցեք նաև, թե ինչպես են զարգացել UI ծրագրավորման գործիքները և ինչ են դրանք այսօր: Աղյուսակում. 1-ը ցույց է տալիս UI-ի մշակման հիմնական խնդիրների ցանկը, որի հիման վրա իրականացվել է օգտատերերի միջերեսների ներդրման տարբեր տեխնոլոգիաների վերլուծություն՝ բաժանված կատեգորիաների: Այս կատեգորիաներից յուրաքանչյուրը ներառում է տեխնոլոգիաներ, որոնք մոտավորապես նույն կերպ են լուծում մեկ կամ մի քանի խնդիրներ:
DBMS-կապված մուտքագրման ձևեր
UI-ի մշակման գործիքների հիմնական կատեգորիաներից մեկը ձևավորվում է այն գործիքներով, որոնք կենտրոնացած են տվյալների մուտքագրման ձևերի վրա՝ հղում կատարելով հարաբերական DBMS-ին: Այս մոտեցման էությունը հավելվածների համար միջերես ստեղծելն է՝ ստեղծելով ձևեր, որոնք ցուցադրում են տվյալների բազայի դաշտերի արժեքները համապատասխան հսկիչներում՝ տեքստային դաշտեր, ցուցակներ, վանդակներ, աղյուսակներ և այլն: Գործիքակազմը թույլ է տալիս նավարկելու նման ձևավորել և հաստատել ուղղակի կապ տարրերի կառավարման և տվյալների բազայի միջև: Մշակողը կարիք չունի անհանգստանալու կողպեքների, տվյալների փոխանցման, վերափոխման և թարմացման մասին. երբ օգտագործողը, օրինակ, փոխում է ռեկորդային համարը ձևի մեջ, դրա մյուս դաշտերը ինքնաբերաբար թարմացվում են: Նմանապես, եթե օգտատերը փոխում է արժեքը դաշտում, որը կապված է տվյալների բազայից որևէ գրառումի հետ, այս փոփոխությունն անմիջապես պահվում է դրանում: Դրան հասնելու համար ձեզ հարկավոր չէ հատուկ կոդ գրել, պարզապես հայտարարեք հսկողության կամ ամբողջ ձևի կապը տվյալների աղբյուրին: Այսպիսով, այս կատեգորիայի գործիքներում տվյալների պարտադիր աջակցությունը այս մեթոդի ուժեղ կողմերից մեկն է: Նման միջավայրերում UI դասավորության և ոճավորման խնդիրները լուծվում են ձևաստեղծների և մասնագիտացված օբյեկտի վրա հիմնված API-ների օգնությամբ: Իրադարձությունների մշակողները (որոնք մշակման միջավայրի հիմնական ծրագրավորման լեզվով իրականացվող մեթոդներն են) սովորաբար տրամադրվում են UI-ի վարքագիծը վերահսկելու համար, մինչդեռ արտահայտությունները (ներառյալ կանոնավոր արտահայտությունները) օգտագործվում են մուտքային արժեքները վերահսկելու համար: Գործիքների այս բազմաթիվ կատեգորիայի տիպիկ ներկայացուցիչներն են Microsoft Access-ը և Oracle Forms-ը:
Կաղապարային պրոցեսորներ
Նշման լեզուներով կիրառվող կաղապարների հիման վրա օգտագործողի միջերեսներ ստեղծելու տեխնոլոգիաները լայնորեն կիրառվում են 1990-ականների կեսերից: Կաղապարների հիմնական առավելություններն են դինամիկ վեբ ինտերֆեյսի ստեղծման ճկունությունն ու հնարավորությունների լայնությունը, հատկապես կառուցվածքի և դասավորության նախագծման առումով: Վաղ օրերին այս գործիքակազմերն օգտագործում էին ձևանմուշներ, որոնցում UI-ի դասավորությունը և կառուցվածքը նշվում էր նշագծման լեզվի միջոցով, և տվյալների կապը կատարվում էր բարձր մակարդակի լեզվի փոքր բլոկների միջոցով (Java, C#, PHP, Python և այլն): ) Վերջինս կարող է օգտագործվել նշագծման հետ համատեղ. Օրինակ, նշագծման պիտակները հանգույցի մեջ ներարկելով, Java-ն կարող է ստեղծել կրկնվող վիզուալներ, ինչպիսիք են աղյուսակները և ցուցակները: Վեբ էջի ներսում հաճախակի շարահյուսությունը փոխելու անհրաժեշտությունը դժվարացրեց ծրագրավորողների համար մշակել և ուղղել կոդը, այնպես որ մոտ մեկ տասնամյակ առաջ անցում սկսվեց բարձր մակարդակի լեզուներից դեպի մասնագիտացված նշագրման պիտակների գրադարաններ և արտահայտման լեզուներ, որոնք ստեղծվել էին հատուկ համար: վեբ տեխնոլոգիաներ.
Նշման պիտակները սկսեցին օգտագործվել վեբ հավելվածների բնորոշ գործառույթներն իրականացնելու համար, իսկ արտահայտությունները օգտագործվեցին սերվերի օբյեկտներում պահվող տվյալների և զանգերի գործառույթներ մուտք գործելու համար: բնորոշ ներկայացուցիչԱյս խումբը JavaServer Pages (JSP) տեխնոլոգիան է, որի պիտակների գրադարանը JSP Standard Tag Library-ն աջակցում է այնպիսի խնդիրների, ինչպիսիք են XML փաստաթղթերի մանիպուլյացիա, հանգույցներ, պայմաններ, DBMS հարցում (տվյալների կապում) և միջազգայնացում (տվյալների ձևաչափում): JSP Expression Language - EL, որը ծառայում է որպես տվյալների կապող գործիք, առաջարկում է հարմար նշում օբյեկտների և հավելվածների հետ աշխատելու համար:
Կան մի շարք վեբ մշակման գործիքներ, որոնք նման են JSP-ներին. կառուցվածքը պլանավորելու և կարգավորելու համար (նրանք օգտագործում են ձևանմուշներ), տվյալների կապակցման համար՝ օգտագործելով արտահայտությունների լեզուն, և միջերեսի վարքագիծը նշվում է ECMAScript լեզվի և Document Object ծրագրավորման ինտերֆեյսի միջոցով իրականացվող իրադարձությունների մշակիչների միջոցով: Մոդել. Տվյալների ձևաչափումն իրականացվում է հատուկ պիտակների գրադարանների միջոցով, CSS (Cascading Style Sheets) սովորաբար օգտագործվում է արտաքին տեսքը ոճավորելու համար: Այս կատեգորիայի գործիքների հայտնի ներկայացուցիչներն են ASP, PHP, Struts, WebWork, Struts2, Spring MVC, Spyce և Ruby on Rails:
Օբյեկտ ուղղված և իրադարձությունների գործիքներ
Միջերեսի ստեղծման գործիքների զգալի մասը հիմնված է օբյեկտի վրա հիմնված մոդելի վրա: Սովորաբար, այս գործիքակազմերն առաջարկում են նախապես կառուցված UI տարրերի գրադարան, և դրանց հիմնական առավելություններն են պարզ բաղադրիչներից բազմակի օգտագործման բլոկներ ստեղծելու հեշտությունը և իրադարձությունների մշակիչների վրա հիմնված ինտուիտիվ, ճկուն վարքագիծը և փոխազդեցության ծրագրավորման գործընթացը: Այս գործիքակազմերում UI-ի մշակման բոլոր առաջադրանքները լուծվում են մասնագիտացված օբյեկտների API-ների միջոցով: Այս կատեգորիան ներառում է միջավայրեր՝ Visual Basic, MFC, AWT, Swing, SWT, Delphi, Google Web Toolkit, Cocoa Touch UIKit, Vaadin և այլն: Սա ներառում է նաև Nokia Qt գործիքակազմը, որն առաջարկում է մի շարք օրիգինալ գաղափարներ: Որոշ գործիքների հավաքածուներում UI կառուցվածքի տարրերի միջև փոխազդեցության ողջ բարդությունն իրականացվում է իրադարձությունների մշակիչների միջոցով, իսկ Qt-ում, բացի դրանցից, կան «ազդանշաններ» և «slots». ազդանշանը փոխանցվում է UI բաղադրիչի կողմից, երբ իրադարձություն է տեղի ունենում. որոշակի իրադարձություն. Սլոտը մեթոդ է, որը կոչվում է ի պատասխան կոնկրետ ազդանշանի, որը կարող է դեկլարատիվ կերպով կապված լինել ցանկացած թվով սլոտների հետ, և հակառակը, մեկ բնիկը կարող է ստանալ այնքան ազդանշան, որքան ցանկանում եք: Ազդանշանը փոխանցող տարրը «չգիտի», թե որ բնիկն այն կստանա։ Այսպիսով, օգտատիրոջ միջերեսի տարրերը թույլ զուգակցվում են ազդանշանային բնիկ միացումներով: Այս մեխանիզմը նպաստում է ինկապսուլյացիայի սկզբունքի կիրառմանը և հնարավորություն է տալիս դեկլարատիվ կերպով սահմանել UI-ի վարքագիծը:
հիբրիդներ
Հիբրիդային տեխնոլոգիաները համեմատաբար նոր են ընդհանուր նշանակության UI-ի մշակման աշխարհում. կաղապարների և արտահայտությունների լեզուների հետ մեկտեղ, նման գործիքակազմերն օգտագործում են օբյեկտի API: Տիպիկ ներկայացուցիչը JavaServer Faces-ն է. պիտակների գրադարաններն օգտագործվում են կառուցվածքը և դասավորությունը նկարագրելու, ինչպես նաև տվյալների ձևաչափման համար; արտահայտման լեզու - տարրեր և իրադարձություններ սերվերի օբյեկտներին և հավելվածի կոդին կապելու համար. օբյեկտի API - տարրեր ցուցադրելու, դրանց վիճակը կառավարելու, իրադարձությունների կառավարման և մուտքագրումը վերահսկելու համար: Այս կատեգորիայի այլ հայտնի գործիքների հավաքածուները ներառում են ASP.NET MVC, Apache Wicket, Apache Tapestry, Apache Click և ZK Framework:
Adobe Flex-ը կոնցեպտուալ առումով մոտ է այս կատեգորիայի տեխնոլոգիաներին, քանի որ այն օգտագործում է կաղապարներ կառուցվածքի և դասավորության համար, իսկ ծրագրավորումն ամբողջությամբ կատարվում է ActionScript-ով: Ինչպես Qt-ն, այնպես էլ Flex շրջանակն ապահովում է վարքի ծրագրավորման և տվյալների կապակցման հետ կապված խնդիրների լուծման մեխանիզմ:
Դեկլարատիվ գործիքների հավաքածուներ
Նման գործիքներն են նորագույն միտում UI մշակման գործիքների ոլորտում։ Նրանք օգտագործում են XML և JSON (JavaScript Object Notation) վրա հիմնված լեզուներ՝ օգտատիրոջ ինտերֆեյսի կառուցվածքը ճշտելու համար, մինչդեռ դեկլարատիվ նշումը հիմնականում օգտագործվում է UI մշակման այլ առաջադրանքների համար: Ի տարբերություն հիբրիդային մոտեցումների, որոնք հիմնականում նախատեսված են վեբ ինտերֆեյսների համար, դեկլարատիվ մոտեցումներն օգտագործվում են նաև բջջային և աշխատասեղանի հարթակների համար հայրենական հավելվածների մշակման ժամանակ։
Android օգտատիրոջ միջերեսի API-ն իրադարձությունների վրա հիմնված է, օբյեկտի վրա հիմնված, բայց հիմնականի հետ մեկտեղ ՕՀ-ն ունի XML-ի վրա հիմնված օժանդակ API, որը թույլ է տալիս հայտարարել օգտատիրոջ ինտերֆեյսի կառուցվածքն ու դասավորությունը, ինչպես նաև ոճավորել դրա տարրերը: և կառավարել դրանց հատկությունները: Ինտերֆեյսի դեկլարատիվ նկարագրությունը ավելի հստակ ցույց է տալիս դրա կառուցվածքը և օգնում է վրիպազերծել. թույլ է տալիս փոխել դասավորությունը առանց վերակազմավորման; օգնում է հարմարվել տարբեր հարթակներին, էկրանի չափերին և կողմերի հարաբերակցությանը: Օգտվողի ավելի դինամիկ միջերեսներ ստեղծելիս կարող եք նաև ծրագրային կերպով նշել և փոխել տարրերի կառուցվածքը՝ օգտագործելով օբյեկտային API-ներ, սակայն տվյալների կապը չի ապահովվում: Այնուամենայնիվ, կա Android-Binding՝ երրորդ կողմի բաց կոդով լուծում, որը թույլ է տալիս կապել UI տարրերը տվյալների մոդելներին:
Դուք կարող եք ստեղծել UI Windows ծրագրերի և հարուստ ինտերնետային հավելվածների համար՝ համապատասխանաբար Windows Platform Foundation և Microsoft Silverlight տեխնոլոգիաների հիման վրա՝ օգտագործելով մեկ այլ XML բառապաշար՝ eXtensible Application Markup Language (XAML): Այն թույլ է տալիս սահմանել UI-ի կառուցվածքը, դասավորությունը և ոճը, և, ի տարբերություն Android-ի նշագրման լեզվի, այն աջակցում է տվյալների կապակցմանը և իրադարձությունները վարելու կարողությանը:
Nokia-ն առաջարկում է Qt Quick-ը, որը բազմպլատֆորմային գործիքակազմ է աշխատասեղանի, շարժական և ներկառուցված օպերացիոն համակարգերի համար, որն աջակցում է QML (JSON շարահյուսության վրա հիմնված դեկլարատիվ սկրիպտային լեզու): Օգտվողի միջերեսի նկարագրությունն ունի հիերարխիկ կառուցվածք, և վարքագիծը ծրագրավորված է ECMAScript-ում: Այստեղ, ինչպես սովորական Qt-ում, աջակցվում է ազդանշանային բնիկի մեխանիզմը: Qt Quick-ն աջակցում է UI տարրերի հատկությունները տվյալների մոդելի հետ կապելու կարողությանը, ինչպես նաև պետական մեքենայի հայեցակարգին, որը թույլ է տալիս գրաֆիկորեն մոդելավորել ինտերֆեյսի վարքագիծը:
Մեկ այլ օրինակ է Enyo-ն՝ միջպլատֆորմային ECMAScript UI գործիքակազմը, որում ինտերֆեյսի կառուցվածքը դեկլարատիվ է, իսկ վարքագիծը վերահսկվում է իրադարձությունների մշակողների կողմից: Իրադարձությունները մշակվում են երեք եղանակով՝ անհատական UI բաղադրիչների մակարդակով, երեխայից ծնողին անցնելով առանց ուղղակի կապի, ինչպես նաև հեռարձակելով և բաժանորդագրվելով նման հաղորդագրություններին (նաև առանց ուղղակի կապի): UI-ի տարրերի թույլ միացումը մեծացնում է ինտերֆեյսի մեծ բեկորների կրկնակի օգտագործման հնարավորությունը և պարփակումը: Ըստ էության, Enyo-ի հիմնական ուժը նրա պարփակման մոդելն է, որը թույլ է տալիս UI-ին կազմված լինել բազմակի օգտագործման, ինքնամփոփ շինարարական բլոկներից՝ սահմանված միջերեսներով: Այս մոդելը նպաստում է աբստրակցիային և ընդգրկում է UI-ի բոլոր ճարտարապետական մակարդակները: Enyo նախագծի անդամներն աշխատում են տվյալների պարտադիր աջակցության իրականացման վրա:
Eclipse XML Window Toolkit-ը ևս մեկ գործիքակազմ է, որը կենտրոնացած է դեկլարատիվ UI նկարագրության վրա: Նրա ստեղծման սկզբնական նպատակն էր միավորել Eclipse-ում UI-ի մշակման բոլոր գործիքները, ներառյալ SWT, JFace, Eclipse Forms և այլն. դրանց բոլոր տարրերն այս կամ այն կերպ ունեն համապատասխանություն XWT-ում: UI-ի կառուցվածքը և դասավորությունը XWT-ում նշվում է XML-ի վրա հիմնված լեզվի միջոցով, իսկ արտահայտման լեզուն օգտագործվում է տվյալների կապակցման համար (հավելվածի Java-ի օբյեկտներ մուտք գործելու համար): Իրադարձությունների մշակումը ծրագրավորված է Java-ում, և CSS-ն օգտագործվում է ինտերֆեյսի տարրերը ոճավորելու համար: XWT հավելվածի կատարման մեխանիզմն իրականացվում է որպես Java հավելված և ActiveX տարր, ինչը նշանակում է, որ այն կարող է աշխատել գրեթե ցանկացած բրաուզերում:
Այս կատեգորիայում կան բազմաթիվ նմանատիպ գործիքներ. AmpleSDK-ն, օրինակ, օգտագործում է XUL-ը որպես UI նկարագրության լեզու, ECMAScript ֆունկցիաները՝ դինամիկ վարքագիծը ծրագրավորելու համար, CSS՝ ոճավորման համար: Dojo Toolkit-ը սահմանում է ինտերֆեյսը դեկլարատիվ կերպով և ապահովում է նախապես սահմանված տարրերի լայն շրջանակ, օբյեկտների պահեստավորում տվյալների հասանելիության համար և ECMAScript-ի վրա հիմնված իրադարձությունների մշակիչ՝ հրապարակում-բաժանորդագրման մեխանիզմով: Գործիքակազմն աջակցում է միջազգայնացմանը, տվյալների առաջադեմ հարցաքննության API-ին, մոդուլյարացմանը և բազմակի դասային ժառանգությանը:
Մոդելների վրա հիմնված գործիքակազմեր
UI-ի զարգացման տեխնոլոգիաների զգալի մասը հիմնված է մոդելների և տիրույթի հատուկ լեզուների վրա: Հիմնականում դրանք ինտերֆեյսի մոդելներ են, բայց կարող են օգտագործվել նաև տիրույթի մոդելներ։ Երկու դեպքում էլ մոդելն անհրաժեշտ է օգտատիրոջ միջերեսը նախօրոք ստեղծելու համար կամ մեկնաբանվում է գործարկման ժամանակ: Տեխնոլոգիաների այս դասը բարձրացնում է աբստրակցիայի մակարդակը, ապահովում է բարելավված համակարգված մեթոդներ օգտատերերի միջերեսների նախագծման և ներդրման համար և ապահովում է հարակից առաջադրանքների ավտոմատացման շրջանակ: Այնուամենայնիվ, որոշ հետազոտողների կարծիքով, մոդելների վրա հիմնված տեխնոլոգիաները չեն ապահովում օգտատիրոջ միջերեսը հավելվածի հետ ինտեգրելու ունիվերսալ միջոց, և դեռևս համաձայնություն չկա, թե մոդելների որ հավաքածուն է լավագույնս համապատասխանում միջերեսը նկարագրելու համար: Տվյալների կապակցման խնդիրը չի լուծվել, և մոդելները չեն համակցվել UI-ի մշակման այլ առաջադրանքներ լուծելու համար:
Վերլուծելով 1990-ականներից սկսած UI-ի մշակման մոդելային մոտեցումների սերունդները, կարելի է եզրակացնել, որ այսօր ընդհանուր առմամբ ընդունված է ընկալում վերացականության մակարդակների և ժամանակակից օգտատերերի միջերեսների մշակման համար հարմար մոդելների տեսակների մասին, բայց դեռևս չկա: կոնսենսուս (ստանդարտներ) տեղեկատվության (իմաստաբանության) վերաբերյալ, որը պետք է պարունակի տարբեր մոդելներ. Առաջադրանքների, երկխոսությունների և ներկայացումների մոդելները կարելի է համարել հիմնական. ներկայացման մոդելը լուծում է կառուցվածքի, պլանավորման և ոճավորման խնդիրները. առաջադրանքի մոդելը պատասխանատու է տվյալների հետ կապելու համար. յուրաքանչյուր առաջադրանքի համար նշվում են UI և տրամաբանական օբյեկտներ, որոնց հետ պետք է աշխատել. երկխոսության մոդելն ընդգրկում է վարքային ասպեկտները: Առաջադրանքի մոդելի օրինակ է Concurrent-TaskTrees-ը (CTT), որը կարող է օգտագործվել MARIA լեզվի հետ համատեղ, որն իրականացնում է UI-ի մնացած մոդելները: CTT-ը զուգակցված MARIA-ի հետ մոդելի վրա հիմնված ամբողջական գործիքակազմ է: UI մոդելավորողների բավականին մեծ ընտանիքը նույնպես ապավինում է UML-ին, կազմակերպությունների հարաբերությունների մոդելներին կամ նմաններին: UML պրոֆիլները լայնորեն օգտագործվում են բիզնես հավելվածների համար օգտագործողների միջերեսներ ստեղծելու համար: Կան նաև ակտիվորեն օգտագործվող այլ գործիքներ, օրինակ՝ WebRatio, UMLi, Intellium Virtual Enterprise և SOLoist:
Ընդհանուր օգտագործողի միջերեսներ
UI տեխնոլոգիաների փոքր, բայց նշանակալի ենթաբազմությունը ստեղծում է UI՝ հիմնված օգտագործողի, տվյալների, առաջադրանքի կամ այլ տեսակի կիրառական մոդելների վրա: Ինտերֆեյսը ստեղծվում է ամբողջ մոդելի հիման վրա կամ կիսաավտոմատ: Մոդելները կարող են նաև մեկնաբանվել գործարկման ժամանակ՝ առանց ինտերֆեյսի ստեղծման հիմք օգտագործելու: Ամեն դեպքում, UI շենքերի ավտոմատացման բարձր մակարդակի պատճառով այս կատեգորիայի տեխնոլոգիաները խնայում են մշակողի ժամանակը և նվազեցնում սխալների թիվը, իսկ գեներացված ինտերֆեյսները ունեն միատեսակ կառուցվածք։ Այնուամենայնիվ, ընդհանուր UI-ները ճկուն չեն, ունեն սահմանափակ ֆունկցիոնալություն և ունեն անկանխատեսելի ստեղծման գործընթաց: Այնուամենայնիվ, տիրույթի մոդելի հետ անմիջական կապի դեպքում միանգամայն հնարավոր է ընդհանուր UI-ներով հավելվածների մշակումը։ Այս կատեգորիայի մոտ մեկ տասնյակ օրինակներ կան, որոնք գլխավորում են լայնորեն կիրառվող «Մերկ օբյեկտներ» ճարտարապետական նախշը: UI-ի ավտոմատ ստեղծումը կարող է հաջողությամբ կիրառվել որոշակի առարկայական ոլորտներում, օրինակ՝ համակարգերի հեռակառավարման համար երկխոսության տուփերի և ինտերֆեյսների նախագծման մեջ: Հետագա զարգացումՀետազոտողները տեխնոլոգիաների այս դասը տեսնում են մոդելավորման տեխնիկայի բարելավման և մոդելների համակցման նոր ուղիներ գտնելու մեջ՝ գեներացված միջերեսների օգտագործելիությունը բարելավելու համար:
Միտումներ և մարտահրավերներ
Նկարը ցույց է տալիս UI մշակման տարբեր գործիքների տեսքի ժամանակագրությունը, դրանց բաշխումն ըստ կատեգորիաների և կիրառման հիմնական ոլորտների, ինչպես նաև Աղյուսակում: 2-ը ցույց է տալիս այն ուղիները, որոնցով տեխնոլոգիաներից յուրաքանչյուրը լուծում է UI-ի զարգացման տարբեր խնդիրներ:
Ընդհանուր օգտագործվող տեխնոլոգիաների մշակման համար վեբ մշակումը բնութագրվում է երկու հակադիր միտումներով. Կաղապարների վրա հիմնված տեխնոլոգիաներից հետո հայտնվեցին օբյեկտի վրա հիմնված API-ներով գործիքակազմեր, որոնք ամենից հաճախ լրացվում էին կաղապարներով (հիբրիդային մոտեցումների դեպքում) կամ ամբողջությամբ փոխարինում դրանք (GWT և Vaadin): Սկզբունքորեն, սա միանգամայն տրամաբանական է, հաշվի առնելով օբյեկտի վրա հիմնված լեզուների ընդհանուր առավելությունը կաղապարային լեզուների նկատմամբ (ժառանգություն, պոլիմորֆիզմ, պարփակում, պարամետրիզացիա, վերօգտագործելիություն և այլն), ընդարձակ UI կազմման առաջադեմ հասկացությունների և մեխանիզմների անհրաժեշտությունը: կառուցվածքները, ինչպես նաև աշխատասեղանի դարաշրջանում օբյեկտի վրա հիմնված API-ների «պատմական հաջողությունը»:
Հատկանշական է, որ UI-ի ձևավորման հրամայական և առարկայական մեթոդների համեմատ այսօր ավելի լայն կիրառություն են ստացել դեկլարատիվները, օրինակ՝ HTML, XML, XPath, CSS, JSON և նմանատիպ նշումները: UI-ի կառուցվածքի մեծ մասը սովորաբար ստատիկ է, ուստի դեկլարատիվ նշումները հիանալի են կառուցվածքի, դասավորության և տվյալների կապակցման համար: Բայց UI-ի վարքագծային ասպեկտները դեռևս իրականացվում են դասական իրադարձությունների վրա հիմնված պարադիգմի համաձայն, չնայած կան բացառություններ, երբ օգտագործվում են դեկլարատիվ միջոցներ:
UI-ի զարգացման նկատելի միտում է կենտրոնացումը ստանդարտ տեխնոլոգիաների և հարթակների վրա: XML-ը և ECMAScript-ն այժմ ավելի տարածված են, քան երբևէ, չնայած մասնագիտացված տեխնոլոգիաները, հատկապես մոդելների վրա հիմնված, ակտիվորեն մրցում են բարձր տեխնիկական չափանիշներով բնակելի տարածքի համար:
Կան մի քանի մարտահրավերներ, որոնք սպասում են լուծելու զարգացման գործիքների վաճառողները և դրանք սահմանելու համար պահանջվող շերտավոր ճարտարապետությունները: Մեծածավալ բիզնես հավելվածների համար օգտագործողի միջերեսները հաճախ հարյուրավոր կամ ավելի էջեր են կազմում, և նման դեպքերում համակարգի ճարտարապետության հստակ ակնարկը բացարձակապես կարևոր է: Գոյություն ունի մոդելավորման նոր տեխնիկա, որը լուծում է այս խնդիրը՝ ներդնելով պարկուճի հայեցակարգը, որն ապահովում է UI բեկորների ուժեղ ինկապսուլյացիա և թույլ է տալիս ճշտել ճարտարապետությունը տարբեր մակարդակներմանրամասն. Պարկուճն արդեն ունի ներքին կառուցվածքը, որը կարող է հետևողականորեն կիրառվել ռեկուրսիվ կերպով UI բաղադրիչների բոլոր ցածր մակարդակներում: Enyo-ի և WebML-ի մշակողները փորձում են լուծել նմանատիպ խնդիր։
Գործիքների աջակցության ճկունությունը, ընդարձակելիությունը և լայնությունը UI զարգացման ընդհանուր տեխնոլոգիաների իրական առավելություններն են, բայց մինչ այժմ դրանք տուժում են. ցածր մակարդակվերացականություն և արտահայտման բացակայություն: Մյուս կողմից, մոդելի վրա հիմնված մոտեցումները պետք է խուսափեն UI-ի ցածր մակարդակի մոդելներից իմաստաբանությունից ժառանգելուց, այլապես վերացական օգտագործողի միջերեսի մոդելները կարող են դառնալ նույնքան բարդ, որքան բուն UI իրականացումը: UI-ի տիրույթից և կիրառական մոդելների իմաստաբանությունից գիտելիքներ օգտագործելու փոխարեն, UI դիզայներներից դեռ պահանջվում է ուղղակիորեն աշխատել ցածր մակարդակի բաղադրիչների հետ՝ երկխոսության տուփեր, ընտրացանկեր և իրադարձությունների մշակիչներ:
UI-ի զարգացման տեխնոլոգիաներն ունեն ևս մեկ լուրջ խնդիր՝ կապված բազմաթիվ թիրախային հարթակների հարմարվողականության պահանջների հետ, որոնք բնորոշ են բոլոր ժամանակակից ինտերակտիվ հավելվածներին։ Բարեբախտաբար, մոդելային կողմնորոշված համայնքը ժամանակին արձագանքեց. 2003-ին առաջարկվեց միացնող ունիվերսալ ճարտարապետություն բազմպլատֆորմ UI-ներ կառուցելու համար օգտագործվող գործընթացների, մոդելների և մեթոդների համար:
Հաշվողական սարքերի և պլատֆորմների ներկայիս բազմազանությունը ինչ-որ չափով հիշեցնում է 90-ականների վերջին աշխատասեղանի դարաշրջանը՝ տարբեր վաճառողների կողմից առաջարկվող օգտատերերի ինտերֆեյս ստեղծելու գործիքների առատությամբ: Մինչ օրս HTML5-ը դեռ չի լուծել տեխնոլոգիական տարաձայնությունների խնդիրը՝ ապարատային առանձնահատկությունների և ծրագրավորման ինտերֆեյսների սահմանափակ աջակցության պատճառով: Ի վերջո, ինչպես շատ ծրագրային ապահովման ինժեներական խնդիրների դեպքում, UI-ի մշակումն այսօր պահանջում է հստակ և պարզ լուծումներ, սակայն դրանք ստեղծողներից պահանջում են անհավատալի ներդրման ջանքեր:
գրականություն
- Պ.Պ. Դա Սիլվա. Օգտատիրոջ միջերեսի դեկլարատիվ մոդելներ և զարգացման միջավայրեր. հարցում: Պրոց. Ինտերակտիվ համակարգեր. դիզայն, ճշգրտում և ստուգում, Springer, 2000, էջ 207-226:
- G. Meixner, F. Paterno, J. Vanderdonckt. Մոդելի վրա հիմնված օգտագործողի միջերեսի մշակման անցյալը, ներկան և ապագան // i-com. 2011.հատ. 10, N3, Հ.2-11.
- G. Mori, F. Paterno, C. Santoro. CTTE. Աջակցություն ինտերակտիվ համակարգերի նախագծման համար առաջադրանքների մոդելների մշակման և վերլուծության համար // IEEE Trans. SoftwareEng. 2002, հատ. 28, N8, P. 797-813:
Ժարկո Միյալովիչ([էլփոստը պաշտպանված է]) - ավագ ինժեներ, Դրագան Միլիչև([էլփոստը պաշտպանված է]) - Բելգրադի համալսարանի դոցենտ։
Zarko Mijailovic, Dragan Milicev, A Retrospective on User Interface Development Technology, IEEE Software, նոյեմբեր/դեկտեմբեր 2013, IEEE Computer Society: Բոլոր իրավունքները պաշտպանված են. Վերատպվել է թույլտվությամբ։
Կլեշչև Ա.Ս., Գրիբովա Վ.Վ. 25.03.2001թ
Ինտերֆեյսը կարևոր է ցանկացած ծրագրային համակարգի համար և հանդիսանում է դրա անբաժանելի մասը՝ կենտրոնացած հիմնականում վերջնական օգտագործողի վրա: Ինտերֆեյսի միջոցով է, որ օգտագործողը դատում է հավելվածը որպես ամբողջություն. ավելին, օգտատերը հաճախ որոշում է կայացնում հավելվածից օգտվել՝ հիմնվելով այն բանի վրա, թե որքանով է հարմարավետ և հասկանալի ինտերֆեյսը: Միևնույն ժամանակ, ինտերֆեյսի նախագծման և մշակման բարդությունը բավականին մեծ է: Մասնագետների գնահատմամբ՝ միջին հաշվով դա ծրագրի իրականացման ժամանակի կեսից ավելին է։ Ծրագրային համակարգերի մշակման և պահպանման ծախսերի նվազեցումը կամ արդյունավետ ծրագրային գործիքների մշակումը տեղին է, որտեղ արդյունավետությունը հասկացվում է որպես ծրագրի մշակման, պահպանման և օգտագործման հեշտություն:
Ծրագրային համակարգերի մշակման և պահպանման ծախսերը նվազեցնելու միջոցներից մեկը գործիքակազմում չորրորդ սերնդի գործիքների առկայությունն է, որոնք հնարավորություն են տալիս նկարագրել (նշել) ստեղծվող ծրագրային գործիքը բարձր մակարդակով և այնուհետև ավտոմատ կերպով ստեղծել գործարկվող կոդ։ ըստ ճշգրտման. Ծրագրային ապահովման շուկան առաջարկում է գործիքների լայն տեսականի դրա մշակման համար: Այնուամենայնիվ, հասանելի գործիքներն աջակցում են չորրորդ սերնդի օգտագործմամբ ինտերֆեյսի միայն որոշ բաղադրիչների մշակմանը, դրա մնացած բաղադրիչները ծրագրավորված են մշակողի կողմից, ինչը զգալիորեն մեծացնում է ծախսերը, մշակման և սպասարկման բարդությունը:
Օգտագործողի միջերեսի մշակման հետազոտությունը սկսվել է ծրագրավորման լեզուներում հատուկ I/O հայտարարությունների հայտնվելով և այժմ հանգեցրել է ինտերֆեյսի մշակման մասնագիտացված գործիքների:
Գրականության մեջ չկա օգտատիրոջ միջերես մշակելու գործիքների ընդհանուր ընդունված դասակարգում: Այսպիսով, օգտագործողի ինտերֆեյսի մշակման ծրագրային ապահովումը բաժանված է երկու հիմնական խմբի՝ օգտագործողի միջերեսի մշակման գործիքներ (գործիքների հավաքածուներ) և բարձր մակարդակի ինտերֆեյսի մշակման գործիքներ (ավելի բարձր մակարդակի զարգացման գործիքներ): Օգտագործողի միջերեսի մշակման գործիքակազմը սովորաբար ներառում է ինտերֆեյսի բաղադրիչների պրիմիտիվների գրադարան (մենյու, կոճակներ, ոլորման տողեր և այլն) և նախատեսված է ծրագրավորողների կողմից օգտագործելու համար: Բարձր մակարդակի ինտերֆեյսի մշակման գործիքները կարող են օգտագործվել ոչ ծրագրավորողների կողմից և տրամադրված են լեզվով, որը թույլ է տալիս ճշգրտել I/O գործառույթները, ինչպես նաև ինտերֆեյսի տարրերի սահմանումը՝ օգտագործելով ուղղակի մանիպուլյացիայի տեխնիկան: Հեղինակները վերաբերում են այնպիսի գործիքներին, ինչպիսիք են երկխոսության ստեղծողները (ինտերֆեյս կառուցողներ) և SUPI - օգտատիրոջ միջերեսի կառավարման համակարգերը (User Interface Management Systems - UIMS): Բացի SUIS-ից, որոշ հեղինակներ օգտագործում են այնպիսի տերմիններ, ինչպիսիք են Օգտվողի միջերեսի մշակման համակարգերը (UIDS) - օգտատիրոջ ինտերֆեյսի մշակման համակարգեր, Օգտագործողի միջերեսի ձևավորման միջավայր (UIDE) - օգտագործողի միջերեսի մշակման միջավայր և այլն:
Ինտերֆեյսի մշակման գործիքակազմը բաժանված է երեք խմբի, որոնք սահմանվում են հետևյալ կերպ. Առաջին խումբը ներառում է գործիքներ, որոնք աջակցում են ինտերֆեյսի ստեղծմանը կոդ գրելու միջոցով՝ UIMS և Toolkits; երկրորդում - ինտերակտիվ գործիքներ, որոնք թույլ են տալիս ինտերֆեյս նախագծել «դատարկներից» (կոճակներ, ընտրացանկեր, ոլորման գծեր և այլն), - Ինտերֆեյս Builders; երրորդ տեսակը հիմնված է ինտերֆեյսի ստեղծման վրա՝ կապելով դրա առանձին ստեղծված բաղադրիչները՝ Component Architectures:
Ինչպես երևում է, տերմինաբանությունը այս ուղղությունըլիարժեք ձևավորված չէ և ներկայումս նույնպես հետազոտության առարկա է։ Այնուամենայնիվ, աշխատությունների մեծ մասում, անդրադառնալ մասնագիտացված միջոցներԻնտերֆեյսի մշակման համար տրված է SUPI տերմինը, որը կօգտագործվի այս հոդվածում:
Մասնագիտացված ինտերֆեյսի հեղինակային գործիքները պարզեցնում են օգտատիրոջ միջերեսի զարգացումը` ծրագրավորողին խնդրելով նշել օգտատիրոջ միջերեսի բաղադրիչները` օգտագործելով հստակեցման լեզուները:
Միջերեսը նշելու մի քանի հիմնական եղանակ կա:
1. Լեզուն, երբ ինտերֆեյսի շարահյուսությունը սահմանելու համար օգտագործվում են հատուկ լեզուներ (դեկլարատիվ, առարկայական, իրադարձությունների լեզուներ և այլն):
2. Գրաֆիկական ճշգրտումը վերաբերում է միջերեսի սահմանմանը, սովորաբար տեսողական ծրագրավորման գործիքների, ցուցադրական ծրագրավորման և օրինակների միջոցով: Այս մեթոդը աջակցում է միջերեսների սահմանափակ դասի:
3. Օբյեկտ-կողմնորոշված մոտեցման վրա հիմնված ինտերֆեյսի ճշգրտումը կապված է ուղղակի մանիպուլյացիա կոչվող սկզբունքի հետ: Դրա հիմնական հատկությունը օգտագործողի փոխազդեցությունն է առանձին օբյեկտների հետ, այլ ոչ թե ամբողջ համակարգի հետ որպես ամբողջություն: Օբյեկտների և կառավարման գործառույթների մանիպուլյացիայի համար օգտագործվող տիպիկ բաղադրիչներն են կարգավորիչները, ընտրացանկերը, երկխոսության գոտիները, տարբեր տեսակի կոճակները:
4. Ինտերֆեյսի ճշգրտում ըստ կիրառական առաջադրանքի ճշգրտման: Այստեղ ինտերֆեյսը ստեղծվում է ավտոմատ կերպով՝ ըստ կիրառական առաջադրանքի իմաստաբանության ճշգրտման: Այնուամենայնիվ, ինտերֆեյսի նկարագրության բարդությունը խոչընդոտում է այս մոտեցումն իրականացնող համակարգերի վաղ ի հայտ գալու հնարավորությունը:
UIMS-ի հիմնական հայեցակարգն է բաժանել օգտատիրոջ միջերեսի մշակումը մնացած հավելվածից: Ներկայումս առանձին ինտերֆեյսի և հավելվածի ձևավորման գաղափարը կա՛մ ամրագրված է SUIS-ի սահմանման մեջ, կա՛մ նրա հիմնական սեփականությունն է:
PIMS-ի կազմը սահմանվում է որպես գործիքների մի շարք զարգացման փուլի և կատարման ժամանակաշրջանի համար: Դիզայնի ժամանակի գործիքները գործում են ինտերֆեյսի մոդելների վրա՝ իրենց դիզայնը ստեղծելու համար: Դրանք կարելի է բաժանել երկու խմբի՝ ինտերակտիվ գործիքներ, ինչպիսիք են մոդելային խմբագրիչները, և ավտոմատ գործիքներ, ինչպիսիք են ձևաստեղծը։ Runtime գործիքներն օգտագործում են ինտերֆեյսի մոդել՝ օգտատերերի գործողություններին աջակցելու համար, ինչպիսիք են օգտագործվող տվյալների հավաքագրումն ու վերլուծությունը:
API-ի գործառույթներն են հեշտացնել և հեշտացնել օգտատիրոջ ինտերֆեյսի մշակումն ու սպասարկումը, ինչպես նաև կառավարել օգտագործողի և կիրառական ծրագրի միջև փոխգործակցությունը:
Ինտերֆեյսի և կիրառական ծրագրի վարքագիծը որոշվում է օգտագործողի հետ փոխգործակցության բնույթով: Կարելի է առանձնացնել փոխգործակցության երեք տարբեր տեսակներ՝ երկխոսության նախաձեռնությունը պատկանում է օգտագործողին, հավելվածի ծրագրին կամ խառը:
Օգտագործողների կառավարման նախաձեռնություն. Այս տեսակի հսկողությունը նշանակում է, որ ինտերֆեյսը տրամադրում է նախաձեռնությունը օգտվողին (կիրառական ծրագիրը նախագծված է այս կերպ), կամ օգտագործողը ինքն է նախաձեռնում նախաձեռնությունը, և ինտերֆեյսն աջակցում է այս հնարավորությունին (կիրառական ծրագիրը նախագծված է այս կերպ):
Դիմումների վերահսկման նախաձեռնություն. Վերահսկողության այս տեսակը նշանակում է, որ եթե կիրառական ծրագրին անհրաժեշտ է որոշակի տեղեկատվություն, ապա այն պահանջում է այն օգտագործողից, օգտատերը ներառվում է որոշման գործընթացում, երբ անհրաժեշտ է մուտքագրել համակարգի կողմից պահանջվող տվյալները:
Խառը կառավարման նախաձեռնություն. Փոխազդեցության այս տեսակը միավորում է նախորդ երկու մոտեցումները, որոնցում օգտատերը նշում է մուտքային տվյալները, բայց եթե կիրառական ծրագրին լուծման համար անհրաժեշտ են լրացուցիչ տվյալներ, ապա այն պահանջում է օգտագործողից:
Այսպիսով, ներկայումս կան մեծ թվով ինտերֆեյսի մշակման գործիքներ, որոնք աջակցում են դրա իրականացման տարբեր մեթոդներին: Այնուամենայնիվ, չկա առաջարկվող գործիքների ընդհանուր ընդհանուր ընդունված դասակարգում, ինչը դժվարացնում է գոյություն ունեցող գործիքները միմյանց հետ համեմատելը և օգտագործողների համար հատուկ գործիք ընտրելը: Հետևաբար, նախքան գործիքների քննարկումն ու համեմատությունը սկսելը, պետք է պատասխանել հետևյալ հարցերին. կա՞ն արդյոք չորրորդ սերնդի գործիքներ օգտատիրոջ միջերեսի բաղադրիչները նշելու համար, և ինչպե՞ս են չորրորդ սերնդի գործիքներն աջակցում օգտատիրոջ միջերեսի յուրաքանչյուր բաղադրիչի մշակմանը:
Առաջին հարցին պատասխանելու կարևորությունը պայմանավորված է մշակող գործիքների արդիականությամբ, որոնք կարող են նվազեցնել իրենց օգնությամբ ստեղծված հավելվածների մշակման և պահպանման ծախսերը: Խնդրի լուծումը չորրորդ սերնդի լեզուների օգտագործումն է, որոնք ծրագրավորողին թույլ են տալիս բարձր մակարդակով նշել ծրագրաշարի բաղադրիչները, այնուհետև ավտոմատ կերպով ստեղծել գործարկվող կոդ՝ ըստ մշակողի սպեցիֆիկացիայի։
Երկրորդ հարցին պատասխանելու համար անհրաժեշտ է առանձնացնել օգտատիրոջ միջերեսի բաղադրիչները, այսինքն՝ այն ասպեկտները, որոնցով ինտերֆեյսները կարելի է համեմատել միմյանց հետ։ Միևնույն ժամանակ, մենք հավատարիմ ենք մնալու հետևյալ սկզբունքներին. 1) օգտատիրոջ միջերեսը պետք է կենտրոնացած լինի վերջնական օգտագործողի վրա և մշակվի նրա պահանջներին համապատասխան. 2) օգտատիրոջ միջերեսը և կիրառական ծրագիրը, որի համար այն նախատեսված է, մշակվում են առանձին:
Օգտագործողի միջերեսի բաղադրիչները սահմանվում են վերը նշված սկզբունքներով, ինչպես նաև այն գործառույթներով, որոնք այն կատարում է:
Ըստ սահմանման, օրինակ, օգտատիրոջ միջերեսը նախատեսված է օգտատիրոջ և որոշ առաջադրանք կատարող գործընթացի միջև փոխազդեցություն ապահովելու համար՝ կիրառական ծրագիրը: Այս փոխազդեցության նպատակն է տեղեկատվություն (մուտքային տվյալներ) օգտվողից կիրառական ծրագիր փոխանցել, ելքային տվյալները (ծրագրի արդյունքները) օգտվողին: Ինտերֆեյսի գործառույթին համապատասխան, կա նաև կիրառական ծրագրի արդյունքների բացատրություն, որը մինչև վերջերս բնորոշ էր միայն փորձագիտական համակարգի ինտերֆեյսներին:
Կողմնորոշումը վերջնական օգտագործողին նշանակում է, որ ինտերֆեյսը պետք է կարողանա ներկայացնել նախնական տվյալները և արդյունքները թեմայի տարածքում ընդհանուր ընդունված ձևով կամ կախված օգտատերերի կատեգորիաներից և նրանց ցանկություններից՝ գրաֆիկական, աղյուսակային, բանավոր և դրանցից յուրաքանչյուրը: կարող է ունենալ նաև մի քանի տեսակի ներկայացումներ: Այլ կերպ ասած, ինչպես նշված է , նույն տեղեկատվության համար, կարող են լինել տարբեր փոխանցող հաղորդագրություններ, որոնք կազմում են համարժեք հաղորդագրությունների դաս: Միևնույն ժամանակ, միշտ կա հիմնական հաղորդագրությունների համակարգ, որտեղ թեմայի վերաբերյալ ցանկացած տեղեկատվություն կարող է արտահայտվել, միանշանակ հասկանալ և մեկնաբանվել նրա բոլոր ներկայացուցիչների կողմից, և որին կրճատվում են օգտվողի բոլոր հաղորդագրությունները: Հաղորդագրությունների նման համակարգը թեմայի տարածքի հասկացությունների համակարգ է: Հասկացությունների համակարգի առումով անվանվում են առարկայական տարածքի օբյեկտները, ձևակերպվում են հայտարարություններ, որ դրանք ունեն որոշակի հատկություններ և բնութագրեր, որոնք թույլ են տալիս հաստատել օբյեկտի նմանությունն ու տարբերությունը այլ օբյեկտների հետ, ինչպես նաև նշել հարաբերությունները: որոնցում առարկաները միմյանց միջև են: Այսպիսով, օգտագործողի միջերեսի բաղադրիչը տեղեկատվության նկարագրությունն է առարկայական տարածքի հասկացությունների համակարգի միջոցով, որը սահմանում է հաղորդագրությունների մեկնաբանման գործառույթը:
Ինչպես նշվեց վերևում, օգտագործողի համար տեղեկատվությունը կարող է ներկայացվել հաղորդագրությունների տեսքով (բանավոր, գրաֆիկական, աղյուսակային), որոնցից յուրաքանչյուրը կարող է տևել տարբեր ձևեր. Այսպիսով, ինտերֆեյսում օգտագործողի և կիրառական ծրագրի համար նույն տեղեկատվությունը փոխանցող հաղորդագրությունները տարբեր կերպ են ներկայացվում. հաղորդագրությունները կիրառական ծրագրի փոփոխականների արժեքներն են: Ակնհայտ է, որ կիրառական ծրագրի փոփոխականների հավաքածուի սահմանումը կրճատվում է անունների, տեսակների և դրանց հնարավոր արժեքները ներկայացնելու եղանակի սահմանման վրա:
Ինտերֆեյսում օգտագործողին հաղորդագրությունների փոխանցման հետ մեկտեղ անհրաժեշտ է սահմանել ատրիբուտներ, որոնք չեն փոխանցում տեղեկատվություն, այլ ստեղծում են նրա համար հարմարավետություն և հարմարավետություն. դրանք կարող են համակցվել ինտերֆեյսի դիզայնի ընդհանուր տերմինի ներքո: Նման ատրիբուտները ներառում են՝ էկրանի վրա հաղորդագրությունների գտնվելու վայրը, դրանց չափը, գույնը և այլն, ինչպես նաև ֆիզիկական մուտքագրման սարքերի կարգավորումը (ստեղնաշար, մանիպուլյատորներ, խոսքի մուտքագրում, մեքենայական տեսողություն և այլն) և ելքային (մոնիթոր, ձայն, լուսանկարչական արդյունք և այլն) և այլն): Այսպիսով, օգտագործողի միջերեսի անբաժանելի մասը, որը անքակտելիորեն կապված է հաղորդագրությունների փոխանցման հետ, հաղորդագրությունների ձևի սահմանումն է:
Ինտերֆեյսը պետք է օգտագործողի կողմից մուտքագրված տեղեկատվությունը փոխակերպի իրեն հասկանալի հաղորդագրությունների տեսքով կիրառական ծրագրի փոփոխականների արժեքների, ինչպես նաև կիրառական ծրագրի փոփոխականների արժեքների, որոնք արդյունք են: դրա աշխատանքը օգտատիրոջ հաղորդագրություններին: Տեղեկատվությունն օգտագործողին որպես ինտերֆեյսի մաս տարբեր հաղորդագրությունների փոխարկելու համար անհրաժեշտ է խելացի օգտագործողի աջակցության բլոկ, որը վերահսկում է հնարավոր սխալները, ստեղծում բացատրություններ և կառավարում օգնության համակարգը:
Երկու կամ ավելի օբյեկտների ցանկացած փոխազդեցություն միմյանց հետ (այս դեպքում՝ օգտագործողի և ինտերֆեյսի) միշտ ենթարկվում է որոշակի կանոնների։ Օգտատիրոջ և ինտերֆեյսի միջև փոխազդեցության կանոնները նույնպես պետք է սահմանվեն ինտերֆեյսում: Այս կանոնները պետք է սահմանեն մի վիճակից մյուսին անցումների հաջորդականությունը: Համապատասխանաբար, օգտագործողի հետ ինտերֆեյսի փոխազդեցությունը պետք է պարունակի հաղորդագրությունների փոխանակման կանոններ (այս դեպքում սրանք օգտատիրոջ և սկզբնական տվյալների և արդյունքների կառավարման ինտերֆեյսի գործողություններն են):
Այսպիսով, օգտագործողի միջերեսը ներառում է.
հիմնական հաղորդագրությունների համակարգ (թեմայի տարածքի հասկացությունների համակարգ);
հաղորդագրությունների համակարգ օգտագործողի համար;
հաղորդագրությունների համակարգ կիրառական ծրագրի համար;
օգտագործողի հարմարավետությունն ու հարմարավետությունն ապահովելու միջոցներ.
օգտագործողների ինտելեկտուալ աջակցության միջոցներ;
օգտագործողի և ինտերֆեյսի միջև փոխազդեցության կառավարման միջոցներ:
Եկեք դիտարկենք, թե ինչպես է օգտատիրոջ միջերեսի յուրաքանչյուր բաղադրիչի մշակումն ապահովվում չորրորդ սերնդի միջոցով:
Հայեցակարգի համակարգի նկարագրման աջակցությունը տրամադրվում է . Համաձայն հայեցակարգի համակարգի ճշգրտման, որի համար առաջարկվում է մասնագիտացված լեզու, հաղորդագրությունները ավտոմատ կերպով գեներացվում են, որոնք բանավոր ձևով ներկայացվում են բազմաթիվ կասկադային ընտրացանկերի և պատուհանների միջոցով: Այս հստակեցման թերությունն այն է, որ տիրույթի հայեցակարգի համակարգի կառուցվածքը սահմանափակվում է հիերարխիկ ներկայացմամբ, և դրա նկարագրությունը կատարվում է մասնագիտացված լեզվով խմբաքանակի ռեժիմում:
Աշխատանքներում առաջարկվում է նաև սկսել ինտերֆեյսի նախագծումը առաջադրանքի և առարկայի մոդելավորմամբ։ Դա անելու համար օգտագործողին առաջարկվում է նկարագրել խնդրի հայտարարությունը ոչ պաշտոնական լեզվով, որից ավտոմատ կերպով դուրս են բերվում առարկայական տարածքի հասկացությունները և դրանց հետ կապված գործողությունները: Հաջորդ քայլերը ստացված խնդրի հայտարարության պաշտոնականացումն են՝ մաղելով ավելորդ տարրերը, կազմակերպելով ընտրված տարրերի դասերը, սահմանելով դրանց վավեր արժեքների տարածքը և տեսակները և գործելով դրանց վրա՝ տիրույթի լիարժեք մոդել ստեղծելու համար: Որպես առաջադրանքի արդյունահանման այս մեթոդի առավելություններ, հեղինակները նշում են ծրագրավորողի և օգտագործողի միջև թյուրիմացության աստիճանի նվազումը, նախագծում օգտագործողի ներգրավումը դրա իրականացման հենց սկզբից և շրջանակի կառուցումը: առաջադրանքի մոդելը և տիրույթի մոդելը: Այնուամենայնիվ, կասկածելի է, թե արդյոք այս մոտեցումը կարող է օգտագործվել բարդ տիրույթի մոդելի հետ կապված խնդիրների լուծման համար, որն ունի խնդրի լուծման համար անհրաժեշտ հասկացությունների համակարգի մեծ ծավալ և բարդ կառուցվածք, օգտվողին տրամադրում է ինտելեկտուալ աջակցություն, քանի որ շրջանակը և մոդելի տարրերը (տերմինները և հասկացությունները) տարբերվում են ոչ պաշտոնական նկարագրության հիման վրա.օգտագործողի առաջադրանքները. Բարդ համակարգերի նախագծման մեր փորձը, ինչպիսին է «Consultant-2» փորձագիտական համակարգը և, մասնավորապես, դրա ինտերֆեյսը, ցույց է տվել, որ հայեցակարգերի համակարգի ձևավորման գործընթացը, անկասկած, պետք է իրականացվի բարձր ներկայացուցիչների ակտիվ մասնակցությամբ։ առարկայական ոլորտի որակավորված մասնագետներ՝ դրա նախկինում կատարված լուրջ վերլուծության հիման վրա՝ հետագա պաշտոնականացման նպատակով: Հետևաբար, ինտերֆեյսի ձևավորման գործիքները պետք է ուղղված լինեն ինտերֆեյսի դիզայներին, այլ ոչ թե վերջնական օգտագործողին:
Գործիքակազմերն ապահովում են երկխոսության մեջ օգտագործվող ինտերֆեյսի տարրերի գրադարաններ, ինչպիսիք են երկխոսության տուփերը, ձևաթղթերը, տարբեր տեսակի ընտրացանկերը, տվյալների հիերարխիայի ներկայացումը ճյուղավորված կառուցվածքի տեսքով և այլն: Միևնույն ժամանակ, մշակողն ունի ոչ միայն անհրաժեշտ ինտերֆեյսի տարրերը ընտրելու հնարավորություն, այլև առաջարկվող հիմնական պարզունակներից բարդ համալիրներ կազմակերպելու հնարավորություն՝ օգտագործելով տեսողական և առարկայական ծրագրավորման գործիքներ: Այնուամենայնիվ, դժվար է խոսել ինտերֆեյսի կառուցման աջակցության մասին, քանի որ առաջարկվող գրադարանները բավականին կամայական կարծիք են արտահայտում ինտերֆեյսի տարրերի ստանդարտների վերաբերյալ, առանց հաշվի առնելու այն հավելվածների առանձնահատկությունները, որոնց համար գրադարանների օգտագործումը հիմնավորված է:
Հարկ է նշել, որ բոլոր գոյություն ունեցող Գործիքակազմերում չկան հատուկ գործիքներ՝ դրա բաղադրիչների հիման վրա օգտագործողի միջերեսի նախագծման համար: Հետևաբար, ինտերֆեյսի դիզայներները ստիպված են նախագծել դրա բոլոր մասերը միասին՝ առանց հստակորեն բաժանելու մի բաղադրիչը մյուսից, թեև դրա տարբեր բաղադրիչների դիզայնը պահանջում է տարբեր տեսակի հասկացությունների և աբստրակցիայի մակարդակների օգտագործում: Այս միջոցներով ինտերֆեյսի մշակման տեխնոլոգիան կազմակերպված է այնպես, որ մշակողը ընտրում է ինտերֆեյսի տարր և «կցում» ինտերֆեյսի բովանդակությունը դրա վրա, և ոչ հակառակը՝ կառուցվածքին և բովանդակությանը (հասկացությունների համակարգին), ձևերին համապատասխան։ դրա ներկայացումն առաջարկվում է (հնարավոր է ավտոմատ ձևավորվի): Այս ձևով ինտերֆեյս մշակելով՝ դրա մշակողը պետք է հարմարեցնի աղբյուրի տվյալների կառուցվածքը և բովանդակությունը գործիքում առաջարկվող ձևերին:
Գրաֆիկորեն ներկայացված չմշակված տվյալների համար կան վեկտորային և ռաստերային գրաֆիկայի բազմաթիվ գրաֆիկական փաթեթներ: Գրաֆիկական փաթեթները թույլ են տալիս ստեղծել միայն պատկերներ, սակայն չունեն գրաֆիկական և բանավոր նկարագրությունները (հասկացությունների համակարգի և հաղորդագրությունների համակարգի կապերը) միացնելու միջոցներ, հետևաբար. այս մասըինտերֆեյսը պետք է ծրագրավորվի: Հարկ է հիշեցնել, որ խոսքը չորրորդ սերնդի գործիքների մասին է, որոնք թույլ են տալիս բարձր մակարդակով նշել ինտերֆեյսը։
Փորձ է արվել կապել հասկացությունների համակարգը և հաղորդագրությունների համակարգը։ Դա անելու համար գործիքակազմն ունի տվյալների բազա, որը պահպանում է տեղեկատվություն այն մասին, թե միջերեսի որ տարրերն են ավելի հարմար՝ ներկայացնելու որոշակի տեսակի տվյալներ: Այս տվյալների բազայի հիման վրա մշակողը կարող է պրիմիտիվներ վերագրել տարրերին կամ տվյալների խմբերին և այնուհետև ավտոմատ կերպով ստեղծել ինտերֆեյսի նախատիպ: Այս մոտեցումը հարմար է տվյալների բանավոր ներկայացման համար, սակայն գրաֆիկական ներկայացումը կախված է թեմայի տարածքից, հետևաբար, այս դեպքում տվյալների բազայում առաջարկվող պարզունակները չեն կարող օգտագործվել հաղորդագրություններ ստեղծելու համար:
Գործիքների բոլոր դասերը աջակցում են ինտերֆեյսի հարմարավետության պարամետրերը սահմանելու մի շարք տարբերակներ՝ օգտագործելով տեսողական և առարկայական ծրագրավորման գործիքներ, որոնք թույլ են տալիս սահմանել ինտերֆեյսի տարրերի գտնվելու վայրը մոնիտորի էկրանին, դրանց գույնը, հյուսվածքը, չափը և այլն՝ կախված նրանից: օգտագործողների պահանջները, հոգեբանությունը և էրգոնոմիկան, ինչպես նաև որոշում են ֆիզիկական մուտքային/ելքային սարքերը:
Օգտագործողի և ինտերֆեյսի միջև փոխգործակցության կազմակերպման համար ներկայումս հայտնի չէ մատչելիությունը, որը թույլ կտա մշակողին հստակեցման մակարդակում որոշել օգտագործողի գործողությունները աղբյուրի տվյալները կառավարելու համար, ուստի մշակողը պետք է ծրագրավորի ինտերֆեյսի այս բաղադրիչը: Աշխատանքի ընթացքում գործիքակազմը մշակողին առաջարկում է նախնական տվյալների հավաքածուներ պահելու, դրանք դիտելու, հետագա մուտքագրման համար խմբագրելու հնարավորություն:
Փոփոխականների մի շարք և դրանց արժեքների ներկայացումը սովորաբար պետք է ծրագրավորվեն, կամ, ինչպես օրինակում, ձևավորվեն գործիքակազմում խստորեն սահմանված կանոնների համաձայն:
Աշխատանքում ներկայացված են ծրագրային համակարգի արդյունքների բացատրությունների գեներացման միջոցներ: Դա անելու համար ինտերֆեյսի մշակողներին առաջարկվում է հատուկ մակրո լեզու, որտեղ նրանք կարող են նկարագրել բացատրության ձևանմուշը: Այնուամենայնիվ, այս լեզուն թույլ է տալիս բացատրությունը ներկայացնել միայն բանավոր ձևով, ունի սահմանափակ միջոցներբացատրության տեքստը ձևավորելու համար և պարունակում է սահմանափակում ծրագրային համակարգի արդյունքների ձևաչափի վրա՝ միայն հարաբերությունների բազմակի տեսքով: Բացատրության ստեղծման շատ այլ համակարգեր բացառապես ուղղված են փորձագիտական համակարգերին, դրանք կախված են եզրակացության շարժիչից և նաև պահանջում են լրացուցիչ գիտելիքներ գիտելիքների բազայում ներառելու համար: Հեղինակները առաջարկում են գործիքներ՝ ավտոմատ կերպով ստեղծելու օգնության գործիքներ՝ գիտելիքների բազան ներկայացնելու համար:
Ինտերֆեյսի և կիրառական ծրագրի միջև փոխազդեցությունը չի ապահովվում բարձր մակարդակով, բայց ծրագրավորված է մշակողի կողմից:
Այսպիսով, MUIS-ի հիմնական նպատակն է նվազեցնել օգտատերերի ինտերֆեյսի ստեղծման և պահպանման ծախսերը, ինչը ձեռք է բերվում ինտերֆեյսի սահմանման բարձր մակարդակի գործիքների տրամադրմամբ և այդպիսով ծրագրավորողին ազատելով ցածր մակարդակի ծրագրավորումից: Առկա մասնագիտացված գործիքները չեն աջակցում ինտերֆեյսի բոլոր բաղադրիչների բարձր մակարդակի զարգացմանը, բաղադրիչների մեծ մասը պետք է ծրագրավորվեն մշակողների կողմից կամ դրանք կոշտ կոդավորված են, ինչը թույլ չի տալիս ապահովել 1-ին սկզբունքը ինտերֆեյսի նախագծման ժամանակ: Սա հանգեցնում է ինտերֆեյսի մշակման և պահպանման ծախսերի զգալի աճի:
Հետևաբար, ներկայումս արդիական է ISMS-ի ստեղծման վրա աշխատանքը, որն ապահովում է բարձր մակարդակի աջակցություն դրա զարգացման բոլոր փուլերին:
Մատենագիտություն
1. Մայերս Բ.Ա. and Rosson M.B. «Հարցում օգտատերերի միջերեսի ծրագրավորման վերաբերյալ», նյութեր SIGCHI'92. Մարդկային գործոնները հաշվողական համակարգերում: Monterrey, CA, May 3-7, 1992. P. 195-202.
2. Կլիմենկո Ս., Ուրազմետով Վ. Գրաֆիկական ինտերֆեյսներ և դրանց մշակման գործիքներ // Mater. Համախմբում. Ծրագրավորման արդյունաբերություն – 96. www.uniyar.ac.ru/network/atm/forum/koi/if/prg/prg96/73/htm.
3. Puerta, A. R. Աջակցող օգտատիրոջ վրա հիմնված ադապտիվ ինտերֆեյսների ինտերֆեյսի մոդելների միջոցով: Առաջին տարեկան սեմինարը իրական ժամանակի խելացի օգտատերերի միջերեսների վերաբերյալ որոշումների աջակցության և տեղեկատվության վիզուալիզացիայի համար, Սան-Ֆրանցիսկո, 1998թ. հունվար: 10 էջ.
4. Brad A. Myers. Մարդկային համակարգչի փոխազդեցության տեխնոլոգիայի համառոտ պատմություն // ACM փոխազդեցություններ. Հատ. 5, ոչ. 2. Մարտ 1998. P. 44-54.
5. Lowgren J. Գիտելիքի վրա հիմնված նախագծման աջակցություն և դիսկուրսի կառավարում օգտագործողների միջերեսի կառավարման համակարգերում: Linkoping Studies in Science and Technology. Ատենախոսություններ թիվ 239, 1989 թ.
6. Puerta, A.R. և Maulsby, D. MOBI–D-ի հետ ինտերֆեյսի ձևավորման գիտելիքների կառավարում: IUI97. Միջազգային կոնֆերանս ինտելեկտուալ օգտատերերի միջերեսների վերաբերյալ, Օռլանդո, հունվար 1997, էջ 249–252:
7. Pressman R. S. Software Engineering: Practitioners Approach European 3d Rev. խմբ. McGraw-Hills Inc., 1994. 802 p.
8. Coates R., Vleymink I. Մարդ-համակարգիչ ինտերֆեյս / Per. անգլերենից։ – Մ.: Միր, 1990.- 501 էջ.
9. Բրյուս Ա. Վուլի ծրագրային համակարգերի բացատրական բաղադրիչ: www.acm.org/crossroads/xrds5–1/explain.html:
10. Bauer F. L., Gooz G. Informatics. Ներածական դասընթաց՝ ժամը 14:00 / Per. նրա հետ. -Մ.՝ Միր, 1990. - Մաս 1։ - 336 էջ, հիվանդ.
11. Գրիբովա Վ.Վ., Կլեշչև Ա.Ս. Փորձագիտական համակարգերում օգտագործողի միջերես մշակելու գործիքակազմ // Ծրագրային արտադրանք և համակարգեր: - 1999. - թիվ 1: - S. 30-34.
12. Պուերտա, Ա.Ռ. Մոդելի վրա հիմնված ինտերֆեյսի մշակման միջավայր: IEEE Software, 14 (4), հուլիս/օգոստոս 1997, էջ 41–47:
13. Չեռնյախովսկայա Մ.Յու. «Խորհրդատու-2» բժշկական ախտորոշման ES-ի գնահատում մի քանի կլինիկաների արխիվային նյութերի վրա: - Վլադիվոստոկ, 1989. - 30 էջ. (Նախ. IAPU ՓԵԲ ՌԱՆ):
14. Սկոպին Ի.Ն. Ծրագրային համակարգի ինտերֆեյսների մշակում // Համակարգային ինֆորմատիկա. - 1998. - Թողարկում 6: – P.123–173.
15. Foley, J., Kim, W.C., Kovacevic S., Murray, K., UIDE: An Intelligent User Interface Design Environment, ACM Press, 1991 թ.
Անցյալ երկուշաբթի ինձ բախտ վիճակվեց հարցազրույց ստանալ ավագ .Net ծրագրավորողի համար միջազգային ընկերությունում: Հարցազրույցի ժամանակ ինձ առաջարկեցին թեստ անցնել, որտեղ մի շարք հարցեր վերաբերում էին .Net-ին։ Մասնավորապես, հարցերից մեկում անհրաժեշտ էր գնահատել (ճիշտ/կեղծ) մի շարք պնդումներ, որոնց թվում էր հետևյալը.
.Net-ում տարրերի ցանկացած զանգված, ինչպիսին է int-ը, լռելյայն իրականացնում է IList-ը, ինչը թույլ է տալիս այն օգտագործել որպես հավաքածու foreach-ի մեջ:
Այս հարցին արագ պատասխանելով բացասական և առանձին ավելացնելով լուսանցքներում: որ foreach-ը պահանջում է ոչ թե IList-ի, այլ IEnumerable-ի իրականացում, ես անցա հաջորդ հարցին: Այնուամենայնիվ, տուն գնալու ճանապարհին ինձ տանջում էր հարցը՝ զանգվածը դեռ իրականացնում է այս ինտերֆեյսը, թե ոչ:
IList-ի մասին ես աղոտ հիշեցի, որ այս ինտերֆեյսը ինձ տալիս է IEnumerable, ինդեքսատոր և Count հատկություն, որը պարունակում է հավաքածուի տարրերի քանակը, ինչպես նաև հազվադեպ օգտագործվող մի քանի հատկություններ, ինչպիսին է IsFixedCollection (): Զանգվածն իր չափի համար ունի Length հատկություն, իսկ IEnumerable-ի Count-ը LINQ-ի ընդլայնման մեթոդ է, որը հնարավոր չէր լինի, եթե այս մեթոդը կիրառվեր դասում: Այսպիսով, պարզվեց, որ զանգվածը չի կարող իրականացնել IList ինտերֆեյսը, բայց ինչ-որ անորոշ զգացում հետապնդել է ինձ: Ուստի հարցազրույցից հետո երեկոյան որոշեցի մի փոքր հետազոտություն անել։
System.Array դաս
Քանի որ ես տեղադրած չունեի Reflector.Net-ը, ես պարզապես գրեցի կարճ C# ծրագիր՝ պարզելու համար, թե ինչ ինտերֆեյսներ են իրականացվում ամբողջ թվային զանգվածով:Var v = նոր int (1, 2, 3); var t = v.GetType(); var i = t.GetInterfaces(); foreach(var tp in i) Console.WriteLine(tp.Name);
Այստեղ ամբողջական ցանկըստացված ինտերֆեյսեր վահանակի պատուհանից.
ICloneable IList ICollection IEnumerable IStructuralՀամեմատելի IStructuralEquatable IList`1 ICollection`1 IEnumerable`1 IReadOnlyList`1 IReadOnlyCollection`1
Այս կերպ, Զանգվածը .Net-ում դեռևս իրականացնում է IList ինտերֆեյսը և դրա ընդհանուր տարբերակը IList<> .
Ավելի ամբողջական տեղեկատվություն ստանալու համար ես կառուցեցի System.Array դասի դիագրամը:
Իմ սխալն անմիջապես գրավեց աչքս. Count-ը ոչ թե IList-ի, այլ ICollection-ի՝ ժառանգական շղթայի նախորդ ինտերֆեյսի սեփականությունն էր: Այնուամենայնիվ, զանգվածն ինքը այլևս չուներ նման հատկություն, ինչպես նաև IList ինտերֆեյսի շատ այլ հատկություններ, չնայած այդ ինտերֆեյսի մյուս հատկությունները՝ IsFixedSize և IsReadOnly, ներդրված էին։ Ինչպե՞ս է դա նույնիսկ հնարավոր:
Ամեն ինչ անմիջապես ընկնում է իր տեղը, երբ հիշում ես, որ C #-ում կարող ես ինտերֆեյսներ իրականացնել ոչ միայն
անուղղակիորեն (ենթադրաբար), բայց նաև բացահայտորեն (բացահայտ): Այս հնարավորության մասին ես գիտեի դասագրքերից, որտեղ բերված էր նման գործի իրականացման օրինակ։ երբ բազային դասն արդեն պարունակում է ինտերֆեյսի մեթոդի նույն անունով մեթոդ: Այս հնարավորությունը ես տեսա նաև ReSharper-ում։ Այնուամենայնիվ, մինչ այժմ ես ուղղակիորեն չեմ հանդիպել իմ սեփական նախագծերում ինտերֆեյսների հստակ ներդրման անհրաժեշտությանը:
Ինտերֆեյսների բացահայտ և անուղղակի ներդրման համեմատություն
Եկեք համեմատենք այս երկու տեսակի ինտերֆեյսի իրականացումը.| Չափանիշներ |
Անուղղակի իրականացում |
Հստակ իրականացում |
|---|---|---|
| Հիմնական շարահյուսություն |
ինտերֆեյս ITest ( void DoTest();) public class ImplicitTest. ITest (public void DoTest() ()) |
միջերես ITest ( void DoTest(); ) public class ExplicitTest. ITtest ( void ITest.DoTest() ()) |
| Տեսանելիություն |
Անուղղակի իրականացումը միշտ եղել է հրապարակային, ուստի մեթոդներին և հատկություններին կարելի է ուղղակիորեն մուտք գործել: var imp = նոր ImplicitTest(); imp.DoTest(); |
Հստակ իրականացումը միշտ մասնավոր է: Իրականացումը մուտք գործելու համար դուք պետք է դասի օրինակը փոխանցեք ինտերֆեյսին (upcast to interface): varexp = նոր ExplicitTest(); ((ITest)exp).DoTest(); |
| Պոլիմորֆիա |
Իմպլիցիտ ինտերֆեյսի իրականացումը կարող է լինել վիրտուալ (վիրտուալ), ինչը թույլ է տալիս վերաշարադրել այս իրականացումը հետնորդ դասերում: |
Հստակ իրականացումը միշտ ստատիկ է: Այն չի կարող վերացվել կամ վերացվել (նոր) հետնորդ դասերում: Նշում. մեկ |
| Աբստրակտ դաս և իրականացում |
Անուղղակի իրականացումը կարող է վերացական լինել և իրականացվել միայն հետնորդ դասում: |
Բացահայտ իրականացումը չի կարող վերացական լինել, բայց դասը ինքնին կարող է ունենալ այլ վերացական մեթոդներ և ինքն իրեն վերացական լինել: Նշում. 2 |
Նշումներ:
Նշում. 1 - Ինչպես իրավացիորեն նշվեց մեկնաբանություններում, իրականացումը կարող է վերացվել՝ ինտերֆեյսի կրկնակի կիրառմամբ սերունդ դասում (տե՛ս հոդվածի առաջին մեկնաբանությունը):
Նշում. 2 - Բլոգներից մեկում ասվում է, որ դասը ինքնին չի կարող վերացական լինել: Թերևս դա ճիշտ էր կոմպիլյատորի որոշ նախորդ տարբերակների համար. իմ փորձերի ժամանակ ես կարող էի ինտերֆեյսը բացահայտորեն իրականացնել աբստրակտ դասում առանց որևէ խնդիրների:
Ինչու է անհրաժեշտ ինտերֆեյսների հստակ իրականացումը
Ինտերֆեյսի հստակ իրականացումը, ըստ MSDN-ի, պահանջվում է, երբ դասի կողմից իրականացվող մի քանի միջերեսներ ունեն նույն ստորագրությամբ մեթոդ: Այս խնդիրն ընդհանուր առմամբ հայտնի է անգլիախոս աշխարհում «մահացու մահացու ադամանդ» սարսափելի անվան տակ, որը ռուսերեն թարգմանվում է որպես «ադամանդի խնդիր»։ Ահա այսպիսի իրավիճակի օրինակ./* Ցուցակ 1 */ ինտերֆեյս IJogger ( void Run(); ) ինտերֆեյս ISkier ( void Run(); ) public class Athlete: ISkier, IJogger ( public void Run() ( Console.WriteLine («Ես մարզիկ եմ, դահուկորդ կամ Վազք?");))
Ի դեպ, այս օրինակը ճիշտ կոդ է C#-ում, այսինքն՝ այն (ճիշտ է) կազմում և գործարկում, մինչդեռ Run() մեթոդը և՛ դասի մեթոդն է, և՛ երկու ինտերֆեյսի իրականացում։ Այսպիսով, մենք կարող ենք ունենալ մեկ իրականացում տարբեր ինտերֆեյսների և հենց դասի համար: Սա կարող եք ստուգել հետևյալ կոդով.
/* Ցուցակ 2 */ var sp = new Athlete(); sp.Run(); (sp as ISkier).Run(); (sp as IJogger).Run();
Այս կոդը գործարկելու արդյունքը կլինի «Ես մարզիկ եմ, դահուկորդ, թե վազորդ»:, տպագրվել է վահանակի վրա երեք անգամ։
Այստեղ մենք կարող ենք օգտագործել բացահայտ ինտերֆեյսի իրականացում բոլոր երեք դեպքերն առանձնացնելու համար.
/* Ցուցակ 3 */ public class Sportsman ( public virtual void Run() ( Console.WriteLine ("I am a Sportsman"); ) ) public class Athlete: Sportsman, ISkier, IJogger ( public override void Run() ( Console. WriteLine («Ես մարզիկ եմ»); ) void ISkier.Run() ( Console.WriteLine («Ես դահուկորդ եմ»); ) void IJogger.Run() ( Console.WriteLine («Ես վազորդ եմ»); ))
Այս դեպքում, ցուցակ 2-ից ծածկագիրը գործարկելիս, վահանակում կտեսնենք երեք տող. «Ես մարզիկ եմ», «Ես դահուկորդ եմ»և «Ես վազորդ եմ».
Տարբեր ինտերֆեյսի ներդրման առավելություններն ու թերությունները
Իրականացման տեսանելիություն և ընտրովի իրականացում
Ինչպես արդեն ցույց է տրվել վերևում, անուղղակի իրականացումը շարահյուսականորեն չի տարբերվում սովորական դասի մեթոդից (ավելին, եթե այս մեթոդն արդեն սահմանվել է նախնիների դասում, ապա այս շարահյուսության մեջ մեթոդը կթաքցվի երեխայի մեջ և կոդը կկազմվի։ առանց խնդիրների գ Կոմպիլյատորի նախազգուշացում մեթոդի թաքցման մասին): Ավելին, հնարավոր է ընտրովիորեն կիրառել մեկ ինտերֆեյսի առանձին մեթոդներ ինչպես բացահայտ, այնպես էլ անուղղակիորեն./* Ցուցակ 4 */ public class Code ( public void Run() ( Console.WriteLine («Ես դասի մեթոդ եմ»); ) ) ինտերֆեյս ICommand ( void Run(); void Execute(); ) public class CodeCommand: Code , ICommand ( // անուղղակի ինտերֆեյսի մեթոդի իրականացում // => հրապարակային իրականացում // ներածական բազային դասի մեթոդը թաքցնում է (նախազգուշացում այստեղ) public void Run() (base.Run(); ) // բացահայտ ինտերֆեյսի մեթոդի իրականացում // => մասնավոր իրականացման void ICommand.Execute() () )
Սա թույլ է տալիս անհատական ինտերֆեյսի մեթոդների իրականացումներն օգտագործել որպես բնիկ դասի մեթոդներ, և դրանք հասանելի են, օրինակ, IntelliSense-ի միջոցով, ի տարբերություն մեթոդների բացահայտ իրականացման, որոնք մասնավոր են և տեսանելի են միայն համապատասխան ինտերֆեյսին փոխանցելուց հետո:
Մյուս կողմից, մեթոդների մասնավոր ներդրման հնարավորությունը թույլ է տալիս թաքցնել մի շարք ինտերֆեյսի մեթոդներ՝ միաժամանակ ամբողջությամբ իրականացնելով այն։ Վերադառնալով .Net-ում զանգվածների մեր առաջին օրինակին, դուք կարող եք տեսնել, որ զանգվածը թաքցնում է, օրինակ, ICollection ինտերֆեյսի Count հատկության իրականացումը` բացահայտելով այս հատկությունը Length (հավանաբար, համատեղելիությունը պահպանելու փորձ) C++ STL և Java): Այսպիսով, մենք կարող ենք թաքցնել ներդրված ինտերֆեյսի առանձին մեթոդները և չթաքցնել (=հրապարակել) մյուսները։
Այստեղ, սակայն, կա այնպիսի խնդիր, որ շատ դեպքերում բոլորովին անհնար է կռահել, թե որ ինտերֆեյսներն են անուղղակիորեն իրականացվում դասի կողմից, քանի որ IntelliSense-ում տեսանելի չեն այդ ինտերֆեյսների ոչ մեթոդները, ոչ հատկությունները (System.Array-ի օրինակը. այստեղ նաև ցուցիչ): Նման իրականացումները բացահայտելու միակ միջոցը արտացոլումն օգտագործելն է, օրինակ՝ Visual Studio-ում Object Browser-ի միջոցով:
Ինտերֆեյսի վերամշակում
Քանի որ ինտերֆեյսի անուղղակի (հրապարակային) իրականացումը չի տարբերվում դասի հանրային մեթոդի իրականացումից, ինտերֆեյսի վերամշակման և դրանից որևէ հանրային մեթոդ հեռացնելու դեպքում (օրինակ՝ Run() և Execute-ը համատեղելիս. () վերը նշված ICommand ինտերֆեյսի մեթոդները մեկ Run( )) բոլոր անուղղակի իրականացումներում, կլինի մի մեթոդ հանրային հասանելիությամբ, որը, ամենայն հավանականությամբ, պետք է ապահովվի նույնիսկ վերամշակումից հետո, քանի որ այս հանրային մեթոդը կարող է արդեն տարբեր լինել: կախվածությունը համակարգի այլ բաղադրիչներից: Արդյունքում կխախտվի «ընդդեմ ինտերֆեյսների, այլ ոչ թե իրականացումների» ծրագրավորման սկզբունքը, քանի որ կախվածությունն արդեն կլինի նախկին ինտերֆեյսի մեթոդի կոնկրետ (և տարբեր դասերում, իհարկե, տարբեր) իրականացումների միջև։/* Ցուցակ 5 */ ինտերֆեյսի IFingers ( void Thumb(); void IndexFinger(); // հնացած ինտերֆեյսի մեթոդ // void MiddleFinger(); ) հանրային դաս HumanPalm. IFingers ( public void Thumb() () public void IndexFinger( ) () // այստեղ կա «կախված» հանրային մեթոդ public void MiddleFinger() () ) հանրային դաս AntropoidHand. IFingers ( void IFingers.Thumb() () void IFingers.IndexFinger() () // այստեղ կոմպիլյատորի սխալը void IFingers.MiddleFinger() () )
Ինտերֆեյսների մասնավոր ներդրման դեպքում, բոլոր դասերը, որոնք այլևս գոյություն չունեցող մեթոդի բացահայտ ներդրում ունեն, պարզապես կդադարեն կոմպիլյացիայից, սակայն այն հեռացնելուց հետո, որն անհարկի է դարձել (կամ վերափոխել այն: նոր մեթոդ) մենք չենք ունենա «լրացուցիչ» հանրային մեթոդ, որը կապված չէ որևէ ինտերֆեյսի հետ: Իհարկե, կարող է անհրաժեշտ լինել վերափոխել կախվածությունը հենց ինտերֆեյսից, բայց այստեղ, ըստ գոնե, «Ծրագիր դեպի ինտերֆեյսներ, ոչ թե իրականացումներ» սկզբունքի խախտում չի լինի։
Ինչ վերաբերում է հատկություններին, ապա անուղղակիորեն ներդրված ինտերֆեյսի հատկությունները (հատկությունները) թույլ են տալիս մուտք գործել դրանք աքսեսուարի մեթոդների միջոցով (ստող և կարգավորող) ինչպես դրսից, այնպես էլ ուղղակիորեն հենց դասից, ինչը կարող է հանգեցնել ավելորդ էֆեկտների (օրինակ՝ տվյալների անհարկի վավերացման ընթացքում: սկզբնավորման հատկությունները):
/* Ցուցակ 6 */ ինտերֆեյս IPProperty ( int Amount ( get; set; ) ) public class ClassWithProperty. IPProperty ( // անուղղակի իրականացում, public public int Amount ( get; set; ) public ClassWithProperty() ( // ներքին կանչ հանրային կարգավորիչ Amount = 1000; ) ) հանրային դաս ClassWithExplicitProperty. IProperty ( // բացահայտ իրականացում, մասնավոր int IPProperty. Գումար ( ստանալ; սահմանել; ) public ClassWithExplicitProperty() ( // ներքին կանչը հնարավոր չէ այստեղ // կոմպիլյատորի սխալ 1000;))
Ինտերֆեյսի հատկությունների հստակ ներդրման դեպքում այս հատկությունները մնում են մասնավոր, և մուտք գործելու համար դուք պետք է անցնեք «երկար» ճանապարհը և հայտարարեք լրացուցիչ մասնավոր դաշտ, որի միջոցով տեղի է ունենում սկզբնավորումը: Սա հանգեցնում է ավելի մաքուր ծածկագրի, երբ սեփականության աքսեսուարներն օգտագործվում են միայն արտաքին մուտքի համար:
Օգտագործելով տեղական փոփոխականների և դասի դաշտերի հստակ մուտքագրում
Ինտերֆեյսների հստակ ներդրման դեպքում մենք պետք է հստակորեն նշենք, որ մենք աշխատում ենք ոչ թե դասի օրինակով, այլ ինտերֆեյսի օրինակով: Այսպիսով, օրինակ, անհնար է դառնում օգտագործել տիպային եզրակացություն և C#-ում տեղական փոփոխականներ հայտարարել՝ օգտագործելով var բանալի բառը։ Փոխարենը, մենք պետք է օգտագործենք հստակ ինտերֆեյսի տիպի հայտարարություն տեղական փոփոխականներ, ինչպես նաև մեթոդի ստորագրություններում և դասի դաշտերում:Այսպիսով, մի կողմից, մենք մի տեսակ ավելի քիչ ճկուն ենք դարձնում ծածկագիրը (օրինակ, ReSharper-ը լռելյայն միշտ առաջարկում է հնարավորության դեպքում օգտագործել հայտարարագիր var-ով), բայց մենք խուսափում ենք հնարավոր խնդիրներից՝ կապված որոշակի իրականացման հետ կապված, քանի որ համակարգը մեծանում է: և դրա ծավալի կոդը։ Այս կետը կարող է շատերի համար հակասական թվալ, բայց այն դեպքում, երբ մի քանի մարդ աշխատում է նախագծի վրա, և նույնիսկ աշխարհի տարբեր մասերում, բացահայտ մուտքագրման օգտագործումը կարող է շատ օգտակար լինել, քանի որ այն մեծացնում է կոդի ընթեռնելիությունը և նվազեցնում ծախսերը: նրա աջակցությունը։
Ինչպես ցանկացած տեխնիկական սարք, համակարգիչը տեղեկատվություն է փոխանակում անձի հետ որոշակի կանոնների միջոցով, որոնք պարտադիր են ինչպես մեքենայի, այնպես էլ անձի համար: Այս կանոնները համակարգչային գրականության մեջ կոչվում են միջերեսներ: Ինտերֆեյսը պետք է լինի պարզ և անհասկանալի, ընկերական և ոչ: Դրա հետ շատ ածականներ են գնում: Բայց մեկում նա մշտական է. նա կա, և դու ոչ մի տեղ չես կարող հեռանալ նրանից:
Ինտերֆեյս- սրանք են օպերացիոն համակարգի օգտատերերի հետ փոխգործակցության կանոնները, ինչպես նաև համակարգչային ցանցում հարևան մակարդակները: Մարդու և համակարգչի միջև կապի տեխնոլոգիան կախված է ինտերֆեյսից:
ԻնտերֆեյսԴա, առաջին հերթին, կանոնների ամբողջություն է։ Ինչպես ցանկացած կանոն, դրանք կարող են ընդհանրացվել, հավաքվել «ծածկագրի» մեջ, խմբավորվել ըստ ընդհանուր հատկանիշի։ Տᴀᴋᴎᴍ ᴏϬᴩᴀᴈᴏᴍ, մենք հասանք «ինտերֆեյսի տիպի» հայեցակարգին որպես մարդկանց և համակարգիչների փոխազդեցության եղանակների նմանության համակցություն: Մենք կարող ենք առաջարկել մարդու և համակարգչի միջև հաղորդակցության տարբեր ինտերֆեյսերի հետևյալ սխեմատիկ դասակարգումը (նկ. 1.):
Փաթեթային տեխնոլոգիա.Պատմականորեն այս տեսակի տեխնոլոգիան առաջինն է հայտնվել: Այն արդեն գոյություն ուներ Սյուեսի և Զուսեի ռելե մեքենաների վրա (Գերմանիա, 1937): Դրա գաղափարը պարզ է. համակարգչի մուտքագրումը նիշերի հաջորդականություն է, որում, ըստ որոշակի կանոնների, նշվում է կատարման համար գործարկված ծրագրերի հաջորդականությունը: Հաջորդ ծրագրի կատարումից հետո գործարկվում է հաջորդը և այլն։ Մեքենան, ըստ որոշակի կանոնների, իր համար գտնում է հրամաններ և տվյալներ։ Այս հաջորդականությունը կարող է լինել, օրինակ, դակված ժապավեն, դակված քարտերի բուրգ, էլեկտրական գրամեքենայի (օրինակ՝ CONSUL) ստեղները սեղմելու հաջորդականությունը: Մեքենան նաև թողարկում է իր հաղորդագրությունները պերֆորատորի, այբբենական թվային տպիչի (ATsPU), գրամեքենայի ժապավենի վրա:
Նման մեքենան «սև արկղ» է (ավելի ճիշտ՝ «սպիտակ կաբինետ»), որի մեջ անընդհատ սնվում է տեղեկատվություն և որը նույնպես անընդհատ «տեղեկացնում» է աշխարհին իր վիճակի մասին։ Այստեղ մարդը քիչ ազդեցություն ունի մեքենայի աշխատանքի վրա. նա կարող է միայն կասեցնել մեքենայի աշխատանքը, փոխել ծրագիրը և նորից միացնել համակարգիչը: Այնուհետև, երբ մեքենաներն ավելի հզորացան և կարողացան սպասարկել միանգամից մի քանի օգտատերերի, օգտագործողի հավերժական սպասումը, օրինակ. - ուտելու համար, մեղմ ասած, անհրաժեշտ դարձավ։ Բացի այդ, համակարգչային կենտրոնները, թերթերին հետևելով, դարձել են թղթի երկրորդ խոշորագույն «արտադրողը»։ Այդ պատճառով ալֆանա-թվային էկրանների հայտնվելով սկսվեց իսկապես օգտագործողի համար հարմար տեխնոլոգիայի՝ հրամանի տողի դարաշրջանը:
հրամանի ինտերֆեյս:
Հրամանի ինտերֆեյսը սովորաբար այդպես է կոչվում, քանի որ այս տեսակի ինտերֆեյսի դեպքում մարդը «հրամաններ» է տալիս համակարգչին, իսկ համակարգիչը կատարում է դրանք և արդյունքը տալիս մարդուն։ Հրամանի միջերեսն իրականացվում է որպես խմբաքանակի տեխնոլոգիա և հրամանի տող տեխնոլոգիա:
Այս տեխնոլոգիայի միջոցով ստեղնաշարը ծառայում է որպես անձից համակարգիչ տեղեկատվություն մուտքագրելու միակ միջոցը, իսկ համակարգիչը տվյալ անձին հաղորդում է այբբենական էկրան (մոնիտոր) օգտագործելով: Այս համակցությունը (մոնիտոր + ստեղնաշար) հայտնի դարձավ որպես տերմինալ կամ կոնսոլ։
Հրամանները մուտքագրվում են հրամանի տողում: Հրամանի տողը հուշման նշան է և թարթող ուղղանկյուն՝ կուրսորը:
Տեղակայված է ref.rf
Երբ ստեղնը սեղմվում է, նիշերը հայտնվում են կուրսորի դիրքում, և կուրսորն ինքը շարժվում է դեպի աջ: Հրամանը ավարտվում է Enter (կամ Վերադարձ.) ստեղնը սեղմելով, որից հետո կատարվում է անցում հաջորդ տողի սկզբին։ Հենց այս դիրքից էլ համակարգիչը ցուցադրում է իր աշխատանքի արդյունքները մոնիտորի վրա։ Այնուհետեւ գործընթացը կրկնվում է:
Հրամանի տողերի տեխնոլոգիան արդեն աշխատել է մոնոխրոմ այբբենական թվային էկրանների վրա: Քանի որ թույլատրվում էր մուտքագրել միայն տառեր, թվեր և կետադրական նշաններ, էկրանի տեխնիկական բնութագրերը նշանակալից չէին: Որպես մոնիտոր կարող են օգտագործվել հեռուստատեսային ընդունիչ և նույնիսկ օսցիլոսկոպի խողովակ:
Այս երկու տեխնոլոգիաներն էլ իրականացվում են հրամանի ինտերֆեյսի տեսքով. մեքենաները սնվում են հրամանի մուտքագրման մեջ, և այն, կարծես, «պատասխանում է» դրանց:
Տեքստային ֆայլերը դարձան ֆայլերի գերակշռող տեսակը հրամանի ինտերֆեյսի հետ աշխատելիս. դրանք և միայն դրանք կարող էին ստեղծվել ստեղնաշարի միջոցով: Հրամանի տողի ինտերֆեյսի ամենալայն օգտագործման ժամանակը UNIX օպերացիոն համակարգի ի հայտ գալն է և առաջին ութ բիթանոց անհատական համակարգիչների հայտնվելը CP/M բազմպլատֆորմ օպերացիոն համակարգով։
WIMP ինտերֆեյս(Պատուհան - պատուհան, Պատկեր - պատկեր, Մենյու - մենյու, Ցուցիչ - ցուցիչ): Այս տեսակի ինտերֆեյսի բնորոշ առանձնահատկությունն այն է, որ օգտագործողի հետ երկխոսությունն իրականացվում է ոչ թե հրամանների, այլ գրաֆիկական պատկերների՝ մենյուների, պատուհանների և այլ տարրերի օգնությամբ: Չնայած մեքենայի հրամանները տրվում են այս ինտերֆեյսում, դա արվում է «անուղղակի»՝ գրաֆիկական պատկերների միջոցով։ Գրաֆիկական ինտերֆեյսի գաղափարը ծագել է 1970-ականների կեսերին, երբ տեսողական ինտերֆեյսի գաղափարը մշակվել է Xerox Palo Alto հետազոտական կենտրոնում (PARC): Գրաֆիկական ինտերֆեյսի համար նախապայմանն էր հրամանին համակարգչի արձագանքման ժամանակի նվազումը, RAM-ի քանակի ավելացումը, ինչպես նաև համակարգիչների տեխնիկական բազայի զարգացումը։ Հայեցակարգի ապարատային հիմքը, իհարկե, համակարգիչների վրա ալֆանա-թվային էկրանների հայտնվելն էր, և այդ էկրաններն արդեն ունեին այնպիսի էֆեկտներ, ինչպիսիք են նիշերի «թրթռումը», գույնի հակադարձումը (սև ֆոնի վրա սպիտակ նիշերի ոճը հակադարձելը, այսինքն. սև նիշեր սպիտակ ֆոնի վրա), ընդգծող նիշեր: Այս էֆեկտները չեն տարածվում ամբողջ էկրանի վրա, այլ միայն մեկ կամ մի քանի նիշերի վրա: Հաջորդ քայլը գունավոր էկրանի ստեղծումն էր, որը թույլ է տալիս այս էֆեկտների հետ մեկտեղ 16 գույներով սիմվոլներ ֆոնի վրա 8 գույների գունապնակով (այսինքն՝ գունային հավաքածու): Գրաֆիկական էկրանների հայտնվելուց հետո, տարբեր գույների էկրանի վրա բազմաթիվ կետերի տեսքով ցանկացած գրաֆիկական պատկեր ցուցադրելու ունակությամբ, էկրանն օգտագործելու երևակայության սահմանափակումներ չկան: PARC-ի առաջին GUI համակարգը՝ 8010 Star Information System, այսպիսով հայտնվեց 1981 թվականին IBM-ի առաջին համակարգչի թողարկումից չորս ամիս առաջ։ Սկզբում տեսողական ինտերֆեյսը օգտագործվում էր միայն ծրագրերում։ Աստիճանաբար նա սկսեց անցնել օպերացիոն համակարգերին, որոնք օգտագործվում էին սկզբում Atari-ի և Apple Macintosh-ի, այնուհետև IBM-ի հետ համատեղելի համակարգիչների վրա:
Ավելի վաղ ժամանակներից, և նաև այս հասկացությունների ազդեցության տակ, տեղի է ունեցել կիրառական ծրագրերի կողմից ստեղնաշարի և մկնիկի օգտագործման միավորման գործընթաց: Այս երկու միտումների միաձուլումը հանգեցրել է օգտատերերի ինտերֆեյսի ստեղծմանը, որի օգնությամբ անձնակազմի վերապատրաստման վրա ծախսված նվազագույն ժամանակով և գումարով կարող եք աշխատել ցանկացած ծրագրային արտադրանքի հետ։ Այս ինտերֆեյսի նկարագրությունը, որը ընդհանուր է բոլոր հավելվածների և օպերացիոն համակարգերի համար, այս մասի թեման է:
Օգտագործողի գրաֆիկական ինտերֆեյսն իր մշակման ընթացքում անցել է երկու փուլով և իրականացվում է տեխնոլոգիայի երկու մակարդակով՝ պարզ գրաֆիկական ինտերֆեյս և «մաքուր» WIMP ինտերֆեյս։
Առաջին փուլում գրաֆիկական ինտերֆեյսը շատ նման էր հրամանի տողերի տեխնոլոգիային: Հրամանի տողի տեխնոլոգիայի տարբերությունները հետևյալն էին.
Ú Նշաններ ցուցադրելիս թույլատրվում էր որոշ նշաններ ընդգծել գույնով, շրջված պատկերով, ընդգծված և թարթող: Դրա շնորհիվ պատկերի արտահայտչականությունը մեծացել է։
Ú Հաշվի առնելով գրաֆիկական ինտերֆեյսի կոնկրետ իրականացումից կախվածությունը, կուրսորը կարող է ներկայացվել ոչ միայն թարթող ուղղանկյունով, այլև մի քանի նիշ և նույնիսկ էկրանի մի մաս ընդգրկող որոշ տարածքով: Այս ընտրված տարածքը տարբերվում է այլ չընտրված մասերից (սովորաբար ըստ գույնի):
Ú Enter ստեղնը սեղմելը միշտ չէ, որ կատարում է հրամանը և անցնում հաջորդ տող: Ցանկացած ստեղն սեղմելու արձագանքը մեծապես կախված է նրանից, թե էկրանի որ մասում էր կուրսորը:
Ú Բացի Enter ստեղնից, մոխրագույն կուրսորային ստեղները ավելի ու ավելի են օգտագործվում ստեղնաշարի վրա (տես ստեղնաշարի բաժինը այս շարքի 3-րդ համարում):
Ú Գրաֆիկական ինտերֆեյսի այս տարբերակում արդեն սկսել են օգտագործվել մանիպուլյատորներ (օրինակ՝ մկնիկ, թրեքբոլ և այլն - տես Նկար Ա.4):
Ամփոփելով՝ մենք կարող ենք տալ այս ինտերֆեյսի հետևյալ տարբերակիչ հատկանիշները.
Ú Նշեք էկրանի տարածքները:
Ú Ստեղնաշարի ստեղների վերաիմաստավորում՝ հիմնվելով համատեքստի վրա:
Ú Օգտագործելով մանիպուլյատորներ և ստեղնաշարի մոխրագույն ստեղներ՝ կուրսորը կառավարելու համար:
Ú Գունավոր մոնիտորների լայն օգտագործում:
Այս տեսակի ինտերֆեյսի տեսքը համընկնում է MS-DOS օպերացիոն համակարգի լայն տարածման հետ։ Նա էր, ով այս ինտերֆեյսը ներկայացրեց զանգվածներին, ինչի շնորհիվ 80-ականները նշանավորվեցին այս տեսակի ինտերֆեյսի բարելավմամբ, կերպարների ցուցադրման բնութագրերի բարելավմամբ և մոնիտորի այլ պարամետրերով:
Այս տեսակի ինտերֆեյսի օգտագործման բնորոշ օրինակ է Nortron Commander ֆայլի կեղևը և Multi-Edit տեքստային խմբագրիչը: Իսկ տեքստային խմբագրիչները Lexicon-ը, ChiWriter-ը և Microsoft Word for Dos տեքստային պրոցեսորը օրինակ են, թե ինչպես է այս ինտերֆեյսը գերազանցել իրեն:
Գրաֆիկական ինտերֆեյսի մշակման երկրորդ փուլը եղել է «մաքուր» WIMP ինտերֆեյսը:Ինտերֆեյսի այս ենթատեսակին բնորոշ են հետևյալ հատկանիշները.
Ú Ծրագրերի, ֆայլերի և փաստաթղթերի հետ բոլոր աշխատանքները կատարվում են պատուհաններում՝ էկրանի որոշակի հատվածներ, որոնք ուրվագծված են շրջանակով:
Ú Բոլոր ծրագրերը, ֆայլերը, փաստաթղթերը, սարքերը և այլ օբյեկտները ներկայացված են որպես պատկերակներ՝ պատկերակներ: Երբ բացվում է, պատկերակները վերածվում են պատուհանների:
Ú Օբյեկտների հետ բոլոր գործողություններն իրականացվում են մենյուի միջոցով: Չնայած մենյուն հայտնվել է գրաֆիկական ինտերֆեյսի մշակման առաջին փուլում, այն չուներ գերիշխող նշանակություն, այլ ծառայում էր միայն որպես հրամանի տողի հավելում։ Մաքուր WIMP ինտերֆեյսում ընտրացանկը դառնում է կառավարման հիմնական տարրը:
Ú Մանիպուլյատորների լայնածավալ օգտագործում՝ առարկաները մատնանշելու համար: Մանիպուլյատորը դադարում է լինել պարզապես խաղալիք՝ ստեղնաշարի հավելում, բայց դառնում է կառավարման հիմնական տարրը: Մանիպուլյատորի օգնությամբ նրանք մատնացույց են անում էկրանի ցանկացած հատված, պատուհաններ կամ պատկերակներ, ընտրում են այն և միայն դրանից հետո մենյուի միջոցով կամ այլ տեխնոլոգիաների միջոցով կառավարում են դրանք։
Հարկ է նշել, որ WIMP-ը դրա իրականացման համար պահանջում է բարձր լուծաչափով գունավոր ռաստերային էկրան և մանիպուլյատոր:
Տեղակայված է ref.rf
Նաև այս տեսակի ինտերֆեյսի վրա կենտրոնացած ծրագրերը մեծացնում են պահանջները համակարգչի աշխատանքի, հիշողության չափի, ավտոբուսի թողունակության և այլնի նկատմամբ: Միևնույն ժամանակ, ինտերֆեյսի այս տեսակն ամենահեշտն է սովորելն ու ինտուիտիվը: Այս պատճառով WIMP ինտերֆեյսը այժմ դարձել է դե ֆակտո ստանդարտ:
Գրաֆիկական ինտերֆեյս ունեցող ծրագրերի վառ օրինակ է Microsoft Windows օպերացիոն համակարգը:
ՄԵՏԱՔՍ- ինտերֆեյս (Խոսք - խոսք, Պատկեր - պատկեր, Լեզու - լեզու, Գիտելիք - գիտելիք): Այս տեսակի ինտերֆեյսը ամենամոտ է հաղորդակցության սովորական, մարդկային ձևին: Այս ինտերֆեյսի շրջանակներում նորմալ «զրույց» է տեղի ունենում մարդու եւ համակարգչի միջեւ։ Միաժամանակ, համակարգիչը իր համար հրամաններ է գտնում՝ վերլուծելով մարդկային խոսքը և գտնելով նրանում հիմնական արտահայտությունները։ Այն նաև փոխակերպում է հրամանի կատարման արդյունքը մարդու կողմից ընթեռնելի ձևի: Այս տեսակի ինտերֆեյսը ամենախստապահանջն է համակարգչի ապարատային ռեսուրսների նկատմամբ, և այս առումով այն օգտագործվում է հիմնականում ռազմական նպատակներով։
90-ականների կեսերից, էժան ձայնային քարտերի հայտնվելուց և խոսքի ճանաչման տեխնոլոգիաների համատարած օգտագործումից հետո, հայտնվեց SILK ինտերֆեյսի այսպես կոչված «խոսքի տեխնոլոգիան»։ Այս տեխնոլոգիայով հրամանները տրվում են ձայնային՝ արտասանելով հատուկ վերապահված բառեր՝ հրամաններ։
Բառերը պետք է արտասանվեն հստակ, նույն արագությամբ: Բառերի միջև դադար է լինում։ Խոսքի ճանաչման ալգորիթմի թերզարգացման պատճառով նման համակարգերը պահանջում են անհատական նախնական կոնֆիգուրացիա յուրաքանչյուր կոնկրետ օգտագործողի համար:
«Խոսքի» տեխնոլոգիան SILK ինտերֆեյսի ամենապարզ իրականացումն է:
Կենսաչափական տեխնոլոգիա («Mimic Interface»)
Այս տեխնոլոգիան առաջացել է 1990-ականների վերջին և դեռ մշակվում է այս գրելու պահին: Համակարգիչը կառավարելու համար օգտագործվում են մարդու դեմքի արտահայտությունը, հայացքի ուղղությունը, աշակերտի չափը և այլ նշաններ։ Օգտատիրոջ նույնականացման համար օգտագործվում է նրա աչքերի ծիածանաթաղանթի նախշը, մատնահետքերը և այլ յուրահատուկ տեղեկություններ։ Պատկերները կարդացվում են թվային տեսախցիկից, այնուհետև հրամաններ են հանվում այս պատկերից՝ օգտագործելով պատկերների ճանաչման հատուկ ծրագրեր: Այս տեխնոլոգիան, ամենայն հավանականությամբ, կզբաղեցնի իր տեղը ծրագրային ապահովման արտադրանքներում և հավելվածներում, որտեղ կարևոր է ճշգրիտ նույնականացնել համակարգչի օգտագործողին:
