모델 표시

View model
다른 용도는 모형 보기(동음이의)를 참조하십시오.
TEAF의 뷰와 관점 매트릭스.

시스템 엔지니어링, 소프트웨어 엔지니어링 및 엔터프라이즈 엔지니어링 뷰 모델 또는 뷰포인트 프레임워크는 시스템 아키텍처, 소프트웨어 아키텍처 또는 엔터프라이즈 아키텍처 구축에 사용되는 일관된 뷰 세트를 정의하는 프레임워크입니다.뷰는 관련된 일련의 [1][2]관심사 관점에서 전체 시스템을 표현한 것입니다.

1990년대 초반부터 시스템 아키텍처를 기술하고 분석하기 위한 접근방식을 규정하기 위한 많은 노력이 있었습니다.이러한 최근의 대처는 일련의 뷰(또는 뷰포인트)가 정의됩니다.이들은 아키텍처 프레임워크 또는 엔터프라이즈 아키텍처 프레임워크라고 불리기도 하지만 일반적으로 "뷰 모델"이라고 불립니다.

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

개요

관점과 관점의 목적은 인간이 매우 복잡한 시스템을 이해할 수 있게 하고, 문제의 요소와 해결책을 전문 영역 중심으로 정리하고, 관심사를 분리하는 것이다.물리 집약적인 시스템의 엔지니어링에서 관점은 엔지니어링 [3]조직 내의 능력과 책임에 상당하는 경우가 많습니다.

대부분의 복잡한 시스템 사양은 매우 광범위하기 때문에 한 명의 개인이 사양의 모든 측면을 완전히 이해할 수 없습니다.또한, 우리는 모두 주어진 시스템에 대해 서로 다른 관심사와 시스템의 사양을 검토하는 다른 이유를 가지고 있습니다.비즈니스 임원은 시스템 구성 시 시스템 구현자와는 다른 질문을 합니다.따라서 시점 프레임워크의 개념은 이해관계자와의 커뮤니케이션을 용이하게 하기 위해 주어진 복잡한 시스템의 사양에 별도의 관점을 제공하는 것이다.각 관점은 시스템의 특정 측면에 관심을 가지고 청중을 만족시킨다.각 관점은 해당 관점의 청중을 위해 어휘와 프레젠테이션을 최적화하는 특정 시점 언어를 사용할 수 있습니다.시점 모델링은 대규모 분산 시스템의 고유한 복잡성을 처리하는 데 효과적인 접근 방식이 되었습니다.

IEEE 규격 1471-2000에서 기술된 아키텍처 기술 관행은 여러 뷰를 사용하여 여러 우려 영역에 대처합니다.각 영역은 시스템의 특정 측면에 중점을 두고 있습니다.다중 뷰를 사용하는 아키텍처 프레임워크의 예로는 Kruchten의 "4+1" 뷰 모델, Zachman Framework, TOGAF, DoDAF 및 RM-ODP가 있습니다.

역사

1970년대에 여러 뷰로 모델링하기 위한 방법이 소프트웨어 엔지니어링에 등장하기 시작했습니다.더글러스 T. 1977년 Ross와 K.E. Schoman은 시스템 요구사항 [4]정의에서 모델링 프로세스를 구성하기 위해 구성 컨텍스트, 관점 및 유리한 점을 도입했습니다.로스와 쇼먼에 따르면, "어떤 측면이 ...을 달성하는 것과 관련이 있다고 생각되는지를 명확히 한다.[모델의] 전체적인 목적"을 정하고 [모델화 대상]을 어떻게 바라볼 것인가?

관점의 예로서, 이 문서에서는 다음을 제시합니다.기술적, 운영적, 경제적 관점.1992년에 앤서니 핀켈스타인과 다른 사람들은 [5]관점에 대한 매우 중요한 논문을 발표했다.그 작품에서 관점이란 개발 과정에서 '배우', '지식원', '역할' 또는 '대리인'이라는 개념과 배우가 유지하는 '관찰' 또는 '관찰'이라는 개념의 결합이라고 생각할 수 있다.이 문서에서 중요한 아이디어는 "표현 스타일, 관점이 볼 수 있는 것을 표현하는 체계와 표기법"과 "특정 영역을 기술하는 관점의 스타일로 표현되는 명세서"를 구별하는 것이었다.IEEE 1471과 같은 후속 연구는 각각 관점과 관점의 두 가지 용어를 사용하여 이 차이를 유지했다.

