뷰 모델

시스템 공학, 소프트웨어 공학, 기업공학에서 뷰 모델(view model) 또는 뷰포인트 프레임워크(viewpoints framework)는 시스템 아키텍처, 소프트웨어 구조 또는 엔터프라이즈 아키텍처 구축에 사용될 일관된 뷰 집합을 정의하는 프레임워크이다. 뷰는 관련 문제 집합의 관점에서 전체 시스템을 나타낸 것이다.^[1][2]

TEAF 관점 및 시점 매트릭스

1990년대 초반부터 시스템 아키텍처를 설명하고 분석하는 접근 방식을 규정하려는 많은 노력이 있었다. 이러한 노력의 결과는 뷰(또는 뷰포인트) 집합을 정의하는 것이었다. 이러한 것들은 때때로 아키텍처 프레임워크 또는 엔터프라이즈 아키텍처 프레임워크라고도 불리지만, 일반적으로 "뷰 모델"이라고 불린다.

일반적으로 뷰는 특정 시스템에 대한 특정 아키텍처 데이터를 제시하는 작업 산출물이다. 그러나 동일한 용어가 때로는 특정 뷰포인트와 각 구체적인 뷰를 정의하는 해당 지침을 포함하는 뷰 정의를 참조하는 데 사용되기도 한다. 뷰 모델이라는 용어는 뷰 정의와 관련이 있다.

개요

뷰와 뷰포인트의 목적은 인간이 매우 복잡계를 이해하고, 전문성 영역을 중심으로 문제와 해결책의 요소를 조직하고, 관심사를 분리하는 것이다. 물리적으로 집중적인 시스템의 공학에서 뷰포인트는 종종 공학 조직 내의 역량 및 책임과 일치한다.^[3]

대부분의 복잡한 시스템 명세는 너무 광범위하여 한 개인이 명세의 모든 측면을 완전히 이해할 수 없다. 또한, 우리는 주어진 시스템에 대해 서로 다른 관심사를 가지고 있으며 시스템의 명세를 검토하는 이유도 다르다. 사업 임원은 시스템 구현자보다 시스템 구성에 대해 다른 질문을 할 것이다. 따라서 뷰포인트 프레임워크의 개념은 이해관계자와의 의사소통을 용이하게 하기 위해 주어진 복잡한 시스템의 명세에 대한 개별적인 뷰포인트를 제공하는 것이다. 각 뷰포인트는 시스템의 특정 측면에 관심을 가진 청중을 만족시킨다. 각 뷰포인트는 해당 뷰포인트의 청중을 위해 어휘와 표현을 최적화하는 특정 뷰포인트 언어를 사용할 수 있다. 뷰포인트 모델링은 대규모 분산 시스템의 고유한 복잡성을 다루는 효과적인 접근 방식이 되었다.

IEEE Std 1471-2000에 설명된 아키텍처 설명 관행은 여러 관심 영역을 다루기 위해 여러 뷰를 사용하며, 각 뷰는 시스템의 특정 측면에 중점을 둔다. 여러 뷰를 사용하는 아키텍처 프레임워크의 예로는 크룩텐의 "4+1" 뷰 모델, 자크만 프레임워크, TOGAF, DoDAF, RM-ODP가 있다.

역사

1970년대에 소프트웨어 공학에서 여러 뷰를 사용하여 모델링하는 방법이 등장하기 시작했다. 더글러스 T. 로스와 K.E. 쇼먼은 1977년에 시스템 요구사항 정의에서 모델링 프로세스를 조직하기 위해 컨텍스트, 뷰포인트, 시점 구성을 도입했다.^[4] 로스와 쇼먼에 따르면, 뷰포인트는 "[모델의] 전체 목적을 달성하는 데 관련 있다고 간주되는 측면을 명확히 하고" "[모델링되는 대상]을 어떻게 볼 것인가"를 결정한다.

뷰포인트의 예로는 기술적, 운영적, 경제적 뷰포인트가 제시된다. 1992년, 앤서니 핀켈스타인 외 다수는 뷰포인트에 관한 매우 중요한 논문을 발표했다.^[5] 이 연구에서: "뷰포인트는 개발 프로세스에서 '행위자', '지식 출처', '역할' 또는 '에이전트'라는 개념과 행위자가 유지하는 '뷰' 또는 '관점'이라는 개념의 조합으로 생각할 수 있다." 이 논문의 중요한 아이디어는 "뷰포인트가 볼 수 있는 것을 표현하는 방식, 스키마 및 표기법인 표현 스타일"과 "뷰포인트의 스타일로 특정 도메인을 설명하는 진술인 명세"를 구별하는 것이었다. IEEE 1471과 같은 후속 작업은 각각 뷰포인트와 뷰라는 두 개의 별도 용어를 사용하여 이러한 구별을 유지했다.

