Cunoștințe, prelegeri, tehnologii componente și distribuite

Rezumat: Sunt luate în considerare conceptele principale ale tehnologiilor de dezvoltare a componentelor software și conceptul de componentă. Se vorbește despre principiile generale de dezvoltare a software-ului distribuit și despre organizarea interacțiunii componentelor acestuia în cadrul apelurilor și tranzacțiilor de la distanță.







Concepte de bază ale tehnologiilor componente

Conceptul de componentă software (componentă software) este unul din elementele cheie ale ingineriei software moderne. Acest termen denumește mai multe lucruri diferite, adesea nu clarifică semnificația implicită în fiecare caz particular.

  • Dacă este o arhitectură software (sau arhitectul său software), componenta înseamnă același lucru cu ceea ce se numește adesea un modul software. Acesta este un element arbitrar și abstract al structurii sistemului, alocat cu certitudine mediului. rezolvarea unor sub-sarcini în cadrul sarcinilor comune ale sistemului și interacțiunea cu mediul printr-o anumită interfață. În acest curs pentru acest concept este folosit termenul arhitectural componentă sau componentă a arhitecturii.
  • Diagramele componente din UML descriu adesea componente care sunt unități de gestionare a asamblărilor și configurațiilor - fișiere cu cod în unele limbi, fișiere binare, orice documente care alcătuiesc sistemul. Uneori, în același loc există componente care sunt unități de implementare a sistemului, acestea sunt componente deja în al treilea, în sensul următor.
  • Componentele de implementare sunt blocurile din care este construit software-ul component. Aceleași componente sunt înțelese atunci când vorbim despre tehnologii componente, componente bazate pe componente sau componente bazate pe dezvoltarea de software, componente JavaBeans. EJB. CORBA, ActiveX, VBA, COM, DCOM. Net, servicii Web, precum și abordarea componentă menționată în titlul acestui curs. Conform [1]. o astfel de componentă este o unitate structurală a unui sistem software care are o interfață bine definită. care descrie pe deplin dependențele sale de mediul înconjurător. O astfel de componentă poate fi furnizată independent sau nu poate fi livrată, adăugată sau scos din sistem, incluzând, poate fi inclusă în sistemele altor furnizori.

Diferența dintre aceste concepte, deși destul de subtilă, poate duce în continuare la o neînțelegere gravă a textului sau a interlocutorului în anumite situații.

Definirea unei componente sau a unui modul arhitectural accentuează izolarea elementelor structurale ale întregului sistem și descompunerea sarcinilor pe care le rezolvă în subprobleme mai mici. Reprezentarea unei astfel de componente sub forma unităților de stocare a informațiilor (fișiere, baze de date etc.) nu contează. Interfața sa, deși definită, poate fi rafinată și extinsă în procesul de dezvoltare.

Conceptul de componentă de asamblare și de control al configurației sunt asociate cu elementele structurale ale sistemului cu care trebuie să vă ocupați de uneltele care efectuează managementul de asamblare și de configurare. precum și persoanele care lucrează cu aceste instrumente. Pentru aceste tipuri de componente, este posibil ca interfețele cu alte elemente similare ale sistemului să nu fie definite.

În această prelegere și în majoritatea celor ce urmează, vom aborda componentele în al treilea sens. Acest concept are mai multe aspecte:

  • O componentă în acest sens este o unitate structurală dedicată, cu o interfață clar definită. Ea are cerințe mai stricte pentru claritatea definiției interfeței. decât o componentă arhitecturală. Absolut toate dependențele sale de mediu ar trebui descrise în această interfață. O componentă poate avea și interfețe multiple. jucând mai multe roluri diferite în sistem.

Nu numai semnătura operațiunilor este importantă în descrierea interfeței componente. care pot fi efectuate cu acesta. De asemenea, devine importantă ce alte componente pot folosi în timpul lucrului și, de asemenea, ce constrângeri trebuie să satisfacă datele de operare și ce proprietăți sunt efectuate pentru rezultatele muncii lor.

Aceste restricții sunt așa-numitul contract de interfață sau contractul de software al componentei. Interfața componentei include un set de operații care pot fi solicitate de orice componentă care implementează această interfață. și setul de operații pe care această componentă le poate provoca ca răspuns la alte componente. Contractul de interfață pentru fiecare operație a componentei în sine (sau utilizată de ea) determină precondiția și postcondiția chemării sale. Precondiția operației trebuie să fie efectuată atunci când este apelată, altfel nu este garantată corectitudinea rezultatelor. Dacă această operație este apelată de către componentă, atunci responsabilitatea de a avea grijă de această condiție este pe clientul care apelează operația. Dacă această operațiune este chemată de o componentă a unei alte componente, el se angajează să îndeplinească această condiție prealabilă. Cu postcondiția, contrariul este adevărat - postcondiția operației invocate de componentă trebuie să fie efectuată după apelul său și aceasta este responsabilitatea componentei. Condiția ulterioară a unei operațiuni determină ce rezultate sunt considerate corecte. În ceea ce privește operațiunile cauzate de o componentă, executarea postcondițiilor lor trebuie să fie garantată de componentele de la care sunt numite, iar componenta apelantă se poate baza pe ele în munca lor.