1990년대 초반부터 시스템 아키텍처를 기술하고 분석하기 위한 접근방식을 코드화하기 위한 많은 노력이 있었습니다.이들은 흔히 아키텍처 프레임워크 또는 때로는 관점 집합이라고 불립니다.이들 중 상당수는 미국 국방부에서 자금을 지원받았지만 일부는 ISO 또는 IEEE에 대한 국제적 또는 국가적 노력에서 비롯됐다.그 중에서도 IEEE Std 1471-2000은 이해관계자의 [6]우려를 해소하기 위해 관점을 적용함으로써 여러 뷰를 사용하여 시스템 아키텍처를 문서화하는 데 유용한 견해, 관점, 이해관계자 및 우려사항의 정의를 확립했다.다중 뷰의 장점은 숨겨진 요구사항과 이해관계자의 불일치를 보다 쉽게 발견할 수 있다는 것입니다.그러나 연구에 따르면 실제로는 여러 관점을 조정하는 복잡성이 증가하여 이러한 [7]이점이 훼손될 수 있습니다.

IEEE 1471(현 ISO/IEC/IEE 42010:2011, 시스템 및 소프트웨어 엔지니어링 - 아키텍처 설명)은 아키텍처의 내용을 규정하고 있으며, 전례 없는 설계, 진화적 설계, 기존 시스템의 설계 캡처 등 다양한 시나리오 하에서 아키텍처의 작성과 사용을 설명하고 있습니다.이 모든 시나리오에서 전체적인 과정은 동일하다. 이해관계자를 식별하고, 우려를 유도하고, 사용할 일련의 관점을 식별한 다음, 이러한 관점 규격을 적용하여 관심 시스템과 관련된 일련의 관점을 개발한다.이 표준은 특정 관점을 정의하는 것이 아니라 설계자와 조직이 자신의 관점을 정의할 수 있는 통일된 메커니즘과 요건을 제공합니다.1996년에 대규모 분산 시스템의 아키텍처와 설계를 기술하기 위한 유용한 프레임워크를 제공하기 위해 개방형 분산 프로세싱을 위한 ISO 참조 모델(RM-ODP)이 발행되었습니다.

모델 토픽 표시

보다

시스템 뷰는 관점에서의 시스템 표현이다.시스템에 대한 이러한 관점은 시스템에 대한 특정 관심사에 초점을 맞춘 관점을 포함하며, 이 관점의 관심사와 관련된 요소만을 가진 단순화된 모델을 제공하기 위해 세부사항을 억제한다.예를 들어 보안 관점은 보안 문제에 초점을 맞추고 보안 관점 모델에는 보다 일반적인 [8]시스템 모델에서 보안과 관련된 요소가 포함됩니다.

보기를 통해 사용자는 특정 관심 영역의 일부를 검사할 수 있습니다.예를 들어, 정보 보기는 특정 정보를 사용하는 모든 기능, 조직, 기술 등을 제공하는 반면 조직 보기는 모든 기능, 기술 및 관심 정보를 특정 조직에 제공할 수 있습니다.Zachman Framework 뷰는 기업의 "무엇", "어떻게", "누구", "어디서", "언제" 또는 "왜"에 중점을 두기 때문에 특정 분석 및 기술적 전문지식을 필요로 하는 작업 생산물 그룹으로 구성됩니다.예를 들어 Functional View 작업 제품은 "미션이 어떻게 수행됩니까?"라는 질문에 답합니다.프로세스 및 활동 모델링을 사용하여 기능 분해 전문가에 의해 가장 쉽게 개발됩니다.기능적인 관점에서 기업을 보여줍니다.또한 조직 및 정보 구성 요소를 표시할 수 있지만 [9]기능과 관련된 경우에만 표시됩니다.

뷰포인트

시스템 엔지니어링에서 관점은 시스템 내의 관심사를 분할 또는 제한하는 것입니다.관점의 채택은 그러한 측면의 문제를 별도로 다룰 수 있도록 사용할 수 있다.또한 적절한 관점을 선택하여 시스템 설계를 특정 전문 [3]분야로 분할할 수 있습니다.

뷰포인트는 뷰를 구성, 표시 및 분석하기 위한 규칙, 규칙 및 언어를 제공합니다.ISO/IEC 42010:2007(IEEE-Std-1471-2000)에서 관점은 개별 뷰에 대한 사양이다.뷰는 관점에서의 시스템 전체의 표현이다.뷰는 하나 이상의 아키텍처 [10]모델로 구성될 수 있습니다.이러한 각 아키텍처 모델은 관련된 아키텍처 시스템에 의해 확립된 방법뿐만 아니라 시스템 전체에 대해서도 개발된다.[6]

모델링 시점

모델링 관점은 시스템의 미리 선택된 측면을 표현하기 위한 여러 가지 방법입니다.각 관점에는 모델이 나타내는 것에 대한 다른 초점, 개념화, 헌신 및 시각화가 있습니다.

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

시점 모델

어떤 관점에서든, 그 관점에서 볼 수 있는 객체만을 포함하는 시스템의 모델을 만들 수 있지만, 또한 그 관점과 관련된 시스템에 존재하는 모든 객체, 관계 및 제약을 포착할 수 있다.이러한 모델은 시점 모델 또는 그 [3]시점에서의 시스템 뷰라고 불립니다.

