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

 

4. 모델링을 하기 앞서

다음 회차에서 Visual Studio 모델링을 배우기 앞서, 많은 개발자들은 모델링을 어떻게 시작하면 좋은지에 대해 고민을 하시는 분들도 많습니다. 모델링의 목적이 복잡하고 추상적인 것으로부터 명확하게 요소를 구분하여 표현하는 것이긴 하지만, 무엇을 명확하게 표현해야 할 지도 고민해야 할 부분 입니다.

예를 들어, 구현을 하기 위해 모델링을 하는 것인지… 아니면 그 상위 시스템과 비즈니스 워크플로우를 명확하게 하고자 하는 것인지… 모델링이라는 도구를 잡는 사람들마다 그 목적이 다르고 사용하는 방법도 다를 것이라고 생각합니다.

한 가지 UML에 대해 잠깐 동안 되집어 생각해 볼 것이 있습니다. 왜 UML 이 성공했는가? 라는 물음입니다. UML이 추구하고자 했던 것은 UML 을 이용하여 소프트웨어를 설계하거나 객체지향적인 설계에 등의 어떠한 노하우도 포함시키지 않았습니다. 다시 말해, UML은 [모델의 표기 방법]만을 규정하였습니다.

어떠한 소프트웨어를 만들던지 그 소프트웨어에 포함되는 구성요소나 설계가 완전히 틀릴 수 있지만, UML을 이용하여 표기법이 통일 된다면 이해 관계자간에 의사소통은 쉬워질 것입니다.

다음 회차에서 다룰 모델링의 표현 방법 등은 잠시 뒤로 미루고 무엇을 모델링할 것인지에 대해 먼저 함께 고민해야 할 것 같습니다.

 

4.1. 모델링의 관점 및 측면

모델러(모델링의 하는 주체)는 어떤 관점과 어느 측면을 바라보고 다양한 방법으로 모델링을 할 수 있습니다. 이런 모델러의 관점과 측면을 이해할 수 있다면 정확하게 정보를 전달할 수 없을지도 모릅니다.

 

모델러가 생각하는 관점과 측면으로 올바르게 모델링의 정보가 전달되지 않는다면, 위와 같은 그림을 해석은 매우 달라질 수 있을 것입니다. 마치 착시현상을 일으키는 것처럼, 오히려 잘못된 정보로 논쟁의 대상이 될 수 도 있기 때문입니다. 그렇기 때문에 모델러는 자신의 의도를 명확하게 모델링 하는 것이 좋습니다.

 

모델링은 다양한 측면으로 나뉠 수 있지만, 아래와 같이 4개로 정의하기도 합니다.

• 정적인 측면
  단지 오브젝트들의 구조적인 관계를 나타냅니다. 정적인 측면은 이름에서도 알 수 있듯이 시간적인 흐름은 전혀 포함되지 않습니다.
  
  
• 기능적인 측면
  시스템이 할 수 있는 행동적인 것을 표현하고자 합니다.
  
  
• 동적인 측면
  오브젝트가 시간의 흐름이나 이벤트에 의해 어떻게 상태가 변화해 가는지에 대해 나타냅니다.
  
  
• 물리적인 측면
  시스템이 동작하기 위해 필요한 물리적인 것들을 나타냅니다. 서버나 데이터베이스 간의 관계를 어떻게 기술 할지에 대해 나타내기도 합니다.

 

그리고 모델링을 하려는 관점이 있을 수 있습니다. 이는 보통 "관점(Perspective)" 또는 "레벨(Level)" 이라고 부르기도 합니다. 이러한 관점은 추상화 정도에 따라서 3가지로 구분을 합니다.

• 개념적 관점
  개념적인 관점은 구현 등의 영역을 전혀 고민하지 않은 채, 실질적인 큰 범위의 영역을 해석하는 관점입니다. 범위에 포함되는 여러 가지 문제를 깊이 있게 이해하는 것이 목적입니다.
  
  
