Архитектонско описни језик

С Википедије, слободне енциклопедије

Архитектонско описни језици (АОЈ) се користе у разним дисциплинама: системском инжењерингу, софтверском инжењерингу, предузетном моделовању и инжењерингу.

Заједница системског инжењеринга користи архитектонски описни језик као језик и/или концептуални модел да опише и представи системске архитектуре

Заједница системског инжењеринга користи архитектонски описни језик као  програмски језик за креирање описа софтверске архитектуре. У случају такозване техничке архитектуре, архитектура мора да буде саопштена софтверским програмерима; функционална архитектура је саопштена  разним актерима и корисницима. Неки АОЈи који су развијени су: Акми (развио је Универзитет Карнеги Мелон), ААДЈ (стандардизован од стране УАИ), Ц2 (развије он стане Универзитета Калифорније), СБЦ-АОЈ (развијен од стране Националног Сун Јат-Сен универзитета), Дарвин (развијен од стране царског колеџа Лондон), и Рајт (развијен од стране ЦМУ).

Актуелна листа архитектонских програмских језика се мозе наћи на Up-to-date list of ADLs.

ISO/IEC/IEEE 42010[1] документ, Systems and software engineering—Architecture description, дефинише архитектонски описни језик као "било каква форма израза за коришћење  у архитектонским описима" и специфише минималне захтеве за АОЈе.

Заједница предузетног моделовања и инжењеринга је такође развила архитектонско описне језике прављене на предузетном нивоу. Примери укључују АрхиМејт (сада стандард од Отворене групе), ДЕМО, АБАКУС (развијен од стране Универзитета технологије, Сиднеј). Ови језици се не односе обавезно на софтверске компоненте, итд. Већина њих, ипак, односи апликациску архитектуру која је саопштне софтверским инжењерима.

Већина написаног испод се примарно односи на перспективу заједнице софтверских инжењера.

Увод[уреди | уреди извор]

Стандардна нотација (АОЈ) за представљање архитектура помаже у промоцији узајамне комуникације, отеловљења ранијих дизајнерских одлука, и креацији трансферне апстракције система. Архитектуре су у прошлости углавном представљене од стране кутија-и-линија цртежа обележених са стварима као што су природа саставног дела, својства, семантике веза, и опште системско понашање. АОЈи резултују од лингвистичког приступа формалној репрезентацији архитектура, и као такви они адресују њене мањкавости. Такође битно, софистицирани АОЈи дозвољавају рану анализу и тестирање изводљивости архитектонских дизајнерских одлука.

Историја[уреди | уреди извор]

АОЈи су били цласифицирани у три широке категорије: кутија-и-линија неформални цртежи, формални архитектонски описни језик, и УМЛ-базиране ознаке.

Кутија-и-линија је била најпреовлађујуће средство за описивање САа. Док је пружала корисне документације, ниво неформалности је ограничио корисност архитектонског описа. Ригорознији начин описивања Сае је био потребан. Цитат Алена и Гарлана (1997),[2] "иако ови [кутија-и-линија] описи мозда обезбеђују корисну документацију, садашњи ниво неформалности ограничава њихову корисност. Како је генерално непрецисзно шта се мисли са оваквим архитектонским описима, можда је немогуће анализирати архитектуру за доследност или одредити не-тривијална њихова својства. Штавише, не постоји начин да се провери да су системске имплементације доследнесвојем архитектонском дизајну." Сличан је закључак у Перију и Вулфу (1992),[3] који извештава да: "Поред тога што пружа чисту и прецизну документацију, примарна сврха спецификација је да обезбеђују аутоматизовану анализу докумената и да изложи разне врсте проблема који иначе не би били пронађени."

Од тад, низ истраживања на формалним језицима за СА опис је био извршен. Десетине формалних АОЈа су били предложени, сваки карактеризован са различитим концептуалним архитектонским елементима, различитом синтаксом и семантиком, фокусирајући се на специфичну операцијску област, или само погодан за различите аналитичке технике. На пример, обласно специфични АОЈи су били представљени да се носе са играђеним и стварно временским системима (као што су ААДЈ,[4] ЕАСТ-АОЈ,[5] and EADL[6]) и ЕАОЈ[6]), апликацијама контролне петље (ДиаСпек[7]), архитектурама линија производа (Коала[8]), и динамичким системима (П-АОЈ[8]). Анализно специфични АОЈи су били претпостављени да се носе са доступношћу, поузданошћу, безбедношћу, ресурсном потрошњом, квалитетом података и анализом учинка у стварном времену (ААДЈ, анализа понашања (Фрактал[9])), и анализом поузданости (ПАОЈ[10])

