Distribuirani AIS postao je svakodnevna stvarnost. Brojni korporativni AIS koriste distribuirane baze podataka. Razrađene su metode distribucije podataka i upravljanja distribuiranim podacima, arhitektonski pristupi koji osiguravaju skalabilnost sustava, implementirajući principe višeslojne arhitekture klijent-poslužitelj, kao i arhitektura srednjeg sloja.

Mobilne arhitekture počinju se primjenjivati ​​u praksi. To se odnosi i na sustave baza podataka i na web aplikacije.

Oživljava se pristup izgradnji distribuiranih sustava baziran na peer-to-peer arhitekturi, u kojem, za razliku od klijent-poslužitelj arhitekture koja danas dominira u distribuiranim sustavima, uloge suradnika u mreži nisu fiksne. Dodjeljuju se ovisno o situaciji u mreži, o opterećenju njezinih čvorova.

U vezi s intenzivnim razvojem komunikacijskih tehnologija, mobilni AIS se aktivno razvija. Razvijena su tehnička sredstva i softver za njihovu izradu. To je dovelo do razvoja mobilnih sustava baza podataka. Mnogi istraživački timovi provode istraživanja o specifičnim značajkama takvih sustava i stvaraju njihove različite prototipove. Java tehnologije postale su važan alat za razvoj mobilnog softvera.

Stvoren je standard Wireless Application Protocol (WAP) koji već podržavaju neki modeli mobitela. Na temelju WAP-a i XML-a, W3C je razvio označni jezik za bežičnu komunikaciju, WML (Wireless Markup Language).

U razvoju AIS-a, više pažnje se počelo pridavati metapodacima. Ovdje se poduzimaju koraci u dva smjera – standardiziranje prezentacije metapodataka i osiguravanje njihove podrške u sustavu.

AIS koristi razne načine i sredstva predstavljanja metapodataka (razne vrste spremišta metapodataka). Nedostatak unifikacije u ovom području značajno otežava rješavanje problema mobilnosti aplikacija, ponovne upotrebe i integracije informacijskih resursa i informacijskih tehnologija, kao i reinženjeringa AIS-a.

Kako bi se prevladale te poteškoće, aktivno se provodi razvoj standarda metapodataka usmjerenih na različite informacijske tehnologije. U tom području već postoji niz međunarodnih, nacionalnih i industrijskih standarda koji definiraju prezentaciju metapodataka i razmjenu metapodataka u AIS-u. Neki od njih već su stekli status de facto standarda. Ovdje ćemo se ograničiti na spominjanje samo najznačajnijih od njih.

Vjerojatno je prvi de facto standard za ovu kategoriju bio jezik opisa podataka CODASYL za umrežene baze podataka. Treba imenovati sljedeće standarde: standard SQL upitnog jezika za relacijske baze podataka, koji sadrži definiciju tzv. informacijske sheme - skup prikaza shema relacijskih baza podataka; standardna komponenta ODMG baze podataka objekata koja opisuje sučelja spremišta sheme objekata; međunarodni standard IRDS (Information Resource Dictionary Systems), koji opisuje sustave za kreiranje i održavanje direktorija informacijskih resursa organizacije.

Zatim treba spomenuti standard Common Warehouse Metamodel (CWM) za predstavljanje metapodataka skladišta podataka koji je razvio konzorcij OMG, na temelju prethodno kreiranog za šire svrhe standarda OIM (Open Information Model) od strane konzorcija MDC (Meta Data Coalition). .

Novi XML za web tehnološku platformu također uključuje standarde prezentacije metapodataka. Podrška za metapodatke jedna je od najvažnijih inovacija weba, koja radikalno mijenja tehnologiju upravljanja njegovim informacijskim resursima. Dok je podrška za metapodatke izvorno bila potrebna u tehnologijama baza podataka, metapodaci nisu bili podržani na webu prve generacije.

Standardi web metapodataka uključuju podskup XML jezika koji se koristi za opisivanje logičke strukture neke vrste XML dokumenta. Ovaj opis se naziva DTD (Definicija vrste dokumenta). Osim toga, XML platforma uključuje standard XML Schema, koji nudi naprednije mogućnosti za opisivanje XML dokumenata. Standard Resource Definition Framework (RDF) definira jednostavan jezik predstavljanja znanja za opisivanje sadržaja XML dokumenata. Konačno, novi standard OWL (Ontology Web Language) definira formalni jezik opisa ontologije za semantički web.

Konzorcij OMG razvio je standard Unified Modeling Language (UML), koji pruža prikaz metapodataka za CASE vizualnu analizu objekata i alate za dizajn. Ovaj jezik je podržan u mnogim CASE softverskim proizvodima. OMG je također stvorio standard XML Metadata Interchange (XMI) za razmjenu metapodataka između CASE alata pomoću UML-a.

Ovdje treba spomenuti i standard Dublin Core (DC), skup metapodataka za opisivanje sadržaja dokumenata različite prirode. Ovaj je standard brzo stekao popularnost i posebno je pronašao široku upotrebu u web okruženju (vidi odjeljak 3.3).

Nastavlja se rad na razvoju postojećih i stvaranju novih standarda za prezentaciju metapodataka za AIS. Detaljnije informacije o dotičnim standardima mogu se pronaći u enciklopediji.

Prema poznatom stručnjaku iz područja informatike E. Tanenbaumu, ne postoji općeprihvaćena, a ujedno i stroga definicija distribuiranog sustava. Neki pameti tvrde da je distribuirano takvo računalni sustav, u kojem kvar računala, u čije postojanje korisnici prije nisu ni sumnjali, dovodi do prestanka njihovog rada. Značajan dio distribuiranih računalnih sustava, nažalost, zadovoljava ovu definiciju, ali se formalno odnosi samo na sustave s jedinstvenom točkom ranjivosti ( jedna točka kvara).

Često je pri definiranju distribuiranog sustava fokus na podjeli njegovih funkcija između nekoliko računala. Ovim pristupom bilo koji se distribuira računalni sustav gdje je obrada podataka podijeljena između dva ili više računala. Prema definiciji E. Tanenbauma, nešto uže raspoređeni sustav može se definirati kao skup neovisnih računala povezanih komunikacijskim kanalima, koji sa stajališta korisnika nekog softvera izgledaju kao jedinstvena cjelina.

Ovaj pristup definiranju distribuiranog sustava ima svoje nedostatke. Na primjer, sve što se koristi u takvom distribuiranom sustavu softver mogao raditi na jednom računalu, ali sa stajališta gornje definicije, takav sustav više neće biti distribuiran. Stoga bi se koncept distribuiranog sustava vjerojatno trebao temeljiti na analizi softvera koji čini takav sustav.

Kao osnovu za opisivanje interakcije dvaju entiteta razmotrite opći model interakcije klijent-poslužitelj, u kojem jedna od strana (klijent) inicira razmjenu podataka slanjem zahtjeva drugoj strani (poslužitelju). Poslužitelj obrađuje zahtjev i po potrebi šalje odgovor klijentu (slika 1.1).

Riža. 1.1.

Interakcija u okviru modela klijent-poslužitelj može biti ili sinkrona, kada klijent čeka da poslužitelj obradi svoj zahtjev, ili asinkrona, u kojoj klijent šalje zahtjev poslužitelju i nastavlja njegovo izvršavanje ne čekajući poslužiteljev zahtjev. odgovor. Model klijenta i poslužitelja može se koristiti kao osnova za opisivanje različitih interakcija. Za ovaj kolegij važna je interakcija sastavnih dijelova softvera koji čini distribuirani sustav.

Riža. 1.2.

Razmotrimo određenu tipičnu aplikaciju koja se, u skladu s modernim konceptima, može podijeliti na sljedeće logičke razine (slika 1.2): korisničko sučelje(PI), aplikacijska logika (LP) i pristup podacima (DD), rad s bazom podataka (DB). Korisnik sustava s njim komunicira putem korisničkog sučelja, baza podataka pohranjuje podatke koji opisuju domenu aplikacije, a logički sloj aplikacije implementira sve algoritme vezane za predmetno područje.

Budući da su u praksi različiti korisnici sustava obično zainteresirani za pristup istim podacima, najjednostavnije razdvajanje funkcija takvog sustava između više računala bit će razdvajanje logičkih slojeva aplikacije između jednog poslužiteljskog dijela aplikacije. , koji je odgovoran za pristup podacima, te dijelovi klijenta koji se nalaze na nekoliko računala.implementirajući korisničko sučelje. Logika aplikacije može se dodijeliti poslužitelju, klijentima ili dijeliti između njih (slika 1.3).

Riža. 1.3.

Arhitektura aplikacija izgrađena na ovom principu naziva se klijent-poslužitelj ili dvoslojna. U praksi se takvi sustavi često ne klasificiraju kao distribuirani, ali se formalno mogu smatrati najjednostavnijim predstavnicima distribuiranih sustava.

Razvoj arhitekture klijent-poslužitelj je troslojna arhitektura, u kojoj su korisničko sučelje, aplikacijska logika i pristup podacima odvojeni u nezavisne komponente sustava koje se mogu izvoditi na neovisnim računalima (slika 1.4).

Riža. 1.4.

Zahtjev korisnika u takvim sustavima sekvencijalno obrađuju klijentski dio sustava, poslužitelj aplikacijske logike i poslužitelj baze podataka. Međutim, distribuirani sustav se obično shvaća kao sustav sa složenijom arhitekturom od troslojnog.

U prethodnom poglavlju pogledali smo čvrsto povezane višeprocesorske sustave sa zajedničkom memorijom, dijeljenim strukturama podataka jezgre i zajedničkim bazenom iz kojeg se pozivaju procesi. Često je, međutim, poželjno alocirati procesore na takav način da budu autonomni od radnog okruženja i radnih uvjeta u svrhu dijeljenja resursa. Pretpostavimo, na primjer, korisnik osobnog računala treba pristupiti datotekama koje se nalaze na većem stroju, ali u isto vrijeme zadržati kontrolu nad osobnim računalom. Iako neki programi, kao što je uucp, podržavaju mrežni prijenos datoteka i druge mrežne funkcije, njihovo korištenje neće biti skriveno od korisnika, budući da je korisnik svjestan da koristi mrežu. Osim toga, treba napomenuti da programi poput uređivača teksta ne rade s izbrisanim datotekama, kao s običnim. Korisnici bi trebali imati standardni skup funkcija UNIX sustava i, osim potencijalnog uskog grla u izvedbi, ne bi trebali osjećati prelazak granica stroja. Tako, na primjer, rad funkcija sustava otvorenih i čitanih s datotekama na udaljenim strojevima ne bi se trebao razlikovati od njihovog rada s datotekama koje pripadaju lokalnim sustavima.