1990년대 초반부터 시스템 아키텍처를 설명하고 분석하는 접근 방식을 체계화하려는 여러 노력이 있었다. 이러한 것들은 종종 아키텍처 프레임워크 또는 때로는 뷰포인트 집합이라고 불린다. 이들 중 다수는 미국 국방부의 자금 지원을 받았지만, 일부는 ISO 또는 IEEE의 국제적 또는 국가적 노력에서 비롯되었다. 이들 중, 소프트웨어 집중 시스템의 아키텍처 설명에 대한 IEEE 권장 실무 지침(IEEE Std 1471-2000)은 뷰, 뷰포인트, 이해관계자 및 관심사의 유용한 정의와 이해관계자 관심사를 다루기 위해 뷰포인트를 적용하여 여러 뷰를 사용하여 시스템 아키텍처를 문서화하는 지침을 수립했다.^[6] 여러 뷰를 사용하는 이점은 숨겨진 요구사항과 이해관계자 간의 불일치를 더 쉽게 발견할 수 있다는 것이다. 그러나 연구에 따르면 실제로는 여러 뷰를 조정하는 추가 복잡성이 이러한 이점을 약화시킬 수 있다.^[7]

IEEE 1471 (현재 ISO/IEC/IEEE 42010:2011, 시스템 및 소프트웨어 공학 — 아키텍처 설명)은 아키텍처 설명의 내용을 규정하고, 전례 있는/없는 설계, 진화적 설계, 기존 시스템의 설계 캡처를 포함한 여러 시나리오에서 이들의 생성 및 사용을 설명한다. 이 모든 시나리오에서 전체 프로세스는 동일하다: 이해관계자를 식별하고, 관심사를 도출하고, 사용될 뷰포인트 집합을 식별한 다음, 이러한 뷰포인트 명세를 적용하여 관심 시스템과 관련된 뷰 집합을 개발한다. 특정 뷰포인트 집합을 정의하는 대신, 이 표준은 아키텍트와 조직이 자체 뷰포인트를 정의하기 위한 균일한 메커니즘과 요구사항을 제공한다. 1996년에 분산 처리 참조 모델(RM-ODP) ISO가 대규모 분산 시스템의 아키텍처 및 설계를 설명하는 데 유용한 프레임워크를 제공하기 위해 발표되었다.

뷰 모델 주제

뷰

시스템의 뷰는 뷰포인트의 관점에서 시스템을 나타낸 것이다. 시스템에 대한 이 뷰포인트는 시스템에 관한 특정 관심사에 초점을 맞추는 관점을 포함하며, 뷰포인트의 관심사와 관련된 요소만 포함하는 단순화된 모델을 제공하기 위해 세부 사항을 숨긴다. 예를 들어, 보안 뷰포인트는 보안 관심사에 초점을 맞추고, 보안 뷰포인트 모델은 시스템의 더 일반적인 모델에서 보안과 관련된 요소를 포함한다.^[8]

뷰는 사용자가 특정 관심 영역의 일부를 검사할 수 있도록 한다. 예를 들어, 정보 뷰는 특정 정보 조각을 사용하는 모든 기능, 조직, 기술 등을 제시할 수 있는 반면, 조직 뷰는 특정 조직과 관련된 모든 기능, 기술 및 정보를 제시할 수 있다. 자크만 프레임워크에서 뷰는 개발에 특정 분석 및 기술 전문 지식이 필요한 작업 산출물 그룹을 포함한다. 이는 기업의 "무엇," "어떻게," "누가," "어디서," "언제," 또는 "왜"에 초점을 맞추기 때문이다. 예를 들어, 기능 뷰 작업 산출물은 "임무는 어떻게 수행되는가?"라는 질문에 답한다. 이러한 작업 산출물은 프로세스 및 활동 모델링을 사용하는 기능 분해 전문가가 가장 쉽게 개발할 수 있다. 이들은 기능의 관점에서 기업을 보여준다. 또한 조직 및 정보 구성 요소를 보여줄 수도 있지만, 기능과 관련될 때만 보여준다.^[9]

