Grensesnitt og teknologier. Hovedteknologiene for implementering av grensesnitt er: Batch

OOP

Sist mandag var jeg så heldig å få et intervju som Senior .Net Developer hos et internasjonalt selskap. Under intervjuet ble jeg bedt om å ta en test hvor en rekke spørsmål var knyttet til .Net. Spesielt i ett av spørsmålene var det nødvendig å vurdere (sant/usant) en rekke påstander, blant annet følgende:

I .Net implementerer en hvilken som helst rekke elementer, for eksempel int, IList som standard, slik at den kan brukes som en samling i en foreach-setning.

Svarer raskt benektende på dette spørsmålet og skriver separat i margen. at foreach krever en implementering ikke av IList, men av IEnumerable, gikk jeg videre til neste spørsmål. På vei hjem ble jeg imidlertid plaget av spørsmålet: implementerer arrayen fortsatt dette grensesnittet eller ikke?

Om IList husket jeg vagt at dette grensesnittet gir meg en IEnumerable, en indekser og en Count-egenskap som inneholder antall elementer i samlingen, samt et par sjelden brukte egenskaper, for eksempel IsFixedCollection(). Arrayen har en Length-egenskap for størrelsen, og Count i IEnumerable er en utvidelsesmetode fra LINQ, som ikke ville vært mulig hvis metoden ble implementert i en klasse. Dermed viste det seg at arrayet ikke kunne implementere IList-grensesnittet, men en eller annen vag følelse hjemsøkte meg. Så kvelden etter intervjuet bestemte jeg meg for å gjøre litt research.

Klasse System.Array

Siden jeg ikke hadde Reflector.Net installert, skrev jeg bare et kort program i C# for å finne ut hva slags grensesnitt som implementeres av en heltallsmatrise.

Var v = ny int ( 1, 2, 3 ); var t = v.GetType(); var i = t.GetInterfaces(); foreach(var tp i i) Console.WriteLine(tp.Name);

Her er den komplette listen over mottatte grensesnitt fra konsollvinduet:

