Википедија

Arhitektonsko opisni jezik

Arhitektonsko opisni jezici (AOJ) se koriste u raznim disciplinama: sistemskom inženjeringu, softverskom inženjeringu, preduzetnom modelovanju i inženjeringu.

Zajednica sistemskog inženjeringa koristi arhitektonski opisni jezik kao jezik i/ili konceptualni model da opiše i predstavi sistemske arhitekture

Zajednica sistemskog inženjeringa koristi arhitektonski opisni jezik kao  programski jezik za kreiranje opisa softverske arhitekture. U slučaju takozvane tehničke arhitekture, arhitektura mora da bude saopštena softverskim programerima; funkcionalna arhitektura je saopštena  raznim akterima i korisnicima. Neki AOJi koji su razvijeni su: Akmi (razvio je Univerzitet Karnegi Melon), AADJ (standardizovan od strane UAI), C2 (razvije on stane Univerziteta Kalifornije), SBC-AOJ (razvijen od strane Nacionalnog Sun Jat-Sen univerziteta), Darvin (razvijen od strane carskog koledža London), i Rajt (razvijen od strane CMU).

Aktuelna lista arhitektonskih programskih jezika se moze naći na Up-to-date list of ADLs.

ISO/IEC/IEEE 42010[1] dokument, Systems and software engineering—Architecture description, definiše arhitektonski opisni jezik kao "bilo kakva forma izraza za korišćenje  u arhitektonskim opisima" i specifiše minimalne zahteve za AOJe.

Zajednica preduzetnog modelovanja i inženjeringa je takođe razvila arhitektonsko opisne jezike pravljene na preduzetnom nivou. Primeri uključuju ArhiMejt (sada standard od Otvorene grupe), DEMO, ABAKUS (razvijen od strane Univerziteta tehnologije, Sidnej). Ovi jezici se ne odnose obavezno na softverske komponente, itd. Većina njih, ipak, odnosi aplikacisku arhitekturu koja je saopštne softverskim inženjerima.

Većina napisanog ispod se primarno odnosi na perspektivu zajednice softverskih inženjera.

Uvod

uredi

Standardna notacija (AOJ) za predstavljanje arhitektura pomaže u promociji uzajamne komunikacije, otelovljenja ranijih dizajnerskih odluka, i kreaciji transferne apstrakcije sistema. Arhitekture su u prošlosti uglavnom predstavljene od strane kutija-i-linija crteža obeleženih sa stvarima kao što su priroda sastavnog dela, svojstva, semantike veza, i opšte sistemsko ponašanje. AOJi rezultuju od lingvističkog pristupa formalnoj reprezentaciji arhitektura, i kao takvi oni adresuju njene manjkavosti. Takođe bitno, sofisticirani AOJi dozvoljavaju ranu analizu i testiranje izvodljivosti arhitektonskih dizajnerskih odluka.

Istorija

uredi

AOJi su bili clasificirani u tri široke kategorije: kutija-i-linija neformalni crteži, formalni arhitektonski opisni jezik, i UML-bazirane oznake.

Kutija-i-linija je bila najpreovlađujuće sredstvo za opisivanje SAa. Dok je pružala korisne dokumentacije, nivo neformalnosti je ograničio korisnost arhitektonskog opisa. Rigorozniji način opisivanja Sae je bio potreban. Citat Alena i Garlana (1997),[2] "iako ovi [kutija-i-linija] opisi mozda obezbeđuju korisnu dokumentaciju, sadašnji nivo neformalnosti ograničava njihovu korisnost. Kako je generalno nepreciszno šta se misli sa ovakvim arhitektonskim opisima, možda je nemoguće analizirati arhitekturu za doslednost ili odrediti ne-trivijalna njihova svojstva. Štaviše, ne postoji način da se proveri da su sistemske implementacije doslednesvojem arhitektonskom dizajnu." Sličan je zaključak u Periju i Vulfu (1992),[3] koji izveštava da: "Pored toga što pruža čistu i preciznu dokumentaciju, primarna svrha specifikacija je da obezbeđuju automatizovanu analizu dokumenata i da izloži razne vrste problema koji inače ne bi bili pronađeni."

