Arhitectura software

Arhitectura software descrie într - un mod simbolic și schematic diferitele elemente ale unuia sau mai multor sisteme informatice, interdependențele lor și interacțiunile lor. Spre deosebire de specificațiile produse de analiza funcțională , modelul arhitectural, produs în timpul fazei de proiectare, nu descrie ce ar trebui să realizeze un sistem computerizat, ci mai degrabă modul în care ar trebui proiectat pentru a îndeplini specificațiile. Analiza descrie „ce să faci” în timp ce arhitectura descrie „cum să o faci”.

Context și motivație

Faza de proiectare a software-ului este echivalentă, în informatică, cu faza de proiectare în ingineria tradițională (mecanică, civilă sau electrică); această fază constă în realizarea completă a produsului într-o formă abstractă înainte de producția efectivă. Pe de altă parte, natura intangibilă a software-ului (modelat în informații și nu în materie) face granița dintre arhitectură și produs mult mai estompată decât în ingineria tradițională. Utilizarea instrumentelor CASE ( inginerie software asistată de calculator ) sau producerea arhitecturii din codul în sine și din documentația sistemului permit evidențierea legăturii strânse dintre arhitectură și produs.

Arhitectura software este cea mai mare livrabilitate într-un proces software după produs (software-ul în sine). Într-adevăr, faza de proiectare ar trebui să consume aproximativ 40% din efortul total de dezvoltare și ar trebui să fie mai mare sau egal, în efort, față de faza de codificare, dar poate fi mai mică. Efortul depinde în mare măsură de tipul de software dezvoltat, de expertiza echipei de dezvoltare, de rata de reutilizare și de procesul software.

Cele două obiective principale ale oricărei arhitecturi software sunt reducerea costurilor și creșterea calității software-ului; reducerea costurilor se realizează în principal prin refolosirea componentelor software și reducerea timpului de întreținere (corectarea erorilor și adaptarea software-ului). Pe de altă parte, calitatea este distribuită pe mai multe criterii; ISO / IEC 25010 este un exemplu al unui astfel de set de criterii.

Criterii de calitate a software-ului

Interoperabilitatea extrinsecă exprimă capacitatea software-ului de a comunica și utiliza resursele altor software, cum ar fi documentele create de o anumită aplicație.

Interoperabilitatea intrinsecă exprimă gradul de coerență între funcționarea comenzilor și a modulelor dintr-un sistem sau software.

Portabilitatea exprimă posibilitatea de a compila codul sursă și / sau de a rula software-ul pe diferite platforme (mașini, sisteme de operare, medii).

Compatibilitatea exprimă posibilitatea, pentru un software, de a funcționa corect într-un mediu vechi (compatibilitate inversă) sau mai recent (compatibilitate inversă).

Valabilitatea exprimă conformitatea funcționalităților software-ului cu cele descrise în specificații.

Verificabilitatea exprimă simplitatea verificării validității.

Integritatea exprimă capacitatea software-ului de a-și proteja funcțiile și datele de accesul neautorizat.

Fiabilitatea este capacitatea software-ului de a gestiona corect propriile erori de operare în timpul executării.

Mentenabilitatea exprimă ușurința de a corecta și modifica software-ul și chiar, uneori, posibilitatea de a modifica software-ul în timp ce rulează.

Reutilizarea exprimă capacitatea de a proiecta software cu componente deja proiectate, permițând în același timp reutilizarea simplă a propriilor componente pentru dezvoltarea altor software.

Extensibilitatea exprimă capacitatea de a extinde pur și simplu funcționalitatea software-ului fără a compromite integritatea și fiabilitatea acestuia.

Eficiența exprimă capacitatea software-ului de a utiliza cât mai bine resursele oferite de aparatul (aparatele) în care va fi instalat software-ul.

Autonomia exprimă capacitatea de a-și controla execuția, datele și comunicațiile.

Transparența exprimă capacitatea software-ului de a ascunde de utilizator (om sau mașină) detaliile inutile pentru utilizarea funcțiilor sale.

Compozibilitatea exprimă capacitatea software-ului de a combina informații din diferite surse.

Utilizarea descrie cât de ușor este pentru utilizatori să învețe și să utilizeze software-ul.

Scăderea degradării software-ului