뷰포인트

시스템 공학에서 뷰포인트는 시스템 내 관심사의 분할 또는 제한이다. 뷰포인트를 채택하는 것은 해당 측면의 문제를 별도로 다룰 수 있도록 유용하다. 뷰포인트를 잘 선택하면 시스템 설계가 특정 전문 분야로 분할되기도 한다.^[3]

뷰포인트는 뷰를 구성하고 제시하며 분석하기 위한 규칙, 규약 및 언어를 제공한다. ISO/IEC 42010:2007(IEEE-Std-1471-2000)에서 뷰포인트는 개별 뷰에 대한 명세이다. 뷰는 뷰포인트의 관점에서 전체 시스템을 나타낸 것이다. 뷰는 하나 이상의 아키텍처 모델로 구성될 수 있다.^[10] 각 아키텍처 모델은 관련 아키텍처 시스템과 전체 시스템에 의해 설정된 방법을 사용하여 개발된다. ^[6]

모델링 관점

모델링 관점은 시스템의 미리 선택된 측면을 표현하는 다양한 방식의 집합이다. 각 관점은 모델이 나타내는 것에 대해 다른 초점, 개념화, 전념 및 시각화를 가지고 있다.

정보 시스템에서 모델링 관점을 나누는 전통적인 방법은 구조적, 기능적, 행동/프로세스적 관점을 구별하는 것이다. 이는 규칙, 객체, 통신, 행위자 및 역할 관점과 함께 모델링 접근 방식을 분류하는 한 가지 방법이다.^[11]

뷰포인트 모델

주어진 뷰포인트에서 해당 뷰포인트에서 보이는 객체만 포함하지만 시스템에 존재하고 해당 뷰포인트와 관련된 모든 객체, 관계 및 제약 조건을 캡처하는 시스템 모델을 만드는 것이 가능하다. 이러한 모델을 뷰포인트 모델 또는 해당 뷰포인트에서 본 시스템의 뷰라고 한다.^[3]

주어진 뷰는 특정 뷰포인트에서 특정 추상화 수준의 시스템에 대한 명세이다. 추상화 수준이 다르면 세부 수준도 다르다. 상위 수준 뷰는 엔지니어가 전체 설계를 구상하고 이해하며 큰 문제점을 식별하고 해결할 수 있도록 한다. 하위 수준 뷰는 엔지니어가 설계의 일부에 집중하고 상세 명세를 개발할 수 있도록 한다.^[3]

그러나 시스템 자체에서 다양한 뷰포인트 모델에 나타나는 모든 명세는 시스템의 실제 구성 요소에서 다루어져야 한다. 그리고 주어진 구성 요소에 대한 명세는 여러 다른 뷰포인트에서 가져올 수 있다. 반면에, 특정 구성 요소 및 구성 요소 상호 작용에 걸친 기능 분배에 의해 유도된 명세는 일반적으로 원래 뷰포인트에 반영된 것과는 다른 관심사 분할을 반영할 것이다. 따라서 개별 구성 요소 및 시스템의 상향식 합성에 대한 관심사를 다루는 추가 뷰포인트도 유용할 수 있다.^[3]

아키텍처 설명

아키텍처 설명은 구성 요소, 해당 구성 요소의 작동 방식, 해당 구성 요소가 작동하는 규칙 및 제약 조건, 해당 구성 요소가 서로 및 환경과 어떻게 관련되는지에 대한 시스템 아키텍처의 표현이다. 아키텍처 설명에서 아키텍처 데이터는 여러 뷰 및 제품에 걸쳐 공유된다.

데이터 계층에는 아키텍처 데이터 요소와 해당 정의 속성 및 관계가 있다. 프레젠테이션 계층에는 아키텍처의 목적, 설명하는 내용, 수행된 다양한 아키텍처 분석을 시각적으로 전달하고 이해하는 데 도움이 되는 제품 및 뷰가 있다. 제품은 아키텍처 데이터를 그래픽, 표 또는 텍스트 형식으로 시각화하는 방법을 제공한다. 뷰는 제품 전반에 걸쳐 아키텍처 데이터를 시각화하고, 아키텍처의 특정 또는 전체적인 관점을 위해 데이터를 논리적으로 구성하는 기능을 제공한다.

시스템 뷰 모델의 유형

3-스키마 접근 방식