주어진 뷰는 주어진 관점에서 특정 추상화 수준의 시스템에 대한 사양입니다.추상화 수준마다 세부 사항 수준이 다릅니다.높은 수준의 뷰를 통해 엔지니어는 설계 전체를 파악하고 전체적인 문제를 파악하고 해결할 수 있습니다.낮은 수준의 뷰를 통해 엔지니어는 설계의 일부에 집중하고 세부 [3]사양을 개발할 수 있습니다.

아키텍처 프레임워크의 뷰, 제품 및 데이터 그림.

그러나 시스템 자체에서 다양한 시점 모델에 나타나는 모든 사양은 시스템의 실현된 구성요소에서 다루어져야 한다.또한 특정 구성요소에 대한 사양은 다양한 관점에서 도출할 수 있습니다.반면에, 특정 요소 및 요소 상호작용에 대한 기능의 분포에 의해 유도되는 규격은 일반적으로 원래의 관점에 반영된 것과 다른 우려의 분할을 반영할 것이다.따라서 개별 구성요소의 우려와 시스템의 상향식 합성을 다루는 추가적인 관점도 [3]유용할 수 있다.

아키텍처 설명

아키텍처 설명은 시스템 아키텍처의 구성 요소, 구성 요소의 기능 방식, 구성 요소가 기능하는 규칙 및 제약 조건, 구성 요소가 서로 및 환경과 어떻게 관련되어 있는지를 나타내는 것입니다.아키텍처 설명에서 아키텍처 데이터는 여러 뷰와 제품에 걸쳐 공유됩니다.

데이터 레이어에는 아키텍처 데이터 요소와 그 정의 속성과 관계가 있습니다.프레젠테이션 레이어에는 아키텍처의 목적, 설명 내용 및 수행된 다양한 아키텍처 분석을 전달하고 이해하기 위한 시각적 수단을 지원하는 제품과 뷰가 있습니다.제품은 아키텍처 데이터를 그래픽, 표 형식 또는 텍스트 표현으로 시각화할 수 있는 방법을 제공합니다.뷰는 제품 간에 발생하는 아키텍처 데이터를 시각화할 수 있는 기능을 제공하여 아키텍처의 특정 또는 전체적 관점을 위해 데이터를 논리적으로 구성합니다.

시스템 뷰 모델 유형

3가지 스킴 어프로치

3가지 스키마 모델의 개념은 데이터 [12]모델링에 3가지 수준을 결정한 ANSI/X3/SPARC 3단계 아키텍처에 의해 1977년에 처음 도입되었습니다.

1977년에 도입된 데이터 모델링을 위한 3가지 스키마 접근방식은 최초의 뷰 모델 중 하나로 간주할 수 있습니다.데이터 [13]통합의 열쇠로서 개념 모델을 촉진하는 정보 시스템 및 시스템 정보 관리를 구축하기 위한 접근법입니다.3가지 스키마 접근법에서는 다음 3가지 스키마와 뷰를 정의합니다.

  • 사용자 뷰용 외부 스키마
  • 개념 스키마는 외부 스키마를 통합합니다.
  • 물리적 스토리지 구조를 정의하는 내부 스키마

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

수년간 정보 시스템 구축에 대한 기술과 관심은 엄청나게 증가해 왔습니다.그러나 대부분의 경우 기존 시스템 구축 접근 방식은 "사용자 뷰"와 "컴퓨터 뷰"라는 두 가지 다른 뷰에서 데이터를 정의하는 데만 초점을 맞췄습니다.「외부 스키마」라고 하는 유저 뷰에서는, 데이터의 정의는, 개인이 특정의 작업을 실시할 때에 도움이 되도록 설계된 리포트나 화면의 컨텍스트에 있습니다.사용 뷰에서 필요한 데이터 구조는 비즈니스 환경 및 사용자의 개인 선호도에 따라 달라집니다.「내부 스키마」라고 불리는 컴퓨터 뷰로부터, 데이터는 보존과 검색을 위한 파일 구조의 관점에서 정의됩니다.컴퓨터 스토리지에 필요한 데이터 구조는 사용되는 특정 컴퓨터 기술과 효율적인 [16]데이터 처리의 필요성에 따라 달라집니다.

4+1 아키텍처 뷰 모델

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

4+1은 1995년 Philippe Kruchten이 설계한 뷰 모델로, 여러 [17]뷰를 동시에 사용하는 것을 기반으로 소프트웨어 집약적인 시스템의 아키텍처를 기술합니다.뷰는 최종 사용자, 개발자, 프로젝트 매니저 등 다양한 이해관계자의 관점에서 시스템을 설명하기 위해 사용됩니다.모델의 4가지 뷰는 논리적 뷰, 개발 뷰, 프로세스 뷰 및 물리적 뷰입니다.