Od tad, niz istraživanja na formalnim jezicima za SA opis je bio izvršen. Desetine formalnih AOJa su bili predloženi, svaki karakterizovan sa različitim konceptualnim arhitektonskim elementima, različitom sintaksom i semantikom, fokusirajući se na specifičnu operacijsku oblast, ili samo pogodan za različite analitičke tehnike. Na primer, oblasno specifični AOJi su bili predstavljeni da se nose sa igrađenim i stvarno vremenskim sistemima (kao što su AADJ,[4] EAST-AOJ,[5] and EADL[6]) i EAOJ[6]), aplikacijama kontrolne petlje (DiaSpek[7]), arhitekturama linija proizvoda (Koala[8]), i dinamičkim sistemima (P-AOJ[8]). Analizno specifični AOJi su bili pretpostavljeni da se nose sa dostupnošću, pouzdanošću, bezbednošću, resursnom potrošnjom, kvalitetom podataka i analizom učinka u stvarnom vremenu (AADJ, analiza ponašanja (Fraktal[9])), i analizom pouzdanosti (PAOJ[10])

Ipak, ovi napori nisu videli željeno usvajanje u industrijskoj praksi. Neko od razloga za nedostatak industrijskog usvajanja su bili analizirani od strane Vudsa i Hilarda,[11] Pandej,[12] Klement,[13] i drugi: formalni AOJi su bili retko integrirani u softverski životni ciklus, oni su retko podržani od strane starijih alata, jedva dokumentovani, fokusirajući se na veoma specifične potrebe, i ne ostavljajući nimalo prostora za nastvake koji omogućavaju dodavanje novih karakteristika.

Kao način da se prevaziđu neka od ovih ograničenja, UML je bio pokazan kao mogući snaslednik postojeći AOJa. Mnogi predlozi su bili predstavljeni da koriste ili nadograđuju UML na više propisan model softverskih arhitektura.[14][15]

U stvari, kao što je naglašeno u skorašnjoj studiji sprovedenoj sa praktikantima,[16]

Karakteristike

uredi

Postoji velika raznovrstnost u AOJima rezvijenih od strane ili akademskih ili industrijskih grupa. Mnogi jezici nisu namenjeni da budu AOJi, ali su ispali pogodni za predstavljanje i analizu arhitekture. U principu, AOJi se razlikuju od jezika zahteva, zato što su AOJi ukorenjeni u prostoru rešenja, dok zahtevi opisuju porblemske prostore. Oni se razlikuju od porgramskih jezika, zato što AOJi ne vezuju arhitektonske apstrakcije za specifična smisaona rešenja. Modelarski jezici predstavljaju ponašanja, dok se AOJi fokusiraju na predstavljanje dokumenta. Ipak, postoje oblasno specifični modelarski jezici (OSMJ) koji se fokusiraju na predstavljanje dokumenata.

Minimalni zahtevi

Jezik mora:

  • Da bude pogodan za komunikaciju arhitekture između svih zainteresovanih strana
  • Da podržava zadatke arhitektonske kreacije, prefinjenost i validaciju
  • da obezbeđuje bazu za dalje implementacije, tako da mora da bude u stanju da dodaje inforamcije AOJoj specifikaciji da bi omogućila da finalna sistemska specifikacija bude izvedena is AOJa
  • Da obezbedi sposobnost predstavljanja većine uobičajenih arhitektonskih stilova
  • Da podržava analitičke sposobnosti ili da obezbedi brzo generisanje prototipskih implementacija

AOJi imaju zajedničku:

  • Grafičku sintaksu sa često tekstualnom formom i zvanično definisanu sintaksu i semantiku
  • Karakteristike za modelovanje distribiranih sistema
  • Malu podršku za hvatanje dizajn informacija, osim kroz mehanizme opšte svrhovne anotacije
  • Sposobnost za predstavljanje hijerarhiskih nivoa detalja uključujući i kreaciju substruktura instalacijom šablona

AOJi se razlikuju u njihovoj sposobnosti da:

  • Se nose sa stvarno vremenskim konstukcijama, kao što su rokovi priorizacija zadataka, na arhitektonskom nivou
  • Podržavaju specifikaciju drugog arhitektonskogsila. Malo njih mogu da se nose sa nasleđem objektno orijentisane klase ili sa dinamikom arhitektura
  • Podržavaju analizu arhitekture
  • Se nose sa različitim instrukcijama iste arhitekture, u vezi sa arhitekturama proizvodne linije

Pozitivni elementi AOJa

uredi
  • AOJi su formatizovan način prikazivanja arhitekture
  • AOJi su namenjeni da budu i ljudsko i mašinsko čitljivi
  • AOJi podržavaju opisivanje sistema na većem nivou nego što je prethodno bilo moguće
  • AOji dozvoljavaju analizu i procenu arhitekture, radi celovitosti, doslednosti, dvosmislenosti, i performansi
  • AOji mogu da podržavaju automatsko generisanje softverskih sistema