Arhitektura distribuiranog sustava prikazana je na slici 13.1. Svako računalo prikazano na slici je samostalna jedinica koja se sastoji od CPU-a, memorije i perifernih uređaja. Model se ne kvari iako računalo nema lokalni datotečni sustav: mora imati periferne uređaje za komunikaciju s drugim strojevima, a sve datoteke koje mu pripadaju mogu se nalaziti na drugom računalu. Fizička memorija dostupna svakom stroju neovisna je o procesima koji se izvode na drugim strojevima. U tom se pogledu distribuirani sustavi razlikuju od čvrsto povezanih višeprocesorskih sustava o kojima se raspravljalo u prethodnom poglavlju. Sukladno tome, jezgra sustava na svakom stroju funkcionira neovisno o vanjskim uvjetima rada distribuiranog okruženja.

Slika 13.1. Model sustava distribuirane arhitekture

Distribuirani sustavi, dobro opisani u literaturi, tradicionalno spadaju u sljedeće kategorije:

Periferni sustavi, koji su skupine strojeva koji imaju snažnu zajedništvo i povezani su s jednim (obično većim) strojem. Periferni procesori dijele svoje opterećenje sa središnjim procesorom i prosljeđuju mu sve pozive operativnog sustava. Cilj perifernog sustava je povećati sveukupne performanse mreže i pružiti mogućnost dodjele procesora jednom procesu u UNIX operativnom okruženju. Sustav se pokreće kao zaseban modul; Za razliku od drugih modela distribuiranih sustava, periferni sustavi nemaju stvarnu autonomiju, osim u slučajevima koji se odnose na dispečeriranje procesa i lokalnu dodjelu memorije.

Distribuirani sustavi kao što je "Newcastle", koji omogućuju daljinsku komunikaciju prema imenima udaljenih datoteka u knjižnici (naziv je preuzet iz članka "The Newcastle Connection" - vidi). Izbrisane datoteke imaju BOM (razlikovni naziv) koji u stazi za pretraživanje sadrži posebne znakove ili opcijsku komponentu naziva koja prethodi korijenu datotečnog sustava. Implementacija ove metode ne uključuje promjene u kernelu sustava, pa je stoga jednostavnija od ostalih metoda o kojima se govori u ovom poglavlju, ali manje fleksibilna.

Distribuirani sustavi su potpuno transparentni, u kojima su standardna različita imena dovoljna za upućivanje na datoteke koje se nalaze na drugim strojevima; na kernelu je da prepozna te datoteke kao izbrisane. Putevi pretraživanja datoteka navedeni u njihovim složenim nazivima prelaze granice stroja na točkama montiranja, bez obzira na to koliko se takvih točaka formira kada se datotečni sustavi montiraju na diskove.

U ovom ćemo poglavlju pogledati arhitekturu svakog modela; sve navedene informacije ne temelje se na rezultatima specifičnih razvoja, već na informacijama objavljenim u raznim tehničkim člancima. To pretpostavlja da su moduli protokola i upravljački programi uređaja odgovorni za adresiranje, usmjeravanje, kontrolu toka i otkrivanje i ispravljanje pogrešaka — drugim riječima, da je svaki model neovisan o mreži koja se koristi. Primjeri korištenja funkcija sustava prikazani u sljedećem odjeljku za periferne sustave rade na sličan način za sustave poput Newcastlea i za potpuno transparentne sustave, o čemu će biti riječi kasnije; stoga ćemo ih jednom detaljno razmotriti, au odjeljcima posvećenim drugim vrstama sustava usredotočit ćemo se uglavnom na značajke koje razlikuju ove modele od svih ostalih.

13.1 PERIFERSKI PROCESORI

Arhitektura perifernog sustava prikazana je na slici 13.2. Cilj ove konfiguracije je poboljšati ukupnu mrežnu izvedbu preraspodjelom pokrenutih procesa između CPU-a i perifernih procesora. Svaki od perifernih procesora nema na raspolaganju nikakve druge lokalne periferne uređaje osim onih koji su mu potrebni za komunikaciju sa središnjom procesorskom jedinicom. Središnjem procesoru na raspolaganju su datotečni sustav i svi uređaji. Pretpostavimo da se svi korisnički procesi izvode na perifernom procesoru i da se ne kreću između perifernih procesora; nakon što se prenesu u procesor, ostaju na njemu do završetka. Periferni procesor sadrži laganu verziju operativnog sustava, dizajniranu za rukovanje lokalnim pozivima u sustav, upravljanje prekidima, dodjelu memorije, rad s mrežnim protokolima i s upravljačkim programom uređaja za komunikaciju sa središnjim procesorom.

Kada se sustav inicijalizira na središnjem procesoru, jezgra učitava lokalni operativni sustav na svaki od perifernih procesora putem komunikacijskih linija. Svaki proces koji se izvodi na periferiji povezan je sa satelitskim procesom koji pripada središnjem procesoru (vidi); kada proces koji se izvodi na perifernom procesoru poziva funkciju sustava koja zahtijeva usluge samo središnjeg procesora, periferni proces komunicira sa svojim satelitom i zahtjev se šalje središnjem procesoru na obradu. Satelitski proces obavlja funkciju sustava i šalje rezultate natrag u periferni procesor. Odnos između perifernog procesa i njegovog satelita sličan je odnosu klijent-poslužitelj o kojem smo detaljno raspravljali u 11. poglavlju: periferni proces djeluje kao klijent svog satelita, koji podržava funkcije rada s datotečnim sustavom. U ovom slučaju, proces udaljenog poslužitelja ima samo jednog klijenta. U odjeljku 13.4 pogledat ćemo procese poslužitelja s više klijenata.

Slika 13.2. Konfiguracija perifernog sustava

Slika 13.3. Formati poruka

Kada periferni proces pozove funkciju sustava koja se može obraditi lokalno, kernel ne treba slati zahtjev satelitskom procesu. Tako, na primjer, kako bi dobio dodatnu memoriju, proces može pozvati funkciju sbrk za lokalno izvršenje. Međutim, ako su usluge središnjeg procesora potrebne, na primjer, za otvaranje datoteke, kernel kodira informacije o parametrima proslijeđenim pozvanoj funkciji i uvjetima izvršenja procesa u poruku koja se šalje satelitskom procesu (slika 13.3). Poruka sadrži znak iz kojeg proizlazi da funkciju sustava obavlja satelitski proces u ime klijenta, parametre proslijeđene funkciji i podatke o okruženju izvođenja procesa (na primjer identifikacijski kodovi korisnika i grupe), koji su različite za različite funkcije. Ostatak poruke su podaci promjenjive duljine (na primjer, složeni naziv datoteke ili podaci koji se zapisuju s funkcijom pisanja).

Satelitski proces čeka zahtjeve iz perifernog procesa; kada se primi zahtjev, dekodira poruku, određuje tip funkcije sustava, izvršava je i pretvara rezultate u odgovor koji se šalje perifernom procesu. Odgovor, osim rezultata izvršavanja funkcije sustava, uključuje poruku o pogrešci (ako postoji), broj signala i niz podataka promjenjive duljine koji sadrži, na primjer, informacije pročitane iz datoteke. Periferski proces se obustavlja dok se ne primi odgovor, nakon što ga primi, dešifrira i prenosi rezultate korisniku. Ovo je opća shema za rukovanje pozivima operativnom sustavu; sada prijeđimo na detaljnije razmatranje pojedinih funkcija.

Da biste objasnili kako periferni sustav radi, razmotrite niz funkcija: getppid, open, write, fork, exit i signal. Funkcija getppid prilično je jednostavna jer se bavi jednostavnim obrascima zahtjeva i odgovora koji se razmjenjuju između periferije i CPU-a. Jezgra na perifernom procesoru generira poruku koja ima predznak, iz čega proizlazi da je tražena funkcija getppid funkcija, te šalje zahtjev središnjem procesoru. Satelitski proces na središnjem procesoru čita poruku s perifernog procesora, dešifrira tip funkcije sustava, izvršava je i dobiva identifikator svog roditelja. Zatim generira odgovor i prosljeđuje ga perifernom procesu na čekanju na drugom kraju komunikacijske linije. Kada periferni procesor primi odgovor, prosljeđuje ga procesu koji je nazvao funkciju sustava getppid. Ako periferni proces pohranjuje podatke (kao što je ID procesa roditelja) u lokalnu memoriju, uopće ne mora komunicirati sa svojim suputnikom.

Ako se pozove funkcija otvorenog sustava, periferni proces šalje poruku svom suputniku, koja uključuje naziv datoteke i druge parametre. Ako je uspješan, prateći proces dodjeljuje indeks i ulaznu točku tablici datoteka, dodjeljuje unos u tablicu deskriptora korisničke datoteke u svom prostoru i vraća deskriptor datoteke perifernom procesu. Cijelo to vrijeme, na drugom kraju komunikacijske linije, periferni proces čeka odgovor. On nema na raspolaganju nikakve strukture koje bi pohranjivale informacije o datoteci koja se otvara; Deskriptor koji vraća open je pokazivač na unos u pratećem procesu u tablici deskriptora korisničke datoteke. Rezultati izvršavanja funkcije prikazani su na slici 13.4.

Slika 13.4. Pozivanje otvorene funkcije iz perifernog procesa

Ako se izvrši poziv sistemskoj funkciji Write, periferni procesor generira poruku koja se sastoji od znaka funkcije pisanja, deskriptora datoteke i količine podataka za pisanje. Zatim iz prostora perifernog procesa preko komunikacijske linije kopira podatke u satelitski proces. Satelitski proces dešifrira primljenu poruku, čita podatke iz komunikacijske linije i zapisuje ih u odgovarajuću datoteku (deskriptor sadržan u poruci koristi se kao pokazivač na čiji indeks i zapis o kojem se koristi u tablici datoteka ); sve se ove radnje izvode na središnjem procesoru. Na kraju rada, satelitski proces šalje perifernom procesu poruku koja potvrđuje primitak poruke i sadrži broj bajtova podataka koji su uspješno kopirani u datoteku. Operacija čitanja je slična; satelit obavještava periferni proces o broju stvarno pročitanih bajtova (u slučaju čitanja podataka s terminala ili kanala, taj se broj ne podudara uvijek s iznosom navedenim u zahtjevu). Za obavljanje jedne ili druge funkcije možda će biti potrebno više puta slati informacijske poruke preko mreže, što je određeno količinom poslanih podataka i veličinom mrežnih paketa.