O arhitectură slabă sau absentă poate provoca probleme grave în timpul întreținerii software-ului. Într-adevăr, orice modificare a unui software slab arhitecturat îi poate destabiliza structura și poate conduce, pe termen lung, la degradare (principiul entropiei software-ului). Prin urmare, arhitectul IT ar trebui să proiecteze în mod sistematic o arhitectură care poate fi menținută și extensibilă.

În procesele iterative precum procesul unificat , gestionarea schimbărilor este primordială. Într-adevăr, se consideră implicit că nevoile utilizatorilor sistemului se pot schimba și că mediul sistemului se poate schimba. Prin urmare, arhitectul IT are responsabilitatea de a prevedea cel mai rău și de a proiecta arhitectura în consecință ; cât se poate de întreținibil și cât se poate de extensibil.

Dezvoltare pentru și prin reutilizare

Reutilizarea componentelor software este activitatea care permite realizarea celor mai substanțiale economii, este încă necesar să aveți componente pentru reutilizare. În plus, reutilizarea componentelor necesită crearea unei arhitecturi software care să permită o integrare armonioasă a acestor componente. Dezvoltarea prin reutilizarea software-ului impune, prin urmare, un ciclu perpetu de producție-reutilizare și o arhitectură software standardizată.

Reutilizarea bine orchestrată necesită crearea și întreținerea unei biblioteci de software și o schimbare a focalizării; crearea unei aplicații este aceeași cu crearea componentelor bibliotecii necesare și apoi crearea aplicației utilizând acele componente. O astfel de bibliotecă pentru dezvoltarea ușoară a aplicațiilor este un cadru (cadriciel) Enterprise și arhitectura sa, iar documentația sa reprezintă pietrele de temelie ale reutilizării software-ului în afaceri.

Prin urmare, rolul arhitectului IT se deplasează spre cel al unui bibliotecar. Arhitectul IT ar trebui să exploreze biblioteca pentru a găsi componentele software adecvate și apoi să creeze componentele lipsă, să le documenteze și să le integreze în bibliotecă. Într-o întreprindere mare, acest rol de bibliotecar este îndeplinit de către arhitectul șef IT care este responsabil pentru dezvoltarea armonioasă a bibliotecii și pentru menținerea integrității arhitecturii sale.

Arhitectura este o chestiune de punct de vedere

Descrierea unui sistem complex, cum ar fi software-ul de calculator, poate fi făcută din mai multe puncte de vedere diferite, dar fiecare se supune formulei lui Perry și Wolf: arhitectură = elemente + forme + motivații. În funcție de nivelul de granularitate , elementele pot varia în mărime (linii de cod, proceduri sau funcții, module sau clase, pachete sau straturi, aplicații sau sisteme informatice), pot varia în rafinament (schiță, soluție pentru îmbunătățire sau soluție de succes ) și în abstractizare (idei sau concepte, clase sau obiecte, componente software). Elementele pot avea, de asemenea, temporalitate (existență limitată în timp) și locație (existență limitată în spațiu).

În timp ce elementele sunt în general reprezentate prin dreptunghiuri sau ovale, formele sunt formate în mare parte din elemente conectate prin linii drepte sau săgeți. Semantica legăturilor determină cea mai mare parte a semanticii diagramei și aspectul sistemului descris în ea.

Principalele tipuri de link-uri

Dependența funcțională înseamnă că elementul sursă necesită elementul destinație pentru a-și atinge funcționalitățile.

Fluxul de control înseamnă că elementul de destinație va prelua controlul execuției după terminarea elementului sursă.

Tranziția de stare înseamnă că sistemul va trece de la starea sursă la starea de destinație.

Schimbarea activității înseamnă că sistemul va efectua activitatea de destinație după activitatea sursă.

Fluxul de date înseamnă că informațiile curg de la elementul sursă la elementul de destinație.

Legătura de comunicare înseamnă că două elemente schimbă informații.

Compoziția înseamnă că elementul sursă este format din una sau mai multe date de tipul elementului de destinație.

Moștenirea (generalizare) , înseamnă că elementul sursă deține toate datele și comportamentele elementului destinație.

Trimitere mesaj înseamnă că elementul sursă trimite un mesaj către elementul de destinație.

Modele de arhitectură