3-스키마 모델의 개념은 1977년 ANSI/X3/SPARC 3단계 아키텍처에 의해 처음 도입되었으며, 이는 데이터를 모델링하기 위한 세 가지 수준을 결정했다.^[12]

1977년에 도입된 3-스키마 접근 방식은 데이터 모델링을 위한 최초의 뷰 모델 중 하나로 간주될 수 있다. 이는 개념 모형을 데이터 통합을 달성하기 위한 핵심으로 홍보하는 정보 시스템 및 시스템 정보 관리를 구축하는 접근 방식이다.^[13] 3-스키마 접근 방식은 세 가지 스키마와 뷰를 정의한다.

• 사용자 뷰를 위한 외부 스키마
• 개념 스키마는 외부 스키마를 통합한다.
• 물리적 저장 구조를 정의하는 내부 스키마

중심에서 개념 스키마는 사용자가 생각하고 이야기하는 방식대로 개념의 온톨로지를 정의한다. 물리적 스키마는 데이터베이스에 저장된 데이터의 내부 형식을 설명하고, 외부 스키마는 애플리케이션 프로그램에 제시되는 데이터의 뷰를 정의한다.^[14] 이 프레임워크는 외부 스키마에 여러 데이터 모델을 사용할 수 있도록 시도했다.^[15]

수년에 걸쳐 정보 시스템 구축에 대한 기술과 관심은 엄청나게 성장했다. 그러나 대부분의 경우 시스템 구축에 대한 전통적인 접근 방식은 "사용자 뷰"와 "컴퓨터 뷰"라는 두 가지 뚜렷한 뷰에서 데이터를 정의하는 데만 중점을 두었다. "외부 스키마"라고 불리는 사용자 뷰에서 데이터의 정의는 개인이 특정 작업을 수행하는 데 도움이 되도록 설계된 보고서 및 화면의 맥락에서 이루어진다. 사용량 뷰에서 데이터의 필수 구조는 비즈니스 환경과 사용자의 개별 선호도에 따라 변경된다. "내부 스키마"라고 불리는 컴퓨터 뷰에서 데이터는 저장 및 검색을 위한 파일 구조 측면에서 정의된다. 컴퓨터 저장을 위한 데이터의 필수 구조는 사용된 특정 컴퓨터 기술과 데이터의 효율적인 처리에 대한 필요성에 따라 달라진다.^[16]

4+1 아키텍처 뷰 모델

4+1 뷰 모델 또는 아키텍처의 그림

4+1은 1995년 필립 크룩텐이 여러 동시 뷰를 기반으로 소프트웨어 집중 시스템의 아키텍처를 설명하기 위해 설계한 뷰 모델이다.^[17] 뷰는 최종 사용자, 개발자 및 프로젝트 관리자와 같은 다양한 이해관계자의 관점에서 시스템을 설명하는 데 사용된다. 모델의 네 가지 뷰는 논리적, 개발, 프로세스 및 물리적 뷰이다.

모델의 네 가지 뷰는 다음을 다룬다.

• 논리적 뷰: 시스템이 최종 사용자에게 제공하는 기능과 관련된다.
• 개발 뷰: 프로그래머의 관점에서 시스템을 보여주며 소프트웨어 관리와 관련된다.
• 프로세스 뷰: 시스템의 동적 측면을 다루고, 시스템 프로세스와 통신 방식을 설명하며, 시스템의 런타임 동작에 중점을 둔다.
• 물리적 뷰: 시스템 엔지니어의 관점에서 시스템을 나타낸다. 물리적 계층에서 소프트웨어 구성 요소의 토폴로지와 이러한 구성 요소 간의 통신과 관련된다.

또한 선택된 유스 케이스 또는 시나리오는 아키텍처를 설명하는 데 활용된다. 따라서 모델은 4+1 뷰를 포함한다.^[17]

엔터프라이즈 아키텍처 뷰의 종류

엔터프라이즈 아키텍처 프레임워크는 엔터프라이즈 아키텍처와 관련된 구조와 뷰를 구성하는 방법을 정의한다. 엔터프라이즈 아키텍처 및 공학 분야가 매우 광범위하고, 기업이 크고 복잡할 수 있기 때문에, 해당 분야와 관련된 모델 또한 크고 복잡한 경향이 있다. 이러한 규모와 복잡성을 관리하기 위해 아키텍처 프레임워크는 작업을 집중시키고 가장 필요할 때 가치 있는 산출물을 생산할 수 있는 도구와 방법을 제공한다.

