소프트웨어 아키텍처 설명

Software architecture description

소프트웨어 아키텍처 설명은 소프트웨어 아키텍처를 표현, 통신 및 분석하기 위한 일련의 관행(구조 렌더링이라고도 함)과 소프트웨어 아키텍처를 표현하는 작업 제품(ISO/IEC/IEEE 42010)을 통해 이러한 관행을 적용한 결과물이다.

아키텍처 설명(AD)은 아키텍처 표현, 아키텍처 규격[1] 또는 소프트웨어 아키텍처 문서라고도 한다.

개념

아키텍처 설명은 소프트웨어 아키텍처를 기록하기 위해 소프트웨어 설계자가 사용하는 실천요강, 기법 및 표현의 유형을 정의한다.아키텍처 설명은 크게 모델링 활동(소프트웨어 아키텍처 모델)이다.아키텍처 모델은 텍스트, 비공식 도면, 도표 또는 기타 형식(모델링 언어)을 포함하여 다양한 형태를 취할 수 있다.아키텍처 설명은 다양한 청중, 이해관계자(예: 최종 사용자, 시스템 소유자, 소프트웨어 개발자, 시스템 엔지니어, 프로그램 관리자) 및 다양한 아키텍처 관심사(예: 기능, 안전성, 제공, 신뢰성, 확장성)를 효과적으로 다루기 위해 여러 가지 다른 종류의 모델을 채택하는 경우가 많다.

흔히, 아키텍처 설명의 모델은 "각각 [보기]가 시스템의 다른 이해관계자에 대한 특정 관심사를 다루도록" 구조의 다중 뷰로 구성된다.[2]아키텍처 관점은 시스템(RM ODP)을 보는 방법이다.아키텍처 설명의 각 뷰에는 해당 뷰가 다루어지는 우려와 이해관계자, 그리고 해당 뷰가 사용하는 모델 종류, 명세 및 모델링 규약을 문서화하는 관점이 있어야 한다(ISO/IEC/IEEE 42010).

다양한 이해관계자와의 소통과 다양한 관심사를 기록하고 분석하는 데 효과적이면서도 복수의 관점을 사용하는 것은 잠재적 문제를 야기한다: 관점이 일반적으로 독립적이지 않기 때문에, 중복 가능성이 있다는 것은 단일 시스템의 관점에 중복성이나 불일치가 있을 수 있다는 것을 의미한다.[3]세부사항을 공유하고, 중복성을 줄이고, 일관성을 강화하기 위해 보기 간 대응의 정의 및 관리에 다양한 메커니즘을 사용할 수 있다.

아키텍처 설명에 대한 일반적인 오해는 AD가 "기술적 문제"만을 논의하지만 AD는 많은 이해관계자들과 관련된 문제를 다루어야 한다는 것이다.어떤 문제들은 기술적인 것이고, 많은 문제들은 그렇지 않다: AD는 건축가, 그들의 고객들, 그리고 다른 사람들이 비용, 일정 그리고 과정을 관리하는 것을 돕기 위해 사용된다.관련된 오해는 AD가 시스템의 구조적 측면만을 다루고 있다는 것이다.그러나, 이것은 종종 구조, 행동, 미학 및 기타 "추가 기능적" 관심사를 포함하는 이해당사자들을 만족시키는 경우는 드물다.

역사

초기 아키텍처 설명은 비공식적인 그림과 도표 및 관련 텍스트를 사용했다.비공식적인 서술은 업계에서 가장 널리 사용되는 표현으로 남아 있다.[4]아키텍처 설명에 대한 영향은 소프트웨어 엔지니어링 영역(대부분의 데이터 추상화 및 프로그래밍 등)과 시스템 설계(SARA[5] 등)에서 비롯되었다.