모델의 4가지 뷰는 다음과 같습니다.

  • 논리적 뷰: 시스템이 최종 사용자에게 제공하는 기능과 관련이 있습니다.
  • 개발 뷰: 프로그래머의 관점에서 시스템을 설명하고 소프트웨어 관리에 관여합니다.
  • 프로세스 뷰: 시스템의 동적 측면을 다루고 시스템 프로세스와 프로세스 간의 통신 방법을 설명하고 시스템의 런타임 동작에 초점을 맞춥니다.
  • 물리적 관점: 시스템 엔지니어의 관점에서 시스템을 나타냅니다.물리층의 소프트웨어 컴포넌트 토폴로지와 이들 컴포넌트 간의 통신에 관한 것입니다.

또한 선택된 사용 사례 또는 시나리오를 사용하여 아키텍처를 설명합니다.따라서 모델에는 4+1 [17]뷰가 포함됩니다.

엔터프라이즈 아키텍처 뷰 유형

엔터프라이즈 아키텍처 프레임워크는 엔터프라이즈 아키텍처와 관련된 구조와 뷰를 구성하는 방법을 정의합니다.엔터프라이즈 아키텍처 및 엔지니어링 분야는 매우 광범위하고, 기업은 크고 복잡할 수 있기 때문에 해당 분야와 관련된 모델도 크고 복잡한 경향이 있습니다.이러한 규모와 복잡성을 관리하기 위해 아키텍처 프레임워크는 작업에 초점을 맞추고 가장 필요할 때 귀중한 아티팩트를 생성할 수 있는 도구와 방법을 제공합니다.

아키텍처 프레임워크는 정보 테크놀로지 및 정보 시스템 거버넌스에서 일반적으로 사용됩니다.조직은 시스템 설계를 승인하기 전에 특정 모델을 제작하도록 요구할 수 있습니다.마찬가지로 조달된 시스템의 문서화에 특정 뷰를 사용할 수도 있습니다.미국 국방부는 특정 값 이상의 자본 프로젝트에 대해 장비 공급업체가 특정 DoDAF 뷰를 제공하도록 규정하고 있습니다.

자크만 프레임워크

행 [18]설명과 함께 Zachman Framework의 간단한 그림.원래의 프레임워크는 보다 고도의 것입니다.이 예에 대해서는, 여기를 참조해 주세요.

1987년 IBM의 John Zachman이 처음 고안한 Zachman Framework는 엔터프라이즈 아키텍처를 위한 프레임워크로, 기업을 공식적이고 고도로 구조화된 방식으로 보고 정의할 수 있습니다.

프레임워크는 아티팩트의 대상자(예: 비즈니스 소유자 및 구축자)와 어떤 특정 문제(예: 데이터 및 기능)를 모두 고려하는 방식으로 아키텍처 "아티팩트"를 구성하기 위해 사용됩니다.이러한 아티팩트에는 설계 문서, 사양 [19]및 모델이 포함될 수 있습니다.

Zachman Framework는 종종 엔터프라이즈 아키텍처의 기본 요소를 표현하기 위한 표준 접근법으로 언급됩니다.Zackman Framework는 미국 연방 정부에 의해 "...기업과 [20]이를 지원하는 시스템의 변화를 관리하기 위한 통합 프레임워크로서 전 세계적으로 인정받았다"고 인정받고 있습니다.

RM-ODP 뷰

RM-ODP 뷰 모델: 시스템과 그 환경에 대한 5가지 일반 및 상호 보완적인 뷰를 제공합니다.

ISO(International Organization for Standardization) Reference Model for Open Distributed Processing(RM-ODP)은 분산 소프트웨어/하드웨어 시스템의 설계를 분할하기 위한 일련의 시점을 지정합니다.대부분의 통합 문제는 그러한 시스템의 설계나 매우 유사한 상황에서 발생하기 때문에, 이러한 관점은 통합 우려를 분리하는 데 유용할 수 있다.RMODP의 관점은 다음과 같습니다.[3]

  • 조직의 비즈니스 목표와 비즈니스 프로세스와 관련된 시스템의 목적과 행동에 관한 기업의 관점
  • 시스템에 의해 취급되는 정보의 성격과 그 정보의 이용과 해석에 관한 제약에 관한 정보 관점
  • 특정 동작을 나타내며 인터페이스에서 상호작용하는 일련의 컴포넌트로의 시스템 기능 분해에 관한 계산적 관점
  • 계산 컴포넌트의 상호작용을 지원하는 데 필요한 메커니즘과 기능에 관한 공학적 관점
  • 시스템 구현을 위한 기술의 명시적 선택, 특히 구성 요소 간의 통신과 관련된 기술 관점