Indiferent de forma pe care o ia o diagramă de arhitectură, ea reprezintă întotdeauna doar un punct de vedere asupra sistemului considerat, cele mai importante fiind motivațiile. Într-adevăr, care este rostul producerii unei diagrame dacă este inutilă (nu este utilizată) sau dacă motivele alegerilor arhitecturale sunt vagi și inexplicabile. Pentru a evita formularea motivațiilor pentru fiecare diagramă, arhitectul IT va produce diferite diagrame pe baza unui șablon de proiectare și va reutiliza modele de proiectare dovedite.

Un model de proiectare (sau arhitectural) este alcătuit dintr-un set de puncte de vedere, fiecare alcătuit dintr-un set de diferite tipuri de diagrame. De asemenea, oferă modalități de a lega diferitele vizualizări și diagrame între ele, astfel încât să navigați cu ușurință, acestea sunt mecanisme de trasabilitate arhitecturală. Trasabilitatea trebuie să se extindă și la specificațiile sistemului și chiar la nevoile pe care aceste specificații le îndeplinesc. Motto-ul celor trei părinți fondatori ai UML este „ Arhitectural-centrat, condus de cazuri de utilizare și dezvoltare iterativă și incrementală ”. Acest motto indică în mod clar că nu trebuie luată nicio decizie arhitecturală fără ca aceasta să fie dirijată (condusă) de satisfacerea specificațiilor sistemului (cazuri de utilizare).

Modelul convențional

Această diagramă descrie, în stânga, specificațiile sistemului care sunt reprezentate și de diagrame (entități-relații, fluxuri de date, tranziții-state). Și în dreapta, avem diferite activități de proiectare, luând ca elemente de intrare rezultatele fazei de analiză. Vedem că arhitectura software tradițională ar necesita producerea a cel puțin patru vizualizări distincte: o arhitectură de date (design de date), o arhitectură funcțională și / sau modulară (design arhitectural), o altă arhitectură funcțională și / sau modulară pentru utilizatorii de interfețe (design de interfață) și o arhitectură detaliată (diagrame, tranziții de stare) a diferitelor module (proiectarea componentelor).

Piramida exprimă faptul că fiecare strat este construit pe cel anterior. Într-adevăr, componentele care îndeplinesc funcționalitățile software-ului trebuie să gestioneze elemente de date care, prin urmare, trebuie descrise în prealabil. De asemenea, componentele care produc interfețele utilizatorului trebuie să utilizeze funcționalitățile software descrise anterior. Și, în cele din urmă, crearea arhitecturii detaliate a fiecăreia dintre componentele software necesită în mod evident ca acestea să fie inventate în prealabil.

Acest model arhitectural impune o separare clară între date, procesare și prezentare.

Model de analiză sau model arhitectural?

Deoarece analiza produce și diagrame, este firesc să ne întrebăm, de fapt, când se termină analiza și când începe arhitectura? Răspunsul la această întrebare este foarte simplu: elementele diagramelor de analiză corespund unor elemente vizibile și de înțeles de către utilizatorii sistemului, în timp ce elementele diagramelor de arhitectură nu corespund niciunei realități tangibile pentru acestea.

Modelul de vizualizare 4 + 1

Modelul Kruchten cunoscut sub numele de model de vizualizare 4 + 1 este cel adoptat în procesul unificat . Din nou, modelul de analiză, cunoscut sub numele de vizualizare a cazurilor de utilizare , formează legătura și motivează crearea tuturor diagramelor arhitecturale.

Vizualizarea cazurilor de utilizare

Vizualizarea cazului de utilizare este un model analitic formalizat de Ivar Jacobson . Un caz de utilizare este definit ca un set de cazuri de utilizare, fiecare scenariu reprezentând o secvență de interacțiune a utilizatorului ( actorului ) cu sistemul.

Interesul cazurilor de utilizare este de a conduce analiza în funcție de cerințele utilizatorilor. Se simt preocupați, deoarece pot înțelege cu ușurință cazurile de utilizare care îi afectează. Prin urmare, această metodă face posibilă formalizarea nevoilor și așteptărilor reale ale utilizatorilor; criticile și comentariile lor fiind elementele de bază ale specificației sistemului.

Setul de cazuri de utilizare ale software-ului specificat este reprezentat de o diagramă de caz de utilizare , fiecare dintre scenariile sale fiind descris de una sau mai multe diagrame dinamice: diagrame de activitate , diagrame de secvență , diagrame de comunicare sau tranziții de stare .