Negativni elementi AOJa

uredi
  • Ne postoji univerzalni odgovor o tome šta bi AOJi trebalo da predstavljaju, posebno što se tiče ponašanja arhitekture
  • Prikazi koji se trenutno koriste su relativno teški da se rasčlane i nisu podrživi od strane komercijalnih alatki
  • Većina AOja teče da budu vertikalno optimizovani ka posebnoj vrsti aanalize

Uobičajeni koncepti arhitekture

uredi

Zajednica AOJa se generalno slaže da su Softverske arhitekture set komponenata i veza između njih. Ali postoje različiti vrste arhitektura kao što su:

Arhitektura predmetnih veza

uredi
  • konfiguracija se sastoji od interfejsova i veza objektno-orijentisanog sistema
  • interfejsovi specifišu karakteristike koje moraju da budu obezbeđene od strane modula u skladu sa interfejsom
  • Veze se predstavljaju od strane interfejsa zajedno sa pozivnim grafikom
  • Usklađenosti su obično podstaknute programskim jezikom
    • Razlaganje— vezati interfejs sa unikatnim modulima
    • Usklađenost interfejsa — statična provera sintaksnih pravila
    • Komunikacisjki integritet — vidljivost između modula

Arhitektura interfejsnih veza

uredi
  • Objašnjava ulogu interfejsova i veza
    • Interfejsi specifišu i "potrebne" i "obezbeđene" karakteristike
    • Veze se definišu između "potrebnih" karakteristika i "obezbeđenih" karakteristika
  • sadrži se od interfejsa, veza i ograničenja
    • Ograničenja ograničavaju ponašanje interfejsa i veza u arhitekturi
    • Ograničenja u arhitektonskoj mapi za zahteve sistema

Većina AOja implementuju interfejsnu veznu arhitekturu.

Arhitektura protiv dizajna

uredi

Arhitektura, u kontekstu softverskih sistema, je grubo podenjena u kategorije, primarne softverske arhitekture, arhitekture mreže, i sistemske arhitekture. U svakoj od ovih kategorija, postoji opipljiva ali nejasna razlika između arhitekture i dizajna. Da bi se izvukla razlika što univerzalnija i jasnija, najbolje je uzeti dizajn u obzir kao imenicu a ne kao glagol, tako da je to poređenje dve imenice.

Dizajn je apstrakcija i specifikacija šablona i organa funkcionalnosti koji su bili ili će biti implementirani. Arhitektura je većeg stepena i u apstrakciji i u granulaciji. shodno tome, arhitektura je takođe više topološka u prirodi nego u dizajnu, u smislu da precizira gde se veliki komponenti susreću i kako se odnose jedni na druge. Arhitektura se fokusira na podelu velikih regija funkcionalnosti u komponente visokog nivoa, gde oni fizički ili virtuelno stanuju, koje sa-police komponente mogu biti uposlene efektno, generalno koje će pojedinačno svaki interfejsov komponent izložiti, koji protokoli će biti uposljeni između njih, i koje prakse i koji će šabloni visokog nivoa moći najbolje da se susretnu sa rastegljivošću, održivošću, pouzdanošću, trajnosti, skalabilnosti, i drugim ne funkcionalnim ciljevima. Dizajn je detaljisanje ovih izbora i konkretnija klasifikacija o tome kako će se funkcionalni zahtevi susresti tokom delegacije delova od te funkcionalnosti do više granularnih komponenti i kako će ovi manji komponenti biti organizovani unutar većih.

Mnogo puta, deo arhitekture je urađen tokom konceptulizacije aplikacije, sistema, ili mreže i može da se pojavi u ne funkcionalnim delovima zahtevne dokumentacije. kanonski, dizajn nije specifiziran u zahtevima, ali je vođen njima.

Proces definisanja arhitekture može uključivati heuristiku, stečenu od strane arhitekte ili arhitektonskog tima kroz iskustvo stečeno u oblasti. Kao i dizajn, arhitektura često evoluira kroz niz iteracija, i kao što je mudrost dizajna visokog nivoa često testirana kada nastane nizak nivo dizajna i implementacije, mudrost arhitekture je testirana u toku specifikacije dizajna visokog nivoa. U oba slučaja, ako se mudrost specifikacije dovodi u pitanje tokom detaljisanja, druga iteracija, arhitekture ili dizajna, može biti neophodna.