아키텍처 프레임워크는 일반적으로 정보기술 및 정보 시스템 거버넌스에서 사용된다. 조직은 시스템 설계가 승인되기 전에 특정 모델이 생산되도록 의무화할 수 있다. 유사하게, 조달된 시스템의 문서화에 특정 뷰가 사용되도록 지정할 수 있다. 미 국방부는 특정 가치 이상의 자본 프로젝트에 대해 장비 공급업체가 특정 DoDAF 뷰를 제공하도록 규정하고 있다.

자크만 프레임워크

행 설명과 함께 자크만 프레임워크의 간소화된 그림.^[18] 원본 프레임워크는 더 고급이다. 예를 들어 여기를 참조.

1987년 IBM의 존 자크만이 처음 구상한 자크만 프레임워크는 기업을 보고 정의하는 공식적이고 고도로 구조화된 방식을 제공하는 엔터프라이즈 아키텍처를 위한 프레임워크이다.

이 프레임워크는 아키텍처 "산출물"을 누가 산출물을 대상으로 하는지(예: 비즈니스 소유자 및 구축자)와 어떤 특정 문제(예: 데이터 및 기능)를 다루는지 모두 고려하는 방식으로 구성하는 데 사용된다. 이러한 산출물에는 설계 문서, 명세 및 모델이 포함될 수 있다.^[19]

자크만 프레임워크는 엔터프라이즈 아키텍처의 기본 요소를 표현하는 표준 접근 방식으로 자주 언급된다. 자크만 프레임워크는 미국 연방 정부로부터 "...기업 및 이를 지원하는 시스템의 변화를 관리하기 위한 통합 프레임워크로 전 세계적으로 인정받았다"고 인정받았다.^[20]

RM-ODP 뷰

시스템과 그 환경에 대한 5가지 일반적이고 상호 보완적인 뷰포인트를 제공하는 RM-ODP 뷰 모델

국제 표준화 기구(ISO) 개방 분산 처리 참조 모델(RM-ODP)^[21]는 분산 소프트웨어/하드웨어 시스템의 설계를 분할하기 위한 뷰포인트 집합을 지정한다. 대부분의 통합 문제는 이러한 시스템의 설계 또는 매우 유사한 상황에서 발생하므로, 이러한 뷰포인트는 통합 문제를 분리하는 데 유용할 수 있다. RM-ODP 뷰포인트는 다음과 같다.^[3]

• 기업 뷰포인트: 조직의 비즈니스 목표 및 비즈니스 프로세스와 관련하여 시스템의 목적과 동작을 다룬다.
• 정보 뷰포인트: 시스템에서 처리되는 정보의 본질 및 해당 정보의 사용 및 해석에 대한 제약 조건을 다룬다.
• 계산 뷰포인트: 시스템을 특정 동작을 나타내고 인터페이스에서 상호 작용하는 구성 요소 집합으로 기능적으로 분해하는 것과 관련된다.
• 엔지니어링 뷰포인트: 계산 구성 요소의 상호 작용을 지원하는 데 필요한 메커니즘 및 기능을 다룬다.
• 기술 뷰포인트: 시스템 구현, 특히 구성 요소 간 통신을 위한 기술의 명시적 선택을 다룬다.

RM-ODP는 또한 뷰포인트 간 일관성 명세를 설계에 포함할 것을 요구한다.^[3]

• 정보 단위를 정의하는 데 기업 객체 및 프로세스 사용
• 계산 구성 요소의 동작을 지정하는 데 기업 객체 및 동작 사용, 계산 인터페이스를 정의하는 데 정보 단위 사용
• 공학적 선택과 계산 인터페이스 및 동작 요구사항의 연관성
• 선택된 기술에서 정보, 계산 및 공학 요구사항의 충족

DoDAF 뷰

미국 국방부 아키텍처 프레임워크(DoDAF)는 엔터프라이즈 아키텍처(EA) 또는 시스템 아키텍처를 보완적이고 일관된 뷰로 구성하는 표준적인 방법을 정의한다. 복잡한 통합 및 상호 운용성 과제를 가진 대규모 시스템에 특히 적합하며, 개발 중인 시스템이 작동할 외부 고객의 운영 도메인을 상세히 설명하는 "운영 뷰"를 사용하는 데 있어 독특하다고 할 수 있다.

DoDAF 뷰 간의 연결^[22]