Viziunea logică

Vizualizarea logică este descrierea arhitecturală principală a unui sistem de calcul și multe proiecte mici se bazează doar pe această vizualizare. Această vizualizare descrie, static și dinamic, sistemul în termeni de obiecte și clase. Vizualizarea logică face posibilă identificarea diferitelor elemente și mecanisme ale sistemului de implementat. Permite descompunerea sistemului în abstracții și este inima reutilizării. Într-adevăr, arhitectul IT recuperează maximum de componente ale diferitelor biblioteci și seturi de instrumente ( cadru ) la dispoziția sa. De asemenea, ar putea fi luată în considerare o căutare activă pentru componente gratuite și / sau comerciale.

Vederea logică este reprezentată în principal de diagrame statice ale claselor și obiecte îmbogățite cu descrieri dinamice: diagrame de activitate , secvență , diagrame de comunicare sau statechart .

Vizualizarea procesului

Vizualizarea procesului descrie interacțiunile dintre diferitele procese, fire de execuție ( fire de execuție) sau sarcini, permite, de asemenea, să exprime sincronizarea și alocarea obiectelor. Această viziune este utilizată mai presus de toate pentru a verifica conformitatea cu constrângerile de fiabilitate, eficiență și performanță ale sistemelor multitasking.

Diagramele folosite în vederea procesului sunt exclusiv dinamici: diagrame de activitate , secvență , diagrame de comunicare sau statechart .

Vizualizarea realizării

Vizualizarea de realizare vă permite să vizualizați organizarea componentelor (bibliotecă dinamică și statică, cod sursă etc.) în mediul de dezvoltare. Permite dezvoltatorilor să se regăsească în mizeria care poate fi un proiect de dezvoltare IT. Această vizualizare este, de asemenea, utilizată pentru a gestiona configurația (autori, versiuni etc.).

Singurele diagrame din această vedere sunt diagramele componente .

Vizualizarea implementării

Vizualizarea de implementare reprezintă sistemul în mediul său de execuție. Se ocupă de constrângeri geografice (distribuția procesoarelor în spațiu), constrângeri de lățime de bandă, timp de răspuns și performanța sistemului, precum și toleranță la erori și la erori. Această vizualizare este foarte utilă pentru instalarea și întreținerea regulată a sistemului.

Diagramele din această vedere sunt diagramele componentelor și diagramele de implementare .

Modele structurale

Un model structural al unei arhitecturi se concentrează pe descompunerea unui sistem într-un set de elemente interconectate mai simple. Un sistem poate fi astfel împărțit în subsisteme, apoi în module sau componente și în elemente mai simple. UML permite această viziune structurală prin diagrame de implementare , în diagramele de componente , a diagramelor structură din materiale compozite , în diagramele de pachete , și diagrame de clase . Modelul C4 permite vizualizarea sistemelor de descompunere, a containerelor (adică executabil pentru subsistem care poate fi implementat independent) și a componentelor.

Stiluri arhitecturale

Arhitectura software, la fel ca arhitectura tradițională, poate fi clasificată în stiluri. Într-adevăr, în ciuda milioanelor de sisteme informatice construite în întreaga lume în ultimii cincizeci de ani, toate se încadrează într-un număr extrem de mic de stiluri arhitecturale. În plus, un sistem computerizat poate utiliza mai multe stiluri în funcție de nivelul de granularitate sau de aspectul sistemului descris. Vom sublinia că, ca și în arhitectura tradițională, apar adesea prin amestecul de stiluri vechi și cele noi.

Apelează și returnează arhitectura

Arhitectura call-and-return se bazează pe rafinamentul treptat propus de Niklaus Wirth . Această abordare, numită și descompunere funcțională, constă în împărțirea unei funcționalități în subfuncționalități care sunt, de asemenea, împărțite în sub-subfuncționalități și așa mai departe; deviza divizează și cucerește este adesea folosită pentru a descrie această abordare.

În timp ce această arhitectură se baza inițial pe utilizarea funcțiilor, trecerea la o metodă modulară sau obiect este destul de naturală; funcționalitatea unui modul sau a unui obiect este realizată de sub-module sau sub-obiecte numite lucrători. Termenul ierarhie de control este apoi folosit pentru a descrie extinderea acestei arhitecturi la paradigma modulară sau a obiectului. O formă derivată din această arhitectură este arhitectura distribuită în care funcțiile, modulele sau clasele sunt găsite distribuite într-o rețea.