RMODP는 다음 사항을 포함하여 [3]시점 간의 일관성 사양을 포함하는 설계에 대한 요건을 추가로 정의합니다.

  • 정보 단위를 정의할 때 엔터프라이즈 객체 및 프로세스 사용
  • 계산 컴포넌트의 동작을 특정할 때 엔터프라이즈 오브젝트와 동작을 사용하고 계산 인터페이스를 정의할 때 정보 단위를 사용한다.
  • 계산 인터페이스 및 동작 요건과의 엔지니어링 선택 관련성
  • 선택한 기술에 대한 정보, 계산 및 엔지니어링 요구 사항의 만족도

DoDAF 뷰

Department of Defense Architecture Framework(DoDAF)는 엔터프라이즈 아키텍처(EA) 또는 시스템 아키텍처를 보완적이고 일관된 뷰로 구성하는 표준 방법을 정의합니다.특히 복잡한 통합과 상호 운용성에 관한 과제를 안고 있는 대규모 시스템에 적합하며, 개발 중인 시스템이 동작하는 외부 고객의 운영 도메인을 상세하게 설명하는 "운용 뷰"를 사용하는 것은 매우 독특한 것입니다.

보기 간 DoDAF 연결.[22]

DoDAF는 그래픽, 표 형식 또는 텍스트 수단을 통해 아키텍처 설명의 광범위한 범위와 복잡성을 시각화, 이해 및 동화하는 메커니즘으로 작용하는 일련의 제품을 정의합니다.이러한 제품은 다음 4가지 뷰로 구성됩니다.

  • 모든 뷰(AV)의 덮어쓰기,
  • 운용 뷰(OV),
  • 시스템 뷰(SV) 및
  • 테크니컬 스탠다드 뷰(TV)

각 뷰는 아래에 설명된 아키텍처의 특정 관점을 나타냅니다.일반적으로 각 시스템 개발에 대해 전체 DoDAF 뷰 세트의 하위 집합만 작성됩니다.이 그림은 운영 보기, 시스템 및 서비스 보기 및 기술 표준 보기를 연결하는 정보를 나타냅니다.공통 아키텍처 데이터 요소에 의해 주도되는 3가지 뷰와 그 상호관계는 상호운용성이나 퍼포먼스 등의 척도를 도출하고 이들 메트릭의 값이 운용상의 미션과 태스크의 [22]효율성에 미치는 영향을 측정하기 위한 기초를 제공합니다.

Federal Enterprise Architecture(Federal 엔터프라이즈 아키텍처)

미국 연방 엔터프라이즈 아키텍처의 엔터프라이즈, 세그먼트 및 솔루션 아키텍처는 세부 사항 수준을 변경하고 관련되지만 뚜렷한 문제를 해결함으로써 다양한 비즈니스 관점을 제공합니다.기업 자체가 계층적으로 구성되어 있듯이 아키텍처 유형별로 제공되는 다양한 뷰도 마찬가지입니다.Federal Enterprise Architecture Practice Guidance(2006)에서는 다음과 같은 3가지 유형의 [23]아키텍처를 정의하고 있습니다.

Federal Enterprise Architecture 수준 및 속성[23]
  • 엔터프라이즈 아키텍처,
  • 세그먼트 아키텍처 및
  • 솔루션 아키텍처

정의상 엔터프라이즈 아키텍처(EA)는 전략, 비즈니스 프로세스, 투자, 데이터, 시스템, 테크놀로지 등 공통 자산 또는 공유 자산을 식별하는 데 기본적으로 관여합니다.EA는 전략에 의해 추진됩니다.이것에 의해, 에이전시의 자원이 에이전시의 미션과 전략적 목표와 목표에 적절히 대응하고 있는지를 특정할 수 있습니다.투자의 관점에서 보면, EA는 IT투자 포트폴리오 전체에 관한 의사결정을 추진하기 위해 사용됩니다.따라서 EA의 주요 이해관계자는 EA가 [23]최대한 효과적이고 효율적으로 임무를 수행할 수 있도록 책임지는 고위 관리자와 경영진입니다.