소프트웨어:[6] 모듈(프로그램, 라이브러리, 서브루틴 및 서브시스템 포함)과 모듈 관계(모듈 간 종속성 및 상호연결성)의 대규모 속성 표현에 초점을 맞춘 모듈 상호접속 언어(MIL)와 같은 대규모 프로그래밍 작업.이 작업은 프로그래밍 언어(예: Ada), 설계 및 아키텍처 표기(Buhr 다이어그램 및 UML의 아키텍처 특징(패키지, 하위시스템, 의존성)에 대한 아키텍처 사고와 아키텍처 설명 언어에 대한 대부분의 작업에 영향을 미쳤다.MILs 외에도, 소프트웨어 엔지니어링 내의 요건 및 설계 분야에서 성숙한 작업의 영향을 받아, 다양한 종류의 모델이 소프트웨어 엔지니어링과 설계로부터 "리프팅"되어 아키텍처의 설명에 적용되었다.여기에는 구조화 분석 SADT의 기능과 활동 모델, 데이터 모델링 기법(특수 관계) 및 객체 지향 기법이 포함되었다.

페리와 울프는[1] 다중 뷰의 역할을 위해 건축물을 건축한 전례를 인용했다: "건축 설계자는 건물의 특정 측면이 강조되는 여러 가지 다른 뷰를 통해 고객과 함께 작업한다."

Perry와 Wolf는 아키텍처의 표현에는 다음과 같은 {요소, 형식 및 이론적}이(가) 포함되어야 하며, 세 종류의 요소(따라서 세 종류의 관점)를 구별해야 한다고 주장했다.

  • 처리: 데이터 변환 방법.
  • 데이터: 사용 및 변환되는 정보
  • 연결: 다른 요소를 함께 고정하는 접착제

Perry와 Wolf는 아키텍처 설명에 대한 네 가지 목표 또는 용도를 식별했다(이 논문에서 "건축 규격"이라 함).

  • 솔루션을 과도하게 지정하지 않고 아키텍처의 제약 조건을 규정하다.
  • 미학과 공학을 분리하다
  • 각각 다른 구조의 측면을 적절한 방식으로 표현하다.
  • 아키텍처 분석, 특히 의존성 및 일관성 분석을 수행한다.

Perry와 Wolf 논문에 이어 소프트웨어 아키텍처 설명에 관한 두 가지 사상이 대두되었다[citation needed].

  • 다중 뷰 스쿨
  • 구조주의 학교

건축설명을 위한 메커니즘

아키텍처 설명에 사용되는 몇 가지 일반적인 메커니즘이 있다.이러한 메커니즘은 성공적인 기술 스타일의 재사용을 촉진하여 많은 시스템에 적용할 수 있다.

  • 건축의 관점
  • 아키텍처 설명 언어
  • 건축 프레임워크

건축의 관점

소프트웨어 아키텍처 설명은 일반적으로 뷰로 구성되는데, 뷰는 빌딩 아키텍처에서 만들어진 다양한 유형의 Blueprint와 유사하다.각 견해는 관점의 관점에 따라 일련의 시스템 우려를 다루는데, 여기서 관점은 주어진 이해당사자 집합과 그들의 관심사(ISO/IEC 42010)의 관점에서 문제의 아키텍처를 표현하기 위해 사용되는 명세서, 모델링 기법을 기술하는 규격이다.관점은 (즉, 다루어야 할) 우려뿐만 아니라 다른 견해와 일관성을 유지하기 위한 프레젠테이션, 사용된 모델 종류, 사용된 규약 및 일관성(상응성) 규칙을 명시한다.

관점의 예는 다음과 같다.

  • 기능적 관점
  • 논리적 관점
  • 정보/데이터 관점
  • 모듈 관점
  • 구성 요소 및 커넥터 관점
  • 요구사항 관점
  • 개발자/이행 관점
  • 동시성/프로세스/실행 시간/스레드/실행 관점
  • 성과 관점
  • 보안 관점
  • 물리적/배포/설치 관점
  • 사용자 작업/피드백 시점

뷰타입(viewtype)이라는 용어는 공통적인 요소와 관계를 공유하는 유사한 뷰의 범주를 가리키는 데 사용된다.[4]

아키텍처 설명 언어

아키텍처 설명 언어(ADL)는 소프트웨어 아키텍처를 기술하는 데 사용되는 표현 수단이다(ISO/IEC/IEEE 42010).Many special-purpose ADLs have been developed since the 1990s, including AADL (SAE standard), Wright (developed by Carnegie Mellon), Acme (developed by Carnegie Mellon), xADL (developed by UCI), Darwin (developed by Imperial College London), DAOP-ADL (developed by University of Málaga), and ByADL (University of L'Aquila, Italy).초기 ADL은 구성 요소, 커넥터 및 구성 측면에서 모델링 시스템을 강조했다.보다 최근의 ADL(ArchiMate 및 SysML과 같은)은 여러 하위 언어를 통해 구성 요소와 커넥터뿐만 아니라 다양한 우려를 표현할 수 있는 "광범위한" 언어인 경향이 있다.UML과 같은 기존 언어는 특수 목적 언어 외에도 "소프트웨어 기반 시스템의 분석, 설계, 구현뿐 아니라 비즈니스 및 유사한 프로세스 모델링"을 위해 ADLs로 사용할 수 있다.

아키텍처 프레임워크

아키텍처 프레임워크는 "애플리케이션 및/또는 이해관계자 커뮤니티의 특정 영역 내에 구축된 아키텍처의 설명을 위한 개념, 원칙 및 실천요강"(ISO/IECE/IEEE 42010)을 포착한다.프레임워크는 보통 하나 이상의 관점 또는 ADL의 관점에서 구현된다.소프트웨어 아키텍처에 대한 관심 프레임워크는 다음을 포함한다.

다중 뷰

"4+1 뷰 모델"에 관한 1995년 크루히텐의 매우 영향력 있는 논문에 제시된 이 접근방식은 모델링되어야 할 다양한 이해관계자와 우려를 강조했다.[2]

구조주의

둘째로, CMU 등의 작업에 반영되어, 아키텍처는 런타임에 시스템의 높은 수준의 조직이었고 아키텍처는 그 요소와 커넥터의 관점에서 설명되어야 한다: "소프트웨어 시스템의 아키텍처는 그러한 컴포들 사이의 컴퓨터 구성 요소와 상호작용의 관점에서 시스템을 정의한다.nents".[7]

1990년대부터 2000년대까지 ADL에 관한 학문적 연구의 대부분은 부품과 커넥터의 패러다임 안에서 이루어졌다.그러나 이러한 ADL은 산업에서 거의 영향을 미치지 않았다.[8]1990년대 이후, 2000년 IEEE 1471이 모범 사례를 체계화하여 AD의 다중 관점을 지원하되 필요하지 않다.

의사 결정을 통한 아키텍처 설명

페리와 울프의 원래 공식의 이론적 측면을 상세히 설명하면서, 결정과 이유를 소프트웨어 아키텍처를 구상하고 표현하는 필수적인 방법으로 문서화하는 제3의 사상이 등장했다.[9]이 접근방식은 의사결정을 아키텍처 설명의 일급 요소로 취급하며, 초기 표현에 종종 내포되어 있던 것을 명시한다.

아키텍처 설명 사용

아키텍처 설명은 (ISO/IEC/IEEE 42010):

  • 시스템 구축과 유지보수를 지도하다
  • 시스템 계획, 비용 및 진화를 지원
  • 아키텍처의 분석, 평가 또는 비교를 위한 매개체 역할을 하다
  • 구조와 시스템에 관한 시스템 이해당사자간의 커뮤니케이션을 촉진한다.
  • 개별 프로젝트(소프트웨어 제품군 및 제품군, 레퍼런스 아키텍처 등)의 범위를 벗어난 아키텍처 지식을 문서화한다.
  • 재사용 가능한 건축 관용구(건축 스타일 및 패턴 등)를 캡처한다.

참조

  1. ^ a b Perry, D. E.; Wolf, A. L. (1992)"소프트웨어 아키텍처 연구를 위한 기초"ACM SIGSoft 소프트웨어 엔지니어링 노트 17(4): 40. doi:10.1145/141874.1484
  2. ^ a b P. B. Kruchten, "건축의 '4+1' 뷰 모델", IEEE Software, vol. 12, no. 6, 페이지 42–50, 1995년 11월
  3. ^ A. 핑클슈타인, J. 크레이머, B.누세베, L. 핀켈슈타인, M.괴딕케.관점: 시스템 개발에 여러 관점을 통합하기 위한 프레임워크.국제 소프트웨어 엔지니어링 및 지식 엔지니어링 저널 2:1:31-58, 1992.
  4. ^ a b P. C. 클레멘츠, F.Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, R. Nord 및 J. Stepord, Documenting Software Architectures: 뷰 및 그 이상.애디슨 웨슬리, 2003년
  5. ^ G. 에스트린, R.S. 펜첼, R. Razouk, M.K. 버논, "The System Architecture's Affective", IEEE Transactions of Software Engineering, 1986.
  6. ^ F. DeRemer 및 H.H. Kron, "대규모 프로그래밍 대 소규모 프로그래밍", IEEE Transactions on Software Engineering, 1976년
  7. ^ M. Shaw와 D.Garlan, Software Architecture: 새로운 분야에 대한 관점, 프렌티스 홀, 1996.
  8. ^ E. 우즈와 R.Hilliard, "Achitecture Description Language in Practice" http://doi.ieeecomputersociety.org/10.1109/WICSA.2005.15
  9. ^ A. Jansen과 J. Bosch, "건축 설계 결정 집합으로서의 소프트웨어 아키텍처" 2005년 제5차 소프트웨어 아키텍처 워킹 IEEE/IFIP 회의의 진행.

참고 항목