• 사양적 관점
  사양적 관점은 문제를 해결하여 완성시키기 위해 필요한 기능 등을 효과적으로 이행할 수 있는 방안을 찾기 위한 관점입니다.
  
  
• 구현적 관점
  구현적 관점은 사양적 관점에서 고안된 방안을 실질적으로 구현하기 위한 관점에서 작성합니다.

 

이러한 관점은 완벽히 독립적인 것은 아닙니다. 필요에 따라 사양적 관점/구현적 관점이 동시에 진행될 수 있습니다.

위와 같은 모델링의 관점과 측면은 개개인에 따라서, 또는 모델링에 참여하는 사람에 따라서 전혀 목적이 일치하지 않을 수 있는 문제가 있습니다. 그렇기 때문에 모델링 이전에 정확하게 목적을 설정하고 개념적 관점의 모델을 작성하는 것이 올바른 시작이라고 할 수 있습니다.

 

4.2. 모델의 표기 방법

기본적으로 모델링을 하기 위해 모델을 표현하는 공통적인 표기법을 알아보겠습니다. 매우 기본적이고 공통적인 표기 방법이므로 모델링에 들어가기 앞서 가장 중요한 부분이기도 합니다. 기본적인 모델링의 표기 방법을 알아야 모델을 통해 전달하고자 하는 메시지를 최소한 이해할 수 있을 것입니다.

4.2.1. 공통적인 표기 방법

공통적인 표기 방법의 기본적인 도형은 4가지 입니다. 즉, 이 4가지만 알면 UML 다이어그램을 읽는 것이 한결 쉽겠지요.

1. 주석(Comment)

   제약 조건이나 주석이나 정보를 표시하는데 사용하는 기호입니다. 이 기호는 한쪽 귀퉁이가 접혀진 직사각형을 사용합니다. 특정한 모델의 요소와 연관이 되는 주석인 경우 점선으로 연결 됩니다.

   

    

2. 패키지

   모델 요소들을 하나로 묶어주는 것으로 폴더 아이콘과 유사하게 표시됩니다. 비슷한 요소의 집합이나 연관성이 있는 요소들을 묶어주는 역할로 주로 사용하기도 하지만, Use Case Diagram 등에서 하위 패키지나 하위 시스템 등을 표현할 때 사용하기도 합니다.

   

    

   

   
   

   3. 의존 관계

모델 요소간의 의존 관계를 표기하는 방법으로 사용이 됩니다. 모델 요소가 다른 모델의 내부를 알고 있다거나 의존의 방향을 나타내는데 사용합니다.

아래와 같은 속이 비었는지 색이 채워졌는지에 따라서 Aggregation(집합체) 인지 Composition(합성) 관계인지 알 수 있습니다. 예를 들어, Composition(합성) 관계는 Class1의 정보가 소멸될 때 Class2의 정보도 함께 소멸되는 것을 미리 짐작할 수 있습니다.



 

4.2.2. 표기 방법의 확장

UML에서는 표기 방법을 확장할 수 있는 많은 장치들이 존재합니다. 이런 표기 방법의 확장은 모델링을 좀 더 정확하게 세세하게 정의할 수 있으며, 확장 표기 방법을 통해 유효성을 검증할 수 있는 수단이 될 수 있습니다.

그 중 가장 많이 사용되는 한 가지를 소개할 예정이며, 이것을 아느냐 모르느냐는 모델링의 퀄리티에 큰 차이가 있을 수 있습니다. 그 밖에 Constrains(제약) 도 모델 요소 간의 성립 관계를 나타낼 수 있습니다.

1. Stereotype(스테레오 타입)

   모델 기호의 의미를 새롭게 재정의 하는 방법으로 Stereotype을 사용할 수 있습니다. 기존적인 Stereotype 은 <<type>>, <<interface>>, <<implementation>> 등이 있으며, 이런 Stereotype을 요구사항에 따라 새롭게 정의할 수 있습니다.