Ипак, ови напори нису видели жељено усвајање у индустријској пракси. Неко од разлога за недостатак индустријског усвајања су били анализирани од стране Вудса и Хиларда,[11] Пандеј,[12] Клемент,[13] и други: формални АОЈи су били ретко интегрирани у софтверски животни циклус, они су ретко подржани од стране старијих алата, једва документовани, фокусирајући се на веома специфичне потребе, и не остављајући нимало простора за настваке који омогућавају додавање нових карактеристика.

Као начин да се превазиђу нека од ових ограничења, УМL је био показан као могући sнаследник постојећи АОЈа. Многи предлози су били представљени да користе или надограђују УМЛ на више прописан модел софтверских архитектура.[14][15]

У ствари, као што је наглашено у скорашњој студији спроведеној са практикантима,[16]

Карактеристике[уреди | уреди извор]

Постоји велика разноврстност у АОЈима резвијених од стране или академских или индустријских група. Многи језици нису намењени да буду АОЈи, али су испали погодни за представљање и анализу архитектуре. У принципу, АОЈи се разликују од језика захтева, зато што су АОЈи укорењени у простору решења, док захтеви описују порблемске просторе. Они се разликују од порграмских језика, зато што АОЈи не везују архитектонске апстракције за специфична смисаона решења. Моделарски језици представљају понашања, док се АОЈи фокусирају на представљање документа. Ипак, постоје обласно специфични моделарски језици (ОСМЈ) који се фокусирају на представљање докумената.

Минимални захтеви

Језик мора:

  • Да буде погодан за комуникацију архитектуре између свих заинтересованих страна
  • Да подржава задатке архитектонске креације, префињеност и валидацију
  • да обезбеђује базу за даље имплементације, тако да мора да буде у стању да додаје инфорамције АОЈој спецификацији да би омогућила да финална системска спецификација буде изведена ис АОЈа
  • Да обезбеди способност представљања већине уобичајених архитектонских стилова
  • Да подржава аналитичке способности или да обезбеди брзо генерисање прототипских имплементација

АОЈи имају заједничку:

  • Графичку синтаксу са често текстуалном формом и званично дефинисану синтаксу и семантику
  • Карактеристике за моделовање дистрибираних система
  • Малу подршку за хватање дизајн информација, осим кроз механизме опште сврховне анотације
  • Способност за представљање хијерархиских нивоа детаља укључујући и креацију субструктура инсталацијом шаблона

АОЈи се разликују у њиховој способности да:

  • Се носе са стварно временским констукцијама, као што су рокови приоризација задатака, на архитектонском нивоу
  • Подржавају спецификацију другог архитектонскогсила. Мало њих могу да се носе са наслеђем објектно оријентисане класе или са динамиком архитектура
  • Подржавају анализу архитектуре
  • Се носе са различитим инструкцијама исте архитектуре, у вези са архитектурама производне линије

Позитивни елементи АОЈа[уреди | уреди извор]

  • АОЈи су форматизован начин приказивања архитектуре
  • АОЈи су намењени да буду и људско и машинско читљиви
  • АОЈи подржавају описивање система на већем нивоу него што је претходно било могуће
  • АОји дозвољавају анализу и процену архитектуре, ради целовитости, доследности, двосмислености, и перформанси
  • АОји могу да подржавају аутоматско генерисање софтверских система

Негативни елементи АОЈа[уреди | уреди извор]

  • Не постоји универзални одговор о томе шта би АОЈи требало да представљају, посебно што се тиче понашања архитектуре
  • Прикази који се тренутно користе су релативно тешки да се расчлане и нису подрживи од стране комерцијалних алатки
  • Већина АОја тече да буду вертикално оптимизовани ка посебној врсти аанализе

Уобичајени концепти архитектуре[уреди | уреди извор]

Заједница АОЈа се генерално слаже да су Софтверске архитектуре сет компонената и веза између њих. Али постоје различити врсте архитектура као што су:

Архитектура предметних веза[уреди | уреди извор]

  • конфигурација се састоји од интерфејсова и веза објектно-оријентисаног система
  • интерфејсови специфишу карактеристике које морају да буду обезбеђене од стране модула у складу са интерфејсом
  • Везе се представљају од стране интерфејса заједно са позивним графиком
  • Усклађености су обично подстакнуте програмским језиком
    • Разлагање— везати интерфејс са уникатним модулима
    • Усклађеност интерфејса — статична провера синтаксних правила
    • Комуникацисјки интегритет — видљивост између модула