Da rezimiramo, primarne razlike između arhitekture i dizajna su one od granularnosti i apstrakcije, i (sledstveno) hronologiji. (Arhitektura generalno prethodi dizajnu, iako je preklapanje i cirkularna iteracija česta realnost.)

Primeri

uredi

Lista ispod daje kandidate za najboljeg AOJa do sada.

Za aktuelnu listu trenutno postojećih arhitektonskih jezika, molimo vas uputite se na Up-to-date list of ADLs.

Pristupi arhitekturi

uredi

Pristupi arhitekturi

  • Akademski pristup
    • fokus na analitičku procenu arhitektonskih modela
    • individualni modeli
    • rigorozne modularne oznake
    • snažne analitičke tehnike
    • dubina pre širine
    • specijalno-svrhovna rešenja
  • Industrijski pristup
    • fokusira se naširok raspon razvojnih problema
    • porodice modela
    • praktičnost pre rigoroznosti
    • arhitektura kao velika slika u razvoju
    • širina preko dubine
    • generalno-svrhovna rešenja

Vidi još

uredi

Reference

uredi
  1. ^ „Arhivirana kopija” (PDF). Arhivirano iz originala (PDF) 26. 04. 2012. g. Pristupljeno 30. 11. 2015. 
  2. ^ Allen, R.; Garlan, D. (1997). „A formal basis for architectural connection”. ACM Transactions on Software Engineering and Methodology. 6 (3): 213. doi:10.1145/258077.258078. 
  3. ^ Perry, D. E.; Wolf, A. L. (1992). „Foundations for the study of software architecture” (PDF). ACM SIGSOFT Software Engineering Notes. 17 (4): 40. doi:10.1145/141874.141884. 
  4. ^ „AADL”. 
  5. ^ „AADL”. 
  6. ^ a b Li, J.; Pilkington, N. T.; Xie, F.; Liu, Q. (2010). „Embedded architecture description language”. Journal of Systems and Software. 83 (2): 235. doi:10.1016/j.jss.2009.09.043. 
  7. ^ „AADL”. Arhivirano iz originala 01. 06. 2013. g. Pristupljeno 30. 11. 2015. 
  8. ^ a b Van Ommering, R.; Van Der Linden, F.; Kramer, J.; Magee, J. (2000). „The Koala component model for consumer electronics software”. Computer. 33 (3): 78. doi:10.1109/2.825699. 
  9. ^ Bruneton, E.; Coupaye, T.; Leclercq, M.; Quéma, V.; Stefani, J. B. (2006). „The FRACTAL component model and its support in Java”. Software: Practice and Experience. 36 (11–12): 1257. doi:10.1002/spe.767. 
  10. ^ „TADL”. 
  11. ^ Woods, E.; Hilliard, R. (2005). „Architecture Description Languages in Practice Session Report”. 5th Working IEEE/IFIP Conference on Software Architecture (WICSA'05). str. 243. ISBN 978-0-7695-2548-8. doi:10.1109/WICSA.2005.15. 
  12. ^ Pandey, R. K. (2010). „Architectural description languages (ADLs) vs UML”. ACM SIGSOFT Software Engineering Notes. 35 (3): 1. doi:10.1145/1764810.1764828. 
  13. ^ Clements, P. C. (1996). „A survey of architecture description languages”. Proceedings of the 8th International Workshop on Software Specification and Design. str. 16—00. ISBN 978-0-8186-7361-0. doi:10.1109/IWSSD.1996.501143. 
  14. ^ „Garlan_TR”. 
  15. ^ Pérez-Martínez, J. E.; Sierra-Alonso, A. (2004). „UML 1.4 versus UML 2.0 as Languages to Describe Software Architectures”. Software Architecture. Lecture Notes in Computer Science. 3047. str. 88. ISBN 978-3-540-22000-8. doi:10.1007/978-3-540-24769-2_7. 
  16. ^ Malavolta, Ivano; Lago, Patricia; Muccini, Henry; Pelliccione, Patrizio; Tang, Antony (2013). „What Industry Needs from Architectural Languages: A Survey”. IEEE Transactions on Software Engineering. 39 (6). doi:10.1109/TSE.2012.74. 

Literatura

uredi
  • Woods, E.; Hilliard, R. (2005). „Architecture Description Languages in Practice Session Report”. 5th Working IEEE/IFIP Conference on Software Architecture (WICSA'05). str. 243. ISBN 978-0-7695-2548-8. doi:10.1109/WICSA.2005.15. 

Spoljašnje veze

uredi
Preuzeto iz „https://sr.wikipedia.org/w/index.php?title=Архитектонско_описни_језик&oldid=26814326”