개발자도 알아야 할 응용 프로그램 모델링 2/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 - 결론 및 저자 소개

3. 모델링 시작하기

 

3.1. 왜 모델링인가?

일반적으로 UML이라고 하면 Unified Modeling Language(통합 모델링 언어)라고 부르는 소프트웨어 공학의 표준화된 언어를 일컫는 용어입니다. 과거 1980년과 1990대 사이에 많은 객체 지향 모델링 기법이 생겨났었지만, 여러 사람들에 의해 다양한 모델링 기법과 표기법을 사용하였으며 어플리케이션을 위한 모델링, 또는 데이터베이스만을 위한 모델링 등 특정한 목표에 의해 사용되어 왔습니다.

1990년대 중반 Rational Software에서 여러 가지 노력 끝에 모델링 방법(Unified Method) 버전 0.8을 내놓았고 그 이후 컨소시엄 형태로 여러 기업이 합류하게 되었습니다. 이들은 1997년에 UML(Unified Modeling Language)로 이름을 바꾼 버전 1.0을 OMG 에 제출하면서 지속적으로 UML을 이끌어 왔습니다.

 

 

참고 : http://en.wikipedia.org/wiki/Unified_Modeling_Language

 

이전에는 여러 가지 독립적인 표기법을 사용했던 것과 달리, UML은 많은 업체 전문가들, 소프트웨어 개발 회사 등이 함께 만들어 오면서 소프트웨어 개발을 위한 전세계적인 표준 언어 모델링 역사가 시작된 것입니다.

모델링은 어떤 다이어그램을 선택하느냐에 따라서 그 내용과 추상화 정도가 달라지게 되지만, 일반적으로 어떤 특정한 개체를 나타내고자 할 때, 그리고 어떤 디자인(목표)를 정의할 때, 목표에 대한 예시(예제)등을 표현할 때 매우 적절하기도 합니다.

 

일상생활에서도 이러한 모델링 속에 우리가 살고 있다고 해도 과언이 아닙니다. 지하철 운행 정보와 지하철 노선도, 자동차 운전시에 네비게이션, 체계적으로 교통을 통제하는 신호등 같은 것들이 대표적이기도 합니다. 이런 생활 속의 모델링은 직접적으로 나에게 어떤 작용을 하는 것은 아니지만, 이러한 모델들은 나에게 의사 소통을 도와주고, 복잡한 것들은 단순화 시켜줍니다.

 

 

3.2. 왜 모델링을 해야 하는가?

아래와 같이 초등학교 교과서에 나올법한 전기 도면이 있습니다. 스위치를 누르면 불이 들어오는 도면입니다.

사실 위와 같은 간단한 전기 도면은 도면 자체로써 크게 가치가 없을지도 모릅니다. 하지만 더 복잡한 전기 도면은 실제로 도면을 통해 시뮬레이션을 하여 큰 오류를 미리 알아낼 수 있기도 합니다. 아래와 같은 표기법 등은 공통된 이해 관계자간에 어떻게 회로가 설계 되었는지, 어떻게 작동하는지 쉽게 이해할 수 있는 것입니다.

다음과 같은 악보도 마찬가지 입니다. 이 악보는 음악을 어떻게 표현하는지에 대한 표기법으로 구성되어 있습니다. 음악의 느낌과 연주 방법을 말로 하는 것보다 아래의 악보를 통해 연주자는 어떻게 연주를 해야 하는지 일관성 있게 알려줄 수 있는 표기법입니다.

 

우리가 모델링을 해야 하는 것도 이런 이유들과 크게 다르지 않습니다. 단순한 기능, 요구 사항의 구현에서는 이와 같은 모델링이 필요하지 않을 수 있겠지만, 이런 기능 명세나 요구 사항, 그리고 시스템, 아키텍처적인 측면에서는 완성되기 이전에 올바르게 그 목표를 정의하고 이해하는지 소통할 수 있는 방법은 모델링이라는 것입니다.

