Jazyk popisu architektury - Architecture description language

Jazyky popisu architektury (ADL) se používají v několika oborech: systémové inženýrství, softwarové inženýrství, a podnikové modelování a strojírenství.

Komunita systémového inženýrství používá jazyk popisu architektury jako jazyk a / nebo konceptuální model popsat a reprezentovat systémové architektury.

Komunita softwarového inženýrství používá jazyk popisu architektury jako počítačový jazyk vytvořit popis a softwarová architektura. V případě tzv technická architektura, architektura musí být sdělena vývojářům softwaru; A funkční architektura je sdělován různým zúčastněným stranám a uživatelům. Některé vyvinuté ADL jsou: Vrchol (vyvinutý společností CMU ), AADL (standardizováno SAE ), C2 (vyvinutý společností UCI ), SBC-ADL (vyvinutý společností Národní univerzita Sun Yat-Sen ), Darwine (vyvinutý společností Imperial College London ), a Wrighte (vyvinutý CMU).

Přehled

The ISO / IEC / IEEE 42010[1] dokument, Systémové a softwarové inženýrství - popis architektury, definuje jazyk popisu architektury jako „libovolnou formu výrazu pro použití v popisech architektury“ a specifikuje minimální požadavky na ADL.

Komunita podnikového modelování a inženýrství také vyvinula jazyky pro popis architektury zajišťované na podnikové úrovni. Mezi příklady patří ArchiMate (nyní standard Otevřená skupina ), DEMO, POČITADLO (vyvinutý společností University of Technology, Sydney ). Tyto jazyky nemusí nutně odkazovat na softwarové komponenty atd. Většina z nich však označuje architekturu aplikace jako architekturu, která je sdělena softwarovým technikům.

Většina níže uvedeného textu se primárně týká perspektivy ze strany softwarového inženýrství.

Standardní notace (ADL) pro zastupování architektur pomáhá podporovat vzájemnou komunikaci, ztělesňování dřívějších návrhových rozhodnutí a vytváření přenosné abstrakce systému. Architektury v minulosti byly do značné míry reprezentovány rámečkovou kresbou anotovanou takovými věcmi, jako je povaha komponenty, vlastnosti, sémantika spojení a celkové chování systému. ADL jsou výsledkem lingvistického přístupu k formálnímu zastoupení architektur a jako takové řeší jeho nedostatky. Důležité také sofistikované ADL umožňují včasnou analýzu a testování proveditelnosti rozhodnutí architektonického návrhu.

Dějiny

ADL byly klasifikovány do tří hlavních kategorií: neformální kresby typu box-and-line, jazyk popisu formální architektury a UML (Unifikovaný Modelovací Jazyk ) notace založené na).

Box-and-line jsou po dlouhou dobu nejdůležitějším prostředkem pro popis SA. Při poskytování užitečné dokumentace omezovala úroveň neformality užitečnost popisu architektury. Byl vyžadován přísnější způsob popisu SA. Cituji Allena a Garlana (1997),[2] „zatímco tyto [box-and-line] popisy mohou poskytovat užitečnou dokumentaci, současná úroveň neformálnosti omezuje jejich užitečnost. Jelikož je obecně nepřesné, co je míněno takovými architektonickými popisy, může být nemožné analyzovat architekturu na konzistenci nebo určit netriviální vlastnosti. Navíc neexistuje způsob, jak ověřit, zda je implementace systému věrná svému architektonickému návrhu. “ Podobný závěr je vyvozen v Perry a Wolf (1992),[3] který uvádí, že: „Kromě poskytování jasné a přesné dokumentace je hlavním účelem specifikací poskytnout automatizovanou analýzu dokumentů a odhalit různé druhy problémů, které by jinak zůstaly nezjištěny.“

Od té doby proběhlo vlákno výzkumu formálních jazyků pro popis SA. Byly navrženy desítky formálních ADL, z nichž každý se vyznačuje odlišnými koncepčními architektonickými prvky, jinou syntaxí nebo sémantikou, se zaměřením na konkrétní provozní doménu nebo vhodný pouze pro různé techniky analýzy. Například byly předloženy ADL specifické pro doménu, které se zabývají zabudovanými systémy a systémy v reálném čase (jako AADL,[4] EAST-ADL,[5] a EADL[6]), aplikace s regulační smyčkou (DiaSpec[7]), architektury produktové řady (Koala[8]) a dynamické systémy (Π-ADL[9])). Byly navrženy analytické ADL, které se zabývají dostupností, spolehlivostí, zabezpečením, spotřebou zdrojů, kvalitou dat a analýzou výkonu v reálném čase (AADL, behaviorální analýza (Fractal[10])) a analýza důvěryhodnosti (TADL[11]).

