개발자도 알아야 할 응용 프로그램 모델링 4/7 - 모델링 다이어그램

본 아티클은 MSDN 에 eBook으로 공개된 문서를 블로그 아티클로 편집하였습니다. VSTS 팀블로그에 의해 작성된 문서의 원문 및 여러 가지 기술 문서는 아래의 링크에서 PDF로 다운로드 받을 수 있습니다. 그리고 본문의 특정 버전을 지칭하는 개발툴 버전 번호는 모두 Visual Studio로 변경되었음을 참고하십시오. (예- Visual Studio 20xx는 Visual Studio로 표기함 )

VSTS 팀블로그 MSDN 기술 문서 : http://msdn.microsoft.com/ko-kr/gg620748 

필자 소개 Microsoft Visual Studio ALM MVP 엄준일 http://blog.powerumc.kr   Visual Studio Korea Team Blog http://vsts2010.net

감수 : 강성재 부장 한국마이크로소프트 개발자 및 플랫폼 사업 총괄     도움주신 분 : 김남영 부장 한국마이크로소프트 개발자 및 플랫폼 사업 총괄

   

[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 1/7 - 들어가기에 앞서...
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 2/7 - 왜 모델링인가?
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 3/7 - 모델링의 표기
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 4/7 - 모델링 다이어그램
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 5/7 - Visualization & Features Pack
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 6/7 - 모델링 확장 (SDK)
[Enterprise Architecture/Architecture] - 개발자도 알아야 할 응용 프로그램 모델링 7/7 - 결론 및 저자 소개

 

5. Visual Studio Modeling

Visual Studio의 모델링 다이어그램은 여러 가지 요구 사항 및 코드를 이해하고 명확하게 의견을 교환하는데 도움을 줍니다. 예를 들면, 사용자의 요구 사항을 Use Case Diagram이나 Sequence Diagram은 개발자에게 매우 유용합니다. 또한 시스템적으로는 Component Diagram, Activity Diagram, Layer Diagrams을 사용합니다.

이러한 여러 가지 다이어그램은 이해 관계자를 이해하고 큰 틀을 표현하는데 매우 효과적이지만, 가장 중요한 것은 이것들을 코드로 표현하는 것이며, 특히 Visual Studio Modeling은 개발자가 올바르게 모델을 구현할 수 있는 수단이 됩니다. 애자일에서 소스 코드가 산출물이라는 잘못된 강박관념에서 벗어나, 오히려 적절한 시점에 초기에 모델링을 하는 것은 매우 효과적이기도 합니다.

 

위의 그림에 정말로 아름다운 보름달이 있습니다. 하늘에 구름 한 점 없는 추석에 볼 수 있는 보름달이죠. 지금 독자 여러분은 모두 이 보름달을 바라보고 있지만, 사실 현실세계에서는 반드시 저 보름달을 모두 함께 바라보리라는 보장을 할 수 없을 겁니다.

필자와 독자 여러분들과 함께 저 보름달에 가기 위해서 여러 가지 이야기를 나누면서 제가 저 보름달을 손가락으로 가리키고 있습니다. 전자인 경우 몇몇의 대부분은 저 보름달에 가기 위한 목표로 즐거운 대화를 나눌 수 있지만, 어떤 누군가는 전혀 그렇지 않을 수도 있습니다. 아쉽게도 후자의 몇몇의 사람들은 보름달을 가리키고 있는 제 손가락 끝의 손톱 때를 보면서 잡담을 나누기도 합니다.

이런 현상은 개발하는 조직에서 특히 쉽게 찾아볼 수 있는 현상입니다. 우리 팀이 나아갈 방향과 목표, 그리고 개발해야 할 이상적인 구조를 이야기 할 때, 어떤 누군가는 어떻게 구현할지 머리 속으로 코드만 생각하는 사람들도 있습니다. 반대로 올바른 코드를 작성하고 적절한 리팩토링에 대해 이야기를 할 때, 발전적인 개선할 점에 대한 내용이 아닌 그 이상의 무언가가 잘못됐다고 불평을 하는 사람들도 있습니다. 왜 그럴까요? 서로가 주제에 대한 문제점에 대해서 인식을 하고 있지만, 그것을 바라보는 시각은 전혀 다르기 때문입니다.

분명 필자가 보름달을 가리키면서 야망에 사로잡혀 허황된 꿈을 꾸는 것처럼 보일 수 있지만, 만약 위와 같은 목표를 이룰 수 있는 우주선 설계 도면과 같은 계획을 한다면 필자의 손가락 끝의 손톱 때가 아닌 더 발전적인 방향의 이야기가 될 가능성이 충분하다는 것입니다. (물론 처음부터 완벽한 설계 도면을 만들기란 어렵겠지요.)

분명 개발자와 개발자 또는 개발자와 관리자 간에 발생할 수 있는 이러한 커뮤니케이션의 실수 가운데 모델링을 통하여 서로 공감대를 이루기 쉬운 커뮤니케이션을 할 수 있는 수단이 됩니다. 머릿속에 있는 자신만의 생각을 뚝딱 뚝딱 코드로 완성하여 "짜잔~" 하고 보여주더라도, 완벽한 코드가 아닐 수 있으며 얼마든지 리팩토링 대상이 될 수 있습니다. 자신의 생각을 코드로만 표현할 수 있는 개발자는 안타깝지만 현재의 시대가 원하는 개발자가 아니라고 필자는 생각이 듭니다.

최근의 대부분 개발 도구는 통합 개발 환경을 제공하고 있으며, 특히 Visual Studio부터는 UML 다이어그램도 지원을 해 주고 있습니다. 다음 단원부터 이런 UML을 통해 독자 여러분들이 어떻게 활용할 수 있을지도 함께 생각하면서 보시면 더욱 이 백서가 빛을 발휘할 것이라고 생각합니다.

 

5.1. UML Activity Diagrams (동작 다이어그램)

Activity Diagrams은 소프트웨어의 일련의 프로세스나 업무/비즈니스 프로세스에 대한 일련의 워크플로우를 나타냅니다. 이런 프로세스나 워크플로우의 흐름을 제어하거나 분기, 조인 등의 프로세스를 기술할 수 있습니다. 또한 소프트웨어에서 사용되는 프로토콜을 정의하거나 컴포넌트 상호간에 상호작용을 이해하거나 기술하는데 사용할 수 있습니다.

이러한 Activity Diagrams을 사용하면 여러 가지 이점이 있습니다.

• 시스템 내부 동작과는 별개로 외부 동작에 집중할 수 있습니다.
• 자연어를 사용하는 것에 의한 모호성을 줄일 수 있습니다.
• 사용자/개발자/테스트 등 일관적인 용어를 정의할 수 있습니다.
• 요구 사항의 차이점의 불일치를 줄일 수 있습니다.
• 요구 사항 변경을 처리하는 시간을 줄일 수 있습니다.

 

5.1.1. Activity Diagrams 만들기

Activity Diagrams은 모델링 프로젝트에서 새로운 항목을 추가하여 생성할 수 있습니다.

1. 솔루션 탐색기에서 모델링 프로젝트에서 마우스 오른쪽 버튼을 클릭하여 추가-> 새 항목을 클릭합니다.
   

    

2. 새 항목 추가 창에서 "UML Activity Diagrams"을 선택하고 추가 버튼을 클릭하여 완료합니다.
   

    

Activity Diagrams이 완성되었습니다.

5.1.2. 간단한 흐름 제어

Activity Diagrams에서 하나의 요소는 하나의 작업을 의미하게 됩니다. 그리고 요소를 연결선으로 연결함으로써 흐름의 제어를 구성할 수 있습니다.

 

 

도구 상자에 여러 가지 요소가 포함이 되어 있고, 이 요소를 Activity Diagrams의 디자인 화면에 추가하기 위해서 도구 상자에서 요소를 선택하고 디자인 화면으로 드래그&드랍 동작을 수행합니다.

아래의 간단한 제어 흐름 예제는 한 동작에서 다음 동작의 흐름을 나타냅니다. 순차적으로 흐름이 전달되는 방식으로 일반적으로 이전 동작이 완료된 후에 다음 동작을 수행합니다. Activity Diagrams은 동작에 대한 흐름을 기술하지만 동작이 실행되거나 동작 사이의 제어가 전달되는 방식은 기술하지 않습니다.

위의 간단한 제어 흐름에서 초기 노드를 시작하여 동작 최종 노드까지 하나의 비즈니스 프로세스가 완료되는 것을 알 수 있습니다. 그 중 의사 결정 요소를 통해 조건에 대한 흐름이 분기가 되며, 병합 노드는 분기된 흐름을 병합하는 역할을 수행합니다.

 

5.1.3. 동시 흐름

동시 흐름은 동시에 동작하는 요소를 기술할 수 있습니다. 다음은 동시 흐름을 기술하는 다이어그램의 예 입니다.

 

처음의 분기 노드는 분기되는 요소에 대해 각 토큰을 생성하여 마지막 병합 노드에서 들어오는 각 토큰에 대해 동시 흐름을 단일 흐름으로 병합하게 됩니다.

"주문서"에 해당하는 신호 보내기 동작은 메시지의 신호를 보냅니다. "금액 지불" 이베트 적용 동작은 다음 동작을 계속하기 전에 메시지나 신호를 기다리는 동작을 수행합니다.

 

5.1.4. 데이터 흐름

데이터 흐름은 각 동작간에 데이터 흐름을 기술하게 됩니다. 다음은 데이터 흐름의 예 입니다.

 

 

위의 개체 노드는 흐름에 따라 전달되는 데이터를 의미 합니다. 이 개체 노드는 입력 핀과 출력 핀을 통해 데이터를 입력 받거나 작업의 처리에 대해 출력을 나타내며, 동작 매개 변수 노드는 동작에 의해 데이터를 생성하거나 받을 때 사용합니다.

 

5.2. UML Use Case Diagrams (사용 사례 다이어그램)

Activity Diagrams에 정의되는 시스템 내부적인 워크플로우나 업무/비즈니스 등을 정의하는 것이 초점이라면, Use Case Diagrams은 시스템이 구현할 업무/비즈니스 프로세스를 다루는 것이 다릅니다.

Use Case Diagrams은 어플리케이션 또는 사용자가 어플리케이션의 시스템으로 수행할 수 있는 작업에 대해 요약합니다. 특히 Use Case Diagrams은 사용자의 요구 사항을 기술하기 위한 중심 역할을 하게 됩니다. 하지만 이러한 요소 사항은 너무 자세하게 기술하지 않으며 별도의 다이어그램으로 세부적인 내용을 기술할 수 있습니다.

Use Case Diagrams을 사용하면 다음과 같은 이점이 있습니다.

• 시스템이나 어플리케이션이 사용자/조직 또는 외부 시스템과 상호 작용하는 흐름의 이해가 쉽습니다.
• 해당 행위자가 달성해야 하는 목표를 쉽게 이해할 수 있습니다.
• 시스템의 범위를 이해할 수 있습니다.

 

5.2.1. Use Case Diagrams 만들기

 

1. 메뉴의 아키텍처->새 다이어그램을 클릭합니다.
   

    

2. 새 다이어그램 추가 창에서 "UML Use Case Diagrams"을 선택하고 확인 버튼을 클릭합니다.
   

 

Use Case Diagrams이 제공하는 도구 모음은 다음과 같습니다.

 

5.2.2. 행위자, 사용 사례, 하위 시스템

행위자, 사용 사례, 하위 시스템은 행위자가 하위 시스템에 참여하여 사용 사례를 만드는 예제입니다.

각 행위자인 고객, 레스토랑 중 고객은 레스토랑이 제공하는 음식점 시스템에 참여하게 됩니다. 레스토랑 행위자 또한 음식점 시스템에 참여하여 메뉴를 주문 받고, 고객 행위자에게 적절한 서비스를 제공한다는 사용 사례를 나타냅니다.

 

5.2.3. 사용 사례 구성

사용 사례 구성은 사용 사례 요소 간에 흐름이 연결되거나 상속, 포함, 아티펙트에 대한 예를 보여 줍니다.

 

일반 고객과 VIP 고객은 "일반화" 요소를 이용하여 상속을 구성합니다. 음식 주문은 음식 주문과 연관되는 사용 사례를 포함하도록 구성하였고, 메뉴 필터는 메뉴 선택 사례를 확장하고 메뉴 필터는 각 요리 필수사항과 요리법을 상속하게 됩니다.

그리고 사용 사례의 아티팩트는 다른 다이어그램이나 외부 링크를 제공합니다. 또는 솔루션 폴더에서 솔루션 항목을 드래그&드랍하게 되면 그 문서에 대한 아티팩트가 자동으로 생성합니다.

이러한 형태로 시스템을 작동하는 방법과 이 시스템과 교류하는 흐름을 나타내며, 구현 레벨의 좀 더 상위 고수준의 관계를 이해하는데 도움이 됩니다.

 

5.2.4. 시스템의 버전 정보 기술하기

시스템의 버전 정보를 기술하기 위해 단계적으로 기능 또는 사용자 측면의 사례를 기술할 수 있습니다.

아래와 같이 Release 1에서는 메뉴 주문 기능을 구현한다는 것으로 이해할 수 있습니다. 음식 주문을 위해 메뉴를 선택하고 주문을 완료하는 단순한 기능의 범위만 제공한다는 것을 알 수 있으며, 이는 설계자 외에 사용자도 명확하게 Release 1의 시스템을 이해할 수 있을 것입니다.

 

아래와 같이 Release 2에서는 기존의 메뉴 주문 기능을 포함하도록 기능을 확장한다는 내용이 포함이 됩니다. 점주에 의해 레스토랑의 메뉴와 레스토랑 관리 기능을 포함시켜 레스토랑의 시스템을 이용하여 메뉴를 선택하고 금액을 지불하거나 메뉴를 관리하는 범위임을 이해할 수 있습니다.

 

아래와 같이 Release 3에서는 기본적인 기능을 확장하고 모바일 디바이스를 통해 메뉴를 제공하는 시스템의 기능을 범위로 한다는 것을 알 수 있습니다.

이렇게 Use Case Diagrams을 이용하여 시스템의 버전 정보를 기술하기 위한 용도로 사용이 가능하며 이렇게 함으로써 점진적인 시스템 구축의 전체 윤곽을 이해 관계자 간에 이해하는데 많은 도움을 줄 수 있습니다.

 

5.2.5. 아티펙트의 문서를 열기 및 연결

아티펙트는 다양한 방법으로 연계되는 다이어그램 및 문서, 그리고 웹 문서 등을 포함시킬 수 있습니다. 다음은 여러 가지 방법으로 아티펙트를 연결하거나 추가하는 방법입니다.

1. 아티팩트의 연결된 문서를 열려면?
   아티펙트의 요소에서 마우스를 두 번 클릭합니다.
   
   
2. 솔루션에 포함된 문서를 아티펙트로 추가하려면?
   솔루션에 포함된 항목을 Use Case Diagrams으로 드래그&드랍합니다.
   
   
3. Word 및 PowerPoint 문서를 추가하려면?
   아티펙트를 선택하여 속성 창에서 하이퍼링크 항목을 클릭하여 추가하고자 하는 문서를 찾아 선택합니다.
   
   
   
4. HTTP/HTTPS 또는 공유 문서를 열려면?

1. 아티펙트를 선택하여 속성 창에서 하이퍼링크를 선택합니다. "URL 또는 파일에 링크" 창에서 링크하고자 하는 HTTP/HTTPS 링크를 입력합니다. 만약 OneNote 의 공유 문서에 링크를 원하면 onenote:// 의 링크를 입력하면 됩니다.
   

 

5.3. UML Component Diagrams (구성 요소 다이어그램)

Component Diagrams은 소프트웨어 시스템의 각 구성 요소를 디자인할 수 있습니다. 시스템 구조에 따른 컴포넌트와 인터페이스를 확인하고 이들 컴포넌트간에 서비스의 동작을 이해하는데 중요한 역할을 합니다.

Component Diagrams을 이용하면 다음과 같은 이점이 있습니다.

• 기존 디자인을 이해하거나 새로운 디자인을 하는데 용이합니다.
• 시스템이 제공하는 인터페이스와 필요한 인터페이스가 잘 정의되면 구성 요소를 분리하여 개선하거나 변경에 쉽게 대처할 수 있습니다.

 

5.3.1. Component Diagrams 만들기

1. 모델링 프로젝트에서 마우스 오른쪽 버튼을 클릭한 후, 추가->새 항목을 클릭합니다.
   
   
   2. 새 항목 추가 대화 상자에서 UML Component Diagrams을 선택하고 추가를 클릭합니다.

1. 

    

Component Diagrams이 제공하는 도구 상자의 요소는 다음과 같습니다.

 

5.3.2. 음식점 Component Diagrams 만들기

간단하게 어떤 구성 요소가 필요한지 간단하게 다음과 같이 구성 요소를 배치 합니다. 주방 서버는 파트로 구성되어있습니다.

파트 구성 요소를 만들려면? 도구 상자에서 구성 요소를 클릭하고 디자인에 포함된 구성 요소 하나를 클릭합니다. 그러면 구성 요소 안에 파트가 아래와 같이 파트가 추가됩니다.

 

각 구성 요소간에 인터페이스 포트가 필요한데, 이 인터페이스 포트는 다른 구성 요소간의 흐름과 데이터를 표현하는데 사용합니다.

웹 브라우저 구성 요소는 필요한 인터페이스로 HTTP 인터페이스를 생성하였습니다. 음식점 웹사이트와 고객 웹 서비스의 제공된 인터페이스를 통해 웹 브라우저가 음식점 웹서비스에 접근할 수 있도록 구성합니다.

 

고객 웹 서비스는 필요한 인터페이스가 필요하며, 이 컴포넌트를 외부 시스템과 연결하기 위해 음식점 웹서비스도 지불 인증에 대한 필요한 인터페이스가 존재합니다. 고객 웹 서비스는 이 필요한 인터페이스를 통해 외부에서 결제 시스템을 제공하는 인터페이스로 연결하기 위해 이 필요한 인터페이스간에 위임을 통해 연결합니다.

 

고객 웹 서비스는 주방 서버가 제공하는 인터페이스가 필요합니다. 고객 웹 서비스에 필요한 인터페이스를 추가하고, 주방 서버는 제공된 인터페이스를 추가하여 이 둘 간에 파트 어셈블리를 이용하여 연결합니다. 연결된 파트 어셈블리는 구성 요소에 따라 다르게 구현될 수 있음을 의미하지만, 이 연결된 파트는 동일한 부모 구성 요소를 필요로 합니다.

주방 서버는 필요한 인터페이스로 주방작업 큐를 추가하여 주방 웹 사이트의 제공된 인터페이스를 위임을 통해 연결하여 주방 서버의 작업을 완료합니다.

 

5.4. UML Class Diagrams (클래스 다이어그램)

Class Diagrams은 컴포넌트 또는 어플리케이션의 내부적으로 사용하는 개체 정보에 대한 구조를 기술합니다. 데이터베이스 테이블이나 XML, 또는 개체의 관계를 표현할 수 있습니다. Class Diagrams은 데이터의 형식이나 관계를 구현 및 분리할 수 있습니다. Class Diagrams은 주로 논리적인 측면에 중점을 두어 정의합니다.

Class Diagrams을 이용하면 다음과 같은 이점이 있습니다.

• 시스템 간에 전달되는 요소에 대한 구현과 독립적인 설명을 제공
• 어플리케이션과 사용자 간의 통신에 사용되는 용어를 명확하게 정의

 

5.4.1. Class Diagrams 만들기

1. 모델링 프로젝트에서 마우스 오른쪽 버튼을 클릭한 후, 추가->새 항목을 선택합니다.
   
   
2. 새 항목 추가 대화 상자에서 "UML Class Diagrams"을 선택한 후 추가를 클릭합니다.

 

다음은 Class Diagrams의 도구 상자에서 지원하는 요소입니다.

 

5.4.2. 메뉴 및 주문 Class Diagrams

메뉴와 주문에 필요한 클래스를 도구 상자에서 끌어와 각 클래스를 만듭니다.

 

그리고 Menu와 MenuItem은 집합체로 구성하기 위해 Menu를 선택하고 에서 추가->집합체를 선택합니다.

 

집합체의 MenuItem을 Menu의 1:* 관계를 만들기 위해 MenuItem을 선택한 후 속성 창에서 "복합성"을 * 로 선택합니다. 그리고 탐색 가능을 False 로 설정하여 단방향 탐색이 가능하도록 합니다.

 

 

Menu와 Order 클래스간의 연결 관계를 만듭니다.

 

Order클래스는 연결 요소의 속성 창에서 복합성을 * 로 선택하고 탐색 가능을 False 로 설정합니다.

 

Menu클래스도 연결 요소의 속성 창에서 탐색 가능을 False 로 설정합니다.

 

다음은 위와 같은 방법으로 관계를 완성한 Class Diagrams 입니다.

 

이제 각 클래스에 속성과 메서드 등의 작업을 추가합니다. 메서드(작업)에 아래와 같이 임의로 정의한 매개 변수를 추가를 할 수 있습니다.

 

Order클래스의 DeleteItem을 선택한 후 속성 창에서 매개 변수를 클릭하여 대화 상자를 엽니다.

 

작업 매개 변수 컬렉션 편집기 대화 상자에서 매개 변수의 이름을 입력한 후 형식에서 MenuItem 형식을 선택하여 확인을 클릭합니다.

 

그럼 다음과 같이 MenuItem 형식의 매개 변수를 갖는 메서드를 추가할 수 있습니다.

 

다음은 완성된 메뉴 및 주문 Class Diagrams입니다.

 

5.5. UML Sequence Diagrams (시퀸스 다이어그램)

Sequence Diagrams은 클래스나 구성 요소, 인스턴스, 시스템 간의 메시지 동작의 순서를 나타내는 다이어그램입니다. 일반적으로 Sequence Diagrams은 위에서 아래로 시간적인 흐름을 갖고 있습니다. Sequence Diagrams의 수평선의 상호 작용 참가자 간의 이벤트를 나타냅니다.

Sequence Diagrams을 사용하면 다음과 같은 이점이 있습니다.

• 구성 요소간의 작업이 진행되는 흐름을 쉽게 확인할 수 있습니다.
• 어플리케이션에서 상호 작용을 어렵게 하는 패턴을 식별할 수 있습니다.

 

5.5.1. Sequence Diagrams 만들기

1. 모델링 프로젝트의 항목에서 마우스 오른쪽 버튼을 클릭하여 추가->새 항목을 선택합니다.
   
   
2. 새 항목 추가 대화 상자에서 "UML Sequence Diagrams"을 선택하고 추가를 클릭합니다.

 

다음은 Sequence Diagrams이 제공하는 대화 상자의 요소입니다.

 

5.5.2. 음식 제공 서비스 Sequence Diagrams

우선 각 메시지 이벤트를 송수신하는 주체인 참가자를 추가해야 합니다. 도구 상자의 수평선을 이용하여 세 개의 참가자를 추가합니다.

비동기 요소를 이용하여 알 수 없는 특정 메시지를 고객 타임라인에 추가 합니다.

손님이 주문을 하기 위해 주문 타임라인에 주문에 대한 메시지를 보내야 합니다.

비동기 메시지를 통해 주문 타임라인에 주문한 내용을 추가하는 메시지를 보냅니다.

주문을 받으면 메뉴 관리자에게 주문 내역이 요리 가능한지 확인을 하는 동기 메시지를 보내고, 메뉴 관리자는 메시지의 응답을 기다리는 호출자에게 어떤 메시지를 콜백합니다. 그럼 주문 타임라인은 그 주문에 대해 최종적으로 정리 작업을 진행하고 주문을 하기 위한 모든 작업을 완료 합니다.

여러 개의 주문에 대해 처리를 할 경우 주문 추가 비동기 메시지부터 루프 코드를 감싸도록 합니다.

 

그리고 루프 코드의 가드를 이용하여 루프가 벗어나게 되는 조건을 기술해 줍니다.

 

주문에 대한 루프 작업이 완료되었다면, 루프가 완료되는 시점의 상호 작용 요소를 추가합니다.

 

상호 작용 요소는 다른 다이어그램과 연결할 수 있는 요소입니다. 현재 Sequence Diagrams과 연결된 새로운 시퀸스를 만들려면 "새 시퀸스 만들기"를 선택합니다. 새로운 시퀸스 만들기를 선택하면 새로운 Sequence Diagrams 파일이 생성이 됩니다.

또는 시퀸스에 연결을 선택하면 이미 존재하는 Sequence Diagrams과 연결을 할 수 있습니다.

 

마지막으로 비동기 메시지를 이용하여 재고 및 매출 업데이트 메시지를 보내고, 시퀸스는 종료됩니다.

 

 

5.6. Layer Diagrams (레이어 다이어그램)

Layer Diagrams은 시스템의 논리적인 아키텍처를 시각화할 수 있습니다. Layer Diagrams은 물리적인 아티펙트를 논리적인 추상 그룹으로 구성합니다.

Layer Diagrams은 논리적인 아키텍처를 시각화하는 것 이외에, 실제 Visual Studio에서는 동작하는 코드와 논리적 아키텍처간의 충돌을 검사하기도 합니다. 시스템을 리팩토링하거나 업데이트 시에 변경에 미치는 영향을 분석하며 체크인 또는 빌드 작업에 충돌에 대한 유효성을 검사하도록 하여 기존의 계획을 강화할 수 있는 방법으로 사용할 수 있습니다.

 

5.6.1. Layer Diagrams 만들기

1. 솔루션 탐색기의 모델링 프로젝트에서 마우스 오른쪽 버튼을 클릭하여 추가->새 항목을 선택합니다.
   
   
2. 새 항목 추가 대화상자에서 Layer Diagrams을 선택하고 추가를 클릭합니다. 

Layer Diagrams은 도구 상자에 다음과 같은 요소를 제공합니다.

 

5.6.2. Layer Diagrams

Layer Diagrams으로 논리적인 3-tier 어플리케이션을 다음과 같이 구성할 수 있습니다.

 

각 레이어에 종속되는 레이어를 추가 하기 위해서 레이어를 선택하여 마우스 오른쪽 버튼을 클릭한 후 추가->레이어를 선택하여 종속된 레이어를 추가할 수 있습니다.

 

다음은 완성된 Layer Diagrams의 예입니다.

 

5.6.3. 코드와 Layer Diagrams 연동

실제 물리적인 코드와 Layer Diagrams 간의 연관 관계를 만들어 아키텍처를 분석하고 유효성을 검사할 수 있습니다.

1. 솔루션 안에 간단한 논리적인 3 tier 를 구현한 프로젝트를 각 레이어에 맞게 드래그&드랍 합니다.

   

    

2. 각 레이어에 추가된 프로젝트의 개수가 표시되는지 확인합니다.

   

    

3. 레이어 탐색기에 추가된 프로젝트가 존재하는 것을 확인할 수 있습니다.

   

    

4. 레이어 디자이너에서 마우스 오른쪽 버튼을 클릭하여 "아키텍처 유효성 검사"를 클릭합니다.

   

   
   

   5. 출력 창에 아키텍처 유효성 검사 결과가 표시됩니다.

    

5.6.4. 네임스페이스로 실제 코드의 유효성 검사

1. 레이어를 선택하여 속성 창을 확인합니다.

   

    

2. 사용할 수 없는 네임스페이스 또는 사용할 수 없는 네임스페이스 종속성에 적절한 네임스페이스를 입력합니다.

   

3. Layer Diagrams에서 마우스 오른쪽 버튼을 클릭하여 아키텍처 유효성 검사를 클릭합니다.

   

    

4. 출력 창에 아키텍처 유효성 검사 결과가 표시됩니다.

   

 

5.6.5. 명령 프롬프트로 유효성을 검사

Visual Studio에서 명령 프롬프트를 이용하여 빌드를 수행할 때 Layer Diagrams의 아키텍처 유효성을 검사할 수 있습니다.

이 방법을 이용하면 개발 도구가 없는 경우, 그리고 Team Foundation의 Team Build 시 아키텍처 유효성을 검사할 때 유용하게 사용할 수 있습니다.

 

5.6.5.1. MSBUILD 명령 프롬프트로 아키텍처 유효성을 검사하려면?

Visual Studio명령 프롬프트를 실행한 수 다음과 같이 MSBUILD 명령 옵션으로 모델링 프로젝트의 아키텍처 유효성을 검사합니다.

C:\> msbuild <FilePath+ModelProjectFileName>.modelproj /p:ValidateArchitecture=true

 

또는 전체 솔루션 중 모델링 프로젝트의 아키텍처 유효성을 검사하려면 다음과 같이 솔루션 파일을 입력한 후 옵션을 지정합니다.

C:\> msbuild <FilePath+SolutionName>.sln /p:ValidateArchitecture=true

 

 

5.6.5.2. Team Foundation 의 Team Build로 아키텍처 유효성을 검사하려면?

Team Foundation 의 Team Build에서 아키텍처 유효성을 검사하려면 다음과 같은 방법으로 MSBUILD 옵션을 지정해 줄 수 있습니다.

1. 팀 프로젝트를 연결하고 아키텍처 유효성을 검사할 빌드 항목을 선택한 후 빌드 정의 편집을 선택합니다.

   

    

2. 프로세스 탭으로 이동한 후 3. 고급 탭으로 이동한 후 MSBUILD 인수 항목에 /p:ValidateArchitecture=true 인수를 입력한 후 저장합니다.