반면 세그먼트 아키텍처는 핵심 업무 영역, 비즈니스 서비스 또는 엔터프라이즈 서비스에 대한 간단한 로드맵을 정의합니다.세그먼트 아키텍처는 비즈니스 관리에 의해 주도되며 시민 및 기관 직원에게 서비스 제공을 개선하는 제품을 제공합니다.투자 관점에서 세그먼트 아키텍처는 핵심 미션 영역 또는 공통 또는 공유 서비스를 지원하는 비즈니스 케이스 또는 비즈니스 케이스 그룹에 대한 의사결정을 주도합니다.세그먼트 아키텍처의 주된 이해관계자는 비즈니스 오너와 매니저입니다.세그먼트 아키텍처는 구조, 재사용 및 정렬의 세 가지 원칙을 통해 EA와 관련됩니다.첫째, 세그먼트 아키텍처는 EA가 사용하는 프레임워크를 계승합니다.단, 핵심 미션 영역이나 공통 또는 공유 서비스의 특정 요구를 충족하도록 확장 및 전문화할 수 있습니다.둘째, 세그먼트 아키텍처는 데이터, 공통 비즈니스 프로세스 및 투자, 애플리케이션 및 기술 등 엔터프라이즈 수준에서 정의된 중요한 자산을 재사용합니다.셋째, 세그먼트 아키텍처는 비즈니스 전략, 의무, 표준 및 성능 [23]측정과 같은 엔터프라이즈 수준에서 정의된 요소에 따라 조정됩니다.

공칭 뷰 세트

"우주 시스템 아키텍처 모델링용 프레임워크"를 찾기 위해 Peter Shames와 Joseph Skipper(2006)는 CCSDS RASDS, RM-ODP, ISO 10746에서 파생된 "공칭 [6]뷰 세트"를 정의했으며 IEEE 1471을 준수했다.

"공칭 [24]뷰 집합"의 그림입니다.

이 "뷰 세트"는 다음과 같이 생각할 수 있는 모델링 뷰의 목록입니다.이러한 뷰 중 일부는 하나의 프로젝트에 사용할 수 없으며 필요에 따라 다른 뷰를 정의할 수 있습니다.일부 분석 요소의 경우 여러 관점의 요소가 계층화된 표현을 사용하여 새로운 뷰로 결합될 수 있습니다.

후자의 프레젠테이션에서는 이 명목상의 일련의 뷰가 확장 RASDS 시멘틱 정보 모델 [24]파생으로 제시되었습니다.여기서 RASDS는 Space Data Systems를 위한 Reference Architecture의 약자입니다.두 번째 이미지를 참조하십시오.

기업의[6] 시점
  • 조직뷰 – 조직요소와 그 구조 및 관계를 포함합니다.계약, 계약, 정책 및 조직의 상호 작용을 포함할 수 있습니다.
  • 요건 뷰– 시스템을 추진하는 요건, 목표 및 목표에 대해 설명합니다.시스템이 무엇을 할 수 있어야 하는지 말해줍니다.
  • 시나리오 뷰– 시스템 사용 방법에 대해 설명합니다.시나리오 계획을 참조하십시오.시스템 동작에 대한 사용자 보기 및 설명을 포함합니다.
정보[6] 관점
  • 메타모델 뷰– 정보모델 요소 및 그 구조 및 관계를 정의하는 추상 뷰입니다.시스템 및 데이터 아키텍처에 의해 생성 및 관리되는 데이터 클래스를 정의합니다.
  • 정보 보기 – 시스템 내에서 실현 및 조작되는 실제 데이터와 정보를 설명합니다.데이터 요소는 메타모델 뷰에 의해 정의되며 다른 뷰에서 기능 객체에 의해 참조됩니다.
스페이스 데이터 시스템의 [24]레퍼런스 아키텍처.
기능적[6] 관점
  • 기능 데이터 흐름 뷰– 시스템 내의 기능 요소, 그 상호작용, 동작, 제공된 서비스, 제약 조건 및 데이터 흐름을 설명하는 추상 뷰입니다.이러한 기능의 실제 실장 방법에 관계없이, 시스템이 실행할 수 있는 기능을 정의합니다.
  • 기능 제어 뷰– 시스템 내 기능 요소 간의 제어 흐름 및 상호 작용에 대해 설명합니다.전체 시스템 제어 상호 작용, 제어 요소와 센서/이펙터 요소 간의 상호 작용 및 관리 상호 작용을 포함합니다.
물리적[6] 시점
  • 데이터 시스템 보기 – 시스템에서 사용되는 기기, 컴퓨터 및 데이터 스토리지 구성 요소, 데이터 시스템 속성 및 통신 커넥터(버스, 네트워크, 포인트 투 포인트 링크)에 대해 설명합니다.
  • Telecomm 뷰: telecomm 컴포넌트(안테나, 트랜시버), 그 속성 및 커넥터(RF 또는 광링크)에 대해 설명합니다.
  • 네비게이션 뷰– 시스템 내 주요 요소(탐사선, 경로, 궤도)의 움직임을 기술합니다.시스템에서 제어할 수 없는 외부 요소 및 힘과의 상호작용을 포함하지만 시스템 동작(행성, 소행성, 태양압, 중력)을 이해하기 위해 모델링해야 합니다.
  • 구조도 – 시스템의 구조 구성 요소(s/c 버스, 스트럿, 패널, 관절), 물리적 특성 및 커넥터와 다른 구성 요소의 관련 구조적 측면(질량, 강성, 부착)을 설명합니다.
  • 서멀 뷰– 시스템 내 액티브 및 패시브 열 컴포넌트(라디에이터, 냉각기, 통풍구)와 그 커넥터(물리 및 빈 공간 복사) 및 속성과 다른 컴포넌트(즉, 선쉐이드로서의 안테나)의 열 특성을 설명합니다.
  • 전원 뷰 – 시스템 내 액티브 및 패시브 전원 컴포넌트(솔라 패널, 배터리, RTG)와 다른 컴포넌트(데이터 시스템 및 추진 요소(파워 싱크, 구조 패널)의 전원 속성을 접지 플레인)에 대해 설명합니다.
  • 추진 뷰 – 시스템 및 커넥터 내의 액티브 및 패시브 추진 구성 요소(터스터, 자이로, 모터, 휠)와 다른 구성 요소의 추진 특성을 설명합니다.