Toto úsilí však nezaznamenalo žádoucí přijetí průmyslovou praxí. Některé důvody tohoto nedostatečného přijetí v odvětví analyzovaly Woods a Hilliard,[12] Pandey,[13] Clements,[14] a další: Formální ADL byly zřídka integrovány do životního cyklu softwaru, jsou zřídka podporovány vyspělými nástroji, sotva zdokumentovány, zaměřeny na velmi specifické potřeby a nezanechávají prostor pro rozšíření umožňující přidávání nových funkcí.

Jako způsob, jak překonat některá z těchto omezení, UML byl označen jako možný nástupce stávajících ADL. Bylo předloženo mnoho návrhů na použití nebo rozšíření UML na správnější modelování softwarových architektur.[15][16]

Ve skutečnosti, jak bylo zdůrazněno v nedávné studii provedené s odborníky,[17] Zatímco odborníci jsou obecně spokojeni s konstrukčními schopnostmi poskytovanými jazyky, které používají, jsou nespokojeni s funkcemi architektonické jazykové analýzy a jejich schopnostmi definovat extra-funkční vlastnosti; architektonické jazyky používané v praxi většinou pocházejí z průmyslového rozvoje místo z akademického výzkumu; architektonický jazyk vyžaduje více formality a lepší použitelnosti.

Vlastnosti

Existuje velké množství ADL vyvinutých akademickými nebo průmyslovými skupinami. Mnoho jazyků nebylo zamýšleno jako ADL, ale ukázalo se, že jsou vhodné pro reprezentaci a analýzu architektury. V zásadě se ADL liší od jazyků požadavků, protože ADL jsou zakořeněny v prostor řešení, zatímco požadavky popisují problémové prostory. Liší se od programovacích jazyků, protože ADL neváží architektonické abstrakce ke konkrétním bodovým řešením. Modelovací jazyky představují chování, kde se ADL zaměřují na reprezentaci komponent. Existují však doménově specifické modelovací jazyky (DSML), které se zaměřují na reprezentaci komponent.

Minimální požadavky

Jazyk musí:

  • Být vhodný pro komunikaci architektury se všemi zúčastněnými stranami
  • Podporujte úkoly vytváření, zdokonalování a ověřování architektury
  • Poskytněte základ pro další implementaci, takže musí být schopen přidat informace ke specifikaci ADL, aby bylo možné odvodit finální specifikaci systému z ADL
  • Poskytuje schopnost reprezentovat většinu běžných architektonických stylů
  • Podporujte analytické schopnosti nebo poskytujte rychlé generování prototypových implementací

ADL mají společné:

  • Grafická syntaxe s často textovou formou a formálně definovanou syntaxí a sémantikou
  • Funkce pro modelování distribuovaných systémů
  • Malá podpora pro zachycení návrhových informací, kromě mechanismů anotací pro obecné účely
  • Schopnost reprezentovat hierarchické úrovně podrobností včetně vytváření substruktur vytvořením instancí šablon

ADL se liší ve své schopnosti:

  • Zpracovávejte konstrukce v reálném čase, jako jsou termíny a priority úkolů, na architektonické úrovni
  • Podporujte specifikaci různých architektonických stylů. Málokdo zvládne objektově orientovanou dědičnost tříd nebo dynamické architektury
  • Podporujte analýzu architektury
  • Zacházejte s různými instancemi stejné architektury ve vztahu k architekturám produktové řady

Pozitivní prvky ADL

  • ADL jsou formálním způsobem reprezentace architektury
  • ADL jsou zamýšleny tak, aby byly jak lidské, tak strojově čitelné
  • Podpora ADL popisující systém na vyšší úrovni, než bylo dříve možné
  • ADL umožňují analýzu a hodnocení architektur pro úplnost, konzistenci, nejednoznačnost a výkon
  • ADL mohou podporovat automatické generování softwarových systémů

Negativní prvky ADL

  • Neexistuje žádná univerzální dohoda o tom, co by ADL měly představovat, zejména pokud jde o chování architektury
  • Reprezentace, které se v současné době používají, je relativně obtížné analyzovat a nejsou podporovány komerčními nástroji
  • Většina ADL má tendenci být velmi vertikálně optimalizována směrem ke konkrétnímu druhu analýzy