Архитектура интерфејсних веза[уреди | уреди извор]

  • Објашњава улогу интерфејсова и веза
    • Интерфејси специфишу и "потребне" и "обезбеђене" карактеристике
    • Везе се дефинишу између "потребних" карактеристика и "обезбеђених" карактеристика
  • садржи се од интерфејса, веза и ограничења
    • Ограничења ограничавају понашање интерфејса и веза у архитектури
    • Ограничења у архитектонској мапи за захтеве система

Већина АОја имплементују интерфејсну везну архитектуру.

Архитектура против дизајна[уреди | уреди извор]

Архитектура, у контексту софтверских система, је грубо подењена у категорије, примарне софтверске архитектуре, архитектуре мреже, и системске архитектуре. У свакој од ових категорија, постоји опипљива али нејасна разлика између архитектуре и дизајна. Да би се извукла разлика што универзалнија и јаснија, најбоље је узети дизајн у обзир као именицу а не као глагол, тако да је то поређење две именице.

Дизајн је апстракција и спецификација шаблона и органа функционалности који су били или ће бити имплементирани. Архитектура је већег степена и у апстракцији и у гранулацији. сходно томе, архитектура је такође више тополошка у природи него у дизајну, у смислу да прецизира где се велики компоненти сусрећу и како се односе једни на друге. Архитектура се фокусира на поделу великих регија функционалности у компоненте високог нивоа, где они физички или виртуелно станују, које са-полице компоненте могу бити упослене ефектно, генерално које ће појединачно сваки интерфејсов компонент изложити, који протоколи ће бити упосљени између њих, и које праксе и који ће шаблони високог нивоа моћи најбоље да се сусретну са растегљивошћу, одрживошћу, поузданошћу, трајности, скалабилности, и другим не функционалним циљевима. Дизајн је детаљисање ових избора и конкретнија класификација о томе како ће се функционални захтеви сусрести током делегације делова од те функционалности до више грануларних компоненти и како ће ови мањи компоненти бити организовани унутар већих.

Много пута, део архитектуре је урађен током концептулизације апликације, система, или мреже и може да се појави у не функционалним деловима захтевне документације. канонски, дизајн није специфизиран у захтевима, али је вођен њима.

Процес дефинисања архитектуре може укључивати хеуристику, стечену од стране архитекте или архитектонског тима кроз искуство стечено у области. Као и дизајн, архитектура често еволуира кроз низ итерација, и као што је мудрост дизајна високог нивоа често тестирана када настане низак ниво дизајна и имплементације, мудрост архитектуре је тестирана у току спецификације дизајна високог нивоа. У оба случаја, ако се мудрост спецификације доводи у питање током детаљисања, друга итерација, архитектуре или дизајна, може бити неопходна.

Да резимирамо, примарне разлике између архитектуре и дизајна су оне од грануларности и апстракције, и (следствено) хронологији. (Архитектура генерално претходи дизајну, иако је преклапање и циркуларна итерација честа реалност.)

Примери[уреди | уреди извор]

Листа испод даје кандидате за најбољег АОЈа до сада.

За актуелну листу тренутно постојећих архитектонских језика, молимо вас упутите се на Up-to-date list of ADLs.

Приступи архитектури[уреди | уреди извор]

Приступи архитектури

  • Академски приступ
    • фокус на аналитичку процену архитектонских модела
    • индивидуални модели
    • ригорозне модуларне ознаке
    • снажне аналитичке технике
    • дубина пре ширине
    • специјално-сврховна решења
  • Индустријски приступ
    • фокусира се наширок распон развојних проблема
    • породице модела
    • практичност пре ригорозности
    • архитектура као велика слика у развоју
    • ширина преко дубине
    • генерално-сврховна решења

Види још[уреди | уреди извор]

Референце[уреди | уреди извор]

  1. ^ „Архивирана копија” (PDF). Архивирано из оригинала (PDF) 26. 04. 2012. г. Приступљено 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. ^ а б 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”. Архивирано из оригинала 01. 06. 2013. г. Приступљено 30. 11. 2015. 
  8. ^ а б 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). стр. 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. стр. 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. стр. 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. 

Литература[уреди | уреди извор]

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

Спољашње везе[уреди | уреди извор]

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