공칭 [6]뷰 세트를 기반으로 하는 MBED 최상위 수준 온톨로지.
공학적[6] 관점
  • 할당 뷰 – 시스템 내 엔지니어링된 물리 컴포넌트 및 계산 컴포넌트에 대한 기능 객체 할당 설명, 성능 분석 및 요건 충족 검증에 사용됩니다.
  • 소프트웨어 뷰 - 시스템의 소프트웨어 엔지니어링 측면, 소프트웨어 설계 및 소프트웨어 컴포넌트 내 기능 구현, 사용할 언어 및 라이브러리 선택, API 정의, 추상적인 기능 오브젝트를 구체적인 소프트웨어 요소로 엔지니어링합니다.소프트웨어 언어를 사용하여 기술된 일부 기능 요소는 실제로 하드웨어(FPGA, ASIC)로 구현될 수 있습니다.
  • 하드웨어 뷰– 시스템에 조립되는 모든 물리 컴포넌트의 시스템, 하드웨어 설계, 선택 및 구현의 하드웨어 엔지니어링 측면을 설명합니다.이러한 견해는 각각 다른 엔지니어링 분야별로 여러 가지가 있을 수 있습니다.
  • Communications Protocol 뷰– 통신 프로토콜 및 관련 데이터 전송 및 데이터 관리 서비스의 엔드 투 엔드 설계를 설명하고 시스템의 각 물리 컴포넌트에 구현된 프로토콜 스택을 표시합니다.
  • 리스크 뷰– 시스템 설계, 프로세스 및 테크놀로지와 관련된 리스크에 대해 설명하고 아키텍처에 기재된 기타 요소에 추가 리스크 평가 속성을 할당합니다.
  • 제어 엔지니어링 뷰 - 제어 가능성의 관점에서 시스템을 분석합니다. 제어 및 제어 시스템 하의 시스템에 요소를 할당합니다.
  • 통합 및 테스트 뷰– 시스템, 서브시스템 및 어셈블리를 조립, 통합 및 테스트하기 위해 수행해야 하는 작업의 관점에서 시스템을 검토합니다.시나리오에 따라 요건을 충족시키는 적절한 기능 검증이 포함됩니다.
  • IV&V 뷰– 요건을 충족하는 시스템 기능 및 적절한 운용에 대한 독립적인 검증 및 검증설계 및 개발된 시스템이 목표와 목표를 충족하고 있는가?
테크놀로지의[6] 관점
  • 표준 보기 – 시스템 설계 중에 채택할 표준을 정의합니다(예: 통신 프로토콜, 방사선 허용 오차, 납땜).이는 기본적으로 설계 및 구현 프로세스에 대한 제약 사항입니다.
  • 인프라스트럭처 뷰– 엔지니어링, 설계 및 제작 프로세스를 지원하는 인프라스트럭처 요소를 정의합니다.데이터 시스템 요소(설계 저장소, 프레임워크, 도구, 네트워크) 및 하드웨어 요소(칩 제조, 열진공 설비, 기계 공장, RF 테스트 랩)를 포함할 수 있습니다.
  • 테크놀로지 개발 및 평가 뷰– 시스템 개발 프로젝트에 포함될 수 있는 알고리즘 또는 컴포넌트를 작성하도록 설계된 테크놀로지 개발 프로그램에 대한 설명이 포함됩니다.선택된 하드웨어 및 소프트웨어 컴포넌트의 속성을 평가하여 설계 중인 미션에 채택하기에 충분한 성숙 상태에 있는지 여부를 판단합니다.