Společné koncepty architektury

Komunita ADL obecně souhlasí s tím, že Softwarová architektura je sada komponent a spojení mezi nimi. Existují však různé druhy architektur, jako například:

Architektura připojení objektu

  • Konfigurace se skládá z rozhraní a připojení objektově orientovaného systému
  • Rozhraní určují funkce, které musí poskytovat moduly odpovídající rozhraní
  • Spojení představovaná rozhraními společně s graf volání
  • Shoda obvykle vynucována programovacím jazykem
    • Dekompozice - přidružení rozhraní k jedinečným modulům
    • Shoda rozhraní - statická kontrola syntaktických pravidel
    • Integrita komunikace - viditelnost mezi moduly

Architektura připojení rozhraní

  • Rozšiřuje roli rozhraní a připojení
    • Rozhraní specifikují funkce „požadované“ i „poskytované“
    • Spojení jsou definována mezi „požadovanými“ funkcemi a „poskytnutými“ funkcemi
  • Skládá se z rozhraní, připojení a omezení
    • Omezení omezují chování rozhraní a připojení v architektuře
    • Omezení v mapě architektury podle požadavků na systém

Většina ADL implementuje architekturu připojení rozhraní.

Architektura vs. design

Architektura je v kontextu softwarových systémů zhruba rozdělena do kategorií, především softwarová architektura, síťová architektura a architektura systémů. V rámci každé z těchto kategorií existuje hmatatelný, ale nejasný rozdíl mezi architekturou a designem. Abychom tento rozdíl vyvodili co nejuniverzálněji a nejjasněji, je nejlepší považovat design spíše za podstatné jméno než za sloveso, aby bylo srovnání mezi dvěma podstatnými jmény.

Design je abstrakce a specifikace vzorů a orgánů funkčnosti, které byly nebo budou implementovány. Architektura je o stupeň vyšší v abstrakci i granularitě. V důsledku toho má architektura také více topologickou povahu než design, protože určuje, kde se hlavní součásti setkávají a jak spolu souvisejí. Architektura se zaměřuje na rozdělení hlavních oblastí funkčnosti na komponenty na vysoké úrovni, kde budou fyzicky nebo virtuálně umístěny, jaké běžné komponenty mohou být efektivně použity, obecně jaké rozhraní každá komponenta vystaví, jaké protokoly budou použity mezi a jaké postupy a vzorce na vysoké úrovni se mohou nejlépe setkat rozšiřitelnost, udržitelnost spolehlivost, trvanlivost, škálovatelnost a další nefunkční cíle. Design je podrobným popisem těchto možností a konkrétnějším vyjasněním toho, jak budou splněny funkční požadavky prostřednictvím delegování částí této funkce na podrobnější součásti a jak budou tyto menší součásti organizovány v rámci větších.

Část architektury se často provádí během konceptualizace aplikace, systému nebo sítě a může se objevit v nefunkčních částech dokumentace požadavků. Kánonicky není design specifikován v požadavcích, ale je jimi spíše řízen.

Proces definování architektury může zahrnovat heuristiku získanou architektem nebo architektonickým týmem na základě zkušeností v doméně. Stejně jako u designu se architektura často vyvíjí řadou iterací a stejně jako se často testuje moudrost designu na vysoké úrovni, když dochází k designu a implementaci na nízké úrovni, moudrost architektury se testuje během specifikace designu na vysoké úrovni. V obou případech, pokud je během podrobností zpochybněna moudrost specifikace, může být nezbytná další iterace architektury nebo designu.

Stručně řečeno, primární rozdíly mezi architekturou a designem jsou rozdíly v granularitě a abstrakci a (následně) chronologii. (Architektura obecně předchází designu, ačkoli běžná realita je překrývání a kruhová iterace.)

Příklady

Níže uvedený seznam uvádí kandidáty, aby byli nejlepší[Citace je zapotřebí ] ADL k dnešnímu dni.

Aktuální seznam aktuálně existujících architektonických jazyků najdete na stránce Aktuální seznam ADL.

Přístupy k architektuře