DoDAF는 그래픽, 표, 텍스트 수단을 통해 아키텍처 설명의 광범위한 범위와 복잡성을 시각화하고 이해하며 동화하는 메커니즘 역할을 하는 일련의 제품을 정의한다. 이 제품은 네 가지 뷰로 구성된다.

• 상위 전체 뷰 (AV),
• 운영 뷰 (OV),
• 시스템 뷰 (SV), 그리고
• 기술 표준 뷰 (TV).

각 뷰는 아래 설명된 대로 아키텍처의 특정 관점을 나타낸다. 각 시스템 개발에는 전체 DoDAF 뷰셋의 하위 집합만 생성되는 것이 일반적이다. 이 그림은 운영 뷰, 시스템 및 서비스 뷰, 기술 표준 뷰를 연결하는 정보를 나타낸다. 세 가지 뷰와 이들의 상호 관계는 공통 아키텍처 데이터 요소에 의해 구동되며, 상호 운용성 또는 성능과 같은 측정값을 도출하고, 이러한 메트릭 값의 운영 임무 및 작업 효율성에 미치는 영향을 측정하는 기반을 제공한다.^[22]

연방 엔터프라이즈 아키텍처 뷰

미국 연방 엔터프라이즈 아키텍처에서 엔터프라이즈, 세그먼트, 솔루션 아키텍처는 세부 수준을 다양화하고 관련되지만 구별되는 문제를 다룸으로써 다른 비즈니스 관점을 제공한다. 기업 자체가 계층적으로 조직된 것처럼, 각 아키텍처 유형이 제공하는 다양한 뷰도 계층적이다. 연방 엔터프라이즈 아키텍처 실무 지침(2006)은 세 가지 유형의 아키텍처를 정의했다.^[23]

연방 엔터프라이즈 아키텍처 수준 및 속성^[23]

• 엔터프라이즈 아키텍처
• 세그먼트 아키텍처, 그리고
• 솔루션 아키텍처.

정의에 따르면 엔터프라이즈 아키텍처(EA)는 전략, 비즈니스 프로세스, 투자, 데이터, 시스템 또는 기술 등 공통 또는 공유 자산을 식별하는 것과 근본적으로 관련된다. EA는 전략에 의해 주도되며, 기관이 자원을 기관 임무 및 전략적 목표에 적절하게 조정했는지 식별하는 데 도움이 된다. 투자 관점에서 EA는 IT 투자 포트폴리오 전체에 대한 의사 결정을 이끌어내는 데 사용된다. 따라서 EA의 주요 이해관계자는 기관이 임무를 가능한 한 효과적이고 효율적으로 수행하도록 보장하는 고위 관리자와 임원이다.^[23]

대조적으로, 세그먼트 아키텍처는 핵심 임무 영역, 비즈니스 서비스 또는 엔터프라이즈 서비스를 위한 간단한 로드맵을 정의한다. 세그먼트 아키텍처는 비즈니스 관리에 의해 주도되며 시민 및 기관 직원에 대한 서비스 제공을 개선하는 제품을 제공한다. 투자 관점에서 세그먼트 아키텍처는 핵심 임무 영역 또는 공통 또는 공유 서비스를 지원하는 비즈니스 사례 또는 비즈니스 사례 그룹에 대한 의사 결정을 이끌어낸다. 세그먼트 아키텍처의 주요 이해관계자는 비즈니스 소유자 및 관리자이다. 세그먼트 아키텍처는 구조, 재사용 및 정렬의 세 가지 원칙을 통해 EA와 관련된다. 첫째, 세그먼트 아키텍처는 EA에서 사용되는 프레임워크를 상속하지만, 핵심 임무 영역 또는 공통 또는 공유 서비스의 특정 요구 사항을 충족하도록 확장 및 전문화될 수 있다. 둘째, 세그먼트 아키텍처는 데이터, 공통 비즈니스 프로세스 및 투자, 애플리케이션 및 기술을 포함하여 엔터프라이즈 수준에서 정의된 중요한 자산을 재사용한다. 셋째, 세그먼트 아키텍처는 비즈니스 전략, 명령, 표준 및 성과 측정과 같이 엔터프라이즈 수준에서 정의된 요소와 정렬된다.^[23]

명목상 뷰 집합

"우주 시스템 아키텍처 모델링을 위한 프레임워크"를 탐색하면서 피터 셰임즈와 조셉 스키퍼(2006)는 "명목상 뷰 집합"을 정의했다.^[6] CCSDS RASDS, RM-ODP, ISO 10746에서 파생되었으며 IEEE 1471을 준수한다.