Arhitectură stratificată

Proiectarea software necesită utilizarea bibliotecilor. O bibliotecă foarte specializată folosește biblioteci mai puțin specializate care folosesc ele însele biblioteci generice. În plus, așa cum am menționat deja, dezvoltarea eficientă a componentelor reutilizabile necesită crearea unei biblioteci software; arhitectura stratificat este consecința inevitabilă a unei astfel de abordare o. Acest lucru se datorează faptului că noile componente le folosesc pe cele vechi și așa mai departe, astfel încât biblioteca tinde să devină un fel de stivă de componente. Împărțirea în straturi constă atunci în gruparea componentelor cu o mare coeziune (semantică similară) astfel încât să se creeze un teanc de pachete de componente; toate componentele stratului superior depind funcțional de componentele stratului inferior.

Arhitectură centrată pe date

În arhitectura centrată pe date , o componentă centrală (SGBD, Datawarehouse , Blackboard) este responsabilă pentru gestionarea datelor (păstrarea, adăugarea, eliminarea, actualizarea, sincronizarea etc.). Componentele periferice, numite clienți, utilizează componenta centrală, numită server de date, care se comportă în general pasiv (SGBD, Datawarehouse). Un server pasiv respectă orbește comenzile, în timp ce un server activ (Blackboard) poate notifica un client dacă are loc o modificare a datelor care îl afectează.

Această arhitectură separă în mod clar datele (servere) de procesare și prezentare (clienți) și astfel permite o integrabilitate foarte mare, de fapt, clienții pot fi adăugați fără a afecta alți clienți. Pe de altă parte, toți clienții sunt dependenți de arhitectura datelor care trebuie să rămână stabilă și care, prin urmare, nu este foarte extensibilă. Prin urmare, acest stil necesită o investiție foarte semnificativă în arhitectura datelor. Depozitele de date și bazele de date federate sunt extensii ale acestei arhitecturi.

Arhitectura fluxului de date

În fluxul de date arhitectura este alcătuită din mai multe componente software legate între ele prin fluxuri de date. Informațiile circulă în rețea și sunt transformate de diferitele componente prin care trece. Când componentele sunt distribuite pe o singură linie și transmit informațiile transformate doar vecinului lor, aceasta se numește arhitectură batch. Dacă componentele sunt distribuite pe o rețea de calculatoare și realizează transformări inteligente și sinteze de informații, atunci vorbim de arhitectură de mediere . Cele Evenimentele arhitecturi orientate sunt , de asemenea , o parte din această categorie.

Arhitectură orientată obiect

Componentele sistemului ( obiecte ) integrează datele și operațiunile de prelucrare a acestor date. Comunicarea și coordonarea dintre obiecte se realizează printr-un mecanism de transmitere a mesajelor. Arhitectura orientată obiect este adesea descris de către cei trei piloni: încapsulare , moștenire și polimorfism . Incapsularea se referă la arhitectura detaliată a fiecărui obiect, datele fiind protejate de accesul direct de către un strat de interfață. În plus, funcțiile secundare, inutile pentru a utiliza obiectul, sunt ascunse utilizatorului obiectului. Moștenirea face posibilă evitarea redundanței codului și facilitează extensibilitatea software-ului, funcționalitățile comune mai multor clase de obiecte fiind grupate împreună într-un strămoș comun. Polimorfismul face posibilă utilizarea diferitelor obiecte (având comportamente distincte) într-un mod identic, această posibilitate se realizează prin definirea interfețelor care urmează a fi implementate (clase abstracte).

Arhitectură orientată către agenți

De Agenții SOA reprezintă o paradigmă în care obiectul , componenta pasiv, devine o componentă proiectiv:

Într-adevăr, în proiectarea obiectelor , obiectul este în esență o componentă pasivă, oferind servicii și folosind alte obiecte pentru a-și atinge funcționalitățile; arhitectura obiectului este deci doar o extensie a arhitecturii în apeluri și retururi, programul poate fi scris în așa fel încât să rămână determinist și previzibil.

Agentul software , pe de altă parte, folosește într-o manieră relativ autonomă, cu propria capacitate de execuție, ceilalți agenți pentru a-și atinge obiectivele: stabilește dialoguri cu ceilalți agenți, negociază și schimbă informații, decide în fiecare moment cu care agenții să comunice în funcție de nevoile lor imediate și de disponibilitatea altor agenți.

