Arhitectura 6 software

arhitectura software

Noțiunea de arhitectură și obiectivele descrierea acestuia. Principalele clase de arhitecturi software. Interacțiunea dintre subsistemele iarhitekturnye funcție. Controlul arhitectura software.

6.1. Conceptul de arhitectura software.

Arhitectura PS - este structura sa se poate observa (sau ar trebui să fie vizibil) în afara acesteia, și anume Introducere PS ca un sistem format dintr-o multitudine de subsisteme care interacționează. Ca astfel de subsisteme de obicei efectua programe individuale. Dezvoltarea arhitecturii este prima etapă în combaterea complexității SS, care este principiul de alocare relativ componente independente realizate.

Principalele obiective ale dezvoltării arhitecturii SS:

· Izolarea și software de cartografiere subsisteme la care funcția externă (definită în descrierea externă) PS;

· Identificarea modalităților de interacțiune între subsistemele software selectate.

Date fiind luate în această etapă, deciziile luate caietul de sarcini suplimentare și specificații funcționale.

6.2. Principalele clase de arhitecturi software.

Există următoarele clase principale de arhitecturi software [6.1]

* 0 întregul program;

* 1 set de programe executabile de sine stătătoare;

* 2 sistem software stratificat;

* 3 echipe de programe concurente.

Întregul program este un caz degenerată de arhitectură PS: în PS conține doar un singur program. O astfel de arhitectură este, în general ales în cazul în care MS are nevoie pentru a efectua o caracteristică orice pronunțată și punerea sa în aplicare nu este prea dificil. Firește, această arhitectură nu are nevoie de nici o descriere (altele decât cele de stabilire arhitectură de clasă), precum și cartografierea funcțiilor externe pentru programul este trivial, și pentru a determina este necesar modul de interacțiune (din cauza absenței oricăror programe de cooperare externă, ci la interacțiunea sa cu utilizator, iar acesta din urmă este descrisă în documentația pentru utilizarea FP).

Complexul Programul executabil independent este format dintr-un set de programe, cum ar fi:

· Oricare dintre aceste programe pot fi activate (pornit) de către utilizator;

· După acest set de punere în aplicare a programului a permis altor programe nu poate fi activat până când serviciul executat este activat programul;

· Toate programele de acest set se va aplica același mediu de informații.

Astfel, acest set de programe de control nu interacționează - interacțiunea dintre ele numai prin mediul informațional totală.

Sistemul de software stratificat constă dintr-un set ordonat de subsisteme software numite straturi. astfel încât:

· La fiecare strat, nu se cunoaște nimic despre proprietățile (și chiar existența) următoarele straturi (mai mari);

· Fiecare strat poate interacționa de Management (vezi componentele) din stratul imediat anterior (inferior) printr-o interfață predeterminată, fără să știe nimic despre structura internă a tuturor straturilor precedente;

· Fiecare strat are anumite resurse pe care el, fie se ascunde de celelalte straturi, sau direct furnizează stratul ulterior (prin interfața specificată) o parte din abstractizare lor.

Astfel, într-un sistem software stratificat, fiecare strat poate pune în aplicare o anumită abstracție de date. Conexiunile dintre straturi sunt valori limitate de transmisie optiuni de tratament pentru fiecare strat adiacent stratului și livrarea rezultatelor acestui tratament pe stratul inferior al feței de jos. Nu utilizați niciodată date la nivel mondial în mai multe straturi.

Ca un exemplu, ia în considerare utilizarea acestei arhitecturi pentru a construi sistemul de operare. Această arhitectură a aplicat în construcția sistemului de operare Dijkstra sau [6.2]. Acest sistem de operare este compus din patru straturi (vezi. Fig. 6.1). Pe stratul sol este realizat din procesul de întrerupere și separarea programelor CPU (procese) în modul de lot. Odată ce acest nivel este conștient de aspectele multi-program ale sistemului. Stratul de sol se realizează organizarea Paged de management al memoriei. Toate straturile superioare oferă o continuă memorie virtuală (nu paginată). Pe al doilea strat comunică cu consola (control) operator. Odată ce acest strat cunoaște caracteristicile tehnice ale consolei. Al treilea strat este realizat de intrare de tamponare și fluxurile de ieșire

Arhitectura 6 software
date și puse în aplicare așa-numitele canale abstracte de intrare și de ieșire, astfel încât aplicațiile nu cunosc caracteristicile tehnice ale dispozitivelor de intrare și de ieșire.

Fig. 6.1. Arhitectura sistemului de operare.

Echipa de programe paralele este un set de programe care pot interacționa unul cu celălalt, în timp ce, în același timp, în curs de desfășurare. Acest lucru înseamnă că aceste programe, în primul rând, din cauza memoriei, sunt activate și pot împărți în mod alternativ timpul unul sau mai multe procesoare centrale, și în al doilea rând, să efectueze între ele dinamic (în timpul rulării) interacțiuni, pe baza carora le-a produs sincronizare. De obicei, interacțiunea dintre aceste procese se realizează prin trecerea reciproc mai multe mesaje.