Jedina funkcija koju treba promijeniti tijekom rada na CPU-u je funkcija sustava vilice. Kada proces izvrši ovu funkciju na CPU-u, kernel odabire periferni procesor za njega i šalje poruku posebnom procesu - poslužitelju, obavještavajući ga da će započeti s istovarom trenutnog procesa. Pod pretpostavkom da je poslužitelj prihvatio zahtjev, kernel koristi fork za stvaranje novog perifernog procesa, dodjeljujući unos u tablicu procesa i adresni prostor. Središnji procesor ispušta kopiju procesa koji je pozvao funkciju fork u periferni procesor, prepisuje novododijeljeni adresni prostor, pokreće lokalni satelit za komunikaciju s novim perifernim procesom i šalje poruku periferiji da inicijalizira programski brojač za novi proces. Satelitski proces (na CPU-u) je potomak procesa koji je nazvao fork; periferni proces tehnički je potomak poslužiteljskog procesa, ali logično je potomak procesa koji je nazvao funkciju vilice. Proces poslužitelja nema logičku vezu s djetetom kada se fork završi; jedini posao poslužitelja je pomoći istovariti dijete. Zbog jake povezanosti komponenti sustava (periferni procesori nemaju autonomiju), periferni proces i satelitski proces imaju isti identifikacijski kod. Odnos između procesa prikazan je na slici 13.5: kontinuirana linija prikazuje odnos roditelj-dijete, a točkasta linija prikazuje odnos između vršnjaka.

Slika 13.5. Izvršavanje funkcije vilice na CPU-u

Kada proces izvrši funkciju vilice na perifernom procesoru, on šalje poruku svom satelitu na CPU-u, koji zatim izvršava cijeli slijed gore opisanih radnji. Satelit odabire novi periferni procesor i vrši potrebne pripreme za istovar slike starog procesa: šalje zahtjev roditeljskom perifernom procesu da pročita njegovu sliku, kao odgovor na što prijenos traženih podataka počinje na drugom kraju komunikacijskog kanala. Satelit čita prenesenu sliku i prepisuje je perifernom potomku. Kada je učitavanje slike završeno, satelit se račva, stvarajući svoje dijete na CPU-u i prosljeđuje vrijednost programskog brojača perifernom djetetu tako da ono zna s koje adrese započeti izvršavanje. Očito bi bilo bolje da je dijete pratećeg procesa dodijeljeno perifernom djetetu kao roditelju, ali u našem slučaju generirani procesi mogu se izvoditi na drugim perifernim procesorima, a ne samo na onom na kojem su kreirani. Odnos između procesa na kraju funkcije vilice prikazan je na slici 13.6. Kada periferni proces završi svoj rad, šalje odgovarajuću poruku satelitskom procesu i to također završava. Prateći proces ne može pokrenuti gašenje.

Slika 13.6. Izvršavanje funkcije vilice na perifernom procesoru

I u višeprocesorskim i u jednoprocesorskim sustavima, proces mora reagirati na signale na isti način: proces ili dovršava izvršavanje funkcije sustava prije provjere signala, ili, naprotiv, nakon primitka signala, odmah izlazi iz suspendiranog stanja i naglo prekida rad funkcije sustava, ako je to u skladu s prioritetom s kojim je suspendiran. Budući da satelitski proces obavlja funkcije sustava u ime perifernog procesa, mora reagirati na signale u koordinaciji s potonjim. Ako na jednoprocesorskom sustavu signal uzrokuje da proces prekine funkciju, prateći proces na višeprocesorskom sustavu trebao bi se ponašati na isti način. Isto se može reći i za slučaj kada signal poziva proces da prekine svoj rad koristeći izlaznu funkciju: periferni proces završava i šalje odgovarajuću poruku satelitskom procesu, koji se, naravno, također završava.

Kada periferni proces pozove funkciju signalnog sustava, on pohranjuje trenutne informacije u lokalne tablice i šalje poruku svom satelitu informirajući ga treba li navedeni signal primiti ili zanemariti. Satelitski proces ne brine hoće li presresti signal ili zadanu akciju. Reakcija procesa na signal ovisi o tri čimbenika (slika 13.7): dolazi li signal dok proces izvršava funkciju sustava, je li signalna funkcija napravljena pomoću funkcije signala kako bi se signal ignorirao, javlja li se signal na istom perifernom procesoru ili na nekom drugom. Prijeđimo na razmatranje raznih mogućnosti.

algoritam sighandle / * algoritam za obradu signala * /

if (trenutni proces je nečiji pratilac ili ima prototip)

ako (signal se zanemaruje)

if (signal je došao tijekom izvršavanja funkcije sustava)

staviti signal ispred satelitskog procesa;

poslati signalnu poruku perifernom procesu;