이러한 모델링은 여러 이해 관계자나 업무의 형태에 따라 매우 효과적으로 이용될 수 있습니다.

업무적인 측면에서 모델링은 업무의 프로세스를 표현하거나 이해하는데 매우 도움이 됩니다. 업무의 흐름에서 각 작업의 흐름을 파악할 수 있으며, 전체적으로 나와 관련되는 조직 체계를 이해하는데 효과적입니다. 아키텍처 측면에서 모델링은 구축하고자 하는 시스템의 추상화된 이해와 다른 연계 시스템과의 데이터나 연계적인 흐름을 정의하여 시스템 관리자 및 설계자, 개발자 간에 의사 소통에 용이합니다. 어플리케이션 측면에서 모델링은 시스템 자체에서 동작되는 방식을 정의하여 추상화된 아키텍처를 저수준에서 이해하는데 효과적입니다. 데이터베이스 측면에서 모델링은 데이터베이스에서 데이터의 구조를 정의하고 어플리케이션과 어떻게 교류하는지에 대해 이해하는데 효과적입니다.

 

 

3.3. 모델링을 위해 어떤 다이어그램이 있는가?

UML은 구조 다이어그램(structure diagram)과 행동 다이어그램(behavior diagram) 이라는 두 가지의 기본적인 다이어그램을 포함합니다. 구조 다이어그램은 시스템의 정적인 구조를 나타냅니다. 다양한 구조 다이어그램들은 다음과 같습니다.

• Class diagram(클래스 다이어그램)은 UML 모델링에서 사용되는 가장 일반적인 다이어그램으로 시스템, 그 구조 그리고 그들의 상호 관계 내에 존재하는 정적인 것을 나타냅니다. 시스템의 논리적 및 물리적 설계를 나타내는 데 주로 사용됩니다.
• Component Diagram(컴포넌트 다이어그램)은 컴포넌트집합 내의구성과 의존관계를 보여줍니다. 구현되는 시스템과 시스템 내에서 부품들이 어떻게 상호 작용하는지를 보여줍니다.
• Object Diagram(개체 다이어그램)은 시스템 내의일련의 개체들 사이의 관계를 보여 주는데, 특정시점에 시스템의 스냅샷을 보여줍니다
• Deployment Diagram(배치 다이어그램)은 물리적 시스템의 실행 시점의 아키텍처를 보여줍니다. 배치 다이어그램은 하드웨어와 이 하드웨어 내에 있는 소프트웨어의 설명을 포함할 수 있습니다.

 

UML 2.0은다음과 같은 구조 다이어그램을 추가되었습니다.

• Composite Structure Diagram(복합체 구조 다이어그램)은 모델링 요소들의 내부적 구조를 보여줍니다.
• Package Diagram(패키지 다이어그램)은 패키지 사이의 의존 관계를 나타냅니다. (패키지는 다른 모델 요소들을 그룹화하는데 사용되는 모델 요소입니다).

Behavior Diagram (행동 다이어그램)은 시스템 내 요소들의 동적인 행동을 나타냅니다. 다양한 행동 다이어그램들은 다음과 같습니다.