앞서 열거한 뷰 모델과 달리 이 "공칭 뷰 세트"는 소프트웨어 집약적인 시스템 [6]아키텍처의 일반적인 클래스를 기술하기 위한 강력하고 확장 가능한 접근방식을 개발할 수 있는 전체 뷰를 나열합니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ ISO/IEC/IEE 42010:2011, 시스템 등 - 아키텍처 설명
  2. ^ ISO/IEC 10746-1, 정보기술 - 오픈 분산 처리 - 레퍼런스 모델:개요
  3. ^ a b c d e f g Edward J. Barkmeyer ea (2003)시스템 통합 자동화에 관한 개념 NIST 2003.
  4. ^ 더글러스 T. Ross와 K.E. Schoman, Jr. "요건 정의를 위한 구조적인 분석." IEEE Transactions on Software Engineering, SE-3 (1), 1977년 1월
  5. ^ A. Finkelstein, J. Kramer, B.누세이베, L. 핑켈슈타인, M.괴디케"관점: 시스템 개발에서 여러 관점을 통합하기 위한 프레임워크입니다."International Journal of Software Engineering and Knowledge Engineering, 2 (1):31-58, 1992.
  6. ^ a b c d e f g h i j k 피터 셰임즈, 조셉 스키퍼."우주 시스템 아키텍처 모델링 프레임워크 지향" 2009년 2월 27일 웨이백 머신에 보관.NASA, JPL.
  7. ^ Easterbrook, S.; Yu, E.; Aranda, J.; Yuntian Fan; Horkoff, J.; Leica, M.; Qadir, R.A. (2005). "Do viewpoints lead to better conceptual models? An exploratory case study". 13th IEEE International Conference on Requirements Engineering (RE'05). pp. 199–208. CiteSeerX 10.1.1.78.4594. doi:10.1109/RE.2005.23. ISBN 978-0-7695-2425-2.
  8. ^ 시난 시 알히르(2003)."모델 주도 아키텍처(MDA)에 대하여"입력: 방법 및 도구.2003년 가을.
  9. ^ 미국 재무부 최고정보책임자회의(2000년).재무부의 엔터프라이즈 아키텍처 프레임워크.버전 1, 2000년7월2009년 3월 18일 Wayback Machine에서 아카이브 완료
  10. ^ IEEE-1471-2000
  11. ^ 존 크록스티, (2003)개념 모델링, 2007년 3월 16일 Wayback Machine에서 아카이브
  12. ^ 매튜 웨스트와 줄리안 파울러(1999년).고품질 데이터 모델 개발 2008년 12월 21일 Wayback Machine에서 아카이브.European Process Industries STEP 기술연락책임자(EPISTLE).
  13. ^ 스트랩 섹션2 어프로치. 2008년 9월 30일 취득.
  14. ^ John F. Sowa (2004).[지식 수프의 도전]"과학, 기술 및 수학 교육의 연구 동향"에 게재되었습니다.J. Ramadas & S. Chunawala 편집자, 2006년 뭄바이 호미바바 센터.
  15. ^ Gad Ariav & James Clifford(1986)데이터베이스 시스템의 새로운 방향: 백서의 개정판.뉴욕대학교 경영대학원정보시스템연구센터, 1986.
  16. ^ itl.nist.gov(1993) 정보 모델링 통합 정의(IDEFIX) 2013-12-03년 웨이백 머신에 보관. 1993년 12월 21일.
  17. ^ a b 크루히텐, 필립(1995년, 11월).아키텍처 청사진 - 소프트웨어 아키텍처의 "4+1" 뷰 모델.IEEE 소프트웨어 12(6), 페이지 42-50.
  18. ^ US Department of Vestor Affairs (2008) 2007년 7월 13일 Wayback Machine에서 아카이브된 Zachman 아키텍처 프레임워크에 관한 튜토리얼.2008년 12월 6일에 액세스.
  19. ^ Wayback Machine, Roger Sessions, Microsoft Developer Network Architecture Center에서 2008-04-09년에 아카이브된 4대 엔터프라이즈 아키텍처 방법론 비교
  20. ^ 2008년 9월 16일 Wayback Machine에서 아카이브된 Federal Enterprise Architecture
  21. ^ ISO/IEC 10746-1:1998 정보 테크놀로지– 오픈 분산 처리 : 레퍼런스 모델– Part 1 : 개요, 국제 표준화 기구, 스위스 제네바, 1998.
  22. ^ a b DoD (2007) DoD 아키텍처 프레임워크 버전 1.5 . 2007년 4월 23일 2005년 3월 11일 Wayback Machine에서 아카이브
  23. ^ a b c d Federal Enterprise Architecture Program Management Office (2006).FEA 프랙티스[dead link] 가이드라인
  24. ^ a b c Peter Shames & Joseph Skipper (2006).Wayback Machine에서 2010년 5월 27일에 아카이브된 우주 시스템 아키텍처 모델링 프레임워크를 향해서. 2006년 5월 25일.
귀속

Public Domain이 문서에는 미국 국립표준기술연구소 웹사이트 https://www.nist.gov의 퍼블릭 도메인 자료가 포함되어 있습니다.

외부 링크

  • Wikimedia Commons의 View 모델 관련 미디어