아키텍처 설명 언어

Architecture description language

아키텍처 기술 언어(ADL)는 시스템 엔지니어링, 소프트웨어 엔지니어링, 엔터프라이즈 모델링 및 엔지니어링 등 여러 분야에서 사용됩니다.

시스템 엔지니어링 커뮤니티는 아키텍처 기술 언어를 언어 및/또는 개념 모델로 사용하여 시스템 아키텍처를 기술하고 표현합니다.

소프트웨어 엔지니어링 커뮤니티에서는 아키텍처 기술 언어를 컴퓨터 언어로 사용하여 소프트웨어 아키텍처에 대한 설명을 만듭니다.이른바 기술 아키텍처의 경우, 아키텍처는 소프트웨어 개발자에게 전달되어야 합니다.기능 아키텍처는 다양한 이해관계자와 사용자에게 전달됩니다.개발된 ADL은 Acme(CMU에 의해 개발), AADL(SAE에 의해 표준화), C2(UCI에 의해 개발), SBC-ADL(National Sun Yat-Sen University에 의해 개발), 다윈(Imperial College London에 의해 개발) 및 라이트(CMU에 의해 개발)이다.

개요

ISO/IEC/IEE 42010[1] 문서, 시스템 및 소프트웨어 엔지니어링—아키텍처 설명에서는 아키텍처 설명 언어를 "아키텍처 설명에 사용하기 위한 모든 형식의 표현"으로 정의하고 ADL에 대한 최소 요건을 지정합니다.

또한 엔터프라이즈 모델링 및 엔지니어링 커뮤니티는 엔터프라이즈 수준에서 사용할 수 있는 아키텍처 기술 언어를 개발했습니다.예를 들어 ArchiMate(현재는 The Open Group의 표준), DEMO, ABACUS(시드니 공과대학에서 개발) 등이 있습니다.이러한 언어는 반드시 소프트웨어 컴포넌트 등을 지칭하는 것은 아닙니다.그러나 대부분의 경우 애플리케이션 아키텍처를 소프트웨어 엔지니어에게 전달되는 아키텍처라고 합니다.

다음 글의 대부분은 주로 소프트웨어 엔지니어링 커뮤니티의 관점을 언급하고 있습니다.

아키텍처를 나타내는 표준 표기법(ADL)은 상호 커뮤니케이션, 초기 설계 결정의 실시 및 시스템의 전송 가능한 추상화 작성을 촉진하는 데 도움이 된다.과거의 아키텍처는 주로 컴포넌트의 특성, 속성, 연결의 의미론 및 전체적인 시스템 동작과 같은 주석을 단 박스 앤 라인 도면으로 표현되었습니다.ADL은 아키텍처의 형식적 표현에 대한 언어적 접근에서 비롯되며, 그 결점에 대처합니다.또, 고도의 ADL에 의해서, 아키텍처 설계 결정의 조기 분석과 실현 가능성 테스트가 가능하게 됩니다.

역사

ADL은 박스 앤 라인 비공식 도면, 정식 아키텍처 기술 언어 및 UML(Unified Modeling Language) 기반 표기법의 3가지 범주로 분류됩니다.

박스 앤 라인은 오랫동안 SA를 설명하는 가장 중요한 수단이었습니다.유용한 문서를 제공하면서도, 비공식적인 수준에서는 아키텍처 설명의 유용성이 제한되었습니다.SA를 기술하기 위한 보다 엄격한 방법이 요구되었습니다.Allen과 Garlan(1997)[2]의 말을 인용하면, "이러한 [상자 앤 라인] 설명은 유용한 문서를 제공할 수 있지만, 현재의 비공식성 수준은 이들의 유용성을 제한한다.일반적으로 그러한 아키텍처 기술이 의미하는 바가 부정확하기 때문에 일관성을 위해 아키텍처를 분석하거나 아키텍처의 사소한 속성을 결정하는 것은 불가능할 수 있다.게다가 시스템 구현이 아키텍처 설계에 충실하고 있는지 확인할 방법이 없습니다."Perry와 Wolf(1992)[3]에서도 유사한 결론이 도출되고 있다.이 보고서에서는 다음과 같이 기술하고 있다.명확하고 정확한 문서를 제공하는 것 외에, 사양의 주된 목적은 문서의 자동 분석을 제공하고, 그렇지 않으면 검출되지 않을 수 있는 다양한 종류의 문제를 밝히는 것이다."