"명목상 뷰 집합"의 그림^[24]

아래 설명된 "뷰 집합"은 가능한 모델링 뷰포인트의 목록이다. 이 모든 뷰가 어떤 프로젝트에도 사용될 필요는 없으며, 필요에 따라 다른 뷰가 정의될 수 있다. 일부 분석에서는 여러 뷰포인트의 요소가 새로운 뷰로 결합될 수 있으며, 아마도 계층화된 표현을 사용할 수도 있다.

후반부 발표에서 이 명목상 뷰 집합은 확장된 RASDS 의미 정보 모델 파생으로 제시되었다.^[24] 여기서 RASDS는 우주 데이터 시스템을 위한 참조 아키텍처(Reference Architecture for Space Data Systems)를 의미한다. 두 번째 이미지를 참조하라.

기업 뷰포인트^[6]

• 조직 뷰 – 조직 요소와 그 구조 및 관계를 포함한다. 합의, 계약, 정책 및 조직 상호 작용을 포함할 수 있다.
• 요구사항 뷰 – 시스템을 구동하는 요구사항, 목표, 목적을 설명한다. 시스템이 무엇을 할 수 있어야 하는지 설명한다.
• 시나리오 뷰 – 시스템이 사용될 의도된 방식을 설명한다. 시나리오 계획을 참조하라. 사용자 뷰와 시스템이 어떻게 동작할 것으로 예상되는지에 대한 설명을 포함한다.

정보 뷰포인트^[6]

• 메타모델 뷰 – 정보 모델 요소와 그 구조 및 관계를 정의하는 추상적인 뷰이다. 시스템에 의해 생성 및 관리되는 데이터 클래스와 데이터 아키텍처를 정의한다.
• 정보 뷰 – 시스템 내에서 실제 데이터 및 정보가 어떻게 실현되고 조작되는지를 설명한다. 데이터 요소는 메타모델 뷰에 의해 정의되며 다른 뷰의 기능 객체에 의해 참조된다.

우주 데이터 시스템을 위한 참조 아키텍처^[24]

기능 뷰포인트^[6]

• 기능 데이터 흐름 뷰 – 시스템의 기능 요소, 그 상호 작용, 동작, 제공되는 서비스, 제약 조건 및 데이터 흐름을 설명하는 추상적인 뷰이다. 이러한 기능이 실제로 어떻게 구현되는지와 관계없이 시스템이 수행할 수 있는 기능을 정의한다.
• 기능 제어 뷰 – 시스템 내 기능 요소 간의 제어 흐름 및 상호 작용을 설명한다. 전체 시스템 제어 상호 작용, 제어 요소와 센서/이펙터 요소 간의 상호 작용 및 관리 상호 작용을 포함한다.

물리적 뷰포인트^[6]

• 데이터 시스템 뷰 – 기기, 컴퓨터, 데이터 저장 구성 요소, 해당 데이터 시스템 속성 및 시스템에 사용되는 통신 연결(버스, 네트워크, 지점 간 링크)을 설명한다.
• 통신 뷰 – 통신 구성 요소(안테나, 트랜시버), 해당 속성 및 해당 연결(RF 또는 광학 링크)을 설명한다.
• 내비게이션 뷰 – 시스템 내 주요 요소의 움직임(궤적, 경로, 궤도)을 설명하며, 시스템의 제어 밖에 있지만 시스템 동작을 이해하기 위해 모델링해야 하는 외부 요소 및 힘(행성, 소행성, 태양 압력, 중력)과의 상호 작용을 포함한다.
• 구조 뷰 – 시스템의 구조 구성 요소(우주선 버스, 스트럿, 패널, 연결부), 해당 물리적 속성 및 연결부, 기타 구성 요소의 관련 구조적 측면(질량, 강성, 부착)을 설명한다.
• 열 뷰 – 시스템의 능동 및 수동 열 구성 요소(라디에이터, 냉각기, 통풍구)와 해당 연결부(물리적 및 자유 공간 방사선) 및 속성을 설명하며, 기타 구성 요소의 열 속성(예: 태양 가리개로서의 안테나)을 포함한다.
• 전력 뷰 – 시스템 내 능동 및 수동 전력 구성 요소(태양광 패널, 배터리, RTG)와 해당 연결부를 설명하며, 기타 구성 요소의 전력 속성(데이터 시스템 및 추진 요소는 전력 소모원, 구조 패널은 접지면)을 포함한다.
• 추진 뷰 – 시스템 내 능동 및 수동 추진 구성 요소(추진기, 자이로, 모터, 바퀴)와 해당 연결부를 설명하며, 기타 구성 요소의 추진 속성을 포함한다.

