Limbajele de descriere a arhitecturii (ADLs) sunt limbaje formale care pot fi folosite pentru a descrie arhitectura unui sistem software puternic. Cum arhitectura devine o temă dominantă în sistemele de dezvoltare de mari dimensiuni, metodele clare de specificare a arhitecturii vor deveni indispensabile.
Prin arhitectură, înțelegem componentele care compun un sistem, specificațiile comportamentale ale acelor componente și șabloanele și mecanismele de interacțiune dintre ele. De notat că un sistem singular este compus de obicei din mai mult de un singur tip de componente: module, activități, funcționalități, etc. . O arhitectură poate alege tipul celor mai potrivite sau semnificative componente, sau poate include mai multe paradigme ale aceluiași sistem, fiecare ilustrând un set diferit de componente.
Până la acest moment, arhitecturile au fost descrise în general prin desene informale cerc-și-linie în care natura componentelor, a proprietăților lor, a semanticii conexiunilor și a comportamentului sistemului ca un întreg sunt slab (dacă nu deloc) definite. Deși astfel de desene oferă adesea o imagine intuitivă asupra construcției sistemului, ele adesea eșuează să răspundă la întrebări ca:
Ce sunt componentele? Sunt ele module care există doar la momentul descrierii, dar sunt compilate împreună înainte de momentul execuției? Sunt ele activități sau procese între-țesute din module diferite, asamblate la momentul compilării și formează unități funcționale la momentul execuției? Sau sunt ceva neclar ca "zone de funcționalitate", ca diagrame de flux de date sau ceva complet diferit?
Ce fac componentele? Cum se comportă? Pe ce alte componente se bazează?
Ce semnificație au conexiunile? Să însemne "trimite date spre", "trimite control spre", "apelează", "este parte din", o combinație a acestora sau complet altceva? Care sunt mecanismele folosite pentru a îndeplini aceste relații?
ADL-urile rezultă dintr-o abordare lingvistică a descrierii formale a arhitecturilor și din acest motiv ele abordează deficiențele descrierilor informale. ADL-urile sofisticate permit analiza timpurie și testarea precoce a fezabilității în deciziile de design.
O arhitectură joacă mai multe roluri în dezvoltarea unui proiect, toate importante și toate facilitate printr-o descriere formală a arhitecturii, cum ar fi un ADL. O descriere formală a arhitecturii este mai ușor de menținut și urmărit decât una informală, poate fi mai ușor consultată și tratată cu autoritate, și poate fi mai ușor transferată spre alte proiecte ca o componentă de bază. Rolurile includ:
Baza de comunicare: membrii echipei de proiect, managerii și clienții se vor adresa toți planului arhitectural ca bază pentru înțelegerea sistemului, dezvoltării lui și comportamentului lui pe perioada execuției.
Planul proiectului: Alegerea componentelor arhitecturale este instituționalizată în dezvoltarea structurii de echipă a organizației, repartizarea muncii, unitățile de management, structura programului de lucru, planurile de integrare, planurile de testare și procesele de mentenanță. Odată construit, o decizie de arhitectură are o durată de viață extrem de lungă și supraviețuiește chiar și în afara produsului pe care îl descrie.
Planul de dezvoltare a produsului. O arhitectură poate fi refolosită în alte sisteme pentru care este mai potrivită. Dacă este administrată cu grijă, o întreagă familie de produse poate fi produsă folosind o singură arhitectură. În acest caz, importanța unei arhitecturi potrivite este amplificată asupra tuturor produselor pe care le va deservi.
Încorporarea celor mai recente decizii de proiectare: arhitectura descrie prima translatare a cerințelor în componente computaționale. Selecția componentelor și conexiunilor, dar și alocarea funcționalităților fiecărei componente, este o codificare a celor mai recente decizii de proiectare legate de un proiect. Toate deciziile de proiectare ulterioare trebuie să fie consistente cu opțiunile arhitecturale. Astfel, deciziile arhitecturale sunt cel mai greu de schimbat și au cele mai extinse consecințe.
Unele ADL-uri oferă o oportunitate pentru analiza la nivelul arhitecturii, cum ar fi generarea automată de simulări, analiza planificării, și altele asemănătoare. Oricum, chiar și în absența capacității de analiză automată, asupra arhitecturii pot fi aplicate și alte strategii de evaluare. Totuși, aceste decizii timpurii de proiectare și atribute calitative de compromis pot fi testate înainte ca schimbarea lor să devină prea costisitoare.
Limbajul de Descriere a Arhitecturii (ADL) este definit ca "un limbaj (grafic, textual sau ambele) pentru descrierea unui sistem software din perspectiva elementelor sale arhitecturale și a relației dintre ele".
Cu alte cuvinte, ADL este un limbaj care permite formalizarea, descrierea, specificarea, modelarea arhitecturilor software. Fiecare dintre aceste aspecte ar trebui îndeplinite de un limbaj care se dorește a fi numit ADL. Un ADL bun trebuie să ofere abstractizări care sunt adecvate pentru modelarea unui sistem de mari dimensiuni. Fiecare ADL încorporează o abordare particulară a specificațiilor și evoluției arhitecturii.
Limbajul de Modelare Unificat (UML) este un limbaj formal grafic considerat standard de industrie de facto. Deși limbajul a fost creat ca limbaj grafic care inițial să asiste analiza și proiectarea software orientată obiect, limbajul a fost revizuit de câteva ori, iar azi este un limbaj formal generic, capabil să descrie un sistem software. UML are o sintaxă și semantică formală bine definite și poate fi verificată și procesată automat. UML include un set de tehnici de notare grafică pentru a crea modele abstracte ale anumitor sisteme.
Combinatorii de descriere arhitecturală din acest exemplu au fost proiectați pentru editorul Proxima de structura generică orientată spre prezentare. Proxima permite atât editarea structurii documentului cât și a prezentării sale. Din cauza complexității arhitecturii Proxima, vom vorbi despre o arhitectură cu un layer simplu pentru un editor orientat spre prezentare pentru a explica metode de descriere a arhitecturii.
Figura de mai sus arată fluxul de date pentru funcțiile layerului în tipul normalizat Simple. Definiția normalizării Simple este:
data Simple state map doc pres gest upd =
Simple { present :: LayerFn state doc
(map, state) pres
, interpret :: LayerFn (map, state) gest
state upd
}Cum diferă ADL-urile de limbajele de programare, limbajele de cerințe, limbajele de modelare și altele asemănătoare? Dat fiind un limbaj pentru exprimarea proprietăților sau comportamentelor unui sistem, care ar fi criteriile pentru a decide dacă este sau nu un ADL? Din păcate nu este clar.
În principiu, ADL-urile diferă de cerințele de limbaj, deoarece cele din urmă descriu spațiile problemei, respectiv celelalte își au rădăcinile în spațiul soluției.
În practică, cerințele sunt adesea împărțite în grupuri comportamentale pentru usurința prezentării, iar limbajele folosite în descrierea acelor comportamente sunt uneori mai potrivite pentru descrierea componentelor arhitecturale, chiar dacă acesta nu a fost scopul inițial al limbajului. De exemplu, Modechart, un limbaj de cerințe similar cu Statechart, a expus capacități analitice mai puternice decât majoritatea ADL-urilor datorită prezenței unui validator de model. Modechart a fost considerat a fi un ADL deoarece componentele sale (state machines) pot fi interpretate ca fiind componente arhitecturale. Dar Modechart nu a fost conceput să fie un ADL, deci este ușor de produs artefacte în Modechart care, în nicio interpretare semantică rezonabilă, nu corespund unei viziuni arhitecturale de sistem.
În principiu, ADL-urile diferă de limbajele de programare deoarece acestea din urmă conectează toate abstractizările arhitecturale cu soluțiile punctuale specifice în timp ce ADL-urile suprimă intenționat sau modifică o astfel de conexiune.
În practică, arhitectura este încorporată și recuperabilă din cod, și multe limbaje oferă viziuni asupra sistemului la nivelul arhitecturii. De exemplu, Ada oferă posibilitatea vizualizării sistemului doar din punctul de vedere a specificațiilor pachetului, respectiv a interfețelor componentelor. Oricum, Ada oferă capacități analitice la nivel de arhitectură puține sau deloc și nici nu oferă o perspectivă la nivel de arhitectură despre cum se inter-conectează componentele.
În principiu, ADL-urile diferă de limbajele de modelare deoarece cele din urmă sunt mai preocupate de comportamentele întregului decât de cele ale componentelor, în vreme ce ADL-urile se concentrează pe descrierea componentelor.
În practică, multe limbaje de modelare permit descrierea componentelor cooperante și pot descrie arhitecturi destul de bine.
Există doi cercetători de top care au oferit câteva caracteristici dezirabile pentru ADL-uri. Shaw enumeră următoarele proprietăți importante pe care un ADL ar trebui să le ofere:
abilitatea de a reprezenta componente (primitive sau compozite) alături de declararea proprietăților, interfețe și implementări;
abilitatea de a reprezenta conexiuni, împreună cu protocoale, declararea proprietăților și implementări;
abstractizări și incapsulări;
tipuri și verificări de tipuri;
Luckham enumeră urmatoarele cerințe pentru un ADL:
abstractizarea componentelor;
abstractizarea comunicării;
integritatea comunicării (limitarea comunicării la acele componente inter-conectate arhitectural);
abilitatea de a modela dinamic arhitecturi;
abilitatea de a raționa despre cauzalitate si timp;
sprijin în rafinarea ierarhică;
Aceste enumerări ilustrează puncte de vedere diferite despre ce înseamnă un ADL. Nu există o delimitare clară între ADL-uri și non-ADL-uri. Limbajele pot oricum să se deosebească prin cât de multe informații arhitecturale pot reprezenta. Limbajele concepute ca ADL-uri ne arată un avantaj clar sub acest aspect față de limbajele construite pentru un alt scop și convertite ulterior să descrie arhitecturi.
Analiza caracteristicilor este o unealtă cu metode de analiză a anumitor domenii, cum ar fi metoda Feature-Oriented Domain Analysis (FODA); funcționează prin catalogarea caracteristicilor de sistem vizibile la nivelul utilizatorului într-o manieră structurată.
Caracteristicile sunt structurate în următoarele trei categorii: caracteristici orientate spre sistem, caracteristici orientate spre limbaj și caracteristici orientate spre proces.
Caracteristicile orientate spre sistem sunt legate de sistemul aplicației derivat din descrierea arhitecturii. De exemplu, anumite ADL-uri s-ar putea să nu poată exprima constrângerile în timp real despre componentele arhitecturale ale sistemului, în timp ce altele pot. Toate caracteristicile din această categorie sunt proprietăți ale unui sistem finalizat; oricum, ele se reflectă asupra capacității ADL-ului să exprime sau descrie respectivele proprietăți la nivelul arhitecturii.
Caracteristicile orientate spre limbaj sunt caracteristici ale ADL-ului însuși, independent de sistemul pentru construcția căruia este folosit. Aceste proprietăți includ acel tip de informații care se regăsesc de obicei într-un manual de referință al limbajului. Un exemplu este cât de formal este specificată sintaxa și semantica ADL-ului, și ce abstractizări sunt încorporate în ADL.
Caracteristicile orientate spre proces sunt caracteristici ale unui proces în legatură cu folosirea ADL-ului pentru a crea, valida, analiza și rafina o descriere arhitecturală, și construirea unui sistem de aplicație din el. Sunt incluse proprietăți care măsoară sau descriu cum sau în ce măsură un ADL permite evaluarea predictivă a sistemului aplicației, în baza informațiilor de la nivelul arhitecturii. Aceste proprietăți măsoară dacă un ADL conține sau nu suficiente informații pentru a face arhitectura analizabilă, indiferent dacă există cu adevărat uneltele care exploatează respectiva competență.
De exemplu, un ADL ar putea permite suficiente informații temporale care să fie oferite pentru a asista analiza planificării. Un analizor (dacă există pentru ADL) ar fi un exemplu de unealtă care exploatează o astfel de informație.
Arhitectura, în contextul sistemelor software, este împărțită în arhitectura softului, arhitectura rețelei și arhitectura sistemului. În fiecare categorie există o distincție tangibilă dar neclară între arhitectură și design.
Designul este abstractizarea și specificarea șabloanelor și componentelor de funcționalitate care au fost sau vor fi implementate. Arhitectura este un nivel superior atât în abstractizare cât și în granularitate.
Arhitectura se realizează în timpul conceptualizării unei aplicații, a unui sistem sau a unei rețele și ar putea apărea în secțiunile non-funcționale ale documentației cerințelor. Canonic, designul nu este specializat în cerințe, dar mai degrabă influențată de ele.
Procesul definirii unei arhitecturi poate implica euristici, cerute de arhitect sau echipa de arhitecți prin experiența domeniului. Ca și în cazul designului, arhitectura evoluează adesea printr-o serie de iterații.
Bharathi B., Sridharan D.; "UML as an Architecture Description Language", International Journal of Recent Trends in Engineering, Vol. 1, No. 2, May 2009
Kang, Kyo C.; Cohen, Sholom G.; Hess, James A.; Novak, William E.; & Peterson, A. Spencer. "Feature Oriented Domain Analysis (FODA)", Feasibility Study (CMU/SEI-90-TR-21, ADA235785). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, November 1990
Paul C. Clements; "A Survey of Architecture Description Languages", Software Engineering Institute, Carnegie Mellon University, March 1996