Istoric

1960-1970

Originea conceptului de arhitectură software datează de la sfârșitul anilor 1960 cu inventarea programării structurate . Un program de computer a fost apoi conceptualizat ca o serie de pași (fluxul de control) reprezentat de primele diagrame arhitecturale, diagramele de flux ( diagramele de flux ). La începutul anilor 1970, odată cu dezvoltarea programării modulare , programele de calculator erau privite ca seturi de componente ( module ) care schimbă informații. În diagramele de flux de date au fost apoi utilizate pentru a reprezenta acest tip de arhitectură.

1964, crearea Simula-I
1967, crearea Simula-67

1970-1980

În deceniul 1970–80 au fost dezvoltate principalele principii arhitecturale. S-a făcut o distincție între arhitectura sistemului care descrie relațiile și interacțiunile tuturor componentelor software și arhitectura detaliată care descrie arhitectura individuală a fiecăreia dintre componente . Arhitectura statică este separată temporar invariant descriind relațiile (dependențe funcționale, controlul fluxului, fluxul de date) ale arhitecturii dinamice, descriind interacțiunile și evoluția sistemului în timp ( diagrame de activitate , secvență , stări , rețele Petri etc.) ). Tot în acest deceniu s-au dezvoltat principiile directoare ale arhitecturii software contemporane: mascarea informațiilor , independență funcțională , coeziune puternică și cuplare slabă. De asemenea, au fost create principalele stiluri arhitecturale: apeluri și returnări de arhitectură ( ierarhie de control ) centrate pe date de arhitectură , flux de date de arhitectură , arhitectură stratificată și obiecte de arhitectură orientate .

Evenimente importante

1970, EF Codd publică: " Un model relațional de date pentru bănci mari de date partajate ", ACM, Vol. 13, n o 6, pp. 377-387 .
1971, N. Wirth creează limbajul Pascal . „ Limbajul de programare Pascal ”, Acta Informatica , n o 1, pp. 35-63 . În același an, a publicat „ Program Development by Stepwise Refinement ”, Comm. ACM, voi. 14, n o 4, pp. 221-227 .
1972, O. Dahl, E. Dijkstra și C. Hoare publică: „ Structured Programming ”, Academic Press.
1973, JB Dennis publică: Modularity , In 4dvanced Course in Software Engineering, F. Bauer, Ed., Springer-Verlag, Berlin.
1974, IBM definește limbajul SEQUEL ( Structured English Query Language ) și îl implementează pe prototipul SEQUEL-XRM.
1975, MA Jackson. Publică: „ Principiile proiectării programelor ”, Academic Press.
1976-77, IBM a revizuit SEQUEL numit SEQUEL / 2 și a fost definit numele SQL .
În 1979, Relational Software și-a introdus produsul Oracle V2 ca sistem de gestionare a bazelor de date relaționale . Această versiune implementează un limbaj SQL de bază ( interogare și alăturare ).
1979, E. Yourdon și LL Constantine publică: „ Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design ”, Prentice Hall.

1980 - 1990

Deceniul 1980-90 a fost cel al dezvoltării arhitecturii orientate obiect. Acest tip de arhitectură a introdus trei noi tipuri de componente software: obiect , clasă și meta-clasă ; precum și relațiile ontologice dintre aceste componente: este o (moștenire), este compusă din (compoziție) etc. Relația de moștenire este o inovație majoră care permite reutilizarea codului și facilitează adaptarea acestuia la alte contexte de utilizare.

Pe de altă parte, la nivel industrial, acest deceniu este, fără îndoială, cel al arhitecturii în trei straturi axate pe date ( 3 niveluri ). Acest tip de arhitectură software, separând arhitectura programelor de arhitectura datelor, este astfel complet opusă principiului coeziunii puternice susținut de arhitectura obiectului. Se pune accent pe arhitectura datelor; diagramele acestui tip de arhitectură sunt modele conceptuale de date și diagrame de relații de entitate. Dezvoltarea sistemelor de gestionare a bazelor de date relaționale , a protocoalelor multibază și a normalizărilor ( standardizărilor ) acestora constituie bazele tehnologice ale acestei alegeri arhitecturale.

Evenimente importante

