Visual Studio에서 모델을 사용하여 시스템, 애플리케이션 또는 구성 요소를 이해하고 변경할 수 있습니다. 모델은 시스템이 작동하는 세계를 시각화하고, 사용자의 요구 사항을 명확히 하고, 시스템의 아키텍처를 정의하고, 코드를 분석하고, 코드가 요구 사항을 충족하는지 확인하는 데 도움이 될 수 있습니다.
각 유형의 모델을 지원하는 Visual Studio 버전을 보려면 아키텍처 및 모델링 도구에 대한 버전 지원을 참조하세요.
모델은 다음과 같은 여러 가지 방법으로 도움이 될 수 있습니다.
그리기 모델링 다이어그램을 사용하면 요구 사항, 아키텍처 및 고급 디자인과 관련된 개념을 명확히 할 수 있습니다. 자세한 내용은 모델 사용자 요구 사항을 참조하세요.
모델을 사용하면 요구 사항의 불일치를 노출하는 데 도움이 될 수 있습니다.
모델과 통신하면 자연어보다 덜 모호하게 중요한 개념을 전달할 수 있습니다. 자세한 내용은 앱 아키텍처 모델링을 참조하세요.
경우에 따라 모델을 사용하여 코드 또는 데이터베이스 스키마 또는 문서와 같은 다른 아티팩트도 생성할 수 있습니다. 예를 들어 Visual Studio의 모델링 구성 요소는 모델에서 생성됩니다. 자세한 내용은 모델에서 앱 생성 및 구성을 참조하세요.
극단적 인 민첩성에서 높은 의식에 이르기까지 다양한 프로세스에서 모델을 사용할 수 있습니다.
모델을 사용하여 모호성 줄이기
모델링 언어는 자연어보다 덜 모호하며 소프트웨어 개발 중에 일반적으로 필요한 아이디어를 표현하도록 설계되었습니다.
프로젝트에 민첩한 사례를 따르는 소규모 팀이 있는 경우 모델을 사용하여 사용자 스토리를 명확하게 설명할 수 있습니다. 고객과 요구 사항에 대해 논의하면서 모델을 만들면 스파이크 또는 프로토타입 코드를 작성하는 것보다 훨씬 더 빠르고 광범위한 제품 영역에서 유용한 질문을 생성할 수 있습니다.
프로젝트가 크고 전 세계 여러 지역에 팀을 포함하는 경우 모델을 사용하여 일반 텍스트보다 훨씬 더 효과적으로 요구 사항 및 아키텍처를 전달할 수 있습니다.
두 경우 모두 모델을 만들면 거의 항상 불일치와 모호성이 크게 감소합니다. 여러 이해 관계자가 시스템이 작동하는 비즈니스 세계에 대해 서로 다른 이해를 가지고 있으며, 개발자는 시스템 작동 방식에 대해 서로 다른 이해를 가지고 있는 경우가 많습니다. 일반적으로 토론의 초점으로 모델을 사용하면 이러한 차이점이 노출됩니다. 모델을 사용하여 불일치를 줄이는 방법에 대한 자세한 내용은 모델 사용자 요구 사항을 참조하세요.
다른 아티팩트와 함께 모델 사용.
모델은 그 자체로 요구 사항 사양 또는 아키텍처가 아닙니다. 이 도구는 이러한 항목의 일부 측면을 보다 명확하게 표현하기 위한 도구이지만 소프트웨어 디자인 중에 필요한 모든 개념을 표현할 수 있는 것은 아닙니다. 따라서 모델은 OneNote 페이지 또는 단락, Microsoft Office 문서, Team Foundation의 작업 항목 또는 프로젝트 룸 벽의 스티커 메모와 같은 다른 통신 수단과 함께 사용해야 합니다. 마지막 항목 외에도 이러한 모든 개체 형식을 모델의 요소 부분에 연결할 수 있습니다.
일반적으로 모델과 함께 사용되는 사양의 다른 측면은 다음과 같습니다. 프로젝트의 규모와 스타일에 따라 다음과 같은 몇 가지 측면을 사용하거나 전혀 사용하지 않을 수 있습니다.
사용자 스토리. 사용자 스토리는 프로젝트 반복 중 하나에서 전달될 시스템 동작의 한 측면에 대해 사용자 및 기타 이해 관계자와 설명하는 간단한 설명입니다. 일반적인 사용자 스토리는 "고객이 할 수 있습니다...."로 시작됩니다. 사용자 스토리는 사용 사례 그룹을 도입하거나 이전에 개발된 사용 사례의 확장을 정의할 수 있습니다. 사용 사례를 정의하거나 확장하면 사용자 스토리를 더 명확하게 만들 수 있습니다.
요청을 변경합니다. 보다 공식적인 프로젝트의 변경 요청은 민첩한 프로젝트의 사용자 스토리와 매우 유사합니다. 민첩한 접근 방식은 모든 요구 사항을 이전 반복에서 개발된 내용의 변경 내용으로 처리합니다.
사용 사례 설명입니다. 사용 사례는 사용자가 특정 목표를 달성하기 위해 시스템과 상호 작용하는 한 가지 방법을 나타냅니다. 전체 설명에는 목표, 이벤트의 기본 및 대체 시퀀스 및 예외적 결과가 포함됩니다. 사용 사례 다이어그램은 사용 사례를 요약하고 개요를 제공하는 데 도움이 됩니다.
시나리오. 시나리오는 시스템, 사용자 및 기타 시스템이 함께 작동하여 이해 관계자에게 가치를 제공하는 방법을 보여 주는 일련의 이벤트에 대한 매우 자세한 설명입니다. 사용자 인터페이스의 슬라이드 쇼 또는 사용자 인터페이스의 프로토타입 형식을 취할 수 있습니다. 하나의 사용 사례 또는 사용 사례 시퀀스를 설명할 수 있습니다.
용어집. 프로젝트의 요구 사항 용어집은 고객이 자신의 세계에 대해 논의하는 단어를 설명합니다. 사용자 인터페이스 및 요구 사항 모델도 이러한 용어를 사용해야 합니다. 클래스 다이어그램은 대부분의 용어 간의 관계를 명확히 하는 데 도움이 될 수 있습니다. 다이어그램 및 용어집을 만들면 사용자와 개발자 간의 오해를 줄일 뿐만 아니라 거의 항상 서로 다른 비즈니스 이해 관계자 간의 오해가 노출됩니다.
비즈니스 규칙. 많은 비즈니스 규칙은 요구 사항 클래스 모델의 연결 및 특성에 대한 고정 제약 조건으로 표현될 수 있으며 시퀀스 다이어그램의 제약 조건으로 표현될 수 있습니다.
고급 디자인. 주요 부분과 주요 파트가 어떻게 함께 맞는지 설명합니다. 구성 요소, 시퀀스 및 인터페이스 다이어그램은 상위 수준 디자인의 주요 부분입니다.
디자인 패턴. 시스템의 여러 부분에서 공유되는 디자인 규칙을 설명합니다.
테스트 사양. 테스트 스크립트 및 테스트 코드 디자인은 작업 및 시퀀스 다이어그램을 잘 사용하여 테스트 단계의 시퀀스를 설명할 수 있습니다. 요구 사항이 변경될 때 쉽게 변경할 수 있도록 시스템 테스트는 요구 사항 모델 측면에서 표현되어야 합니다.
프로젝트 계획. 프로젝트 계획 또는 백로그는 각 기능이 전달될 시기를 정의합니다. 구현하거나 확장하는 사용 사례 및 비즈니스 규칙을 명시하여 각 기능을 정의할 수 있습니다. 계획에서 직접 사용 사례 및 비즈니스 규칙을 참조하거나 별도의 문서에서 기능 집합을 정의하고 계획의 기능 제목을 사용할 수 있습니다.
반복 계획에서 모델 사용
모든 프로젝트는 규모와 조직에서 다르지만 일반적인 프로젝트는 2~6주 간의 일련의 반복으로 계획됩니다. 초기 반복의 피드백을 사용하여 범위 및 이후 반복에 대한 계획을 조정할 수 있도록 충분한 반복을 계획하는 것이 중요합니다.
반복 프로젝트에서 모델링의 이점을 실현하는 데 도움이 되는 다음과 같은 제안이 유용할 수 있습니다.
반복이 진행됨에 따라 포커스를 더 선명하게하라.
각 반복이 가까워지면 모델을 사용하여 반복이 끝날 때 배달할 항목을 정의하는 데 도움이 됩니다.
초기 반복에서 모든 항목을 자세히 모델링하지 마세요. 첫 번째 반복에서 사용자 용어집의 주 항목에 대한 클래스 다이어그램을 만들고, 주요 사용 사례의 다이어그램을 그리고, 주요 구성 요소의 다이어그램을 그립니다. 세부 정보는 프로젝트의 뒷부분에서 변경되므로 자세히 설명하지 마세요. 이 모델에 정의된 용어를 사용하여 기능 또는 주요 사용자 스토리 목록을 만듭니다. 프로젝트 전체에서 예상 워크로드의 대략적인 균형을 맞추기 위해 반복에 기능을 할당합니다. 이러한 할당은 프로젝트의 뒷부분에서 변경됩니다.
초기 반복에서 가장 중요한 모든 사용 사례의 간소화된 버전을 구현해 보세요. 이러한 사용 사례를 나중에 반복하여 확장합니다. 이 방법을 사용하면 프로젝트에서 너무 늦게 요구 사항 또는 아키텍처의 결함을 발견하여 이에 대해 아무것도 할 수 없는 위험을 줄일 수 있습니다.
각 반복이 끝날 무렵 요구 사항 워크샵을 개최하여 다음 반복에서 개발될 요구 사항 또는 사용자 스토리를 자세히 정의합니다. 우선 순위를 결정할 수 있는 사용자 및 비즈니스 관련자와 개발자 및 시스템 테스터를 초대합니다. 3시간 동안 2주 반복에 대한 요구 사항을 정의할 수 있습니다.
워크샵의 목적은 모든 사람들이 다음 반복이 끝날 때까지 달성 될 일에 동의하는 것입니다. 모델을 도구 중 하나로 사용하여 요구 사항을 명확히 합니다. 워크샵의 출력은 반복 백로그입니다. 즉, Team Foundation의 개발 작업 목록과 Microsoft Test Manager의 테스트 도구 모음입니다.
요구 사항 워크샵에서 개발 작업에 대한 예상을 결정해야 하는 경우에만 설계에 대해 논의합니다. 그렇지 않으면 사용자가 직접 경험할 수 있는 시스템 동작에 대해 계속 논의합니다. 요구 사항 모델을 아키텍처 모델과 별도로 유지합니다.
일반적으로 비기술 관련자는 UML 다이어그램을 이해하는 데 아무런 문제가 없으며, 몇 가지 지침이 있습니다.
모델을 작업 항목에 연결
요구 사항 워크샵 후에 요구 사항 모델의 세부 정보를 자세히 설명한 후 모델을 개발 작업에 연결합니다. Team Foundation의 작업 항목을 모델의 요소에 연결하여 이 작업을 수행할 수 있습니다.
모든 요소를 작업 항목에 연결할 수 있지만 가장 유용한 요소는 다음과 같습니다.
- 비즈니스 규칙 또는 서비스 품질 요구 사항을 설명하는 주석입니다. 자세한 내용은 모델 사용자 요구 사항을 참조하세요.
모델에 테스트 연결
요구 사항 모델을 사용하여 승인 테스트의 디자인을 안내합니다. 개발 작업과 동시에 이러한 테스트를 만듭니다.
이 기술에 대한 자세한 내용은 모델에서 테스트 개발을 참조하세요.
남은 작업 시간 예측
요구 사항 모델은 각 반복의 크기와 관련하여 프로젝트의 총 크기를 예측하는 데 도움이 될 수 있습니다. 사용 사례 및 클래스의 수와 복잡성을 평가하면 필요한 개발 작업을 예측하는 데 도움이 될 수 있습니다. 처음 몇 번의 반복을 완료한 경우 적용되는 요구 사항과 여전히 충족해야 하는 요구 사항을 비교하면 프로젝트의 나머지 부분의 비용과 범위에 대한 대략적인 측정값을 제공할 수 있습니다.
각 반복이 끝날 무렵, 향후 반복에 대한 요구 사항 할당을 검토합니다. 각 반복이 끝날 때 소프트웨어의 상태를 사용 사례 다이어그램의 하위 시스템으로 나타내는 것이 유용할 수 있습니다. 토론에서 사용 사례 및 사용 사례 확장을 이러한 하위 시스템 중 하나에서 다른 하위 시스템으로 이동할 수 있습니다.
추상화 수준
모델에는 소프트웨어와 관련하여 다양한 추상화가 있습니다. 가장 구체적인 모델은 프로그램 코드를 직접 나타내며, 가장 추상적인 모델은 코드에 표시되거나 표시되지 않을 수 있는 비즈니스 개념을 나타냅니다.
모델은 여러 종류의 다이어그램을 통해 볼 수 있습니다. 모델 및 다이어그램에 대한 자세한 내용은 앱에 대한 모델 만들기를 참조하세요.
다양한 종류의 다이어그램은 다양한 추상화 수준에서 디자인을 설명하는 데 유용합니다. 대부분의 다이어그램 형식은 둘 이상의 수준에서 유용합니다. 이 표에서는 다이어그램의 각 형식을 사용하는 방법을 보여줍니다.
| 디자인 수준 | 다이어그램 형식 |
|---|---|
| 비즈니스 프로세스 시스템을 사용할 컨텍스트를 이해하면 사용자에게 필요한 사항을 이해하는 데 도움이 됩니다. |
- 개념 클래스 다이어그램은 비즈니스 프로세스 내에서 사용되는 비즈니스 개념을 설명합니다. |
| 사용자 요구 사항 사용자가 시스템에서 필요로 하는 사항에 대한 정의입니다. |
- 비즈니스 규칙 및 서비스 품질 요구 사항은 별도의 문서에서 설명할 수 있습니다. |
| 높은 수준의 디자인 시스템의 전반적인 구조: 주요 구성 요소 및 함께 결합하는 방법. |
- 종속성 다이어그램은 시스템이 상호 종속적인 부분으로 구조화되는 방법을 설명합니다. 종속성 다이어그램에 대해 프로그램 코드의 유효성을 검사하여 아키텍처를 준수하는지 확인할 수 있습니다. |
| 코드 분석 코드에서 다이어그램을 생성할 수 있습니다. |
- 종속성 다이어그램은 클래스 간의 종속성을 보여 줍니다. 업데이트된 코드는 종속성 다이어그램에 대해 유효성을 검사할 수 있습니다. - 클래스 다이어그램은 코드의 클래스를 보여 줍니다. |
외부 리소스
관련 콘텐츠
비고
텍스트 템플릿 변환 구성 요소는 Visual Studio 확장 개발 워크로드의 일부로 자동으로 설치됩니다. Visual Studio 설치 관리자의 개별 구성 요소 탭에서 SDK, 라이브러리 및 프레임워크 범주 아래에 설치할 수도 있습니다. 개별 구성 요소 탭에서 모델링 SDK 구성 요소를 설치합니다.