Cel mai simplu tip de astfel de arhitectură este banda transportoare. Oportunități de organizare a transportorului sunt, de exemplu, pe un sistem de operare UNIX [6.3]. Transportorul este o serie de programe, în care ieșirea standard a fiecărui program, cu excepția ultimului, este conectat la intrarea standard a următorului program al acestei secvențe (vezi. Fig. 6.2). Banda transportoare se ocupă de flux câteva mesaje. Fiecare mesaj care fluxul este alimentat la intrarea primului program care a procesat mesajul este transmis la următorul program, iar ea începe procesarea acestuia următorul flux de mesaje. În același mod, fiecare program funcționează conducta: a primit un mesaj de la programul anterior, și tratarea lui, acesta trimite un mesaj următorul program revizuit și începe să proceseze mesajul următor. Ultimul program pe banda rulanta ieșiri rezultatul întregului transportorului (mesaj rezultat). Astfel, într-o conductă constând din n programe pot fi în același timp în procesul de prelucrare până la n mesaje. Desigur, datorită faptului că diferitele aplicații transportoare pot fi cheltuite pentru prelucrarea mesajelor regulate de lungimi variabile de timp, trebuie să ofere o modalitate de a sincroniza aceste procese (unele procese pot fi în faza de așteptare sau posibilitatea de a transfera mesaje prelucrate sau posibilitatea de a primi un alt mesaj).

Fig. 6.2. Transportorul de programe paralele.

În general, echipa de programe paralele pot fi organizate în porturile de mesaje. Portul de mesaje este un subsistem software-ul care servește o anumită coadă de mesaje: poate accepta pentru păstrarea în siguranță din program orice mesaj, punând-o în loc și poate emite un alt mesaj la un alt program, la cererea acesteia. Mesajul transmis de către un program de anumite porturi nu vor mai aparține acestui program (și resursele sale), dar nu face parte și nici un alt program în timp ce într-o coadă, nu va fi transferat la orice program, la cererea acesteia. Astfel, programul transmite mesajul nu va fi în faza de așteptare până când programul primește acest mesaj, nu ar fi gata să-l ocupe (cu excepția cazului în portul primitor va fi aglomerat).

Un exemplu al unui sistem software cu porturile de mesaje este prezentată în Fig. 6.3. Portul U poate fi considerat ca un port de intrare pentru mesajele prezentate în această figură, echipa de programe paralele și portul W - cum ar fi mesaje de port de ieșire pentru acest grup de programe.

Arhitectura 6 software

Fig. 6.3. Un exemplu al unui sistem software cu mesaje porturi.

6.3. Caracteristici arhitecturale.

Pentru a asigura interoperabilitatea dintre subsistemele în unele cazuri, nu au nevoie pentru a crea orice componente software suplimentare (în plus față de punerea în aplicare a funcțiilor externe) - acest lucru poate fi destul de fixat în acordurile în avans și caracteristici standard ale software-ului de bază (sistem de operare). Deci, într-un complex de programe executabile în mod independent pentru interoperabilitate descriere suficientă (specificație) a mediului IT total extern și caracteristicile sistemului de operare pentru a porni programe. Sistemul software stratificat poate fi alocat un suficiente straturi software specificație și aparatele convenționale pentru procedurile de tratament. Interacțiunea conducte de software între programe pot oferi, de asemenea pentru sistemul de operare (cum este cazul în sistemul de operare UNIX).

Cu toate acestea, în unele cazuri, crearea de componente software suplimentare pot fi necesare pentru a asigura interoperabilitatea între subsisteme software. Deci, pentru a controla funcționarea complexe programe executabile stand-alone de multe ori a crea o coajă de construcții, mai convenabil (în acest domeniu) pentru prepararea mediului de informații externe necesare și va lansa programul dorit decât învelișul de bază a sistemului de operare. In sistemele de software stratificate pot fi stabilite special strat de manipulare aparat pentru procedurile (de exemplu, oferind o execuție paralelă a acestor proceduri). Echipa de programe paralele necesită subsistem software special pentru gestionarea porturilor de comunicații. Aceste componente software implementat decât funcțiile PS externe și funcțiile care rezultă din dezvoltarea arhitecturii acestui SM. Prin urmare, aceste funcții vor fi numite arhitectură.

6.4. Controlul arhitectura software.

Pentru a controla arhitectura SS utilizat controlul adiacent și

Arhitectura de control Adiacent pe partea de sus a PS - este dezvoltatorii de control sale Aspect: designeri și dezvoltatori de specificații de calitate ale caietului de sarcini funcționale. Controlul Adiacent arhitectura PS de mai jos - este controlul potențialilor dezvoltatori de subsisteme software care fac parte din SS, în conformitate cu arhitectura dezvoltată.

Exerciții la capitolul 6.

6.1. Ce este o arhitectura software?

6.2. Care este caracteristica arhitecturală?

Literatura Curs 6.

6.2. E.W. Dijkstra. Structura de THE-multiprogramming // Comunicările ACM. - 1968, 11 (5). - Pp. 341-346.

6.3. M. Christian. Introducere în sistemul de operare UNIX. - M. Finanțe și Statistică, 1985. - P. 46-49.

articole similare