1983, Grady Booch publică: „ Inginerie software cu Ada ”, Benjamin Cummings.
1983, Relational Software devine Oracle Corporation și introduce Oracle V3 (suport pentru tranzacții).
1983-1985, Bjarne Stroustrup dezvoltă C ++ la Laboratorul Bell.
1984, U. Dayal și H. Hwang publică: „ Vizualizați definiția și generalizarea pentru integrarea bazelor de date în MULTIBASE: Un sistem pentru baze de date distribuite eterogene ”, IEEE Trans, Software Engineering, SE-10, No. 6, 628-644.
În 1986, SQL a fost adoptat de American Standards Institute ( ANSI ), apoi ca standard internațional de ISO (ISO / IEC 9075).
În 1987, Ivar Jacobson a fondat Objectory Systems pentru a-și vinde metoda de dezvoltare: ObjectOry
1990, AP Sheth și JA Larson publică: „ Sisteme de baze de date federate și gestionarea bazelor de date distribuite, eterogene și autonome ”. Sondaje de calcul ACM.

1990 - 2000

La începutul deceniului 1990-2000 exista un număr foarte mare de reprezentări arhitecturale distincte. Apărut în 1995 , UML ( Unified Modeling Language ) a devenit în 2007 un standard internațional (ISO / IEC 19501) utilizat în special pentru reprezentarea arhitecturii software. Odată cu răspândirea dezvoltării orientate pe obiecte în industrie, sistemele de gestionare a bazelor de date sunt acum văzute ca o modalitate convenabilă de a asigura persistența obiectelor. Obiectivele și sistemele de gestionare a bazelor de date relaționale își fac apariția. De asemenea, vedem apariția arhitecturilor distribuite; programele de calculator nu mai sunt privite pur și simplu ca oferind servicii ființelor umane, ci și altor programe. Sosirea rețelelor deschise, în special a internetului , schimbă complet peisajul arhitectural. Arhitectura cu trei nivele (3 nivele) centrată pe date este acum realizată de serverul de baze de date , serverul de aplicații web și tripletul browserului web .

Cercetările universitare privind arhitectura software se concentrează mai mult pe problemele de cuplare între obiecte și interoperabilitatea sintactică și semantică. Problema cuplării este percepută în esență ca o problemă de comunicare între obiecte, chiar și de dialoguri între agenți inteligenți ; apare arhitectura orientată către agent. Principiul reutilizării componentelor software este acum aplicat arhitecturii. Modurile de a face lucruri, principiile sau stilurile arhitecturale pot fi refolosite; de modelele de design apar.

Evenimente importante