La implementarea interfeței, precondițiile operațiilor pot fi slăbite, iar postcondițiile - devin mai puternice. Acest lucru înseamnă că, prin punerea în aplicare a acestei operațiuni, unele componente pot da seama pentru o mare varietate de date de intrare decât este necesar condiție prealabilă, și poate efectua, de asemenea, ca urmare a mai restrictive decât cele postconditie necesare. Cu toate acestea, componentele externe nu se pot baza pe aceasta atâta timp cât funcționează cu interfața sursă. - implementarea se poate schimba. În mod similar, în cazul în care o interfață de componentă a sistemului necesită alte componente cu un anumit set de operațiuni, acest lucru nu înseamnă că punerea în aplicare a acestei interfețe cauzează într-adevăr aceste operații.

  • Componenta în acest sens este unitatea de implementare. Poate fi atașat la restul sistemului atunci când funcționează de ceva timp și trebuie să-și îndeplinească toate funcțiile dacă sistemul original avea deja toate componentele de care depinde. Poate fi scos din ea. Firește, după aceea, componentele care depind de ea pot să nu mai funcționeze. Acesta poate fi integrat în produse software terțe părți și distribuit cu aceștia. În același timp, nici o parte din ea nu are aceste proprietăți.

    În mod ideal, o astfel de componentă poate fi adăugată sau complet înlocuită de o altă implementare a acelorași interfețe direct în timpul funcționării sistemului, fără a se opri. Deși nu toate tipurile de componente au această proprietate, disponibilitatea sa este foarte de dorit.

    Toate acestea înseamnă că o astfel de componentă trebuie să fie operabilă în orice mediu în care sunt disponibile alte componente necesare funcționării sale. Aceasta necesită o anumită infrastructură, care permite componentelor să se găsească reciproc și să interacționeze în conformitate cu anumite reguli.

  • Setul de interfețe componente reguli de definire și implementare, precum și regulile conform cărora componentele se execută în sistem și interacționează unul cu altul, luat combina numit modelul component (modelul component) [2]. Modelul component include reguli care reglează ciclul de viață al unei componente, adică apoi, prin ce stare se extinde la existența lor într-un sistem (descărcate, încărcate și pasivă, activă, stocate în memoria cache și așa mai departe.) și modul de efectuare a tranzițiilor între aceste state.

    Există mai multe modele componente. Interacționează corect între ele numai componentele construite în cadrul aceluiași model, deoarece modelul component definește "limba" în care componentele pot comunica între ele.

    În plus față de modelul componentei. pentru funcționarea componentelor, este necesar un anumit set de servicii de bază. De exemplu, componentele ar trebui să fie capabile să se găsească reciproc într-un mediu care poate fi distribuit mai multor mașini. Componentele ar trebui să fie în măsură să trimită fiecare alte date, din nou, poate, folosind comunicațiile în rețea, dar punerea în aplicare a componentelor individuale prin ele însele nu depind de tipul de liant utilizat și pe localizarea partenerilor lor de interacțiune. Un set de astfel de bază. necesare pentru operarea majorității componentelor de serviciu, împreună cu modelul component susținut de acestea, se numește cadru component (sau componentă cadru). Exemple de medii de componente cunoscute sunt diverse implementări ale J2EE. NET, CORBA. Prin J2EE. NET și CORBA sunt specificațiile modelelor componente și ale unui set de servicii de bază. care trebuie susținute de implementările lor.

    Componente care funcționează în medii componente. implementând în mod diferit același model de componente și aceleași specificații pentru serviciile de bază. ar trebui să poată interacționa liber. În practică, din păcate, acest lucru nu este întotdeauna posibil să fie atins, însă orice obstacol în calea unei astfel de interacțiuni este văzut ca o problemă gravă, sub rezerva unei probleme de rezolvare timpurie.

    Relația dintre componente, interfețele lor. modelul componentei și mediul componentelor pot fi reprezentate așa cum se face în Fig. 12.1.

  • Componentele diferă de clasele de limbi orientate pe obiect:
    • Clasa definește nu numai un set de interfețe implementate. ci și punerea în aplicare a acestora, deoarece conține codul operațiunilor care vor fi determinate. Contractul component, cel mai adesea, nu stabilește implementarea interfețelor sale.
    • Clasa este scrisă într-un limbaj de programare specific. Componenta nu este legată de o anumită limbă, cu excepția cazului în care, desigur, modelul său component necesită acest lucru - modelul component este pentru componente aceleași ca și pentru clase este limba de programare.
    • De obicei, componenta este o unitate structurală mai mare decât clasa. Implementarea unei componente constă adesea din mai multe clase strâns legate.


    click pentru a mari imaginea
    Fig. 12.1. Elementele principale ale software-ului component

    Trebuie remarcat faptul că, deși piața de software a existat de mult timp și tehnologiile componente au fost dezvoltate timp de aproximativ 20 de ani, piața componentelor se dezvoltă destul de încet. Furnizorii de componente sunt numai companii individuale asociate strâns cu dezvoltatorii de medii specifice de componente. mai degrabă decât o comunitate largă de dezvoltatori individuali și corporativi, ca creatori de tehnologii componente imaginate atunci când s-au născut.

    Se pare că unul dintre principalii factori care împiedică dezvoltarea acestei piețe este "rasa tehnologică" între furnizorii principalelor componente media. Consecința sa este lipsa stabilității în dezvoltarea lor. Versiunile noi apar prea des și, adesea, suficient cu lansarea de noi versiuni, elementele schimbării modelului de componentă. Deci, atunci când dezvoltați componente pentru versiunea următoare, trebuie să urmați câteva alte reguli, iar componentele vechi nu pot fi reutilizate.







    Trimiteți-le prietenilor: