4 + 1 아키텍처 뷰 모델과 UML 간의 매핑

4 + 1 아키텍처 뷰 모델이 UML에 매핑되는 방식에 대해 약간 혼란 스럽습니다.

Wikipedia 는 다음과 같은 매핑을 제공합니다.

• 논리적보기 : 클래스 다이어그램, 통신 다이어그램, 시퀀스 다이어그램.
• 개발 뷰 : 컴포넌트 다이어그램, 패키지 다이어그램
• 프로세스 뷰 : 활동 다이어그램
• 물리적 뷰 : 배포 다이어그램
• 시나리오 : 사용 사례 다이어그램

용지 객체 라이프 사이클 개념의 UML 시퀀스 다이어그램을 구축해의 역할은 다음과 같은 매핑을 제공합니다 :

• 논리적 뷰 (클래스 다이어그램 (CD), 개체 다이어그램 (OD), 시퀀스 다이어그램 (SD), 협업 다이어그램 (COD), 상태 차트 다이어그램 (SCD), 활동 다이어그램 (AD))
• 개발 뷰 (패키지 다이어그램, 컴포넌트 다이어그램)
• 프로세스 뷰 (사용 사례 다이어그램, CD, OD, SD, COD, SCD, AD)
• 물리적 뷰 (배치 다이어그램)
• 위에서 언급 한 네 가지를 결합한 사용 사례보기 (사용 사례 다이어그램, OD, SD, COD, SCD, AD).

웹 페이지 UML 4 + 1 재질보기 에는 다음과 같은 매핑이 있습니다.

마지막으로 백서 UML 2로 4 + 1 뷰 아키텍처 적용 은 또 다른 매핑을 제공합니다.

• 논리적 뷰 클래스 다이어그램, 객체 다이어그램, 상태 차트 및 복합 구조
• 프로세스 뷰 시퀀스 다이어그램, 커뮤니케이션 다이어그램, 활동 다이어그램, 타이밍 다이어그램, 상호 작용 개요 다이어그램
• 개발 뷰 컴포넌트 다이어그램
• 물리적 뷰 배포 다이어그램
• 유스 케이스보기 유스 케이스 다이어그램, 활동 다이어그램

추가 검색을 통해 다른 매핑도 공개 될 것입니다.

여러 사람들이 일반적으로 다른 관점을 가지고 있지만, 이것이 왜 그런지 모르겠습니다. 특히, 각 UML 다이어그램은 특정 측면에서 시스템을 설명합니다. 예를 들어 왜 "시퀀스 다이어그램"이 한 저자에 의해 시스템의 "논리적 관점"을 설명하는 것으로 간주되는 반면 다른 저자는 "프로세스보기"를 설명하는 것으로 간주합니까?

혼란을 명확히 도와 주시겠습니까?

나는 일반적으로 Bart van Ingen Schenau의 답변에 동의하지만 , 몇 가지 요점이 추가로 자세히 설명해야한다고 생각합니다.

4 + 1 뷰 모델의 장점은 특정 모델링 표기법을 사용할 필요없이 이해 관계자가 필요한 정보 유형에 매핑된다는 것입니다. 모든 그룹이 시스템을 이해하고 지속적으로 업무를 수행 할 수있는 정보를 갖도록하는 데 중점을 둡니다.

소프트웨어 아키텍처의 4 + 1 뷰 모델은 Philippe Kruchten의 논문 아키텍처 청사진- 원래 IEEE 소프트웨어 (1995 년 11 월)에 게시 된 소프트웨어 아키텍처의 "4 + 1"뷰 모델에 설명 되어 있습니다. 이 발행물은 UML을 구체적으로 언급하지 않습니다. 실제로,이 논문은 논리적 관점을 위해 Booch 표기법 을 사용하고 , 프로세스 관점과 개발 관점을 위해 Booch 표기법을 확장하며, 물리적 관점을 개발하기위한 "여러 형태"의 사용, 시나리오에 대한 새로운 표기법을 요구합니다.

각 뷰를 특정 유형의 다이어그램에 매핑하는 대신 각 뷰의 대상 사용자가 누구이며 필요한 정보를 고려하십시오. 이를 알고 다양한 유형의 모델과 필요한 정보를 제공하는 모델을 살펴보십시오.

논리적 뷰는 원하는 모든 기능을 시스템에서 캡처하는 데 대한 최종 사용자의 우려를 해결하기 위해 설계되었습니다. 객체 지향 시스템에서 이것은 종종 클래스 수준에 있습니다. 복잡한 시스템에서는 패키지보기가 필요하고 패키지를 여러 클래스 다이어그램으로 분해 할 수 있습니다. 다른 패러다임에서는 모듈과 모듈이 제공하는 기능을 나타내는 데 관심이있을 수 있습니다. 결과적으로 필요한 기능을 해당 기능을 제공하는 구성 요소에 맵핑해야합니다.

프로세스 뷰는 전체 시스템을 설계 한 다음 서브 시스템 또는 시스템을 시스템 시스템에 통합하는 사람들을 위해 설계되었습니다. 이보기에는 시스템에있는 작업 및 프로세스, 외부 환경 및 / 또는 시스템 내의 구성 요소 간 인터페이스,주고받은 메시지, 성능, 가용성, 내결함성 및 무결성이 어떻게 해결되는지가 표시됩니다.

개발 뷰는 주로 모듈과 서브 시스템을 빌드 할 개발자를위한 것입니다. 모듈 간의 종속성과 관계, 모듈 구성, ​​재사용 및 이식성에 대해 설명해야합니다.

실제보기는 주로 소프트웨어의 실제 위치, 노드 간 실제 연결, 배포 및 설치 및 확장 성을 이해해야하는 시스템 설계자 및 관리자를위한 것입니다.

마지막으로, 시나리오는 요구 사항을 포착하여 모든 이해 당사자가 시스템 사용 방법을 이해할 수 있도록 도와줍니다.

각 뷰가 무엇을 제공해야하는지 이해 한 후에는 사용할 모델링 표기법과 필요한 세부 수준을 선택할 수 있습니다. Bart의 마지막 단락은 특히 사실입니다. 특정 디자인 요소에 중점을 두거나 다양한 유형의 다이어그램을 세트로 결합하여 UML 모델에서 다양한 레벨의 세부 사항을 표시 할 수 있습니다. 또한 시스템 아키텍처 ( SysML , 엔터티-관계 모델링 또는 IDEF) 를보다 잘 설명하기 위해 UML을 넘어 다른 모델링 표기법으로 넘어가는 것도 좋습니다 .

4 + 1 아키텍처 모델의 뷰와 다양한 UML 다이어그램간에 일대일 맵핑을 찾을 수없는 이유는 해당 맵핑이 없기 때문입니다.

모든 저자가 자신의 '매핑 (mapping)'으로 말하려고하는 것은 각 뷰마다 그 뷰에서 알리고 싶은 정보를 전달하는 데 유용한 다른 UML 다이어그램 세트가 있다는 것입니다.

또한 일부 UML 다이어그램은 다이어그램에서 다른 요소를 강조하여 다른 방식으로 사용될 수 있으므로 여러보기에 유용합니다. 그러나 하나의 UML 다이어그램 유형을 여러보기에서 사용할 수 있더라도 각보기마다 다른 다이어그램 (또는 다이어그램 세트)을 그릴 수 있습니다.

내가 동의하지만 토마스 오웬스 응답 최종 사용자의 요구에 대한 수용에 접근, 언급 할 실패 한 가지 이유는 원래 정의하는 이유이다 Kruchten에 의해 "4 + 1보기 모델 아키텍처" 어떤을하지 않습니다 UML에 대한 특정 참조는 기사가 답변 상태로 1995 년에 작성되었지만 1997 년까지 UML이 표준으로 채택되지 않았기 때문 입니다.

이 기사에서 Booch 표기법을 계속 사용하면 Grady Booch가 UML 개발에 참여한 사람들 중 하나이기 때문에 각 모델 뷰를 특정 UML 다이어그램과 관련시키는 것이 적절할 수 있습니다.

4 + 1 모델의 원래 정의가 의존하는 Booch 표기법의 "추상 치"에서 여러 UML 다이어그램을 어느 정도 고려할 수 있기 때문에, 많은 다른 저자들이 각 뷰에 다른 UML 다이어그램을 적용 할 수 있다고 생각하기 때문입니다. 각보기를 나타냅니다.

희망이 있으면 다른 사람들 이이 문제를 더 잘 해결할 수 있기를 바랍니다.

1995 년에 다시 구매 한 VCR을 계속 사용하십니까? 4 + 1은 당시 소프트웨어가 초기 단계에 있었을 때 적용 할 수있었습니다. 그러나 그때도 2 ~ 3 개 이상의 "조회"를 사용한 사람은 없습니다. 지난 20 년 동안 소프트웨어 엔지니어링이 변경되었습니다. 오늘날, 범위 / 컨텍스트와 개념적, 논리적, 물리적 그리고 ...는 모두 차별화됩니다. 많은 COTS 솔루션 등이 통합되어야합니다. 오늘 우리는 풍경 맵, 서비스 구현 및 수십 가지 다른 관점과 관점에 대해 이야기하고 있습니다. 이것을 보는 가장 좋은 방법은 Zachman과 같은 간단한 분류 체계를 통하는 것입니다 : 6 개의 견해와 6 개의 견해. 그것이 출발점이되게하십시오. 6 개의 견해는 다음과 같습니다. 문맥 적 개념 또는 비즈니스 논리 또는 시스템 물리적 또는 기술 제공 또는 아티팩트 기능 기업

6 가지 관점은 다음과 같습니다. 데이터 또는 기능 또는 네트워크 방법 또는 사람 또는 시간 또는시기 또는 동기 또는 이유

예를 봅시다. 데이터에만 관심이 있다면 범위보기로 시작하여 "우리의 범위는 CRM"입니다. 데이터 관점에 대한 개념적인 관점에서 CRM에 대한 의미 론적 모델이 제시 될 것입니다. 이 모델은 데이터 개체가 아닌 개념적 비즈니스 정보 개념입니다. 다음으로 논리보기에서 개념 CRM 모델에서 논리 데이터 모델을 생성합니다. 논리 데이터 모델을 생성하기 위해 ER 방법론을 사용할 수 있습니다. 그런 다음 물리적 관점에서 물리적 데이터 모델을 생성합니다. 여기서는 선택한 DB 플랫폼, 인덱스 등의 구체적인 데이터 유형을 정의합니다. 마지막으로 배달 뷰에는 DDL 스크립트가 있고 기능적인 엔터프라이즈 뷰에는 일부 데이터베이스 서버에 바이너리 파일이 배포되어 있습니다. DBM 공급 업체의 내부 데이터 구조에 매핑됩니다. 우리는 모든 관점이나 열에 대해 이것을 반복합니다. 또한 이해 관계자가 둘 이상인 경우 각 관점 / 조회 조합에 대해 둘 이상의 모델을 작성합니다. 이제이 분류 체계를 갖추 었으므로 자신의 관점과 관점을 정의하고이를 분류 체계에 맞출 수 있습니다. 예를 들어, 기업 차원의 이니셔티브의 경우 다음 관점이 모두 중요합니다. 행위자 협력 응용 프로그램 동작 응용 프로그램 협력 응용 프로그램 구조 응용 프로그램 사용 비즈니스 기능 비즈니스 프로세스 비즈니스 프로세스 협력 구현 및 배포 정보 구조 인프라 인프라 사용 풍경 맵 개요 계층화 된 조직 서비스 실현 등 이제이 분류 체계를 갖추 었으므로 자신의 관점과 관점을 정의하고이를 분류 체계에 맞출 수 있습니다. 예를 들어, 기업 차원의 이니셔티브의 경우 다음 관점이 모두 중요합니다. 행위자 협력 응용 프로그램 동작 응용 프로그램 협력 응용 프로그램 구조 응용 프로그램 사용 비즈니스 기능 비즈니스 프로세스 비즈니스 프로세스 협력 구현 및 배포 정보 구조 인프라 인프라 사용 풍경 맵 개요 계층화 된 조직 서비스 실현 등 이제이 분류 체계를 갖추 었으므로 자신의 관점과 관점을 정의하고이를 분류 체계에 맞출 수 있습니다. 예를 들어, 기업 차원의 이니셔티브의 경우 다음 관점이 모두 중요합니다. 행위자 협력 응용 프로그램 동작 응용 프로그램 협력 응용 프로그램 구조 응용 프로그램 사용 비즈니스 기능 비즈니스 프로세스 비즈니스 프로세스 협력 구현 및 배포 정보 구조 인프라 인프라 사용 풍경 맵 개요 계층화 된 조직 서비스 실현 등

Krutchen의 4 + 1은 이러한 모든 요구를 충족시킬 수 없었습니다.