1992, Gio Wiederhold publică: „ Mediatorii în arhitectura sistemelor informaționale viitoare ”, IEEE Computer Magazine
1994, definiția modernă a agentului software este acceptată de comunitatea științifică: „ Problemă specială privind serviciile inteligente. », Comunicarea ACM.
1994, Sun Microsystems lansează limbajul Java de programare a obiectelor pure .
1995, se naște UML (OOPSLA'95).
1995, Gamma și colab. publicați: „ Modele de proiectare: elemente ale software-urilor reutilizabile orientate pe obiecte ”, Addison-Wesley.
1998, W3C recomandă limbajul etichetei XML.

2000 - 2010

Acest deceniu se caracterizează printr-o revenire a bazelor de date distribuite , posibilă datorită tehnologiilor XML . XML este un set de reguli pentru reprezentarea și structurarea datelor, este o restricție a SGML . Aceste date pot fi normalizate sintactic, iar flexibilitatea tehnologiei face posibilă exprimarea diferitelor semantici. Arhitectura tradițională pe 3 niveluri poate fi găsită sub forma a trei straturi de medieri de date: gestionarea datelor XML, transformarea și fuziunea datelor XML și prezentarea datelor XML. Tehnologia XML permite specificarea sintaxei ( DTD , XSD ), transformarea ( XSLT ), prezentarea ( XSL ) și specificația semantică ( RDF , RDFS , OWL ). Există biblioteci software pentru gestionarea datelor XML, iar majoritatea sistemelor de gestionare a bazelor de date acceptă acum XML.

Acest nou tip de arhitectură este opus vizualizării centralizate a datelor găsite într-o arhitectură tradițională centrată pe date (cum ar fi „ datawarehouse ” promovată de IBM ). Această formă de arhitectură se numește mediere de date , se caracterizează prin:

Prelucrarea inteligentă a informațiilor (date care susțin un nivel ridicat de abstractizare și generalizare).
Accesul și integrarea mai multor surse de informații.
O transformare dinamică a fluxului de informații de către filtre și traducători.
Existența unor directoare și baze de informații inteligente precum cataloage.
Gestionarea incertitudinii asociate cu datele lipsă sau incomplete și datele slab înțelese.
Gestionarea explicită a interoperabilității semantice datorită ontologiilor și domeniilor generale.

Dezvoltarea orientată către agenți (OA) iese treptat din universități, există o multitudine de instrumente software pentru proiectarea sistemelor bazate pe agenți, dar majoritatea nu sunt încă destinate să devină instrumente de producție. Limbajul KQML (Knowledge Query and Manipulation Language) este un limbaj de comunicare inter-agent care ar putea deveni foarte bine esențial în viitorul apropiat. Nu va exista nicio revoluție în limbajele de programare, diferitele funcționalități ale agenților sunt implementate folosind biblioteci software. Cele trei tipuri de arhitecturi OA care apar sunt: arhitectura atentă , arhitectura reactivă și arhitectura hibridă .

Instrumente

Azuki - Java framework cu scopul de a separa preocupările.
BoUML - Modelator UML multi -platform open source compatibil cu standardul UML 2.0 capabil de inginerie inversă
IBM Rational - Produsul celor trei prieteni fondatori ai UML
Silverrun - Un software de modelare pentru metoda Datarun, versiunea nord-americană a Merise.
Open ModelSphere - Modelarea conceptuală și relațională a datelor, modelarea proceselor de afaceri și modelarea UML sub licență GPL.
Acceleo - Generator de coduri open source bazat pe Eclipse și EMF
Power Designer - Software de modelare pentru Merise, SGBD, UML, procese de afaceri, arhitectură Enterprise.
DocGen BOUML - plugin BOUML care permite generarea de documente de arhitectură, analiză și proiectare dintr-un model UML și filozofia OpenUP.
Papyrus - plug-in Eclipse pentru modelarea UML2, SysML și MARTE.
Obeo Designer - Atelier de modelare personalizat bazat pe platforma Eclipse și o abordare DSL
Capella - Un atelier de modelare pentru arhitecturi de sisteme, hardware și software.

Note și referințe

Pressman RS, Software Engineering: A Practitioner's Approach, ediția a treia. McGraw-Hill. Capitolul 4, p. 107, 1992.
„ ISO / IEC 25010: 2011 ” , pe ISO (accesat la 15 iulie 2019 )
(în) „ ISO / IEC 25010 ” pe iso25000.com (accesat la 15 iulie 2019 )
Yourdon E., Reutilizarea software-ului. Strategii de dezvoltare a aplicațiilor. zbor. 1, n0. 6, p. 28-33, iunie 1994.
David Garlan, Robert Allen, John Ockerbloom, Architectural Mismatch: Why Reuse Is So Hard , IEEE Software, noiembrie / dec. 1995
Perry DE, Wolf AL, Fundația pentru studiul arhitecturii software. ACM Software Eng. Note, p. 40-50, octombrie 1992
Philippe B. Kruchten, The 4 + 1 View Model of Architecture , IEEE Software, noiembrie 1995.
Jacobson I., Booch G., Rumbaugh J., Unified Software Development Process, ( ISBN 0-201-57169-2 )
(în) Enríquez, René , Arhitectură software cu primăvara 5. 0: Proiectare și arhitectură Aplicații Java extrem de scalabile, robuste și de înaltă performanță. , Packt Publishing Ltd,2018, 41-44 p. ( ISBN 978-1-78899-673-0 , OCLC 1053798657 , citit online )
Bass L., Clement P., Kazman R., Software Architecture in Practice, Addison-Wesley, 1998
David Garlan și Mary Shaw, Introducere în arhitectura software , CMU-CS-94-166, Școala de informatică, Universitatea Carnegie Mellon, ianuarie 1994
Wirth N., Program Development by Stepwise Refinement, CACM, vol. 14, nr. 4, 1971, pp. 221-227
„ OpenUP ” ( Arhivă • Wikiwix • Archive.is • Google • Ce să faci? ) .
[1] .
[2] .
[3] .