ostalo (/ * periferni proces * /

/ * je li primljen signal tijekom izvršavanja funkcije sustava ili ne * /

poslati signal satelitskom procesu;

algoritam satelitski_end_syscall / * završetak funkcije sustava koju poziva periferni proces * /

ulazna informacija: nema

otisak: nema

if (prekid je primljen tijekom izvršavanja funkcije sustava)

poslati prekidnu poruku, signal perifernom procesu;

else / * izvođenje funkcije sustava nije prekinuto * /

poslati odgovor: omogućiti zastavicu koja pokazuje dolazak signala;

Slika 13.7. Obrada signala u perifernom sustavu

Pretpostavimo da je periferni proces obustavio svoj rad dok satelitski proces obavlja funkciju sustava u njegovo ime. Ako se signal javlja negdje drugdje, satelitski ga proces detektira ranije od perifernog procesa. Moguća su tri slučaja.

1. Ako tijekom čekanja nekog događaja satelitski proces nije ušao u suspendirano stanje iz kojeg bi izašao po prijemu signala, on do kraja obavlja funkciju sustava, šalje rezultate izvršenja perifernom procesu i prikazuje koji je signal primio.

2. Ako je proces upućen da zanemari ovu vrstu signala, satelit nastavlja slijediti algoritam izvršavanja funkcije sustava bez izlaska iz suspendiranog stanja pomoću longjmp. U odgovoru koji se šalje perifernom procesu neće biti poruke o primljenom signalu.

3. Ako satelitski proces po prijemu signala prekine izvršavanje funkcije sustava (longjmp), o tome obavještava periferni proces i obavještava ga o broju signala.

Periferni proces traži informacije o primitku signala u primljenom odgovoru i, ako ih ima, obrađuje signale prije izlaska iz funkcije sustava. Dakle, ponašanje procesa u višeprocesorskom sustavu točno odgovara njegovom ponašanju u jednoprocesorskom sustavu: ili izlazi bez izlaska iz načina rada jezgre, ili poziva prilagođenu funkciju obrade signala, ili ignorira signal i uspješno dovršava funkciju sustava.

Slika 13.8. Prekid tijekom izvršavanja funkcije sustava

Pretpostavimo, na primjer, da periferni proces poziva funkciju čitanja s terminala spojenog na središnji procesor i pauzira svoj rad dok satelitski proces obavlja funkciju (slika 13.8). Ako korisnik pritisne tipku za prekid, CPU jezgra šalje signal satelitskom procesu. Ako je satelit bio u suspendiranom stanju, čekajući dio podataka s terminala, odmah izlazi iz tog stanja i prekida funkciju čitanja. U svom odgovoru na zahtjev perifernog procesa, satelit daje kod greške i broj signala koji odgovara prekidu. Periferni proces analizira odgovor i, budući da poruka kaže da je stigao prekid, šalje signal sam sebi. Prije izlaska iz funkcije čitanja, periferna jezgra provjerava ima li signala, detektira signal prekida iz satelitskog procesa i obrađuje ga kao i obično. Ako, kao rezultat prijema signala prekida, periferni proces prekine svoj rad koristeći izlaznu funkciju, ova funkcija se brine za ubijanje satelitskog procesa. Ako periferni proces presreće signale prekida, poziva korisnički definiranu funkciju za rukovanje signalom i vraća korisniku šifru pogreške nakon izlaska iz funkcije čitanja. S druge strane, ako satelit izvršava funkciju stat sustava u ime perifernog procesa, neće prekinuti njegovo izvođenje kada primi signal (zajamčeno je da će funkcija stat izaći iz bilo koje pauze, budući da ima ograničeno vrijeme čekanja resursa ). Satelit završava izvršavanje funkcije i vraća broj signala perifernom procesu. Periferni proces šalje signal sam sebi i prima ga na izlazu iz funkcije sustava.

Ako se pojavi signal na perifernom procesoru tijekom izvršavanja funkcije sustava, periferni će proces biti u mraku hoće li se uskoro vratiti na kontrolu sa satelitskog procesa ili će potonji ići u suspendirano stanje na neodređeno vrijeme. Periferni proces šalje posebnu poruku satelitu, obavještavajući ga o pojavi signala. Jezgra na CPU-u dešifrira poruku i šalje signal satelitu, čija je reakcija na primanje signala opisana u prethodnim odlomcima (nenormalan završetak izvršavanja funkcije ili njezin završetak). Periferni proces ne može izravno poslati poruku satelitu jer je satelit zauzet obavljanjem funkcije sustava i ne čita podatke s komunikacijske linije.

Pozivajući se na pročitani primjer, treba napomenuti da periferni proces nema pojma čeka li njegov pratitelj na unos s terminala ili izvodi druge radnje. Periferni proces šalje signalnu poruku satelitu: ako je satelit u suspendiranom stanju s prekidnim prioritetom, odmah izlazi iz tog stanja i prekida funkciju sustava; inače, funkcija se prenosi do uspješnog završetka.

Konačno, razmotrite slučaj dolaska signala u vrijeme koje nije povezano s izvršavanjem funkcije sustava. Ako signal potječe od drugog procesora, satelit ga prvi prima i šalje signalnu poruku perifernom procesu, bez obzira odnosi li se signal na periferni proces ili ne. Periferna jezgra dešifrira poruku i šalje signal procesu koji na nju reagira na uobičajen način. Ako signal potječe od perifernog procesora, proces izvodi standardne radnje bez pribjegavanja uslugama svog satelita.

Kada periferni proces šalje signal drugim perifernim procesima, on kodira poruku o pozivu za ukidanje i šalje je satelitskom procesu, koji lokalno izvršava pozvanu funkciju. Ako se neki od procesa za koje je signal namijenjen nalazi na drugim perifernim procesorima, njihovi sateliti će primiti signal (i reagirati na njega kako je gore opisano).

13.2 TIP KOMUNIKACIJE NEWCASTLE

U prethodnom odjeljku razmatrali smo tip čvrsto povezanog sustava koji karakterizira slanje svih poziva funkcijama podsustava za upravljanje datotekama koji nastaju na perifernom procesoru udaljenom (središnjem) procesoru. Sada prelazimo na razmatranje sustava sa slabijom vezom, koji se sastoje od strojeva koji pozivaju datoteke koje se nalaze na drugim strojevima. U mreži osobnih računala i radnih stanica, na primjer, korisnici često pristupaju datotekama koje se nalaze na velikom stroju. U sljedeća dva odjeljka pogledat ćemo konfiguracije sustava u kojima se sve funkcije sustava izvode u lokalnim podsustavima, ali je istovremeno moguć pristup datotekama (preko funkcija podsustava za upravljanje datotekama) koje se nalaze na drugim strojevima.

Ovi sustavi koriste jedan od sljedeća dva puta za identifikaciju izbrisanih datoteka. Na nekim sustavima, složenom imenu datoteke dodaje se poseban znak: komponenta imena koja prethodi ovom znaku identificira stroj, a ostatak imena je datoteka na tom stroju. Tako, na primjer, istaknuto ime

"sftig! / fs1 / mjb / rje"

identificira datoteku "/ fs1 / mjb / rje" na stroju "sftig". Ova shema identifikacije datoteka slijedi uucp konvenciju za prijenos datoteka između sustava sličnih UNIX-u. U drugoj shemi, izbrisane datoteke se identificiraju dodavanjem posebnog prefiksa imenu, na primjer:

/../sftig/fs1/mjb/rje

gdje je "/../" prefiks koji označava da je datoteka izbrisana; druga komponenta naziva datoteke je naziv udaljenog stroja. Ova shema koristi poznatu sintaksu naziva datoteke UNIX, tako da za razliku od prve sheme, korisnički programi se ne moraju prilagođavati korištenju imena neobične konstrukcije (vidi).

Slika 13.9. Formuliranje zahtjeva za datotečni poslužitelj (procesor)

Ostatak ovog odjeljka posvetit ćemo modelu sustava koji koristi Newcastle vezu, u kojem se kernel ne bavi prepoznavanjem izbrisanih datoteka; ova funkcija je u potpunosti dodijeljena potprogramima iz standardne C biblioteke, koji u ovom slučaju igraju ulogu sučelja sustava. Ove rutine analiziraju prvu komponentu naziva datoteke, koja u obje opisane metode identifikacije sadrži znak udaljenosti datoteke. Ovo je odmak od rutine u kojoj bibliotečke rutine ne analiziraju nazive datoteka. Slika 13.9 pokazuje kako se formuliraju zahtjevi datotečnom poslužitelju. Ako je datoteka lokalna, kernel lokalnog sustava normalno obrađuje zahtjev. Razmotrimo suprotan slučaj:

otvori ("/../ sftig / fs1 / mjb / rje / datoteka", O_RDONLY);

Otvoreni potprogram u biblioteci C analizira prve dvije komponente različitog naziva datoteke i zna tražiti datoteku na udaljenom stroju "sftig". Kako bi dobio informaciju o tome je li proces prethodno imao vezu s određenim strojem, potprogram pokreće posebnu strukturu u kojoj pamti tu činjenicu, a u slučaju negativnog odgovora uspostavlja vezu s poslužiteljem datoteka koji radi na udaljenom stroju. Kada proces formulira svoj prvi zahtjev za daljinsku obradu, udaljeni poslužitelj potvrđuje zahtjev, ako je potrebno, bilježi u polja identifikacijskih kodova korisnika i grupe i kreira satelitski proces koji će djelovati u ime klijentskog procesa.

Da bi ispunio zahtjeve klijenta, satelit mora imati iste dozvole za datoteke na udaljenom stroju kao i klijent. Drugim riječima, korisnik "mjb" mora imati ista prava pristupa i udaljenim i lokalnim datotekama. Nažalost, moguće je da se identifikacijski kod klijenta "mjb" podudara s identifikacijskim kodom drugog klijenta na udaljenom računalu. Stoga bi administratori sustava na strojevima koji rade na mreži trebali ili osigurati da se svakom korisniku dodijeli identifikacijski kod koji je jedinstven za cijelu mrežu, ili izvršiti pretvorbu koda u trenutku formuliranja zahtjeva za mrežnu uslugu. Ako se to ne učini, prateći proces imat će prava drugog klijenta na udaljenom računalu.

Delikatnije pitanje je dobivanje prava superkorisnika u vezi s radom s udaljenim datotekama. S jedne strane, superkorisnički klijent ne bi trebao imati ista prava nad udaljenim sustavom kako ne bi doveo u zabludu sigurnosne kontrole udaljenog sustava. S druge strane, neki od programa, ako im se ne dodijele prava superkorisnika, jednostavno neće moći raditi. Primjer takvog programa je program mkdir (vidi Poglavlje 7), koji stvara novi direktorij. Udaljeni sustav neće dopustiti klijentu da stvori novi direktorij jer prava superkorisnika nisu na snazi ​​nakon brisanja. Problem kreiranja udaljenih direktorija služi kao ozbiljan razlog za reviziju sistemske funkcije mkdir u smjeru proširenja njezinih mogućnosti u automatskom uspostavljanju svih veza potrebnih korisniku. Međutim, još uvijek je čest problem da setuid programi (kao što je program mkdir) dobivaju privilegije superkorisnika nad udaljenim datotekama. Možda bi najbolje rješenje za ovaj problem bilo postavljanje dodatnih karakteristika za datoteke koje opisuju pristup njima od strane udaljenih superkorisnika; nažalost, to bi zahtijevalo promjene u strukturi indeksa diska (u smislu dodavanja novih polja) i stvorilo bi previše nereda u postojećim sustavima.

Ako otvoreni potprogram uspije, lokalna knjižnica ostavlja odgovarajuću bilješku o tome u strukturi dostupnoj korisniku koja sadrži adresu mrežnog čvora, ID procesa satelitskog procesa, deskriptor datoteke i druge slične informacije. Knjižnične rutine čitanja i pisanja određuju, na temelju deskriptora datoteke, je li datoteka izbrisana, i ako jest, šalju poruku satelitu. Klijentski proces komunicira sa svojim suputnikom u svim slučajevima pristupa funkcijama sustava koje zahtijevaju usluge udaljenog stroja. Ako proces pristupa dvjema datotekama koje se nalaze na istom udaljenom stroju, koristi jedan satelit, ali ako se datoteke nalaze na različitim strojevima, već se koriste dva satelita: po jedan na svakom stroju. Dva satelita se također koriste kada dva procesa pristupaju datoteci na udaljenom stroju. Pozivanjem funkcije sustava putem satelita proces generira poruku koja uključuje broj funkcije, naziv staze pretraživanja i druge potrebne informacije, slične onima koje su uključene u strukturu poruke u sustavu s perifernim procesorima.

Mehanizam za izvođenje operacija na trenutnom imeniku je složeniji. Kada proces odabere udaljeni direktorij kao trenutni, rutina knjižnice šalje poruku satelitu, koja mijenja trenutni direktorij, a rutina pamti da je direktorij izbrisan. U svim slučajevima kada naziv staze pretraživanja počinje znakom koji nije kosa crta (/), potprogram šalje ime udaljenom stroju, gdje ga satelitski proces usmjerava iz trenutnog direktorija. Ako je trenutni direktorij lokalni, rutina jednostavno prosljeđuje naziv staze pretraživanja lokalnoj kernelu sustava. Funkcija chroot sustava na udaljenom direktoriju je slična, ali ostaje nezapažena za lokalnu kernel; strogo govoreći, proces može zanemariti ovu operaciju, budući da samo knjižnica bilježi njezino izvršenje.

Kada proces pozove fork, odgovarajuća knjižnična rutina šalje poruke svakom satelitu. Satelitski procesi se granaju i šalju svoje podređene ID-ove roditeljskom klijentu. Klijentski proces pokreće funkciju sustava fork, koja prenosi kontrolu na dijete koje stvara; lokalno dijete je u dijalogu s udaljenim satelitskim dijetetom čije adrese pohranjuje knjižnična rutina. Ovo tumačenje funkcije vilice olakšava satelitskim procesima kontrolu otvorenih datoteka i trenutnih direktorija. Kada proces koji radi s udaljenim datotekama završi (pozivanjem funkcije izlaza), potprogram šalje poruke svim svojim udaljenim satelitima kako bi oni učinili isto kada primi poruku. U vježbama se razmatraju određeni aspekti implementacije funkcija exec i exit sustava.

Prednost Newcastle veze je da pristup procesa udaljenim datotekama postaje transparentan (nevidljiv za korisnika), bez potrebe za bilo kakvim promjenama u kernelu sustava. Međutim, ovaj razvoj ima niz nedostataka. Prije svega, tijekom njegove implementacije moguće je smanjenje performansi sustava. Zbog korištenja proširene biblioteke C povećava se veličina memorije koju koristi svaki proces, čak i ako proces ne pristupa udaljenim datotekama; knjižnica duplicira funkcije kernela i zahtijeva više memorijskog prostora. Povećanje veličine procesa produljuje razdoblje pokretanja i može stvoriti više sukoba za memorijske resurse, stvarajući uvjete za češće istovar i stranice zadataka. Lokalni zahtjevi će se izvršavati sporije zbog povećanja trajanja svakog poziva prema kernelu, a može se usporiti i obrada udaljenih zahtjeva, povećava se trošak slanja putem mreže. Dodatna obrada udaljenih zahtjeva na razini korisnika povećava broj prebacivanja konteksta, operacija iskrcavanja i zamjene. Konačno, kako bi se pristupilo udaljenim datotekama, programi se moraju ponovno kompajlirati pomoću novih knjižnica; stari programi i isporučeni objektni moduli neće moći raditi s udaljenim datotekama bez toga. Svi ovi nedostaci su odsutni u sustavu opisanom u sljedećem odjeljku.

13.3 "TRANSPARENTNI" DISTRIBUIRANI DATOTEČNI SUSTAVI

Izraz "transparentna alokacija" znači da korisnici na jednom računalu mogu pristupiti datotekama na drugom stroju, a da ne shvaćaju da prelaze granice stroja, baš kao što su na svom stroju kada prelaze s jednog datotečnog sustava na drugi prelaze točke montiranja. Imena kojima se procesi odnose na datoteke smještene na udaljenim strojevima slična su imenima lokalnih datoteka: u njima nema posebnih znakova. U konfiguraciji prikazanoj na slici 13.10, direktorij "/ usr / src" koji pripada stroju B je "montiran" u direktorij "/ usr / src" koji pripada stroju A. isti izvorni kod sustava, koji se tradicionalno nalazi u "/ usr / src" imenik. Korisnici koji rade na stroju A mogu pristupiti datotekama koje se nalaze na stroju B koristeći uobičajenu sintaksu pisanja naziva datoteka (na primjer: "/usr/src/cmd/login.c"), a kernel sama odlučuje je li datoteka udaljena ili lokalna . Korisnici koji rade na stroju B imaju pristup svojim lokalnim datotekama (nesvjesni da korisnici stroja A mogu pristupiti istim datotekama), ali, zauzvrat, nemaju pristup datotekama koje se nalaze na stroju A. Naravno, moguće su i druge opcije, u posebice one u kojima su svi udaljeni sustavi montirani u korijenu lokalnog sustava, tako da korisnici mogu pristupiti svim datotekama na svim sustavima.

Slika 13.10. Sustavi datoteka nakon daljinskog montiranja

Sličnosti između montiranja lokalnih datotečnih sustava i dopuštanja pristupa udaljenim datotečnim sustavima potaknule su prilagodbu funkcije montiranja na udaljene datotečne sustave. U ovom slučaju, kernel ima na raspolaganju tablicu za montiranje proširenog formata. Izvršavajući funkciju montiranja, kernel organizira mrežnu vezu s udaljenim strojem i pohranjuje informacije koje karakteriziraju ovu vezu u tablicu montiranja.

Zanimljiv problem ima veze s nazivima staza koje uključuju "..". Ako proces napravi trenutni direktorij iz udaljenog datotečnog sustava, tada će korištenje znakova ".." u nazivu vjerojatnije vratiti proces u lokalni datotečni sustav umjesto pristupa datotekama iznad trenutnog direktorija. Vraćajući se ponovo na sliku 13.10, imajte na umu da će proces koji pripada stroju A, nakon što je prethodno odabrao trenutni direktorij "/usr / src / cmd" koji se nalazi u udaljenom datotečnom sustavu, izvršiti naredbu

trenutni direktorij bit će korijenski direktorij stroja A, a ne stroja B. Algoritam namei u jezgri udaljenog sustava, nakon što primi slijed znakova "..", provjerava je li pozivni proces agent klijentskog procesa , i ako je tako, postavlja, tretira li klijent trenutni radni direktorij kao korijen udaljenog datotečnog sustava.

Komunikacija s udaljenim strojem ima jedan od dva oblika: poziv udaljene procedure ili poziv funkcije udaljenog sustava. U prvom obliku, svaka procedura kernela koja se bavi indeksima provjerava pokazuje li indeks na udaljenu datoteku, i ako jest, šalje zahtjev udaljenom stroju za izvođenje navedene operacije. Ova shema se prirodno uklapa u apstraktnu strukturu podrške za datotečne sustave različitih tipova, opisanu u završnom dijelu poglavlja 5. Dakle, pristup udaljenoj datoteci može pokrenuti prijenos nekoliko poruka preko mreže, čiji je broj određuje se brojem podrazumijevanih operacija na datoteci, uz odgovarajuće povećanje vremena odgovora na zahtjev, uzimajući u obzir vrijeme čekanja prihvaćeno u mreži. Svaki skup udaljenih operacija uključuje najmanje akcije za zaključavanje indeksa, brojanje referenci itd. U svrhu poboljšanja modela predložena su različita rješenja optimizacije koja se odnose na kombiniranje nekoliko operacija u jedan upit (poruku) i međuspremnik najvažnijih podataka (cm. ).

Slika 13.11. Otvaranje udaljene datoteke

Razmislite o procesu koji otvara udaljenu datoteku "/usr/src/cmd/login.c", gdje je "src" točka montiranja. Raščlanjivanjem naziva datoteke (koristeći shemu namei-iget), kernel otkriva da je datoteka izbrisana i šalje zahtjev glavnom stroju da dobije zaključani indeks. Nakon što dobije željeni odgovor, lokalna kernel stvara kopiju indeksa u memoriji koja odgovara udaljenoj datoteci. Zatim kernel provjerava potrebna prava pristupa datoteci (za čitanje, na primjer) slanjem druge poruke udaljenom računalu. Otvoreni algoritam nastavlja se u potpunosti u skladu s planom navedenim u 5. poglavlju, šaljući poruke udaljenom stroju po potrebi, sve dok algoritam nije dovršen i indeks se ne oslobodi. Odnos između struktura podataka jezgre po završetku otvorenog algoritma prikazan je na slici 13.11.

Ako klijent pozove funkciju sustava za čitanje, jezgra klijenta zaključava lokalni indeks, izdaje zaključavanje udaljenog indeksa, zahtjev za čitanje, kopira podatke u lokalnu memoriju, izdaje zahtjev za oslobađanje udaljenog indeksa i oslobađa lokalni indeks . Ova shema je u skladu sa semantikom postojeće jednoprocesorske jezgre, ali učestalost korištenja mreže (više poziva na svaku funkciju sustava) smanjuje performanse cijelog sustava. Međutim, kako bi se smanjio protok poruka na mreži, više se operacija može kombinirati u jedan zahtjev. U primjeru s funkcijom čitanja, klijent može poslati poslužitelju jedan opći zahtjev za "čitanje", a poslužitelj sam odlučuje zgrabiti i otpustiti indeks kada se izvrši. Smanjenje mrežnog prometa također se može postići korištenjem udaljenih međuspremnika (kao što smo gore raspravljali), ali se mora paziti da se funkcije sistemske datoteke koje koriste te međuspremnike ispravno izvršavaju.

U drugom obliku komunikacije s udaljenim strojem (poziv funkciji udaljenog sustava), lokalna jezgra otkriva da je funkcija sustava povezana s udaljenom datotekom i šalje parametre navedene u svom pozivu udaljenom sustavu, koji izvršava funkciju i vraća rezultate klijentu. Klijentski stroj prima rezultate izvršenja funkcije i izlazi iz stanja poziva. Većina funkcija sustava može se izvesti korištenjem samo jednog mrežnog zahtjeva i primanja odgovora nakon razumnog vremena, ali ne uklapaju se sve funkcije u ovaj model. Tako, na primjer, nakon primanja određenih signala, kernel kreira datoteku za proces pod nazivom "core" (poglavlje 7). Stvaranje ove datoteke nije povezano s određenom funkcijom sustava, ali završava izvođenjem nekoliko operacija kao što je stvaranje datoteke, provjera dopuštenja i izvođenje niza upisivanja.

U slučaju funkcije otvorenog sustava, zahtjev za izvršavanje funkcije poslan udaljenom stroju uključuje dio naziva datoteke koji je ostao nakon izuzimanja komponenti naziva staze pretraživanja koje razlikuju udaljenu datoteku, kao i razne zastavice. U ranijem primjeru otvaranja datoteke "/usr/src/cmd/login.c", kernel šalje naziv "cmd / login.c" udaljenom stroju. Poruka također uključuje vjerodajnice kao što su identifikacijski kodovi korisnika i grupe, koji su potrebni za provjeru dopuštenja datoteka na udaljenom računalu. Ako se od udaljenog stroja primi odgovor koji ukazuje na uspješnu funkciju otvaranja, lokalna jezgra dohvaća slobodni indeks u memoriju lokalnog stroja i označava ga kao indeks udaljene datoteke, pohranjuje informacije o udaljenom stroju i udaljenom indeksu i rutinski dodjeljuje novi unos u tablici datoteka. U usporedbi sa stvarnim indeksom na udaljenom stroju, indeks u vlasništvu lokalnog stroja je formalan i ne krši konfiguraciju modela, koja je uglavnom ista kao i konfiguracija koja se koristi pri pozivanju udaljene procedure (slika 13.11). Ako funkcija koju poziva proces pristupa udaljenoj datoteci putem svog deskriptora, lokalna kernel zna iz (lokalnog) indeksa da je datoteka udaljena, formulira zahtjev koji uključuje pozvanu funkciju i šalje ga udaljenom stroju. Zahtjev sadrži pokazivač na udaljeni indeks pomoću kojeg satelitski proces može identificirati samu udaljenu datoteku.

Nakon što je primila rezultat izvršavanja bilo koje funkcije sustava, kernel može pribjeći uslugama posebnog programa za njegovu obradu (nakon čijeg završetka će kernel završiti rad s funkcijom), jer se lokalna obrada rezultata koristi u jednoprocesorskom sustavu nije uvijek prikladan za sustav s nekoliko procesora. Kao rezultat toga, moguće su promjene u semantici algoritama sustava, usmjerene na pružanje podrške za izvršavanje udaljenih funkcija sustava. Međutim, u isto vrijeme, minimalan protok poruka kruži mrežom, osiguravajući minimalno vrijeme odgovora sustava na dolazne zahtjeve.

13.4 DISTRIBUIRANI MODEL BEZ PROCESA PRIJENOSA

Korištenje procesa prijenosa (satelitskih procesa) u transparentnom distribuiranom sustavu olakšava praćenje izbrisanih datoteka, ali je tablica procesa udaljenog sustava preopterećena satelitskim procesima koji većinu vremena miruju. U drugim shemama, posebni procesi poslužitelja koriste se za obradu udaljenih zahtjeva (vidi i). Udaljeni sustav ima skup (skup) poslužiteljskih procesa koje s vremena na vrijeme dodjeljuje za obradu dolaznih udaljenih zahtjeva. Nakon obrade zahtjeva, poslužiteljski proces se vraća u spremište i ulazi u stanje spremno za obradu drugih zahtjeva. Poslužitelj ne sprema korisnički kontekst između dva poziva, jer može obraditi zahtjeve iz nekoliko procesa odjednom. Stoga svaka poruka koja dolazi iz klijentskog procesa mora sadržavati informacije o njegovom okruženju izvršavanja, odnosno: identifikacijske kodove korisnika, trenutni direktorij, signale, itd. funkcije.

Kada proces otvori udaljenu datoteku, udaljena kernel dodjeljuje indeks za sljedeće veze na datoteku. Lokalni stroj održava prilagođenu tablicu deskriptora datoteka, tablicu datoteka i tablicu indeksa s redovitim skupom zapisa, s unosom u tablici indeksa koji identificira udaljeni stroj i udaljeni indeks. U slučajevima kada funkcija sustava (na primjer, čitanje) koristi deskriptor datoteke, kernel šalje poruku koja upućuje na prethodno dodijeljeni udaljeni indeks i prenosi informacije vezane za proces: identifikacijski kod korisnika, maksimalnu veličinu datoteke, itd. stroj ima serverski proces koji mu je na raspolaganju, interakcija s klijentom poprima prethodno opisani oblik, međutim, veza između klijenta i poslužitelja uspostavlja se samo za vrijeme trajanja funkcije sustava.

Korištenje poslužitelja umjesto satelitskih procesa može otežati upravljanje podatkovnim prometom, signalima i udaljenim uređajima. Veliki broj zahtjeva udaljenom stroju u nedostatku dovoljnog broja poslužitelja treba staviti u red čekanja. To zahtijeva protokol višeg sloja od onog koji se koristi na glavnoj mreži. U satelitskom modelu, s druge strane, prezasićenost je eliminirana jer se svi zahtjevi klijenata obrađuju sinkrono. Klijent može imati najviše jedan zahtjev na čekanju.

Obrada signala koji prekidaju izvršavanje funkcije sustava također je komplicirana kada se koriste poslužitelji, budući da udaljeni stroj mora tražiti odgovarajući poslužitelj koji služi izvršenju funkcije. Čak je moguće da zbog zauzetosti svih poslužitelja zahtjev za funkciju sustava čeka na obradu. Uvjeti za nastanak konkurencije također nastaju kada poslužitelj vrati rezultat funkcije sustava pozivnom procesu, a odgovor poslužitelja uključuje slanje odgovarajuće signalne poruke kroz mrežu. Svaka poruka mora biti označena kako bi je udaljeni sustav mogao prepoznati i, ako je potrebno, prekinuti procese poslužitelja. Prilikom korištenja satelita automatski se identificira proces koji vodi ispunjenje zahtjeva klijenta, a u slučaju pristizanja signala nije teško provjeriti je li zahtjev obrađen ili ne.

Konačno, ako funkcija sustava koju je pozvao klijent uzrokuje pauzu poslužitelja na neodređeno vrijeme (na primjer, prilikom čitanja podataka s udaljenog terminala), poslužitelj ne može obraditi druge zahtjeve za oslobađanje spremišta poslužitelja. Ako nekoliko procesa pristupa udaljenim uređajima odjednom i ako je broj poslužitelja ograničen odozgo, postoji prilično opipljivo usko grlo. To se ne događa sa satelitima, budući da se satelit dodjeljuje svakom klijentskom procesu. Drugi problem s korištenjem poslužitelja za udaljene uređaje bit će obrađen u vježbi 13.14.

Unatoč prednostima koje pruža korištenje satelitskih procesa, potreba za slobodnim unosima u tablicu procesa u praksi postaje toliko akutna da se u većini slučajeva još uvijek koriste usluge poslužiteljskih procesa za obradu udaljenih zahtjeva.

Slika 13.12. Konceptualni dijagram interakcije s udaljenim datotekama na razini kernela

13.5 ZAKLJUČCI

U ovom poglavlju razmotrili smo tri sheme za rad s datotekama smještenim na udaljenim strojevima, tretirajući udaljene datotečne sustave kao ekstenziju lokalnog. Arhitektonske razlike između ovih rasporeda prikazane su na slici 13.12. Svi se oni, pak, razlikuju od višeprocesorskih sustava opisanih u prethodnom poglavlju po tome što procesori ovdje ne dijele fizičku memoriju. Sustav perifernog procesora sastoji se od čvrsto povezanog skupa procesora koji dijele resurse datoteka središnjeg procesora. Veza tipa Newcastle omogućuje skriveni ("transparentni") pristup udaljenim datotekama, ali ne putem kernela operacijskog sustava, već korištenjem posebne C biblioteke. Iz tog razloga svi programi koji namjeravaju koristiti ovu vrstu poveznice moraju se ponovno kompajlirati, što je općenito ozbiljan nedostatak ove sheme. Udaljenost datoteke označava se posebnim nizom znakova koji opisuju stroj na kojem se datoteka nalazi, a to je još jedan čimbenik koji ograničava prenosivost programa.

U transparentnim distribuiranim sustavima, za pristup udaljenim datotekama koristi se modifikacija funkcije sustava montiranja. Indeksi na lokalnom sustavu označeni su kao udaljene datoteke, a lokalna kernel šalje poruku udaljenom sustavu koja opisuje traženu funkciju sustava, njene parametre i udaljeni indeks. Komunikacija u "transparentnom" distribuiranom sustavu podržana je u dva oblika: u obliku poziva udaljenoj proceduri (poruka se šalje udaljenom stroju s popisom operacija povezanih s indeksom) i u obliku poziva na funkciju udaljenog sustava (poruka opisuje traženu funkciju). Završni dio poglavlja govori o pitanjima vezanim uz obradu udaljenih zahtjeva korištenjem satelitskih procesa i poslužitelja.

13.6 VJEŽBE

*1. Opišite implementaciju funkcije izlaznog sustava u sustavu s perifernim procesorima. Koja je razlika između ovog slučaja i kada proces završi nakon primitka neuhvaćenog signala? Kako bi kernel trebao izbaciti sadržaj memorije?

2. Procesi ne mogu zanemariti SIGKILL signale; Objasnite što se događa u perifernom sustavu kada proces primi takav signal.

* 3. Opišite implementaciju funkcije exec sustava na sustavu s perifernim procesorima.

*4. Kako bi središnji procesor trebao raspodijeliti procese među perifernim procesorima kako bi uravnotežio ukupno opterećenje?

*5. Što se događa ako periferni procesor nema dovoljno memorije da primi sve procese koji su mu prebačeni? Kako bi trebalo izvršiti rasterećenje i zamjenu procesa u mreži?

6. Razmislite o sustavu u kojem se šalju zahtjevi udaljenom poslužitelju datoteka ako se u nazivu datoteke nalazi poseban prefiks. Neka proces pozove execl ("/../ sftig / bin / sh", "sh", 0); Izvršni se nalazi na udaljenom stroju, ali mora biti pokrenut na lokalnom sustavu. Objasnite kako se udaljeni modul migrira na lokalni sustav.

7. Ako administrator treba dodati nove strojeve postojećem sustavu s vezom kao što je Newcastle, koji je onda najbolji način da o tome obavijesti module C biblioteke?

*osam. Tijekom izvršavanja funkcije exec, kernel prepisuje adresni prostor procesa, uključujući tablice knjižnica koje koristi Newcastle veza za praćenje veza na udaljene datoteke. Nakon izvršenja funkcije, proces mora zadržati mogućnost pristupa tim datotekama pomoću njihovih starih deskriptora. Opišite provedbu ove točke.

*devet. Kao što je prikazano u odjeljku 13.2, pozivanje funkcije izlaznog sustava na sustavima s vezom Newcastle rezultira slanjem poruke pratećem procesu, prisiljavajući potonjeg da prekine. To se radi na razini knjižničnih rutina. Što se događa kada lokalni proces primi signal koji mu govori da izađe u načinu rada jezgre?

*deset. U sustavu s vezom na Newcastle, gdje se udaljene datoteke identificiraju prefiksom imena posebnim prefiksom, kako korisnik, navodeći ".." (roditeljski direktorij) kao komponentu naziva datoteke, može prijeći udaljenu točku montiranja?

11. Iz Poglavlja 7 znamo da različiti signali uzrokuju da proces izbacuje sadržaj memorije u trenutni direktorij. Što bi se trebalo dogoditi ako je trenutni direktorij iz udaljenog datotečnog sustava? Kakav biste odgovor dali ako sustav koristi odnos poput Newcastlea?

*12. Kakve bi implikacije na lokalne procese to imalo da se svi satelitski ili poslužiteljski procesi uklone iz sustava?

*13. Razmislite o tome kako implementirati algoritam veze u transparentan distribuirani sustav, čiji parametri mogu biti dva udaljena imena datoteka, kao i exec algoritam, povezan s izvođenjem nekoliko internih operacija čitanja. Razmotrimo dva oblika komunikacije: poziv udaljene procedure i poziv funkcije udaljenog sustava.

*četrnaest. Prilikom pristupa uređaju, poslužiteljski proces može ući u suspendirano stanje iz kojeg će ga ukloniti upravljački program uređaja. Naravno, ako je broj poslužitelja ograničen, sustav više neće moći zadovoljiti zahtjeve lokalnog stroja. Osmislite pouzdanu shemu prema kojoj svi procesi poslužitelja nisu obustavljeni dok se čeka da se dovrše I/O povezani s uređajem. Funkcija sustava se neće prekinuti dok su svi poslužitelji zauzeti.

Slika 13.13. Konfiguracija terminalskog poslužitelja

*15. Kada se korisnik prijavi u sustav, disciplina terminalske linije pohranjuje informaciju da je terminal operaterski terminal koji vodi grupu procesa. Iz tog razloga, kada korisnik pritisne tipku "break" na terminalskoj tipkovnici, svi procesi u grupi primaju signal prekida. Razmislite o konfiguraciji sustava u kojoj su svi terminali fizički spojeni na jedan stroj, ali je registracija korisnika logički implementirana na drugim strojevima (slika 13.13). U svakom slučaju, sustav kreira getty proces za udaljeni terminal. Ako zahtjeve udaljenom sustavu obrađuje skup poslužiteljskih procesa, imajte na umu da kada se izvrši otvorena procedura, poslužitelj prestaje čekati vezu. Kada se funkcija otvaranja dovrši, poslužitelj se vraća u skup poslužitelja, prekidajući svoju vezu s terminalom. Kako se signal prekida aktivira pritiskom na tipku "break" šalje na adrese procesa uključenih u istu grupu?

*16. Dijeljenje memorije je značajka svojstvena lokalnim strojevima. S logičke točke gledišta, dodjela zajedničkog područja fizičke memorije (lokalne ili udaljene) može se provesti za procese koji pripadaju različitim strojevima. Opišite provedbu ove točke.

* 17. Algoritmi za dojavljivanje procesa i stranični algoritmi o kojima se raspravlja u 9. poglavlju pretpostavljaju korištenje lokalnog pagera. Koje promjene treba napraviti u ovim algoritmima kako bi mogli podržati uređaje za daljinsko istovar?

*osamnaest. Pretpostavimo da udaljeni stroj (ili mreža) doživi kobni pad i protokol lokalnog mrežnog sloja bilježi tu činjenicu. Razviti shemu oporavka za lokalni sustav koji šalje zahtjeve udaljenom poslužitelju. Osim toga, razviti shemu oporavka za poslužiteljski sustav koji je izgubio kontakt s klijentima.

*19. Kada proces pristupi udaljenoj datoteci, moguće je da će proces proći kroz više strojeva u potrazi za datotekom. Uzmite ime "/ usr / src / uts / 3b2 / os" kao primjer, gdje je "/ usr" direktorij koji pripada stroju A, "/ usr / src" je točka postavljanja korijena stroja B, " / usr / src / uts / 3b2 "točka je postavljanja korijena stroja C. Hodanje kroz više strojeva do konačnog odredišta naziva se multihop. Međutim, ako postoji izravna mrežna veza između strojeva A i C, slanje podataka putem stroja B bilo bi neučinkovito. Opišite značajke implementacije "multishoppinga" u sustavu s vezom Newcastle i u "transparentnom" distribuiranom sustavu.

Trenutno svi razvijeni u komercijalne svrhe IS imaju distribuiranu arhitekturu, što podrazumijeva korištenje globalnih i/ili lokalnih mreža.

Povijesno gledano, arhitektura file-server je prva postala široko rasprostranjena, budući da je njena logika jednostavna i najlakše je u takvu arhitekturu prenijeti IS-ove koji su već u upotrebi. Zatim je transformirana u arhitekturu poslužitelj-klijent, što se može tumačiti kao njezin logičan nastavak. Suvremeni sustavi koji se koriste u globalnoj mreži INTERNET uglavnom se odnose na arhitekturu distribuiranih objekata (vidi sl. III‑15 )

IS se može zamisliti kako se sastoji od sljedećih komponenti (slika III-16)

III.03.2. a Aplikacije poslužitelja datoteka.

Povijesno je to prva distribuirana arhitektura (sl. III-17). Organizirano je vrlo jednostavno: na poslužitelju su samo podaci, a sve ostalo pripada klijentskom stroju. Budući da su lokalne mreže prilično jeftine, a zbog činjenice da je s takvom arhitekturom aplikativni softver autonoman, takva se arhitektura danas često koristi. Možemo reći da se radi o varijanti klijent-poslužitelj arhitekture, u kojoj se na poslužitelju nalaze samo datoteke s podacima. Različita osobna računala komuniciraju samo putem zajedničkog spremišta podataka, stoga je programe napisane za jedno računalo najlakše prilagoditi takvoj arhitekturi.

Prednosti:

Prednosti arhitekture datotečnog poslužitelja:

Jednostavnost organizacije;

Ne proturječi potrebnim zahtjevima za održavanje integriteta i pouzdanosti baze podataka.

Zagušenje mreže;

Nepredvidiv odgovor na zahtjev.

Ovi nedostaci se objašnjavaju činjenicom da svaki zahtjev prema bazi podataka dovodi do prijenosa značajnih količina informacija preko mreže. Na primjer, za odabir jednog ili nekoliko redaka iz tablica, cijela tablica se preuzima na klijentski stroj i DBMS već odabire tamo. Značajan mrežni promet posebno je opterećen organizacijom udaljenog pristupa bazi podataka.

III.03.2. b Klijent-poslužitelj aplikacije.

U ovom slučaju postoji raspodjela odgovornosti između poslužitelja i klijenta. Ovisno o tome kako su razdvojeni razlikovati mast i tanak klijent.

U modelu tankog klijenta, sav rad aplikacije i upravljanje podacima obavlja se na poslužitelju. Korisničko sučelje u tim sustavima „migrira“ na osobno računalo, a sama softverska aplikacija obavlja funkcije poslužitelja, t.j. pokreće sve procese aplikacije i upravlja podacima. Model tankog klijenta također se može implementirati gdje su klijenti računala ili radne stanice. Mrežni uređaji pokreću internetski preglednik i korisničko sučelje implementirano unutar sustava.

Glavni mana modeli tankog klijenta - veliko opterećenje poslužitelja i mreže. Svi izračuni se izvode na poslužitelju, a to može dovesti do značajnog mrežnog prometa između klijenta i poslužitelja. U modernim računalima ima dovoljno računalne snage, ali se praktički ne koristi u modelu / tankom klijentu banke

Nasuprot tome, model debelog klijenta koristi procesorsku snagu lokalnih strojeva: sama aplikacija se postavlja na klijentsko računalo. Primjer ove vrste arhitekture su ATM sustavi, u kojima je bankomat klijent, a poslužitelj središnje računalo koje opslužuje bazu podataka korisničkih računa.

III.03.2. c Dvoslojna i troslojna arhitektura klijent-poslužitelj.

Sve gore navedene arhitekture su dvoslojne. Oni razlikuju razinu klijenta i razinu poslužitelja. Strogo govoreći, IC se sastoji od tri logičke razine:

· Korisnička razina;

Razina aplikacije:

· Podatkovni sloj.

Stoga, u dvoslojnom modelu, gdje su uključene samo dvije razine, postoje problemi s skalabilnosti i performansama ako je odabran model tankog klijenta, ili problemi upravljanja sustavom ako je odabran model debelog klijenta. Ovi se problemi mogu izbjeći primjenom modela koji se sastoji od tri razine, pri čemu su dvije od njih poslužitelji (Sl. III-21).

Poslužitelj podataka

Zapravo, poslužitelj aplikacija i poslužitelj podataka mogu se nalaziti na istom stroju, ali ne mogu obavljati funkcije jedan drugog. Lijepa stvar kod troslojnog modela je to što logički razdvaja izvršavanje aplikacije i upravljanje podacima.

Tablica III-5 Primjena različitih tipova arhitektura

Arhitektura	Primjena
Dvoslojni tanki klijent	1 Naslijeđeni sustavi u kojima nije preporučljivo odvojiti izvršavanje aplikacije i upravljanje podacima. 2 Izračunajte intenzivne aplikacije s malo upravljanja podacima. 3 Aplikacije s velikim količinama podataka, ali malo računanja.
Dvoslojni debeli klijent	1 Aplikacije u kojima korisnik zahtijeva intenzivnu obradu podataka, odnosno vizualizaciju podataka. 2 Aplikacije s relativno konstantnim skupom korisničkih funkcija koje se primjenjuju na dobro vođeno okruženje sustava.
Troslojni poslužitelj-klijent	1 Velike aplikacije sa ćelijama i tisućama klijenata 2 Aplikacije u kojima se podaci i metode obrade često mijenjaju. 3 Aplikacije koje integriraju podatke iz više izvora.

Ovaj model je prikladan za mnoge vrste aplikacija, ali ograničava programere IS-a koji moraju odlučiti gdje će pružiti usluge, pružiti podršku za skalabilnost i razviti alate za povezivanje novih kupaca.

III.03.2. d Arhitektura distribuiranog objekta.

Općenitiji pristup pruža arhitektura distribuiranog objekta, čiji su objekti glavne komponente. Pružaju skup usluga putem svojih sučelja. Drugi objekti šalju zahtjeve bez razlikovanja između klijenta i poslužitelja. Objekti se mogu nalaziti na različitim računalima u mreži i komunicirati putem međuprograma, slično sistemskoj sabirnici, koja vam omogućuje povezivanje različitih uređaja i podržava komunikaciju između hardverskih uređaja.

…

Upravitelj ODBC upravljačkih programa

Vozač 1

Vozač K

DB 1

DB K

Rad sa SQL-om

…

ODBC arhitektura uključuje komponente:

1. Aplikacija (npr. IS). Obavlja zadatke: zahtijeva vezu s izvorom podataka, šalje SQL upite izvoru podataka, opisuje područje pohrane i format za SQL upite, obrađuje pogreške i obavještava korisnika o njima, izvršava ili vraća transakcije, zahtijeva vezu s izvor podataka.

2. Upravitelj uređaja. Učitava drajvere na zahtjev aplikacija, nudi jedno sučelje za sve aplikacije, a ODBC administratorsko sučelje je isto i bez obzira na to s kojim će DBMS-om aplikacija komunicirati. Upravitelj drajvera koji isporučuje Microsoft je biblioteka s dinamičkim učitavanjem (DLL).

3. Driver ovisi o DBMS-u. ODBC upravljački program je biblioteka dinamičke veze (DLL) koja implementira ODBC funkcije i stupa u interakciju s izvorom podataka. Driver je program koji obrađuje zahtjev za funkciju specifičnu za DBMS (može mijenjati zahtjeve u skladu s DBMS-om) i vraća rezultat aplikaciji. Svaki DBMS koji podržava ODBC tehnologiju mora programerima aplikacija osigurati drajver za taj DBMS.

4. Izvor podataka sadrži kontrolne informacije koje je odredio korisnik, informacije o izvoru podataka i koristi se za pristup određenom DBMS-u. U ovom slučaju koriste se sredstva OS-a i mrežne platforme.

Dinamički model

Ovaj model pretpostavlja mnoge aspekte, za koje se koristi najmanje 5 dijagrama u UML-u, vidi str. 2.04.2- 2.04.5.

Razmotrite aspekt upravljanja. Model upravljanja nadopunjuje strukturne modele.

Bez obzira na to kako je struktura sustava opisana, ona se sastoji od skupa strukturnih jedinica (funkcija ili objekata). Da bi funkcionirali kao cjelina, moraju biti kontrolirani, a u statičkim dijagramima nema kontrolnih informacija. Upravljački modeli dizajniraju tijek kontrole između sustava.

Postoje dvije glavne vrste kontrole u softverskim sustavima.

1. Centralizirano upravljanje.

2. Upravljanje temeljeno na događajima.

Centralizirano upravljanje može biti:

· Hijerarhijski- po principu "pozovi-povrati" (ovako najčešće funkcioniraju obrazovni programi)

· Model dispečera koji se koristi za paralelne sustave.

V modeli dispečera pretpostavlja se da je jedna od komponenti sustava dispečer. Upravlja i pokretanjem i gašenjem sustava te koordinacijom ostatka procesa u sustavu. Procesi se mogu odvijati paralelno jedan s drugim. Proces se odnosi na program, podsustav ili proceduru koja se trenutno izvodi. Ovaj model se također može primijeniti u sekvencijalnim sustavima, gdje upravljački program poziva pojedine podsustave ovisno o nekim varijablama stanja (putem operatora slučaj).

Upravljanje događajima pretpostavlja odsutnost bilo kakvog potprograma odgovornog za upravljanje. Upravljanje se provodi vanjskim događajima: pritiskom na tipku miša, pritiskom na tipkovnicu, mijenjanjem očitanja senzora, mijenjanjem očitanja tajmera itd. Svaki vanjski događaj se kodira i stavlja u red događaja. Ako je data reakcija na događaj u redu čekanja, tada se poziva procedura (potprogram) koja izvodi reakciju na ovaj događaj. Događaji na koje sustav reagira mogu se dogoditi ili u drugim podsustavima ili u vanjskom okruženju sustava.

Primjer takvog upravljanja je organizacija aplikacija u sustavu Windows.

Svi prethodno opisani strukturni modeli mogu se implementirati korištenjem centraliziranog upravljanja ili upravljanja temeljenog na događajima.

Korisničko sučelje

Prilikom razvoja modela sučelja treba uzeti u obzir ne samo zadatke dizajniranog softvera, već i značajke mozga povezane s percepcijom informacija.

III.03.4. a Psihofizičke karakteristike osobe povezane s percepcijom i obradom informacija.

Dio mozga, koji se konvencionalno može nazvati procesorom percepcije, neprestano, bez sudjelovanja svijesti, obrađuje dolazne informacije, uspoređuje ih s prošlim iskustvom i stavlja u pohranu.

Kada nam vizualna slika privuče pažnju, tada nam informacija koja nas zanima stiže u kratkoročno pamćenje. Ako naša pozornost nije bila privučena, tada informacije u pohrani nestaju i zamjenjuju se sljedećim dijelovima.

U svakom trenutku vremena fokus pažnje može biti fiksiran u jednoj točki, pa ako postane potrebno istovremeno pratiti nekoliko situacija, fokus se pomiče s jednog praćenog objekta na drugi. Pritom je pažnja raspršena, a neki detalji se mogu previdjeti. Također je značajno da se percepcija u velikoj mjeri temelji na motivaciji.

Kada promijenite okvir, mozak je neko vrijeme blokiran: svladava novu sliku, naglašavajući najvažnije detalje. To znači da ako trebate brzi odgovor korisnika, ne biste trebali naglo mijenjati slike.

Kratkoročno pamćenje je usko grlo u čovjekovom sustavu za obradu informacija. Kapacitet mu je 7 ± 2 nepovezana objekta. Nezatražene informacije pohranjuju se u njemu ne duže od 30 sekundi. Kako ne bismo zaboravili neku važnu informaciju za nas, obično je ponavljamo sami sebi, ažurirajući informacije u kratkoročnom pamćenju. Stoga, pri dizajniranju sučelja, treba imati na umu da je velikoj većini teško, primjerice, zapamtiti i unijeti brojeve koji sadrže više od pet znamenki na drugom zaslonu.

Iako su kapacitet i vrijeme pohrane dugotrajne memorije neograničeni, pristup informacijama nije lak. Mehanizam za izdvajanje informacija iz dugotrajne memorije je asocijativne prirode. Kako bi se poboljšalo pamćenje informacija, ono je povezano s podacima koje memorija već pohranjuje i olakšava njihovo dobivanje. Budući da je pristup dugoročnoj memoriji otežan, preporučljivo je očekivati ​​da korisnik ne zapamti informaciju, već da će je korisnik prepoznati.

III.03.4. b Osnovni kriteriji za ocjenjivanje sučelja

Brojna istraživanja i ankete vodećih tvrtki za razvoj softvera pokazale su da korisnici cijene u sučelju:

1) lakoća svladavanja i pamćenja - posebno procijeniti vrijeme svladavanja i trajanje očuvanja informacija i pamćenja;

2) brzinu postizanja rezultata pri korištenju sustava, koja je određena brojem naredbi i postavki unesenih ili odabranih mišem;

3) subjektivno zadovoljstvo radom sustava (lakoća korištenja, umor i sl.).

Štoviše, za profesionalne korisnike koji stalno rade s istim paketom, drugi i treći kriterij brzo dolaze na prvo mjesto, a za neprofesionalne korisnike koji povremeno rade sa softverom i obavljaju relativno jednostavne zadatke - prvi i treći.

S ove točke gledišta, sučelja s besplatnom navigacijom danas imaju najbolje karakteristike za profesionalne korisnike, a sučelja za izravnu manipulaciju za neprofesionalne korisnike. Odavno je primijećeno da prilikom kopiranja datoteka, pod svim ostalim jednakim uvjetima, većina profesionalaca koristi ljuske poput Fara, a neprofesionalci koriste Windows "drag and drop".

III.03.4. c Vrste korisničkih sučelja

Razlikuju se sljedeće vrste korisničkih sučelja:

primitivno

Besplatna navigacija

Izravna manipulacija.

Sučelje je primitivno

primitivno naziva se sučelje koje organizira interakciju s korisnikom i koristi se u načinu rada konzole. Jedino odstupanje od sekvencijalnog procesa koji podaci pružaju je petlja kroz više skupova podataka.