명목상 뷰 집합을 기반으로 한 MBED 최상위 온톨로지^[6]

엔지니어링 뷰포인트^[6]

• 할당 뷰 – 기능 객체를 시스템 내에서 공학적으로 제작된 물리적 및 계산 구성 요소에 할당하는 것을 설명하며, 성능 분석 및 요구사항 충족 검증에 사용된다.
• 소프트웨어 뷰 – 시스템의 소프트웨어 공학적 측면, 소프트웨어 구성 요소 내 기능의 소프트웨어 설계 및 구현, 사용될 언어 및 라이브러리 선택, API 정의, 추상 기능 객체를 실제 소프트웨어 요소로 공학하는 것을 설명한다. 소프트웨어 언어를 사용하여 설명된 일부 기능 요소는 실제로 하드웨어(FPGA, ASIC)로 구현될 수 있다.
• 하드웨어 뷰 – 시스템의 하드웨어 공학적 측면, 하드웨어 설계, 시스템으로 조립될 모든 물리적 구성 요소의 선택 및 구현을 설명한다. 이러한 뷰는 여러 개 있을 수 있으며, 각 뷰는 다른 공학 분야에 특화된다.
• 통신 프로토콜 뷰 – 통신 프로토콜 및 관련 데이터 전송 및 데이터 관리 서비스의 엔드투엔드 설계를 설명하며, 시스템의 각 물리적 구성 요소에 구현된 프로토콜 스택을 보여준다.
• 위험 뷰 – 시스템 설계, 프로세스 및 기술과 관련된 위험을 설명하고, 아키텍처에 설명된 다른 요소에 추가 위험 평가 속성을 할당한다.
• 제어 공학 뷰 – 제어 가능성, 제어 대상 시스템 및 제어 시스템으로 요소 할당의 관점에서 시스템을 분석한다.
• 통합 및 테스트 뷰 – 시스템 및 서브 시스템, 어셈블리를 조립, 통합 및 테스트하기 위해 무엇을 해야 하는지 관점에서 시스템을 살펴본다. 요구사항 충족을 위해 시나리오에 의해 구동되는 적절한 기능 검증을 포함한다.
• IV&V 뷰 – 요구사항 충족을 위한 시스템 기능 및 적절한 작동의 독립적인 검증 및 확인. 설계 및 개발된 시스템이 목표 및 목적을 충족하는지 여부.

기술 뷰포인트^[6]

• 표준 뷰 – 시스템 설계(예: 통신 프로토콜, 방사선 내성, 납땜) 중에 채택될 표준을 정의한다. 이는 본질적으로 설계 및 구현 프로세스에 대한 제약 조건이다.
• 인프라 뷰 – 엔지니어링, 설계 및 제작 프로세스를 지원할 인프라 요소를 정의한다. 데이터 시스템 요소(설계 리포지토리, 프레임워크, 도구, 네트워크) 및 하드웨어 요소(칩 제작, 열 진공 시설, 기계 공장, RF 테스트 랩)를 포함할 수 있다.
• 기술 개발 및 평가 뷰 – 시스템 개발 프로젝트에 포함될 수 있는 알고리즘 또는 구성 요소를 생산하도록 설계된 기술 개발 프로그램을 설명한다. 설계 중인 임무에 채택될 만큼 충분히 성숙한 상태인지 판단하기 위해 선택된 하드웨어 및 소프트웨어 구성 요소의 속성 평가를 포함한다.

이전에 나열된 뷰 모델과 달리, 이 "명목상 뷰 집합"은 광범위한 뷰를 나열하며, 일반적인 소프트웨어 집약적 시스템 아키텍처를 설명하기 위한 강력하고 확장 가능한 접근 방식을 개발할 수 있다.^[6]

같이 보기

• 엔터프라이즈 아키텍처 프레임워크
• 조직 아키텍처
• 소프트웨어 개발 방법론
• 재무부 엔터프라이즈 아키텍처 프레임워크
• TOGAF
• 자크만 프레임워크
• 온톨로지
• 지식 습득