Přístupy k architektuře

  • Akademický přístup
    • zaměření na analytické hodnocení architektonických modelů
    • jednotlivé modely
    • pečlivé modelové notace
    • výkonné analytické techniky
    • hloubka po šířce
    • účelová řešení
  • Průmyslový přístup
    • zaměřit se na širokou škálu rozvojových problémů
    • rodiny modelů
    • praktičnost přes přísnost
    • architektura jako velký obrázek ve vývoji
    • šířka přes hloubku
    • univerzální řešení

Viz také

Reference

  1. ^ Výbor ISO / IECJTC 1 / SC 7 (01.03.2011). „ISO / IEC FDIS42010“ (PDF). Archivovány od originál (PDF) dne 26.04.2012. Citováno 2011-12-05.
  2. ^ Allen, R .; Garlan, D. (1997). "Formální základ pro architektonické spojení". Transakce ACM v softwarovém inženýrství a metodice. 6 (3): 213. CiteSeerX  10.1.1.40.66. doi:10.1145/258077.258078.
  3. ^ Perry, D. E.; Vlk, A. L. (1992). „Základy pro studium softwarové architektury“ (PDF). Poznámky k softwarovému inženýrství ACM SIGSOFT. 17 (4): 40. CiteSeerX  10.1.1.40.5174. doi:10.1145/141874.141884.
  4. ^ „AADL - jazyk pro analýzu a design architektury“. Institut softwarového inženýrství, Carnegie Mellon University. Července 2019.
  5. ^ „EAST-ADL“.
  6. ^ Li, J .; Pilkington, N. T .; Xie, F .; Liu, Q. (2010). Msgstr "Jazyk popisu vestavěné architektury". Journal of Systems and Software. 83 (2): 235. CiteSeerX  10.1.1.134.8898. doi:10.1016 / j.jss.2009.09.043.
  7. ^ „AADL“. Archivovány od originál dne 01.06.2013. Citováno 2012-12-10.
  8. ^ Van Ommering, R .; Van Der Linden, F .; Kramer, J .; Magee, J. (2000). "Model komponenty Koala pro software spotřební elektroniky". Počítač. 33 (3): 78. CiteSeerX  10.1.1.469.8243. doi:10.1109/2.825699.
  9. ^ Oquendo, Flavio (2004). "π-ADL". Poznámky k softwarovému inženýrství ACM SIGSOFT. 29 (3): 1. doi:10.1145/986710.986728. ISSN  0163-5948.
  10. ^ Bruneton, E .; Coupaye, T .; Leclercq, M .; Quéma, V .; Stefani, J. B. (2006). Msgstr "Model komponenty FRACTAL a jeho podpora v Javě". Software: Praxe a zkušenosti. 36 (11–12): 1257. CiteSeerX  10.1.1.471.4374. doi:10,1002 / spe. 767.
  11. ^ „TADL“. 2009-04-29.
  12. ^ Woods, E .; Hilliard, R. (2005). "Architektura Popis Jazyky v praxi Zpráva o relaci". 5. pracovní konference IEEE / IFIP o softwarové architektuře (WICSA'05). str. 243. doi:10.1109 / WICSA.2005.15. ISBN  978-0-7695-2548-8.
  13. ^ Pandey, R. K. (2010). Msgstr "Jazyky architektonického popisu (ADL) vs UML". Poznámky k softwarovému inženýrství ACM SIGSOFT. 35 (3): 1. doi:10.1145/1764810.1764828.
  14. ^ Clements, P. C. (1996). "Přehled jazyků popisu architektury". Sborník příspěvků z 8. mezinárodního semináře o specifikaci a designu softwaru. str. 16–00. CiteSeerX  10.1.1.208.3401. doi:10.1109 / IWSSD.1996.501143. ISBN  978-0-8186-7361-0.
  15. ^ „Garlan_TR“.
  16. ^ Pérez-Martínez, J. E .; Sierra-Alonso, A. (2004). "UML 1.4 versus UML 2.0 jako jazyky k popisu softwarových architektur". Softwarová architektura. Přednášky z informatiky. 3047. str. 88. doi:10.1007/978-3-540-24769-2_7. ISBN  978-3-540-22000-8.
  17. ^ Malavolta, Ivano; Lago, Patricia; Muccini, Henry; Pelliccione, Patrizio; Tang, Antony (2013). „Co průmysl potřebuje od architektonických jazyků: průzkum“. Transakce IEEE v softwarovém inženýrství. 39 (6): 869–891. doi:10.1109 / TSE.2012.74.

externí odkazy