Sučelje izbornika.

Za razliku od primitivnog sučelja, omogućuje korisniku da odabere operaciju s posebnog popisa koji prikazuje program. Ova sučelja pretpostavljaju implementaciju mnogih scenarija rada, slijed radnji u kojima određuju korisnici. Organizacija izbornika poput stabla sugerira da je teško pronaći stavku na više od dvije razine izbornika.

(Materijal web-mjesta http://se.math.spbu.ru)

Uvod.

Danas su gotovo svi veliki softverski sustavi distribuirani. Distribuirani sustav- sustav u kojem se obrada informacija ne koncentrira na jedno računalo, već je raspoređena na nekoliko računala. U dizajnu distribuiranih sustava, koji ima puno zajedničkog s dizajnom softvera općenito, još uvijek treba razmotriti neke specifičnosti.

Postoji šest glavnih karakteristika distribuiranih sustava.

1. Dijeljenje resursa. Distribuirani sustavi omogućuju dijeljenje i hardverskih (tvrdi diskovi, pisači) i softverskih (datoteke, kompajleri) resursa.
2. Otvorenost.To je mogućnost proširenja sustava dodavanjem novih resursa.
3. Paralelizam.U distribuiranim sustavima, više procesa može se izvoditi istovremeno na različitim računalima u mreži. Ovi procesi mogu biti u interakciji dok su u tijeku.
4. Skalabilnost . Pod, ispod skalabilnost razumije se mogućnost dodavanja novih svojstava i metoda.
5. Tolerancija kvarova. Prisutnost više računala omogućuje dupliciranje informacija i otpornost na neke hardverske i softverske pogreške. Distribuirani sustavi mogu podržati djelomičnu funkcionalnost u slučaju pogreške. Potpuni kvar sustava događa se samo s mrežnim pogreškama.
6. Transparentnost.Korisnicima je omogućen potpuni pristup resursima u sustavu, a pritom su im skrivene informacije o raspodjeli resursa u cijelom sustavu.

Distribuirani sustavi također imaju niz nedostataka.

1. Složenost... Mnogo je teže razumjeti i vrednovati svojstva distribuiranih sustava općenito, a teže ih je projektirati, testirati i održavati. Također, performanse sustava ovise o brzini mreže, a ne o pojedinačnim procesorima. Preraspodjela resursa može značajno promijeniti brzinu sustava.
2. Sigurnost... Obično se sustavu može pristupiti s nekoliko različitih strojeva, poruke na mreži mogu se pratiti i presretati. Stoga je u distribuiranom sustavu puno teže održavati sigurnost.
3. Upravljivost... Sustav se može sastojati od različitih vrsta računala na kojima se mogu instalirati različite verzije operacijskih sustava. Pogreške na jednom stroju mogu se proširiti na druge strojeve na nepredvidiv način.
4. Nepredvidivo ... Reakcija distribuiranih sustava na neke događaje je nepredvidiva i ovisi o punom opterećenju sustava, njegovoj organizaciji i opterećenju mreže. Budući da se ovi parametri mogu stalno mijenjati, vrijeme odgovora na zahtjev može se značajno razlikovati od vremena.

Iz ovih nedostataka možete vidjeti da se pri projektiranju distribuiranih sustava javlja niz problema koje programeri moraju uzeti u obzir.

1. Identifikacija resursa ... Resursi u distribuiranim sustavima nalaze se na različitim računalima, stoga treba razmišljati o sustavu imenovanja resursa tako da korisnici mogu lako pristupiti i uputiti se na resurse koji su im potrebni. Primjer je sustav URL (Uniform Resource Locator) koji definira nazive web stranica.
2. Komunikacija... Univerzalna operativnost Interneta i učinkovita implementacija TCP/IP protokola na Internetu za većinu distribuiranih sustava primjeri su najučinkovitijeg načina organizacije komunikacije između računala. Međutim, u nekim slučajevima gdje je potrebna posebna izvedba ili pouzdanost, moguće je koristiti specijalizirane alate.
3. Kvaliteta usluge sustava ... Ovaj parametar odražava performanse, zdravlje i pouzdanost. Na kvalitetu usluge utječe niz čimbenika: distribucija procesa, resursa, hardvera i prilagodljivost sustava.
4. Arhitektura softvera ... Arhitektura softvera opisuje raspodjelu funkcija sustava među komponentama sustava, kao i distribuciju tih komponenti među procesorima. Ako trebate održavati visokokvalitetne usluge sustava, odabir prave arhitekture je ključan.

Izazov za dizajnere distribuiranih sustava je dizajn softvera i hardvera koji će osigurati sve potrebne karakteristike distribuiranog sustava. To zahtijeva poznavanje prednosti i mana različitih arhitektura distribuiranih sustava. Postoje tri vrste arhitektura distribuiranog sustava.

1. Arhitektura klijent/poslužitelj ... U ovom modelu, sustav se može zamisliti kao skup usluga koje poslužitelji pružaju klijentima. U takvim sustavima poslužitelji i klijenti se međusobno značajno razlikuju.
2. Troslojna arhitektura ... U ovom modelu poslužitelj ne pruža usluge klijentima izravno, već putem poslužitelja poslovne logike.

O prva dva modela rečeno je više puta, zadržimo se na trećem detaljnije.

1. Arhitektura distribuiranih objekata ... U ovom slučaju ne postoje razlike između poslužitelja i klijenata, a sustav se može zamisliti kao skup međusobno povezanih objekata čija lokacija zapravo nije važna. Ne postoji razlika između davatelja usluga i njihovih korisnika.

Ova se arhitektura danas naširoko koristi i također se zove arhitektura web usluga. Web usluga je aplikacija koja je dostupna putem interneta i pruža neke usluge čiji je oblik neovisan o davatelju (s obzirom da se koristi univerzalni format podataka - XML) i platformi rada. Trenutno postoje tri različite tehnologije koje podržavaju koncept distribuiranih objektnih sustava. To su tehnologije EJB, CORBA i DCOM.

Prvo, nekoliko riječi o tome što je XML općenito. XML je generički format podataka koji se koristi za pružanje web usluga. Web usluge se temelje na otvorenim standardima i protokolima: SOAP, UDDI i WSDL.

1. SAPUN ( Simple Object Access Protocol, koji je razvio W3C, definira format za zahtjeve za web usluge. Poruke između web usluge i njezinog korisnika pakirane su u takozvane SOAP omotnice (ponekad se nazivaju i XML omotnice). Sama poruka može sadržavati ili zahtjev za izvođenje neke radnje, ili odgovor - rezultat ove radnje.
2. WSDL (jezik opisa web usluge).Sučelje web usluge opisano je u WSDL dokumentima (a WSDL je podskup XML-a). Prije implementacije usluge, programer sastavlja njezin opis na WSDL jeziku, navodi adresu web usluge, podržane protokole, popis dopuštenih operacija te formate zahtjeva i odgovora.
3. UDDI (univerzalni opis, otkrivanje i integracija) - Protokol pretraživanja internetskih usluga ( http://www.uddi.org/). To je poslovni registar u kojem davatelji web usluga registriraju usluge, a programeri pronalaze usluge koje trebaju uključiti u svoje aplikacije.

Iz razgovora se može činiti da su web servisi najbolje i neosporno rješenje, a pitanje je samo izbor razvojnih alata. Međutim, nije. Postoji alternativa web-uslugama, semantički web, o kojoj je prije pet godina govorio kreator WWW-a Tim Berners-Lee.

Ako je cilj web usluga olakšati komunikaciju između aplikacija, onda je semantički web dizajniran za rješavanje puno složenijeg problema – korištenjem mehanizama metapodataka za povećanje učinkovitosti vrijednosti informacija koje se mogu pronaći na webu. To se može učiniti napuštanjem pristupa orijentiranog na dokumente u korist objektno orijentiranog pristupa.

Bibliografija

1. SomervilleI. Softversko inženjerstvo.
2. Dranitsa A. Java vs. .NET. - "Computerra", br. 516.
3. Internet resursi.