ICloneable IList ICollection IEnumerable IStructuralComparable IStructuralEquatable IList`1 ICollection`1 IEnumerable`1 IReadOnlyList`1 IReadOnlyCollection`1

Dermed, en array i .Net implementerer fortsatt IList-grensesnittet og dens generaliserte versjon IList<> .

For å få mer fullstendig informasjon bygde jeg et diagram over System.Array-klassen.

Min feil fanget meg umiddelbart: Count var ikke en egenskap til IList, men til ICollection, det forrige grensesnittet i arvekjeden. Selve arrayet hadde imidlertid ikke lenger en slik egenskap, og heller ikke mange av de andre egenskapene til IList-grensesnittet, selv om grensesnittets andre egenskaper, IsFixedSize og IsReadOnly, ble implementert. Hvordan er dette mulig?

Alt faller umiddelbart på plass når du husker at i C# kan du implementere grensesnitt ikke bare
implisitt, men også eksplisitt. Jeg kjente til denne muligheten fra lærebøker, som ga et eksempel på slik implementering i en sak. når basisklassen allerede inneholder en metode med samme navn som grensesnittmetoden. Jeg så også denne funksjonen i ReSharper. Men til nå har jeg ikke direkte støtt på behovet for å eksplisitt implementere grensesnitt i mine egne prosjekter.

Sammenligning av eksplisitt og implisitt implementering av grensesnitt

La oss sammenligne disse to typene grensesnittimplementeringer:.

Kriterier	Implisitt implementering	Eksplisitt implementering
Grunnleggende syntaks	grensesnitt ITest ( void DoTest(); ) offentlig klasse ImplicitTest: ITest ( public void DoTest() ( ) )	grensesnitt ITest ( void DoTest(); ) offentlig klasse ExplicitTest: ITest ( void ITest.DoTest() ( ) )
Synlighet	Implisitt implementering har alltid vært offentlig, så metoder og egenskaper kan nås direkte. var imp = new ImplicitTest(); imp.DoTest();	Eksplisitt implementering er alltid privat. For å få tilgang til implementeringen, må du caste klasseforekomsten til grensesnittet (upcast til grensesnitt). var exp = new ExplicitTest(); ((ITest)exp).DoTest();
Polymorfi	Den implisitte implementeringen av et grensesnitt kan være virtuell, noe som gjør at denne implementeringen kan skrives om i etterkommerklasser.	Eksplisitt implementering er alltid statisk. Den kan ikke overstyres (overstyre) eller blokkeres (ny) i etterkommerklasser. Merk 1
Abstrakt klasse og implementering	En implisitt implementering kan være abstrakt og implementert bare i en etterkommerklasse.	En eksplisitt implementering kan ikke være abstrakt, men selve klassen kan ha andre abstrakte metoder og være abstrakt i seg selv. Merk 2

Merknader:
Merk 1 - Som med rette bemerket i kommentarene, kan implementeringen overstyres ved gjentatt eksplisitt implementering av grensesnittet i etterkommerklassen (se den første kommentaren til artikkelen).

Merk 2 - En av bloggene sier at en klasse i seg selv ikke kan være abstrakt. Kanskje dette var sant for noen av de tidligere versjonene av kompilatoren; i mine eksperimenter kunne jeg implementere grensesnittet eksplisitt i en abstrakt klasse uten problemer.

Hvorfor trenger vi eksplisitt implementering av grensesnitt?

Eksplisitt grensesnittimplementering, ifølge MSDN, er nødvendig når flere grensesnitt implementert av en klasse har en metode med samme signatur. Dette problemet er generelt kjent i den engelsktalende verden under det kjølige navnet "dødens dødelige diamant", som er oversatt til russisk som "diamantproblemet". Her er et eksempel på en slik situasjon:

/* Listing 1 */ interface IJogger ( void Run(); ) interface ISkier ( void Run(); ) public class Athlete: ISkier, IJogger ( public void Run() ( Console.WriteLine("Er jeg en idrettsutøver, skiløper eller Jogger?"); ) )

Dette eksemplet er forresten korrekt kode i C#, det vil si at den kompilerer og kjører (korrekt), mens Run()-metoden både er en metode for selve klassen og en implementering av så mange som to grensesnitt. På denne måten kan vi ha én implementering for ulike grensesnitt og for selve klassen. Du kan sjekke dette med følgende kode:

/* Listing 2 */ var sp = new Athlete(); sp.Kjør(); (sp som ISkier).Kjør(); (sp som IJogger).Kjør();

Resultatet av å kjøre denne koden vil være "Er jeg en idrettsutøver, skiløper eller jogger?", skrevet ut på konsollen tre ganger.

Det er her vi kan bruke eksplisitt grensesnittimplementering for å skille alle tre tilfellene:

/* Listing 3 */ public class Sportsman ( public virtual void Run() ( Console.WriteLine("I am a Sportsman"); ) ) offentlig klasse Atlet: Sportsman, ISkier, IJogger ( public override void Run() ( Console. WriteLine("Jeg er en idrettsutøver"); ) void ISkier.Run() ( Console.WriteLine("Jeg er en skiløper"); ) void IJogger.Run() ( Console.WriteLine("Jeg er en jogger"); ) )

I dette tilfellet, når vi kjører koden fra oppføring 2, vil vi se tre linjer i konsollen, "Jeg er en idrettsutøver", "Jeg er en skiløper" Og "Jeg er jogger".

Fordeler og ulemper med ulike grensesnittimplementeringer

Implementeringssynlighet og selektiv implementering

Som allerede vist ovenfor, er en implisitt implementering ikke syntaktisk forskjellig fra en vanlig klassemetode (og hvis denne metoden allerede er definert i stamfarklassen, vil metoden i denne syntaksen være skjult i etterkommeren og koden vil være kompilert uten problemer kompilatorvarsel om å skjule metoden.). Dessuten er det mulig å selektivt implementere individuelle metoder for ett grensesnitt, enten eksplisitt eller implisitt:

/* Listing 4 */ public class Code ( public void Run() ( Console.WriteLine("Jeg er en klassemetode"); ) ) grensesnitt ICommand ( void Run(); void Execute(); ) public class CodeCommand: Code , ICommand ( // implisitt grensesnittmetodeimplementering // => offentlig implementering // implisitt baseklassemetode skjuler (advarsel her) public void Run() ( base.Run(); ) // eksplisitt grensesnittmetodeimplementering // => privat implementering ugyldig ICommand.Execute() () )

Dette gjør at implementeringer av individuelle grensesnittmetoder kan brukes som native metoder for klassen, og de er tilgjengelige, for eksempel gjennom IntelliSense, i motsetning til eksplisitt implementering av metoder, som er private og kun synlige etter casting til det tilsvarende grensesnittet.

På den annen side lar muligheten til å implementere metoder privat deg skjule en rekke grensesnittmetoder mens du implementerer det fullt ut. For å gå tilbake til vårt aller første eksempel med arrays i .Net, kan du se at arrayet skjuler for eksempel implementeringen av Count-egenskapen til ICollection-grensesnittet, og eksponerer denne egenskapen under navnet Length (sannsynligvis er dette et forsøk på å opprettholde kompatibilitet) med C++ STL og Java). Dermed kan vi skjule visse metoder for det implementerte grensesnittet og ikke skjule (= offentliggjøre) andre.

Problemet her er imidlertid at det i mange tilfeller er helt umulig å gjette hvilke grensesnitt som implementeres "implisitt" av en klasse, siden verken metodene eller egenskapene til disse grensesnittene er synlige i IntelliSense (eksemplet med System.Array er også lærerikt her). Den eneste måten å identifisere slike implementeringer på er å bruke refleksjon, for eksempel ved å bruke Object Browser i Visual Studio.

Refaktorering av grensesnitt

Siden den implisitte (offentlige) implementeringen av et grensesnitt ikke skiller seg fra implementeringen av en offentlig metode for en klasse, i tilfelle refaktorisering av grensesnittet og fjerning av offentlig metode fra det (for eksempel når du kombinerer Run() og Execute () metoder fra ovennevnte ICommand-grensesnitt til én metode. Kjør( )) i alle implisitte implementeringer, vil metoden forbli åpen tilgang, som med stor sannsynlighet må støttes selv etter refaktorisering, siden denne offentlige metoden allerede kan ha ulike avhengigheter i andre komponenter i systemet. Som et resultat av dette vil programmeringsprinsippet "mot grensesnitt, ikke implementeringer" bli brutt, siden avhengighetene allerede vil være mellom spesifikke (og i forskjellige klasser, sannsynligvis forskjellige) implementeringer av den tidligere grensesnittmetoden.

/* Listing 5 */ interface IFingers ( void Thumb(); void IndexFinger(); // en foreldet grensesnittmetode // void MiddleFinger(); ) public class HumanPalm: IFingers ( public void Thumb() () public void IndexFinger( ) () // her er en "dinglende" offentlig metode public void MiddleFinger() () ) public class AnthropoidHand: IFingers ( void IFingers.Thumb() () void IFingers.IndexFinger() () // her kompilatorfeilen void IFingers.MiddleFinger() () )

Ved privat implementering av grensesnitt vil alle klasser med en eksplisitt implementering av en metode som ikke lenger eksisterer ganske enkelt slutte å kompilere, men etter å ha fjernet implementeringen som har blitt unødvendig (eller refaktorert den til en ny metode), vil vi ikke ha en "ekstra" offentlig metode som ikke er knyttet til noe grensesnitt. Selvfølgelig kan det være nødvendig å refaktorisere avhengigheter på selve grensesnittet, men i det minste her vil det ikke være noe brudd på "program til grensesnitt, ikke implementeringer"-prinsippet.

Når det gjelder egenskaper, lar implisitt implementerte grensesnittegenskaper (egenskaper) deg få tilgang til dem gjennom tilgangsmetoder (getter og setter) både eksternt og direkte fra selve klassen, noe som kan føre til unødvendige effekter (for eksempel unødvendig datavalidering under initialiseringsegenskaper) .

/* Oppføring 6 */ grensesnitt IPproperty ( int Amount ( get; set; ) ) public class ClassWithProperty: IPproperty ( // implisitt implementering, public public int Amount ( get; set; ) public ClassWithProperty() ( // intern påkalling av public setter Amount = 1000; ) ) public class ClassWithExplicitProperty: IPproperty ( // eksplisitt implementering, privat int IPproperty.Amount ( get; set; ) public ClassWithExplicitProperty() ( // intern påkalling er ikke mulig // kompilatorfeil her Mengde = 1000;))

Når du eksplisitt implementerer grensesnittegenskaper, forblir disse egenskapene private og for å få tilgang må du ta den "lange" banen og deklarere et ekstra privat felt som initialisering skjer gjennom. Dette resulterer i renere kode der eiendomstilbehør bare brukes for ekstern tilgang.

Bruker eksplisitt skriving av lokale variabler og klassefelt

Ved eksplisitt implementering av grensesnitt, må vi eksplisitt indikere at vi ikke jobber med en forekomst av en klasse, men med en forekomst av et grensesnitt. Dermed blir det for eksempel umulig å bruke typeinferens og deklarere lokale variabler i C# ved å bruke var-tjenesteordet. I stedet må vi bruke en eksplisitt erklæring av grensesnitttypen når vi deklarerer lokale variabler, samt i metodesignaturen og i klassefelt.

Dermed ser vi på den ene siden ut til å gjøre koden noe mindre fleksibel (for eksempel foreslår ReSharper som standard alltid å bruke en erklæring med var hvis mulig), men vi unngår potensielle problemer knyttet til binding til en spesifikk implementering ettersom systemet vokser og volumet vokser.kode. Dette punktet kan virke kontroversielt for mange, men i tilfelle flere personer jobber med et prosjekt, og til og med i forskjellige deler av verden, kan bruk av eksplisitt skriving være svært nyttig, da det øker lesbarheten til koden og reduserer kostnadene å opprettholde den.

Som enhver teknisk enhet, utveksler en datamaskin informasjon med en person gjennom et sett med visse regler som er obligatoriske for både maskinen og personen. Disse reglene kalles et grensesnitt i datalitteratur. Grensesnittet kan være forståelig eller uforståelig, vennlig eller ikke. Mange adjektiver gjelder for det. Men én ting er konstant: den eksisterer, og du kan ikke unnslippe den.

Grensesnitt- dette er reglene for samhandling mellom operativsystem og brukere, samt nabonivåer i datanettverket. Teknologien for menneske-datamaskin kommunikasjon avhenger av grensesnittet.

Grensesnitt– Dette er for det første et sett med regler. Som alle regler kan de generaliseres, samles i en "kode" og grupperes i henhold til en felles egenskap. Dermed kom vi til konseptet "grensesnitttype" som en kombinasjon av lignende måter for interaksjon mellom mennesker og datamaskiner. Vi kan foreslå følgende skjematiske klassifisering av ulike menneske-datamaskin kommunikasjonsgrensesnitt (fig. 1.).

Batch-teknologi. Historisk sett dukket denne typen teknologi opp først. Den eksisterte allerede på relémaskinene til Sues og Zuse (Tyskland, 1937). Ideen er enkel: en sekvens av symboler leveres til datamaskininngangen, der, i henhold til visse regler, sekvensen av programmer som er lansert for kjøring er indikert. Etter at neste program er utført, startes det neste, og så videre. Maskinen finner i henhold til visse regler kommandoer og data for seg selv. Denne sekvensen kan for eksempel være en hullpapirtape, en stabel med hullkort eller en sekvens med å trykke på tastene på en elektrisk skrivemaskin (CONSUL-type). Maskinen sender også sine meldinger til en stanse, en alfanumerisk utskriftsenhet (ADP) eller et skrivemaskinbånd.

En slik maskin er en "svart boks" (nærmere bestemt et "hvitt skap"), hvor det hele tiden tilføres informasjon og som også konstant "informerer" verden om dens tilstand. En person her har liten innflytelse på driften av maskinen - han kan bare pause driften av maskinen, endre programmet og starte datamaskinen på nytt. Deretter, da maskinene ble kraftigere og kunne betjene flere brukere samtidig, ventet brukere for alltid som: "Jeg sendte data til maskinen. Jeg venter på at den skal svare. Og vil den svare i det hele tatt?" – det ble mildt sagt kjedelig. I tillegg har datasentre, etter aviser, blitt den andre store "produsenten" av returpapir. Derfor, med bruken av alfanumeriske skjermer, begynte æraen med virkelig brukervennlig teknologi - kommandolinjen.

Kommandogrensesnitt.

Kommandogrensesnittet kalles så fordi i denne typen grensesnitt gir en person "kommandoer" til datamaskinen, og datamaskinen utfører dem og gir resultatet til personen. Kommandogrensesnittet er implementert i form av batchteknologi og kommandolinjeteknologi.

Med denne teknologien er et tastatur den eneste måten å legge inn informasjon fra en person til en datamaskin, og datamaskinen viser informasjon til personen ved hjelp av en alfanumerisk skjerm (skjerm). Denne kombinasjonen (skjerm + tastatur) ble kalt en terminal eller konsoll.

Kommandoer skrives på kommandolinjen. Kommandolinjen er et ledetekstsymbol og et blinkende rektangel - en markør. Når du trykker på en tast, vises symboler ved markørens plassering, og selve markøren flyttes til høyre. Kommandoen avsluttes ved å trykke på Enter (eller Retur), som deretter flytter til begynnelsen av neste linje. Det er fra denne posisjonen at datamaskinen viser resultatene av arbeidet sitt på skjermen. Deretter gjentas prosessen.

Kommandolinjeteknologi fungerte allerede på monokrome alfanumeriske skjermer. Siden det kun var mulig å legge inn bokstaver, tall og skilletegn, var de tekniske egenskapene til skjermen ikke vesentlige. En TV-mottaker og til og med et oscilloskoprør kan brukes som monitor.

Begge disse teknologiene er implementert i form av et kommandogrensesnitt - kommandoer blir gitt til maskinen som input, og den "svarer" så å si på dem.

Tekstfiler ble den dominerende typen filer når man jobbet med kommandogrensesnittet - de og bare de kunne lages ved hjelp av tastaturet. Tiden da kommandolinjegrensesnittet ble mest brukt, var fremveksten av UNIX-operativsystemet og utseendet til de første åtte-bits personlige datamaskinene med multi-plattform CP/M-operativsystemet.

WIMP-grensesnitt(Vindu - vindu, Bilde - bilde, Meny - meny, Peker - peker). Et karakteristisk trekk ved denne typen grensesnitt er at dialogen med brukeren ikke utføres ved hjelp av kommandoer, men ved hjelp av grafiske bilder - menyer, vinduer og andre elementer. Selv om kommandoer gis til maskinen i dette grensesnittet, gjøres dette "indirekte", gjennom grafiske bilder. Ideen om et grafisk grensesnitt begynte på midten av 70-tallet da konseptet med et visuelt grensesnitt ble utviklet ved Xerox Palo Alto Research Center (PARC). Forutsetningen for det grafiske grensesnittet var en reduksjon i datamaskinens reaksjonstid på en kommando, en økning i mengden RAM, samt utvikling av den tekniske basen til datamaskiner. Maskinvaregrunnlaget for konseptet var selvfølgelig utseendet til alfanumeriske skjermer på datamaskiner, og disse skjermene hadde allerede slike effekter som "flimmer" av tegn, fargeinversjon (endre omrisset av hvite tegn på svart bakgrunn til motsatt, det vil si svarte tegn på hvit bakgrunn ), som understreker tegn. Disse effektene strakk seg ikke til hele skjermen, men bare til en eller flere karakterer. Neste trinn var å lage en fargeskjerm som ville tillate visning, sammen med disse effektene, av tegn i 16 farger på en bakgrunn med en palett (det vil si et fargesett) med 8 farger. Etter fremkomsten av grafiske skjermer, med muligheten til å vise alle grafiske bilder i form av mange prikker på en skjerm i forskjellige farger, var det ingen grenser for fantasien ved bruk av skjermen! Det første systemet med et grafisk grensesnitt, 8010 Star Information System fra PARC-gruppen, dukket dermed opp fire måneder før utgivelsen av den første IBM-datamaskinen i 1981. Opprinnelig ble det visuelle grensesnittet bare brukt i programmer. Gradvis begynte han å bytte til operativsystemer, først brukt på Atari- og Apple Macintosh-datamaskiner, og deretter på IBM-kompatible datamaskiner.

Fra en tidligere tid, og også påvirket av disse konseptene, var det en prosess for å forene bruken av tastatur og mus av applikasjonsprogrammer. Sammenslåingen av disse to trendene førte til opprettelsen av et brukergrensesnitt som, med minimal tid og penger brukt på omskolering av personalet, kan jobbe med et hvilket som helst programvareprodukt. Denne delen er viet en beskrivelse av dette grensesnittet, felles for alle applikasjoner og operativsystemer.

Det grafiske brukergrensesnittet har gått gjennom to stadier under utviklingen og er implementert på to teknologinivåer: et enkelt grafisk grensesnitt og et "rent" WIMP-grensesnitt.

I den første fasen var GUI veldig lik kommandolinjeteknologi. Forskjellene fra kommandolinjeteknologien var som følger:

Ú Ved visning av tegn var det tillatt å fremheve noen tegn med farge, omvendt bilde, understreking og flimring. Takket være dette har uttrykksevnen til bildet økt.

Ú Avhengig av den spesifikke implementeringen av det grafiske grensesnittet, kan markøren vises ikke bare som et flimrende rektangel, men også som et område som dekker flere tegn og til og med en del av skjermen. Dette valgte området skiller seg fra andre uvalgte deler (vanligvis etter farge).

Ú Å trykke på Enter-tasten utfører ikke alltid kommandoen og går til neste linje. Reaksjonen på å trykke på en tast avhenger i stor grad av hvor markøren var på skjermen.

Ú I tillegg til Enter-tasten, har «grå» markørkontrolltaster blitt stadig mer brukt på tastaturet (se avsnittet om tastaturet i utgave 3 av denne serien.)

Ú Allerede i denne utgaven av det grafiske grensesnittet begynte man å bruke manipulatorer (som en mus, styrekule osv. - se figur A.4.) De gjorde det mulig å raskt velge ønsket del av skjermen og flytte markøren .

For å oppsummere kan vi sitere følgende karakteristiske trekk ved dette grensesnittet:

Ú Velge områder på skjermen.

Ú Omdefiner tastaturtaster avhengig av kontekst.

Ú Bruke manipulatorer og grå tastaturtaster for å kontrollere markøren.

Ú Utbredt bruk av fargemonitorer.

Utseendet til denne typen grensesnitt faller sammen med den utbredte bruken av MS-DOS-operativsystemet. Det var hun som introduserte dette grensesnittet til massene, takket være at 80-tallet ble preget av forbedringen av denne typen grensesnitt, og forbedret egenskapene til karaktervisning og andre skjermparametere.

Et typisk eksempel på bruk av denne typen grensesnitt er Nortron Commander-filskallet og Multi-Edit-tekstredigeringsprogrammet. Og tekstredigererne Lexicon, ChiWriter og Microsoft Word for Dos tekstbehandler er eksempler på hvordan dette grensesnittet har overgått seg selv.

Den andre fasen i utviklingen av det grafiske grensesnittet var det "rene" WIMP-grensesnittet. Denne undertypen av grensesnitt er preget av følgende funksjoner:

Ú Alt arbeid med programmer, filer og dokumenter skjer i vinduer - visse deler av skjermen er omgitt av en ramme.

Ú Alle programmer, filer, dokumenter, enheter og andre objekter presenteres i form av ikoner. Når de åpnes, blir ikonene til vinduer.

Ú Alle handlinger med objekter utføres ved hjelp av menyen. Selv om menyen dukket opp på det første stadiet av utviklingen av det grafiske grensesnittet, hadde den ikke en dominerende rolle i den, men fungerte bare som et tillegg til kommandolinjen. I et rent WIMP-grensesnitt blir menyen hovedkontrollelementet.

Ú Utstrakt bruk av manipulatorer for å peke på objekter. Pekeenheten slutter å være bare et leketøy - et tillegg til tastaturet, men blir hovedkontrollelementet. Ved å bruke en manipulator peker de på et hvilket som helst område av skjermen, vinduet eller ikonet, velger det og kontrollerer dem først gjennom menyen eller ved hjelp av andre teknologier.

Det skal bemerkes at WIMP krever en høyoppløselig fargerasterskjerm og en pekeenhet for implementeringen. Også programmer orientert mot denne typen grensesnitt stiller økte krav til datamaskinens ytelse, minnekapasitet, bussbåndbredde osv. Imidlertid er denne typen grensesnitt den enkleste å lære og intuitiv. Derfor har nå WIMP-grensesnittet blitt en de facto standard.

Et slående eksempel på programmer med et grafisk grensesnitt er Microsoft Windows-operativsystemet.

SILKE- grensesnitt (Tale - tale, Bilde - bilde, Språk - språk, Kunnskap - kunnskap). Denne typen grensesnitt er nærmest den vanlige, menneskelige kommunikasjonsformen. Innenfor rammen av dette grensesnittet er det en normal "samtale" mellom en person og en datamaskin. Samtidig finner datamaskinen kommandoer for seg selv ved å analysere menneskelig tale og finne nøkkelsetninger i den. Den konverterer også resultatet av kommandoutførelsen til en form som kan leses av mennesker. Denne typen grensesnitt er den mest krevende for maskinvareressurser, og derfor brukes den hovedsakelig til militære formål.

Siden midten av 90-tallet, etter fremkomsten av rimelige lydkort og den utbredte bruken av talegjenkjenningsteknologier, dukket det såkalte "taleteknologien" SILK-grensesnittet opp. Med denne teknologien gis kommandoer med stemmen ved å uttale spesielle reserverte ord - kommandoer.

Ord må uttales tydelig, i samme tempo. En pause er nødvendig mellom ordene. På grunn av underutviklingen av talegjenkjenningsalgoritmen, krever slike systemer individuell forhåndsinnstilling for hver spesifikke bruker.

"Tale"-teknologi er den enkleste implementeringen av SILK-grensesnittet.

Biometrisk teknologi ("Mimic interface.")

Denne teknologien dukket opp på slutten av 90-tallet av det 20. århundre og er fortsatt under utvikling i skrivende stund. For å kontrollere datamaskinen brukes en persons ansiktsuttrykk, retningen på blikket hans, størrelsen på pupillen og andre tegn. For å identifisere brukeren brukes et mønster av iris i øynene, fingeravtrykk og annen unik informasjon. Bilder leses fra et digitalt videokamera, og deretter hentes kommandoer ut fra dette bildet ved hjelp av spesielle mønstergjenkjenningsprogrammer. Denne teknologien vil sannsynligvis finne sin plass i programvareprodukter og applikasjoner der det er viktig å identifisere datamaskinbrukeren nøyaktig.

Typer grensesnitt

Et grensesnitt er for det første et sett med regler. Som alle regler kan de generaliseres, samles i en "kode" og grupperes i henhold til en felles egenskap. Dermed kom vi til konseptet "grensesnitttype" som en kombinasjon av lignende måter for interaksjon mellom mennesker og datamaskiner. Kort fortalt kan vi foreslå følgende skjematiske klassifisering av forskjellige menneske-datamaskin kommunikasjonsgrensesnitt.

Moderne typer grensesnitt er:

1) Kommandogrensesnitt. Kommandogrensesnittet kalles så fordi i denne typen grensesnitt gir en person "kommandoer" til datamaskinen, og datamaskinen utfører dem og gir resultatet til personen. Kommandogrensesnittet er implementert i form av batchteknologi og kommandolinjeteknologi.

2) WIMP - grensesnitt (Vindu - vindu, Bilde - bilde, Meny - meny, Peker - peker). Et karakteristisk trekk ved denne typen grensesnitt er at dialogen med brukeren ikke utføres ved hjelp av kommandoer, men ved hjelp av grafiske bilder - menyer, vinduer og andre elementer. Selv om kommandoer gis til maskinen i dette grensesnittet, gjøres dette "indirekte", gjennom grafiske bilder. Denne typen grensesnitt er implementert på to teknologinivåer: et enkelt grafisk grensesnitt og et "rent" WIMP-grensesnitt.

3) SILK - grensesnitt (Tale - tale, Bilde - bilde, Språk - språk, Kunnskap - kunnskap). Denne typen grensesnitt er nærmest den vanlige, menneskelige kommunikasjonsformen. Innenfor rammen av dette grensesnittet er det en normal "samtale" mellom en person og en datamaskin. Samtidig finner datamaskinen kommandoer for seg selv ved å analysere menneskelig tale og finne nøkkelsetninger i den. Den konverterer også resultatet av kommandoutførelsen til en form som kan leses av mennesker. Denne typen grensesnitt er den mest krevende for maskinvareressurser, og derfor brukes den hovedsakelig til militære formål.

Kommandogrensesnitt

Batch-teknologi. Historisk sett dukket denne typen teknologi opp først. Den eksisterte allerede på relémaskinene til Sues og Zuse (Tyskland, 1937). Ideen er enkel: en sekvens av symboler leveres til datamaskininngangen, der, i henhold til visse regler, sekvensen av programmer som er lansert for kjøring er indikert. Etter at neste program er utført, startes det neste, og så videre. Maskinen finner i henhold til visse regler kommandoer og data for seg selv. Denne sekvensen kan for eksempel være en hullpapirtape, en stabel med hullkort eller en sekvens med å trykke på tastene på en elektrisk skrivemaskin (CONSUL-type). Maskinen sender også sine meldinger til en stanse, en alfanumerisk utskriftsenhet (ADP) eller et skrivemaskinbånd. En slik maskin er en "svart boks" (nærmere bestemt et "hvitt skap"), som det hele tiden tilføres informasjon i og som også hele tiden "informerer" verden om dens tilstand (se figur 1). En person her har liten innflytelse på driften av maskinen - han kan bare sette maskinen på pause, endre programmet og starte datamaskinen på nytt. Deretter, da maskinene ble kraftigere og kunne betjene flere brukere samtidig, ble den evige ventetiden til brukere som: "Jeg sendte data til maskinen. Jeg venter på at den skal svare. Og vil den svare i det hele tatt?" - ble mildt sagt kjedelig. I tillegg har datasentre, etter aviser, blitt den andre store "produsenten" av returpapir. Derfor, med bruken av alfanumeriske skjermer, begynte æraen med virkelig brukervennlig teknologi - kommandolinjen.

Fig.2. Utsikt over en stormaskin i EC-serien

Kommandolinjeteknologi. Med denne teknologien er et tastatur den eneste måten å legge inn informasjon fra en person til en datamaskin, og datamaskinen viser informasjon til personen ved hjelp av en alfanumerisk skjerm (skjerm). Denne kombinasjonen (skjerm + tastatur) ble kalt en terminal eller konsoll. Kommandoer skrives på kommandolinjen. Kommandolinjen er et ledetekstsymbol og et blinkende rektangel - en markør. Når du trykker på en tast, vises symboler ved markørens plassering, og selve markøren flyttes til høyre. Dette ligner veldig på å skrive en kommando på en skrivemaskin. Men i motsetning til det, vises bokstavene på skjermen, ikke på papir, og et feil skrevet tegn kan slettes. Kommandoen avsluttes ved å trykke på Enter (eller Retur)-tasten. Denne går deretter til begynnelsen av neste linje. Det er fra denne posisjonen at datamaskinen viser resultatene av arbeidet sitt på skjermen. Deretter gjentas prosessen. Kommandolinjeteknologi fungerte allerede på monokrome alfanumeriske skjermer. Siden det kun var mulig å legge inn bokstaver, tall og skilletegn, var de tekniske egenskapene til skjermen ikke vesentlige. En TV-mottaker og til og med et oscilloskoprør kan brukes som monitor.

Begge disse teknologiene er implementert i form av et kommandogrensesnitt - kommandoer blir gitt til maskinen som input, og den "svarer" så å si på dem.

Tekstfiler ble den dominerende typen filer når man jobbet med kommandogrensesnittet - de og bare de kunne lages ved hjelp av tastaturet. Tiden da kommandolinjegrensesnittet ble mest brukt, var bruken av UNIX-operativsystemet og utseendet til de første åtte-bits personlige datamaskinene med multi-plattform CP/M-operativsystemet.

GUI

Hvordan og når dukket det grafiske grensesnittet opp? Ideen hans oppsto på midten av 70-tallet, da konseptet med et visuelt grensesnitt ble utviklet ved Xerox Palo Alto Research Center (PARC). Forutsetningen for det grafiske grensesnittet var en reduksjon i datamaskinens reaksjonstid på en kommando, en økning i mengden RAM, samt utvikling av den tekniske basen til datamaskiner. Maskinvaregrunnlaget for konseptet var selvfølgelig utseendet til alfanumeriske skjermer på datamaskiner, og disse skjermene hadde allerede slike effekter som "flimmer" av tegn, fargeinversjon (endre omrisset av hvite tegn på svart bakgrunn til motsatt, det vil si svarte tegn på hvit bakgrunn ), som understreker tegn. Disse effektene strakk seg ikke til hele skjermen, men bare til en eller flere karakterer. Neste trinn var å lage en fargeskjerm som ville tillate visning, sammen med disse effektene, av tegn i 16 farger på en bakgrunn med en palett (det vil si et fargesett) med 8 farger. Etter fremkomsten av grafiske skjermer, med muligheten til å vise alle grafiske bilder i form av mange prikker på en skjerm i forskjellige farger, var det ingen grenser for fantasien ved bruk av skjermen! Det første systemet med et grafisk grensesnitt, 8010 Star Information System fra PARC-gruppen, dukket dermed opp fire måneder før utgivelsen av den første IBM-datamaskinen i 1981. Opprinnelig ble det visuelle grensesnittet bare brukt i programmer. Gradvis begynte han å bytte til operativsystemer, først brukt på Atari- og Apple Macintosh-datamaskiner, og deretter på IBM-kompatible datamaskiner.

Enkelt GUI

I den første fasen var GUI veldig lik kommandolinjeteknologi. Forskjellene fra kommandolinjeteknologien var som følger:

1. Ved visning av tegn var det tillatt å fremheve noen tegn med farge, omvendt bilde, understreking og flimring. Takket være dette har uttrykksevnen til bildet økt.

2. Avhengig av den spesifikke implementeringen av det grafiske grensesnittet, kan markøren vises ikke bare som et flimrende rektangel, men også som et område som dekker flere tegn og til og med en del av skjermen. Dette valgte området skiller seg fra andre uvalgte deler (vanligvis etter farge).

3. Å trykke på Enter-tasten utfører ikke alltid kommandoen og går til neste linje. Reaksjonen på å trykke på en tast avhenger i stor grad av hvor markøren var på skjermen.

4. I tillegg til Enter-tasten, brukes «grå» markørkontrolltaster i økende grad på tastaturet.

5. Allerede i denne utgaven av det grafiske grensesnittet begynte man å bruke manipulatorer (som mus, styrekule osv. - se fig. 3) De gjorde det mulig å raskt velge ønsket del av skjermen og flytte markøren .

Fig.3. Manipulatorer

For å oppsummere kan vi sitere følgende karakteristiske trekk ved dette grensesnittet.

1) Velge områder på skjermen.

2) Omdefinering av tastaturtaster avhengig av konteksten.

3) Bruke manipulatorer og grå tastaturtaster for å kontrollere markøren.

4) Utbredt bruk av fargeskjermer.

Et typisk eksempel på bruk av denne typen grensesnitt er Nortron Commander-filskallet (se filskall nedenfor) og Multi-Edit-tekstredigeringsprogrammet. Og tekstredigererne Lexicon, ChiWriter og Microsoft Word for Dos tekstbehandler er eksempler på hvordan dette grensesnittet har overgått seg selv.

WIMP-grensesnitt

Den andre fasen i utviklingen av det grafiske grensesnittet var det "rene" WIMP-grensesnittet.Denne undertypen av grensesnitt er preget av følgende funksjoner.

1. Alt arbeid med programmer, filer og dokumenter skjer i vinduer - visse deler av skjermen er omgitt av en ramme.

2. Alle programmer, filer, dokumenter, enheter og andre objekter presenteres i form av ikoner. Når de åpnes, blir ikonene til vinduer.

3. Alle handlinger med objekter utføres ved hjelp av menyen. Selv om menyen dukket opp på det første stadiet av utviklingen av det grafiske grensesnittet, hadde den ikke en dominerende rolle i den, men fungerte bare som et tillegg til kommandolinjen. I et rent WIMP-grensesnitt blir menyen hovedkontrollelementet.

4. Utstrakt bruk av manipulasjonsmidler for å peke på objekter. Pekeenheten slutter å være bare et leketøy - et tillegg til tastaturet, men blir hovedkontrollelementet. Ved å bruke en manipulator peker de på et hvilket som helst område av skjermen, vinduet eller ikonet, VELG det, og først deretter kontrollerer de dem gjennom menyen eller ved hjelp av andre teknologier.

Et slående eksempel på programmer med et grafisk grensesnitt er Microsoft Windows-operativsystemet.

Taleteknologi

"Slapp av" - slår av talegrensesnittet.

"Åpne" - bytter til modusen for å ringe et bestemt program. Programnavnet kalles i neste ord.

"Jeg vil diktere" - bytter fra kommandomodus til stemmeskrivingsmodus.

"Kommandomodus" - gå tilbake til talekommandomodus.

Og noen andre.

"Tale"-teknologi er den enkleste implementeringen av SILK-grensesnittet.

Informasjon systemer i økonomi (30)
Sammendrag >> Økonomi
... informasjon 6 1.3. Klassifisering informasjon teknologier 9 1.5. Stadier av utvikling informasjon systemer... helhet maskinvare midler... informativ teknologier. Et eksempel på et slikt kriterium kan være tilpasset grensesnitt ... 3.5. Programvare fasiliteter...
Informasjon teknologier innen ledelse (5)
Sammendrag >> Stat og lov
11 2.1 Programvare bestemmelse 15... informasjon teknologier. Konsept" informativ teknologi" kan defineres som et sett med programvare- maskinvare midler og systemer... opprettelse og støtte tilpasset grensesnitt for ulike kategorier...
Informasjon kontrollteknologier (10)
Forelesning >> Datavitenskap
Type tilpasset grensesnitt automatisert informativ teknologier blir delt... kontorer organiserer spesialiserte programmatisk-maskinvare kompleks - ... system videokonferanser, e-post osv.); mot globalisering informasjon teknologi...

FOREDRAG 23.-24

Tema 3.2 Utvikling av brukergrensesnitt

1. Typer brukergrensesnitt og utviklingsstadier.

2. Psykofysiske egenskaper ved en person knyttet til persepsjon, memorering og behandling av informasjon.

3. Bruker- og programvaregrensesnittmodeller.

4. Klassifikasjoner av dialoger og generelle prinsipper for deres utvikling.

5. Grunnleggende komponenter i grafiske brukergrensesnitt.

6. Implementering av dialoger i et grafisk brukergrensesnitt.

7. Direkte manipulasjon brukergrensesnitt og deres design.

8. Intelligente elementer i brukergrensesnitt.

I de tidlige stadiene av utviklingen av datateknologi ble brukergrensesnittet ansett som et kommunikasjonsmiddel mellom en person og operativsystemet og var ganske primitivt.

Med bruken av interaktiv programvare begynte spesielle brukergrensesnitt å bli brukt. For øyeblikket er hovedproblemet utviklingen av interaktive grensesnitt for komplekse programvareprodukter designet for bruk av ikke-profesjonelle brukere.

1. Typer brukergrensesnitt og utviklingsstadier

Brukergrensesnitt– et sett med programvare og maskinvare som sikrer brukerinteraksjon med en datamaskin. Grunnlag for samhandling– dialoger.

Dialog– regulert utveksling av informasjon mellom en person og en datamaskin, utført i sanntid og rettet mot å i fellesskap løse et spesifikt problem: informasjonsutveksling og koordinering av handlinger. Hver samtale består av separate input/output-prosesser som fysisk gir kommunikasjon mellom brukeren og datamaskinen.

Informasjonsutveksling utføres ved å sende meldinger og styresignaler.

Beskjed– en informasjon som deltar i en dialogutveksling.

Typer meldinger:

Inndatameldinger som genereres av en person som bruker inndatamidler: tastatur, manipulatorer (mus, etc.);

Utdatameldinger som genereres av en datamaskin i form av tekster, lyder og/eller bilder og vises til brukeren på en skjerm eller andre informasjonsenheter.

Brukeren genererer meldinger som:

Informasjonsforespørsel,

Forespørsel om hjelp,

Be om en operasjon eller funksjon,

Legge inn eller endre informasjon

Velge et rammefelt.

Mottar som svar:

Tips eller hjelp,

Ordform– et stykke tekst mellom to tilstøtende mellomrom eller skilletegn.

Morfologisk analyse - bearbeiding av ordformer uten sammenheng med kontekst.

Prosedyremessig - innebærer å identifisere en stamme i gjeldende ordform, som deretter identifiseres.

Etter å ha gjenkjent ordformer, utføres en syntaktisk analyse av meldingen, basert på resultatene som dens syntaktiske struktur bestemmes av, det vil si at en setning analyseres.

Et grensesnitt som implementerer en formuleringsform for dialog må: konvertere meldinger fra en naturlig språkform til en intern representasjonsform og tilbake, utføre analyse og syntese av bruker- og systemmeldinger, spore og huske den fullførte delen av dialogen.

Feil setningsform:

Høye ressurskostnader;

Ingen garanti for entydig tolkning av ordlyden;

Behovet for å skrive inn lange, grammatisk korrekte fraser.

Verdighet fraseform – fri kommunikasjon med systemet.

Direktiveskjema - bruk av kommandoer (direktiver) et spesialdesignet formelt språk.

Team– en setning på dette språket som beskriver kombinerte data som inkluderer identifikatoren for prosessen som initieres og, eventuelt, data for den.

Kommandoen kan legges inn:

Som en tekstlinje i et spesialdesignet format (MS DOS-kommandoer på kommandolinjen);

Ved å trykke på en bestemt kombinasjon av taster (kombinasjoner av "rask tilgang" for Windows-applikasjoner);

Ved å manipulere musen (“dra” ikoner);

En kombinasjon av den andre og tredje metoden.

Fordeler direktivform:

Liten mengde inputinformasjon;

Fleksibilitet – muligheten til å velge en operasjon er begrenset av settet med gyldige kommandoer;

Fokus på brukerdrevet dialog;

Bruker minimalt skjermområde eller ikke bruker det i det hele tatt;

Mulighet for kombinasjon med andre former.

Feil direktivform:

Det virtuelle fraværet av meldinger på skjermen, som krever å huske de angitte kommandoene og deres syntaks;

Nesten fullstendig fravær av tilbakemelding om tilstanden til igangsatte prosesser;

Behovet for ferdigheter i å skrive inn tekstinformasjon eller manipulere en mus;

Mangel på brukertilpasning.

Direktiveskjemaet er praktisk for den profesjonelle brukeren som vanligvis raskt husker syntaksen til ofte brukte kommandoer eller tastekombinasjoner. Fordelene med skjemaet (fleksibilitet og gode midlertidige egenskaper) er spesielt tydelige i dette tilfellet.

Tabellform – brukeren velger et svar fra de foreslåtte av programmet. Dialogspråket har den enkleste syntaksen og entydig semantikk, som er ganske enkel å implementere. Skjemaet er brukervennlig, siden det alltid er enklere å velge, noe som er avgjørende for en ikke-profesjonell bruker. Dette skjemaet kan brukes hvis settet med mulige svar på et bestemt spørsmål er begrenset. Hvis antallet mulige svar er stort (mer enn 20), er det kanskje ikke hensiktsmessig å bruke en tabellform.

Fordeler og i tabellform:

Tilgjengelighet av et hint;

Redusere antall inndatafeil: brukeren legger ikke inn informasjon, men peker på den;

Redusert brukeropplæringstid;

Mulighet for kombinasjon med andre former;

I noen tilfeller kan brukerkonfigureres.

Feil tabellform:

Skjermnavigasjonsferdigheter kreves;

Bruk av et relativt stort skjermområde for å vise visuelle komponenter;

Intensiv bruk av dataressurser knyttet til behovet for å kontinuerlig oppdatere informasjon på skjermen.

Typer og former for dialog velges uavhengig av hverandre: enhver form er aktuelt for begge typer dialoger.

Synkron- dialoger som oppstår under normal drift av programvaren.

Asynkron– dialoger som oppstår på initiativ av systemet eller brukeren når det normale prosesscenarioet brytes. De brukes til å sende nødmeldinger fra systemet eller brukeren.

Utvikling av dialoger. Stadier av design og implementering av dialoger:

Definere settet med nødvendige dialoger, deres hovedbudskap og mulige scenarier - design abstrakte dialoger;

Bestemme type og form for hver dialog, samt syntaks og semantikk for språkene som brukes - design spesifikke dialoger;

Velge primære og sekundære enheter og designe input/output prosesser for hver dialog, samt klargjøre meldingene som sendes - design tekniske dialoger.

Grunnlaget for abstrakte dialoger er ideologien til den teknologiske prosessen som programvareproduktet er ment å automatisere for.

I tillegg til skript de bruker grensesnitttilstandsdiagrammer eller dialoggrafer.

Dialoggraf– en rettet vektet graf, hvor hvert toppunkt er assosiert med et spesifikt bilde på skjermen ( ramme) eller en viss tilstand av dialog, preget av et sett med handlinger tilgjengelig for brukeren. Buer som kommer fra hjørnene viser mulige tilstandsendringer når brukeren utfører spesifiserte handlinger. Buer som kommer fra hjørnene viser mulige tilstandsendringer når brukeren utfører spesifiserte handlinger. Buevektene indikerer betingelsene for overganger fra tilstand til tilstand og operasjonene som utføres under overgangen.

Hver rute i grafen tilsvarer et mulig dialogalternativ.

Figur 3 – Abstrakte dialoggrafer:

a – dialog kontrollert av systemet; b – brukerstyrt dialog

5. Grunnleggende komponenter i grafiske brukergrensesnitt

Grafiske brukergrensesnitt støttes av operativsystemene Windows, Apple Macintosh, OS/2 osv. For slike grensesnitt er det utviklet sett med standard brukerinteraksjonskomponenter for hvert operativsystem.

Grensesnitt er bygget ved hjelp av WIMP-teknologi: W – Windows (vinduer), I – Ikoner (ikoner), M – Mus (mus), P – Pop-up (pop-up eller rullegardinmenyer). Hovedelementene i grafiske grensesnitt: vinduer, ikoner, input/output-komponenter og musen, som brukes som en pekeenhet og en enhet for direkte manipulering av objekter på skjermen.

Vindu.Vindu - et rektangulært, avgrenset område på den fysiske skjermen. Vinduet kan endre størrelse og plassering på skjermen.

Hovedvinduer (applikasjonsvinduer);

Underordnede eller underordnede vinduer;

dialogvinduer;

Informasjon vinduer;

Menyvinduer.

Søknadsvindu Windows inneholder: en ramme som avgrenser vinduets arbeidsområde, en tittellinje med en systemmenyknapp og vinduvisnings- og avslutningsknapper, en menylinje, en ikonmeny (verktøylinje), horisontale og vertikale rullefelt og en statuslinje.

Barnevindu Windows brukes i multi-document programmeringsgrensesnitt (MDI). Dette vinduet inneholder ingen meny. I tittellinjen er et spesielt navn som identifiserer dokumentet eller filen knyttet til det. Ikonene for alle underordnede vinduer er de samme.

Dialogvindu Windows brukes til å vise og stille inn ulike driftsmoduser, nødvendige parametere eller annen informasjon.

Tittellinje med systemmenyknapp;

Komponenter som lar brukeren legge inn eller velge et svar;

Tilleggskomponenter som gir et hint (en visningsboks eller en hjelpeknapp).

Vindusstørrelsen kan ikke endres, men den kan flyttes rundt på skjermen.

Informasjonsvinduer to typer:

Meldingsvinduer;

Hjelpevinduer.

Meldingsvinduer inneholder: en tittel med en systemmenyknapp, meldingstekst, en eller flere brukerreaksjonsknapper (Ja, Nei, Avbryt).

Hjelpevindu inneholder: meny, rullefelt, informasjonsområde, som ligner på et programvindu, men har et svært spesialisert formål.

Menyvinduer Windows brukes som åpningshierarkiske menypaneler eller som kontekstmenyer.

Hver linje i menyvinduet kan tilsvare:

Team;

Neste nivå meny, som er gitt av pilen;

Dialogvindu, som er indikert med tre prikker.

Lagt til en indikasjon på hurtigtaster.

Piktogrammer. Et ikon er et lite vindu med et grafisk bilde som gjenspeiler innholdet i bufferen det er knyttet til.

Typer piktogrammer:

Programvare relatert til det aktuelle programmet;

Ikoner for barnevinduer som gir tilgang til ulike dokumenter;

Verktøylinjeikoner dupliserer tilgang til de tilsvarende funksjonene gjennom menyen, og gir rask tilgang;

Objektikoner for direkte manipulering av objekter.

Direkte bildemanipulering. Direkte bildemanipulering – dette er muligheten til å erstatte en kommando for å påvirke et objekt med en fysisk handling i grensesnittet, utført ved hjelp av musen. I dette tilfellet betraktes ethvert område av skjermen som et reisemål, som kan aktiveres ved å flytte markøren og trykke på museknappen.

Avhengig av reaksjonen på påvirkningen, skilles typene mottakere:

Indikasjon og valg (utvidende ikoner, bestemme det aktive vinduet);

Knapper på skjermen og "skyve" barrierer (utføre syklisk gjentatte handlinger (utføre visse operasjoner eller tegning, underforstått når du aktiverer et bestemt område av skjermen - en knapp)).

Dynamisk visuelt signal - endre bildet på skjermen (musepekeren når du utfører spesifikke operasjoner, endre bildet av en knapp).

I/O-komponenter. Grensesnitt inkluderer flere menyer: en hierarkisk hovedmeny eller "rullegardinmeny", piktografiske menyer (verktøylinjer) og kontekstmenyer for forskjellige situasjoner. Enhver av de spesifiserte menyene er en input-output-komponent som implementerer en dialog med brukeren ved hjelp av et tabellskjema.

En hierarkisk meny brukes til å organisere operasjonene som utføres av programvaren, hvis antallet overstiger det som anbefales av IBM), og for å gi brukeren en oversikt over dem. Verktøylinjer og kontekstmenyer brukes for å gi rask tilgang til ofte brukte kommandoer, slik at brukeren kan navigere relativt fritt.

Andre former for I/O:

Uttrykk,

Tabell,

Blandet.

6. Implementere dialoger i et grafisk brukergrensesnitt

Dialoger av begge typer:

Brukerstyrt

System kontrollert.

Implementering av brukerstyrte dialoger. For implementering brukes ulike typer menyer:

Hoved,

Verktøylinjer,

Kontekstuell og knappebasert.

Som et alternativ til menyen, er det tilrådelig å bruke en retningsgivende form for dialog, som tildeler visse tastekombinasjoner til hovedkommandoene. Det er tilrådelig å gi muligheten til å kontrollere menyen med et tastatur hvis brukeren bruker mesteparten av tiden på å jobbe med systemet på å skrive inn tekst eller data, dvs. samhandle med tastaturet.

Meny. Menyen er utformet basert på dialoggrafene til programvaren som utvikles. Hvis antall operasjoner ikke overstiger 5, brukes vanligvis knapper. Hvis antallet operasjoner ikke er mer enn 9-10, er det en enkeltnivåmeny. Hvis antallet operasjoner er mer enn 10, brukes en "rullegardin" to-nivå hierarkisk meny.

Nedtrekksmenyen. Det første nivået i den hierarkiske menyen skal inneholde navnene på hovedgruppene av operasjoner.

Tradisjonelt (vanligvis i tekst- og grafiske redaktører):

1. element Fil,

2. element Rediger,

3. element Vis,

Det siste elementet er Hjelp.

Antall nivåer i den hierarkiske menyen bør ikke overstige 2-3 (vanskelig å søke). Antall operasjoner i et vindu bør ikke overstige 7-8 operasjoner.

Hvis antall operasjoner overstiger 70-80. Microsoft Word-utviklere foreslått tilpasningsdyktig hierarkisk meny, der innholdet i menyvinduet på andre nivå endres hele tiden, og viser bare de operasjonene som brukeren bruker. Hvis brukeren ikke finner ønsket operasjon, viser Word hele menyvinduet etter noen få sekunder eller når du trykker på en spesiell knapp.

7 Direkte manipulasjon brukergrensesnitt og deres design

Den direkte manipulasjonsevnen som tilbys av WIMP-grensesnitt tillater utvikling av objektorienterte direkte manipulasjonsgrensesnitt for applikasjoner.

Grensesnitt bruker en retningsgivende form for dialog: en kommando legges inn når visse handlinger utføres med objektikonet med musen. Hovedelementene i disse grensesnittene er: metaforer, objekter, objektrepresentasjoner og Dra og slipp-teknologier.

Metaforer. Metaforer- mental overføring av egenskaper eller egenskaper ved en gjenstand til en annen, noe lik den første. Bruk av metaforer i grensesnitt innebærer aktivering av brukerens eksisterende opplevelse.

Det direkte manipulasjonsgrensesnittet skal gi brukeren et miljø som inneholder kjente elementer som brukeren har møtt mer enn en gang i profesjonelle aktiviteter eller i hverdagen, og gi ham muligheten til å manipulere individuelle objekter. (Metafor "Kasting av søppel" - for sletting av filer).

Lignende elementer bør oppføre seg på en lignende måte, elementer uthevet i samme farge bør stå i et visst forhold til hverandre.

Det er tilrådelig å ikke gjøre bildene for realistiske, for ikke å lure brukerens forventninger.

Metaforer og animasjon. Når man implementerer metaforer, får multimedia, hovedsakelig animasjon, en økende rolle. Ved å bruke animasjon kan du ikke bare underholde brukeren, men også "forberede" ham på en endring i rammer, noe som reduserer tiden som kreves for å tilpasse seg en endret situasjon.

https://pandia.ru/text/78/247/images/image005_68.gif">Et program som implementerer animerte grensesnitt er aldri inaktivt, siden mens det venter på at brukeren skal skrive inn en kommando, fortsetter det å vise de tilsvarende rammene. Slike programmer er basert på tidsprogrammering. I motsetning til hendelsesprogrammering, som lar deg assosiere bildet på skjermen med eksterne og interne hendelser i systemet, lar tidsprogrammering deg endre det projiserte rekkefølge av rammer avhengig av tilstanden til de simulerte prosessene og brukerhandlingene.

Direkte og deres representasjoner.

De tre hovedtypene av direkte er:

Dataobjekter

Containerobjekter,

Enhetsobjekter.

Dataobjekter gi brukeren informasjon (tekster, bilder, regneark, musikk, videoer). Innenfor operativsystemet tilsvarer slike objekter applikasjoner som startes når objektet åpnes.

Beholderobjekter kan manipulere sine interne objekter, inkludert andre beholdere (kopier dem eller sorter dem i hvilken som helst rekkefølge). Typiske beholdere inkluderer mapper og kurver. Når en beholder åpnes, vises komponentene den lagrer og kan manipuleres. Komponenter kan angis med piktogrammer eller presenteres i tabellform.

Enhetsobjekter representerer enheter som eksisterer i den virkelige verden: telefoner, fakser, skrivere osv. de brukes til å referere til disse enhetene i grensesnittets abstrakte verden. Når du utvider et slikt objekt, kan du se innstillingene.

Hvert objekt tilsvarer ett vindu. I den opprinnelige tilstanden er dette vinduet representert av et ikon, men om nødvendig kan du åpne det og utføre de nødvendige operasjonene, for eksempel objektinnstillinger. Når et objektvindu åpnes, kan det inneholde menyer og verktøylinjer. Ikonet må samsvare med en kontekstmeny som inneholder en liste over operasjoner på objektet.

Ikonnavnet er utformet forskjellig for hver type objekt. Ikoner til dataobjekter gis navn som tilsvarer navnene på de lagrede dataene, og datatypen er kodet av selve ikonet. Navnet på et beholderikon eller enhetsikon identifiserer selve objektet og er derfor uavhengig av innholdet.

Skillet mellom objekttyper er betinget, siden det samme objektet i forskjellige situasjoner kan oppføre seg som et dataobjekt, som et enhetsobjekt, som et containerobjekt (en skriver er et enhetsobjekt, den kan ha egenskaper containerobjekt kan inneholde dataobjekter i utskriftskøen; representasjon i form av et ikon, utskriftskøvindu, innstillingsvindu; det anbefales å angi navnet på representasjonen i tittelen på objektvinduet).

TeknologiDraogMiste. Grunnleggende prinsipper for direkte manipulasjon, som beskrevet i IBM User Interface Design Guide:

Resultatet av å flytte et objekt må oppfylle brukerens forventninger;

Brukere bør ikke uventet miste informasjon;

Brukeren skal kunne angre en feil handling.

Innledende utheving - brukes som tilbakemelding til brukeren for å informere ham om at objektet er fanget; i Windows brukes utheving til dette formålet;

Visualisering av bevegelse - brukes til å identifisere handlingen som utføres;

Målvalg - brukes til å identifisere destinasjonen, og viser dermed hvor objektet vil "falle" hvis det slippes på det aktuelle tidspunktet;

Handlingsvisualisering - brukes til å indikere ventetiden for en operasjon å fullføre; vanligvis brukes animasjon eller endring av markørformen til et "timeglass" for dette formålet.

Det er to typer destinasjoner: den ene godtar objektet, og den andre en kopi av det (Brukeren "kaster" dokumentet i "søppelet" - selve dokumentet blir ødelagt, og hvis det sendes til skriveren, så kopi av dokumentet overføres).

Designe direkte manipulasjonsgrensesnitt. Design utføres på grunnlag av dialoggrafer utviklet for spesifikk programvare og inkluderer følgende prosedyrer:

Formasjon sett med domeneobjekter, som skal presenteres på skjermen, og i dette tilfellet legges ikke brukstilfeller til grunn, men en konseptuell modell av fagområdet;

Analyse gjenstander, definere dem typer Og innleveringer, samt en liste over operasjoner med disse objektene;

Avklaring objektinteraksjoner og matrisekonstruksjon direkte manipulasjon;

Definisjon visuelle representasjoner gjenstander;

Utvikling objektvindu-menyen Og kontekstmenyer;

Opprettelse prototype grensesnitt;

Tester for Brukervennlighet.

8 Intelligente brukergrensesnittelementer

Brukergrensesnittelementer: Master, Advisor, Agent. Det er gjort mange forsøk på å lage et sosialisert brukergrensesnitt. Grunnlaget for et slikt grensesnitt er ideen om å lage et personlig, det vil si "ha en personlighet", grensesnitt. Underholdningsprogrammer som Cats and Dogs, som implementerer den komplekse oppførselen til kjæledyr i forskjellige situasjoner, viser at teknisk sett er dette et fullstendig løsbart problem.

Rådgivere. De er en form for hint. De kan nås fra hjelpemenyen, vinduets kommandolinje eller fra en popup-meny. Rådgivere hjelper brukere med å utføre spesifikke oppgaver.

Mestere. Veiviserprogrammet brukes til å utføre vanlige oppgaver som sjelden utføres av en individuell bruker (installere programmer eller maskinvare). Å utføre slike handlinger krever at brukeren tar komplekse, sammenhengende beslutninger, hvis rekkefølge er diktert av veiviserprogrammet. Intelligente veivisere er i stand til å demonstrere ved hvert trinn i visningsvinduet resultatene av brukerens svar på tidligere spørsmål, og hjelper sistnevnte med å navigere i situasjonen.

Veiviseren implementerer et sekvensielt eller trelignende dialogscenario. Det er tilrådelig å bruke det til å løse godt strukturerte, sekvensielle problemer.

I dette tilfellet er det nødvendig:

Gi brukeren muligheten til å gå tilbake til forrige trinn;

Sørg for muligheten for å kansellere mesterens arbeid;

Nummerer trinnene og informer brukeren om antall Master-trinn, spesielt hvis det er mer enn tre slike trinn;

Forklar hvert trinn for brukeren;

Hvis mulig, demonstrer resultatene av allerede fullførte operasjoner på hvert trinn.

Programvareagenter. Brukes til å utføre rutinearbeid. Hovedfunksjonene til assisterende agenter er: observasjon, søk, ledelse. Det er:

agentprogrammer konfigurert til å utføre spesifiserte oppgaver;

agentprogrammer som kan lære (ved å ta opp brukerhandlinger (som en båndopptaker)).

Grensesnittklassifisering

Det vil si at et grensesnitt er et sett med regler. Som alle regler kan de generaliseres, samles i en "kode" og grupperes i henhold til en felles egenskap. Dermed kom vi til konseptet " type grensesnitt" som en kombinasjon av lignende måter for interaksjon mellom mennesker og datamaskiner. Vi kan foreslå følgende skjematiske klassifisering av forskjellige menneske-datamaskin kommunikasjonsgrensesnitt.

^ Moderne typer grensesnitt er:

1) Kommandogrensesnitt. Kommandogrensesnittet kalles så fordi i denne typen grensesnitt gir en person "kommandoer" til datamaskinen, og datamaskinen utfører dem og gir resultatet til personen. Kommandogrensesnittet er implementert i form av batchteknologi og kommandolinjeteknologi.

2) ^ WIMP - grensesnitt(Vindu - vindu, Bilde - bilde, Meny - meny, Peker - peker). Et karakteristisk trekk ved denne typen grensesnitt er at dialogen med brukeren ikke utføres ved hjelp av kommandoer, men ved hjelp av grafiske bilder - menyer, vinduer og andre elementer. Selv om kommandoer gis til maskinen i dette grensesnittet, gjøres dette "indirekte", gjennom grafiske bilder. Denne typen grensesnitt er implementert på to teknologinivåer: et enkelt grafisk grensesnitt og et "rent" WIMP-grensesnitt.

3) ^ SILK - grensesnitt(Tale - tale, Bilde - bilde, Språk - språk, Kunnskap - kunnskap). Denne typen grensesnitt er nærmest den vanlige, menneskelige kommunikasjonsformen. Innenfor rammen av dette grensesnittet er det en normal "samtale" mellom en person og en datamaskin. Samtidig finner datamaskinen kommandoer for seg selv ved å analysere menneskelig tale og finne nøkkelsetninger i den. Den konverterer også resultatet av kommandoutførelsen til en form som kan leses av mennesker. Denne typen grensesnitt er den mest krevende for maskinvareressurser, og derfor brukes den hovedsakelig til militære formål.

^ 1. Offentlig grensesnitt - basert på semantiske nettverk.

I de følgende kapitlene vil du lære mer om disse typene grensesnitt.
^

Batch-teknologi

Historisk sett dukket denne typen teknologi opp først. Den eksisterte allerede på relémaskinene til Sues og Zuse (Tyskland, 1937).

Ideen er enkel : en sekvens av symboler leveres til datamaskininngangen, der, i henhold til visse regler, sekvensen av programmer som er lansert for kjøring er indikert. Etter at neste program er utført, startes det neste, og så videre. Maskinen finner i henhold til visse regler kommandoer og data for seg selv. Denne sekvensen kan for eksempel være en hullpapirtape, en stabel med hullkort eller en sekvens med å trykke på tastene på en elektrisk skrivemaskin (CONSUL-type). Maskinen sender også sine meldinger til en stanse, en alfanumerisk utskriftsenhet (ADP) eller et skrivemaskinbånd.

Med bruken av alfanumeriske skjermer begynte æraen med virkelig brukervennlig teknologi - kommandolinjen.
^

Kommandolinjeteknologi.

Kommandoer skrives på kommandolinjen. Kommandolinjen er et ledetekstsymbol og et blinkende rektangel - Når du trykker på en tast, vises symboler ved markørens plassering, og selve markøren flyttes til høyre. Dette ligner veldig på å skrive en kommando på en skrivemaskin. Men i motsetning til det, vises bokstavene på skjermen, ikke på papir, og et feil skrevet tegn kan slettes. Kommandoen avsluttes ved å trykke på Enter (eller Retur), som deretter flytter til begynnelsen av neste linje. Det er fra denne posisjonen at datamaskinen viser resultatene av arbeidet sitt på skjermen. Deretter gjentas prosessen.

Tekstfiler ble den dominerende typen filer når man jobbet med kommandogrensesnittet - de og bare de kunne lages ved hjelp av tastaturet.
^

GUI

Hvordan og når dukket det grafiske grensesnittet opp?

Ideen hans oppsto på midten av 70-tallet, da konseptet med et visuelt grensesnitt ble utviklet ved Xerox Palo Alto Research Center (PARC). Forutsetningen for det grafiske grensesnittet var en reduksjon i datamaskinens reaksjonstid på en kommando, en økning i mengden RAM, samt utvikling av den tekniske basen til datamaskiner. Maskinvaregrunnlaget for konseptet var selvfølgelig utseendet til alfanumeriske skjermer på datamaskiner, og disse skjermene hadde allerede slike effekter som "flimmer" av tegn, fargeinversjon (endre omrisset av hvite tegn på svart bakgrunn til motsatt, det vil si svarte tegn på hvit bakgrunn ), som understreker tegn. Disse effektene strakk seg ikke til hele skjermen, men bare til en eller flere karakterer.

Neste trinn var å lage en fargeskjerm som ville tillate visning, sammen med disse effektene, av tegn i 16 farger på en bakgrunn med en palett (det vil si et fargesett) med 8 farger. Etter fremkomsten av grafiske skjermer, med muligheten til å vise alle grafiske bilder i form av mange prikker på en skjerm i forskjellige farger, var det ingen grenser for fantasien ved bruk av skjermen! Det første systemet med et grafisk grensesnitt, 8010 Star Information System fra PARC-gruppen, dukket dermed opp fire måneder før utgivelsen av den første IBM-datamaskinen i 1981. Opprinnelig ble det visuelle grensesnittet bare brukt i programmer. Gradvis begynte han å bytte til operativsystemer som ble brukt først på Atari- og Apple Macintosh-datamaskiner, og deretter på IBM-kompatible datamaskiner.

Det grafiske brukergrensesnittet har gått gjennom to stadier under utviklingen. Utviklingen av det grafiske grensesnittet fra 1974 til i dag vil bli diskutert nedenfor.
^

Enkelt grafisk grensesnitt.

I den første fasen var GUI veldig lik kommandolinjeteknologi. Forskjellene fra kommandolinjeteknologien var som følger.

A) Ved visning av tegn var det mulig å fremheve noen tegn med farge, omvendt bilde, understreking og flimring. Takket være dette har uttrykksevnen til bildet økt.

B) Avhengig av den spesifikke implementeringen av det grafiske grensesnittet, kan markøren representeres ikke bare av et flimrende rektangel, men også av et område som dekker flere tegn og til og med en del av skjermen. Dette valgte området skiller seg fra andre uvalgte deler (vanligvis etter farge).

C) Å trykke på Enter-tasten utfører ikke alltid kommandoen og går til neste linje. Reaksjonen på å trykke på en tast avhenger i stor grad av hvor markøren var på skjermen.

D) I tillegg til Enter-tasten, har grå markørtaster blitt stadig mer vanlige på tastaturet (se tastaturdelen i utgave 3 av denne serien.)

E) Allerede i denne utgaven av det grafiske grensesnittet begynte man å bruke manipulatorer (som en mus, styrekule osv. - se figur A.4.) De gjorde det mulig å raskt velge ønsket del av skjermen og flytte markøren.

Ris. A.4. Manipulatorer