그 후, SA 기술용 정식 언어에 관한 일련의 연구가 행해지고 있다.수십 개의 공식 ADL이 제안되었으며, 각각 다른 개념적 아키텍처 요소, 다른 구문 또는 의미론, 특정 운영 영역에 초점을 맞추거나 다른 분석 기술에만 적합합니다.예를 들어 도메인 고유의 ADL은 임베디드 및 실시간 시스템([4]AADL, [5]EAST-ADL[6], EADL 등), 제어 루프[7] 애플리케이션(DiaSpec), 제품 라인 아키텍처(Koala[8]), 동적 시스템(δ-ADL[9])을 처리하기 위해 제시되었습니다.분석 고유의 ADL은 가용성, 신뢰성, 보안, 자원 소비, 데이터 품질 및 실시간 성능 분석(AADL[10], 행동 분석(Fractal), 신뢰도 분석(TADL)[11]을 다루기 위해 제안되었습니다.

그러나 이러한 노력은 산업 관행에서 바람직한 채택을 보여주지 못하고 있다.산업 채택의 결핍에 대하는 이유. 우즈와 Hilliard,[12]Pandey,[13]Clements,[14]등 공식적인 ADLs에 의해서 분석되었다는 거의 없는 소프트웨어 라이프 사이클에 통합하고 있지만 좀처럼 성숙한 도구에 의해, 거의 충분히 문서화되는 경우, 매우 특수한 필요성에 공여가 addi을 활성화하기 위해 배게 집중 지원된다.새로운의 tion특징들.

이러한 제한을 극복하기 위한 방법으로서 UML은 기존 ADL의 가능한 후계자로 제시되고 있습니다.소프트웨어 아키텍처를 보다 적절하게 모델링하기 [15][16]위해 UML을 사용하거나 확장하기 위한 많은 제안이 제시되었습니다.

A2013년 study[17]은 실무 종사자들이 일반적으로 ADLS 그들이 사용의 설계 능력을 갖지만 그들과 몇가지 주요 관심사가 만족했다:그들은 능력extra-functional 속성을 정의하기 그 연습에 사용되는 대부분 산업 발전보다는 학술 연구에서부터 기원되어;그들은 분석 기능이 부족하다는 것을 발견했다.결혼 전 성은보다 격식을 차리고 조작성을 높입니다.

특성.

ADL에는 학회 또는 산업 단체에서 개발한 다양한 종류가 있습니다.많은 언어가 ADL을 의도하지 않았지만 아키텍처를 표현하고 분석하는 데 적합한 것으로 나타났습니다.ADL은 솔루션 공간에 뿌리를 두고 있는 반면, 요건은 문제 공간을 기술하기 때문에 ADL은 원칙적으로 요건 언어와 다릅니다.ADL은 아키텍처 추상화를 특정 포인트 솔루션에 바인딩하지 않기 때문에 프로그래밍 언어와 다릅니다.모델링 언어는 동작을 나타냅니다.ADL은 컴포넌트 표현에 초점을 맞춥니다.단, 컴포넌트 표현에 초점을 맞춘 도메인 고유 모델링 언어(DSML)가 있습니다.

최소한의 요건

언어는 다음과 같습니다.

  • 아키텍처를 모든 관계자에게 전달하는 데 적합하다
  • 아키텍처 작성, 개선 및 검증 태스크 지원
  • ADL에서 최종 시스템 사양을 도출할 수 있도록 ADL 사양에 정보를 추가할 수 있도록 추가 구현 기반을 제공합니다.
  • 일반적인 아키텍처 스타일의 대부분을 나타낼 수 있는 기능을 제공합니다.
  • 분석 기능을 지원하거나 프로토타입의 신속한 생성 구현 제공

ADL의 공통점은 다음과 같습니다.

  • 대부분의 경우 텍스트 형식과 공식적으로 정의된 구문 및 의미를 가진 그래픽 구문
  • 분산 시스템 모델링 기능
  • 범용 주석 메커니즘을 제외하고 설계 정보 수집을 거의 지원하지 않음
  • 템플릿을 인스턴스화하여 하위 구조 작성을 포함한 계층적 세부 수준을 나타내는 기능

ADL의 기능은 다음과 같습니다.

  • 아키텍처 수준에서 마감일 및 작업 우선순위 등의 실시간 구성 처리
  • 다양한 건축 스타일의 사양을 지원합니다.객체 지향 클래스 상속 또는 동적 아키텍처를 처리하는 사람은 거의 없음
  • 아키텍처 분석 지원
  • 제품군 아키텍처와 관련하여 동일한 아키텍처의 다양한 인스턴스화 처리

ADL의 장점

  • ADL은 아키텍처를 나타내는 정식 방식입니다.
  • ADL은 사람과 기계 양쪽에서 읽을 수 있도록 설계되어 있습니다.
  • ADL은 기존보다 높은 수준의 시스템 기술 지원
  • ADL을 통해 아키텍처의 완전성, 일관성, 모호성 및 퍼포먼스를 분석 및 평가할 수 있습니다.
  • ADL은 소프트웨어 시스템의 자동 생성을 지원할 수 있습니다.

ADL의 마이너스 요소

  • ADL이 무엇을 나타내야 하는지, 특히 아키텍처의 동작에 관해 보편적으로 합의된 것은 없습니다.
  • 현재 사용 중인 표현은 해석하기가 비교적 어려우며 상용 도구에서 지원되지 않습니다.
  • 대부분의 ADL은 특정 종류의 분석에 매우 수직으로 최적화되는 경향이 있습니다.

아키텍처의 공통 개념

ADL 커뮤니티는 일반적으로 소프트웨어 아키텍처가 컴포넌트와 컴포넌트 간의 접속이라는 점에 동의합니다.그러나 다음과 같은 다른 종류의 아키텍처가 있습니다.

오브젝트 접속 아키텍처

  • 구성은 객체 지향 시스템의 인터페이스와 연결로 구성됩니다.
  • 인터페이스는 인터페이스에 준거한 모듈이 제공해야 하는 기능을 지정합니다.
  • 콜 그래프와 함께 인터페이스로 표시되는 접속
  • 일반적으로 프로그래밍 언어에 의해 강제되는 컴플라이언스
    • 분해: 인터페이스를 고유 모듈과 관련짓습니다.
    • 인터페이스 준거: 구문 규칙 정적 체크
    • 통신 무결성 - 모듈 간 가시성

인터페이스 접속 아키텍처

  • 인터페이스와 접속의 역할을 확장합니다.
    • 인터페이스는 '필수' 기능과 '제공' 기능을 모두 지정합니다.
    • 접속은 "필수" 기능과 "제공" 기능 간에 정의됩니다.
  • 인터페이스, 접속 및 제약으로 구성됨
    • 아키텍처 내 인터페이스 및 접속 동작은 제약에 의해 제한된다.
    • 아키텍처의 제약 조건은 시스템 요건에 대응합니다.

대부분의 ADL은 인터페이스 접속 아키텍처를 구현하고 있습니다.

아키텍처와 설계

소프트웨어 시스템의 맥락에서 아키텍처는 크게 소프트웨어 아키텍처, 네트워크 아키텍처 및 시스템 아키텍처로 나뉩니다.이러한 범주들 각각에서, 건축과 설계 사이에는 분명하지만 애매한 구분이 있습니다.이 구별을 가능한 한 보편적이고 명확하게 그리기 위해서는 디자인을 동사로서가 아니라 명사로서 고려하는 것이 가장 좋습니다.그래서 두 명사를 비교하는 것이 가장 좋습니다.

디자인은 구현되었거나 구현될 기능성 패턴과 기관의 추상화 및 사양입니다.아키텍처는 추상화와 세분화 모두에서 어느 정도 높습니다.결과적으로, 아키텍처는 주요 구성요소가 어디에서 만나고 어떻게 그것들이 서로 관련되는지를 규정한다는 점에서 설계보다는 본질적으로 위상적이다.아키텍처는 기능의 주요 영역을 개략적인 컴포넌트로 분할하고, 물리적인 컴포넌트 또는 가상적인 컴포넌트가 존재하는 장소, 효과적으로 사용할 수 있는 기성 컴포넌트, 일반적으로 각 컴포넌트 간에 어떤 인터페이스를 사용할 것인지, 각 컴포넌트 간에 어떤 프로토콜을 사용할 것인지, 그리고 어떤 프랙티스와 개략적인 패턴에 초점을 맞추고 있습니다.Tern은 확장성, 유지보수성, 신뢰성, 내구성, 확장성 및 기타 비기능적 목표를 가장 잘 충족할 수 있습니다.설계는 이러한 선택의 세부 사항이며, 보다 세분화된 구성요소에 해당 기능의 일부를 위임함으로써 기능 요건을 충족하는 방법 및 이러한 작은 구성요소가 보다 큰 구성요소에서 어떻게 구성되는지에 대한 보다 구체적인 명확화입니다.

대부분의 경우 아키텍처의 일부는 애플리케이션, 시스템 또는 네트워크의 개념화 중에 수행되며 요건 문서의 기능하지 않는 섹션에 기재되어 있습니다.규범적으로 설계는 요건에 명시되지 않고 오히려 요건에 의해 추진됩니다.

아키텍처를 정의하는 프로세스에는 도메인 내 경험을 통해 건축가 또는 건축팀이 습득한 휴리스틱스가 포함될 수 있습니다.설계와 마찬가지로 아키텍처는 일련의 반복을 통해 발전하는 경우가 많으며, 저수준 설계와 구현이 이루어질 때 고수준 설계의 지혜가 시험되는 경우가 많듯이 아키텍처의 지혜도 고수준 설계의 사양에서 시험됩니다.두 경우 모두 상세 설명 중에 명세서의 타당성에 의문이 제기된다면, 경우에 따라 아키텍처나 설계의 또 다른 반복이 필요할 수 있다.

요약하자면, 아키텍처와 설계의 주요 차이점은 세분화와 추상화, 그리고 (결과적으로) 연대순입니다.(중복과 순환 반복은 일반적인 현실이지만 일반적으로 아키텍처가 설계보다 우선합니다.)

예

아래 목록에는 지금까지 최고의[citation needed] ADL 후보가 나와 있습니다.

현재의 아키텍처 언어의 최신 리스트에 대해서는, ADL 의 최신 리스트를 참조해 주세요.

아키텍처에 대한 접근법

아키텍처에 대한 접근법

  • 학술적 접근법
    • 건축 모델의 분석 평가에 집중하다
    • 개별 모델
    • 엄밀한 모델링 표기법
    • 강력한 분석 기술
    • 폭에 걸친 깊이
    • 특수 목적의 해결책
  • 산업적 접근
    • 광범위한 개발 문제에 초점을 맞추다
    • 모델 패밀리
    • 엄격함보다 현실성
    • 개발의 큰 그림으로서의 건축
    • 폭과 깊이
    • 범용 솔루션

「 」를 참조해 주세요.

레퍼런스

  1. ^ ISO/IECJTC 1/SC 7 Committee (2011-03-01). "ISO/IEC FDIS42010" (PDF). Archived from the original (PDF) on 2012-04-26. Retrieved 2011-12-05.
  2. ^ Allen, R.; Garlan, D. (1997). "A formal basis for architectural connection". ACM Transactions on Software Engineering and Methodology. 6 (3): 213. CiteSeerX 10.1.1.40.66. doi:10.1145/258077.258078. S2CID 326385.
  3. ^ Perry, D. E.; Wolf, A. L. (1992). "Foundations for the study of software architecture" (PDF). ACM SIGSOFT Software Engineering Notes. 17 (4): 40. CiteSeerX 10.1.1.40.5174. doi:10.1145/141874.141884. S2CID 628695.
  4. ^ "AADL — Architecture Analysis and Design Language". Software Engineering Institute, Carnegie Mellon University. July 2019.
  5. ^ "EAST-ADL".
  6. ^ Li, J.; Pilkington, N. T.; Xie, F.; Liu, Q. (2010). "Embedded architecture description language". Journal of Systems and Software. 83 (2): 235. CiteSeerX 10.1.1.134.8898. doi:10.1016/j.jss.2009.09.043. S2CID 8075069.
  7. ^ "AADL". Archived from the original on 2013-06-01. Retrieved 2012-12-10.
  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. CiteSeerX 10.1.1.469.8243. doi:10.1109/2.825699.
  9. ^ Oquendo, Flavio (2004). "π-ADL". ACM SIGSOFT Software Engineering Notes. 29 (3): 1–14. doi:10.1145/986710.986728. ISSN 0163-5948. S2CID 10781129.
  10. ^ 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. CiteSeerX 10.1.1.471.4374. doi:10.1002/spe.767. S2CID 12541723.
  11. ^ Mohammad, Mubarak Sami (2009-04-29). TADL (phd). Concordia University.
  12. ^ Woods, E.; Hilliard, R. (2005). "Architecture Description Languages in Practice Session Report". 5th Working IEEE/IFIP Conference on Software Architecture (WICSA'05). p. 243. doi:10.1109/WICSA.2005.15. ISBN 978-0-7695-2548-8. S2CID 18175375.
  13. ^ Pandey, R. K. (2010). "Architectural description languages (ADLs) vs UML". ACM SIGSOFT Software Engineering Notes. 35 (3): 1–5. doi:10.1145/1764810.1764828. S2CID 18848376.
  14. ^ Clements, P. C. (1996). "A survey of architecture description languages". Proceedings of the 8th International Workshop on Software Specification and Design. pp. 16–00. CiteSeerX 10.1.1.208.3401. doi:10.1109/IWSSD.1996.501143. ISBN 978-0-8186-7361-0. S2CID 7307554.
  15. ^ "Garlan_TR".
  16. ^ 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. Vol. 3047. p. 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). "What Industry Needs from Architectural Languages: A Survey". IEEE Transactions on Software Engineering. 39 (6): 869–891. doi:10.1109/TSE.2012.74. S2CID 6383726.

외부 링크

Wikimedia Commons에는 아키텍처 기술 언어와 관련된 미디어가 있습니다.