• Activity Diagram(활동 다이어그램)은 시스템 내의 활동들의 흐름을 보여준다. 여러 업무 프로세스들을 설명하는데 자주 사용됩니다.
• Use Case Diagram(사용 사례 다이어그램)은 시스템이 구현할 업무 프로세스를 다룹니다. Use Case Diagram은 시스템이 작동하는 방법과 시스템과 교류하는 사람들을 나타냅니다.
• Statechart Diagram(상태 다이어그램)은 개체의 상태와, 이 개체가 상태들 사이를 어떻게 전이하는지 보여줍니다. 상태 다이어그램은 상태, 전이, 이벤트, 그리고 활동을 포함할 수 있습니다. 상태 다이어그램은 동적 뷰를 제공하며, 이벤트 중심의 행동을 모델링할 때 매우 중요하죠. 예를 들어, 전화 교환 시스템 내의 스위치를 나타내기 위해 상태 다이어그램을 사용할 수 있습니다. 이 스위치는 여러 이벤트들에 기초하여 상태를 바꾸며, 어떻게 이 스위치가 작동하는지를 이해하기 위해 상태 다이어그램에서 이 이벤트들을 모델링할 수 있습니다. UML 2.0에서는 State Machine Diagram(상태 기계 다이어그램)이라고 합니다.
• Collaboration Diagram(협력 다이어그램)은 Sequence Diagram(순차 다이어그램) 처럼 Interaction Diagram(교류 다이어그램)의 일종입니다. 협력 다이어그램은 개체들이 어떻게 협력하고 교류하는지를 강조합니다. UML 2.0 에서 협력 다이어그램과 대등한 것은 Communication Diagram(통신 다이어그램)입니다.
• Sequence Diagram(순차 다이어그램)은 또 다른 종류의 교류 다이어그램입니다. Sequence Diagram은 시스템의 다른 요소들 사이의 메시지들의 시간 순서를 강조합니다.

UML 2.0은 다음과 같은 행동 다이어그램을 추가합니다.

• Timing Diagram(타이밍 다이어그램)은 또 다른 종류의 교류 다이어그램이다. 세부 타이밍 정보와, 교류하는 요소들의 상태 또는 조건 정보에 대한 변경 사항을 나타냅니다.
• Interaction Overview Diagram(교류 개요 다이어그램)은 Interaction Sequences(교류 순차)들 사이의 제어 흐름에 대한 개요를 보여주는 데 사용되는 고수준의 다이어그램입니다.

 

3.4. Visual Studio의 모델링 지원

Visual Studio부터 지원하는 모델링은 다음과 같은 제품에서 지원합니다. 더 자세한 내용은 Visual Studio 제품 페이지를 참고하십시오. (http://www.microsoft.com/visualstudio/ko-kr/products)

Visual Studio버전의 모델링은 현재 UML 2.0 기준의 13가지의 모든 다이어그램을 제공하지 않습니다. Visual Studio에서 제공하는 다이어그램은 다음과 같습니다.

• UML Activity Diagrams
• UML Use Case Diagrams
• UML Sequence Diagrams
• UML Class Diagrams
• Layer Diagrams

 

제품 기능	Professional (MSDN Essentials 포함)	Professional (MSDN 포함)	Premium (MSDN 포함)	Ultimate (MSDN 포함)	Test Professional (MSDN 포함)
아키텍처 및 모델링
아키텍처 탐색기
UML® 2.0 규격 다이어그램(활동, 사용 사례, 시퀀스, 클래스, 구성 요소)
Layer Diagrams 및 종속성 유효성 검사
읽기 전용 다이어그램(UML, 레이어, DGML 그래프)

 

 

3.5. 모델링 프로젝트 생성

Visual Studio에서는 모델링을 위한 프로젝트 형식을 지원해 줍니다. 모델링 프로젝트 형식은 여러 가지 다이어그램을 만들 수 있는 아이템 템플릿을 제공을 해줍니다. 우리가 다이어그램을 만들기 전에 먼저 모델링 프로젝트를 어떻게 만드는지 아래의 단계를 따라 하면서 살펴봅시다.

 

모델링 프로젝트를 생성하기 위해 Visual Studio을 실행합니다.

1. 파일->새로 만들기-> 프로젝트를 선택합니다.

   

    

2. 프로젝트 템플릿에서 "모델링 프로젝트"를 선택하고, 프로젝트의 이름과 솔루션 이름을 입력하고 확인 버튼을 클릭합니다.
   

    

3. 솔루션 탐색기에 모델링 프로젝트가 생성된 것을 확인합니다.
   

 

모델링 프로젝트를 정상적으로 생성이 완료가 되었다면 이제부터 모델링을 할 수 있는 환경이 모두 완료되었습니다.