|
|
 |
|
| 시스템 상세 설계를 위한 시스템 디자이너와 클래스 디자이너 |
| |
| [ 이병철(테크라이터) 2005/10/04] |
| |
IT 시스템의 설계는 철저히 지적인 노동으로 구성된다. 아키텍트는 시스템에 요구 되는 기능을 충족시키면서 성공적인 제품을 만들기 위해 끊임 없이 고민해야 하고, 그러한 노력이 성공적으로 조화를 이룰 때 훌륭한 설계가 나오게 된다.
그렇기 때문에 시스템의 설계는 철저히 지식 집약적이고 아키텍트의 역량에 크게 좌우된다. 즉 좋은 툴이 곧 훌륭한 설계를 보장하지는 않는다. 하지만 잘 만들어진 툴은 복잡한 시스템 설계 과정에서 아키텍트가 처리해야 할 많은 부분을 도와 줄 수 있으며, 결과적으로 생산성을 향상 시키는데 중요한 역할을 할 수 있다.
비주얼 스튜디오 2005는 애플리케이션 설계 과정을 지원하기 위하여 다양한 툴을 제공하고 있다. 그 중 시스템 디자이너와 클래스 디자이너의 기능과 효용성에 대해 알아 보도록 하자.
개별 시스템의 설계를 위한 시스템 디자이너
지난 호에서 우리는 애플리케이션 디자이너를 살펴 보았다. 애플리케이션 디자이너를 이용하여 분산 시스템의 큰 그림을 쉽게 그릴 수 있었고 실제 구현되는 코드와 자동으로 싱크가 이루어지는 것을 확인했다.
 | | 시스템 디자이너의 작업 환경 |
시스템 디자이너는 전체 애플리케이션을 구성하는 개별 시스템에 대해 좀 더 상세한 다이어그램을 그릴 수 있도록 돕는다. 즉 애플리케이션 디자이너로 작성한 애플리케이션 다이어그램의 서브셋을 작성 하는 것이다.
기본적인 사용 및 작성 방법은 애플리케이션 디자이너와 동일하다. 단 애플리케이션 다이어그램이 솔루션에 하나만 존재 가능했던 것과는 달리 시스템 다이어그램은 필요에 따라 여러 개가 생성 될 수 있으며, 작성된 시스템 다이어그램은 다른 시스템 다이어그램에 포함되어 재사용 될 수 있다. 이러한 작업은 시스템 뷰의 항목을 시스템 다이어그램에 끌어다 놓는 방식으로 진행 된다.
 | | 시스템 뷰 |
대기업과 같은 큰 조직에서는 기존에 이미 존재하는 시스템이 수십여 개에 이를 수 있다. 이러한 각 시스템을 연동하여 분산 시스템을 설계 할 때 한 장의 그림으로는 파악이 어려울 뿐 아니라 각 시스템간 연동시의 설정 값을 정확하게 설정 하기도 쉽지 않다. 이러한 환경에서 각 시스템을 별도의 다이어그램으로 분리하여 관리하면 각 시스템을 파악하기가 쉬워질 뿐만 아니라 설정 값 역시 실제 상황에 맞게 설정하기 쉬워진다.
굳이 이렇게까지 해야 할 필요가 있는 것인가 하는 생각을 할 수도 있지만 수많은 시스템을 한 사람이 관리 하는 것이 아니라는 것을 감안한다면 이해가 될 것이다. 즉 아키텍트는 전체 어플리케이션의 큰 그림을 그릴 수 있지만, 각 시스템은 수 많은 다른 관리자들에 의해 관리되고 있을 수 있다. 이러한 경우 해당 시스템의 시스템 다이어그램을 가지고 해당 관리자와 이야기 한다면 상호간의 이해가 쉬울 뿐만아니라 더욱 구체적인 값을 설정 할 수 있다.
이러한 작업을 위해 아키텍트는 애플리케이션 디자이너를 이용하여 설계 할 때, 설정 값이 변경 될 수 있도록 Overridable 로 설정 할 수 있고, 시스템 디자이너에서 실제 배포 환경에 맞게 그 값을 변경 할 수 있다.
이러한 과정을 거쳐 각 시스템의 구체적인 설정을 결정하면 이 값들은 배포 다이어그램과 연동되어 설정을 검증하는데 사용된다. 또한 시스템의 구성 요소간 연결에 사용되는 엔드 포인트는 하나의 클래스로 매핑되어 클래스 다이어그램에 추가 할 수 있다.
정리하자면 이전 연재에서 알아 보았던 애플리케이션 디자이너로 전체 시스템을 포괄하는 큰 그림을 그린 후, 시스템 디자이너에서는 개별 시스템 간의 관계에 집중한 작은 그림들을 그리는 것이다. 이러한 작업의 결과는 다음 회에 설명 할 데이터 센터 다이어그램/배포 다이어그램과 연계된다.
 | | 항목의 값을 Overridable로 설정 (애플리케이션 디자이너) |
 | | 항목의 값을 필요에 따라 변경 (시스템 디자이너) |
시스템 구현의 시작, 클래스 디자이너
이제 좀 더 구체적인 설계를 위한 툴을 알아 보자. 비주얼 스튜디오 2005는 클래스 디자이너를 제공하여 클래스 설계를 돕고 있다.
클래스의 설계는 개발자의 작업과 직접적으로 관계되는 부분이기 때문에, 클래스 디자이너는 개발자들의 관심을 가장 많이 받게 될 도구일 것이다. 이제 클래스 디자이너의 기능들을 살펴 보도록 하자.
기본적인 인터페이스는 지금까지 살펴 본 다른 디자이너들과 같다. 클래스, 열거형, 인터페이스, 추상 클래스, 위임자, 구조체 등의 쉐이프를 제공하며, 간단한 끌어다 놓기와 연결로 작업이 진행된다. 이 과정 역시 매우 쉽고 직관적이다.
 | | 클래스 디자이너의 작업 환경 |
필드, 메소드, 프로퍼티 등 클래스의 다양한 항목들을 종류, 접근권한, 알파벳 순과 같이 원하는 대로 정렬하여 볼 수 있으며 다이어그램에 표현 된 쉐이프 들의 자동 정렬 역시 지원한다.
클래스 디자이너는 코드와 매우 직접적으로 연결되어 있다. 이 말은 사용할 언어의 특성이 그대로 다이어그램에 반영된다는 것을 의미한다. 즉 C#을 사용할 경우와 VB를 사용할 경우 각 해당 언어에 특성에 맞춰 다이어그램이 표현되며 특정 언어에만 존재하는 특성도 정확하게 반영된다. VB의 경우 모듈 쉐이프가 추가 되고, 각 필드의 데이터 형 역시 VB 문법에 맞추어 "Comment As String" 과 같은 형태로 표현 된다. C#의 경우라면 "Comment : string" 으로 표현 되게 되며 Refactor 메뉴가 나타난다. 비주얼 스튜디오의 DSL(Domain Specific Language)이 추구하는 "코드와 밀접하게 연계 된 설계"를 볼 수 있는 한 가지 예라고 할 수 있겠다.
또한 코드의 자동 싱크 역시 제공되는데 이는 개발자의 생산성 향상에 큰 도움을 준다. 많은 수의 개발자가 동시에 참여하는 대형 프로젝트의 경우, 다른 사람이 작성한 클래스 라이브러리를 이용해야 할 경우가 많다. 이런 프로젝트에서는 오래 된 다이어그램이 라이브러리의 변경을 반영하지 못하고 개발자들 간의 커뮤니케이션이 잘 이루어지지 않는 경우가 많다. 또한 그로 인해 라이브러리를 이용하는 개발자가 애를 먹는 경우가 심심치 않게 일어난다. 하지만 비주얼 스튜디오 2005에서는 더 이상 그런 걱정을 할 필요는 없을 것이다.
또 한가지 훌륭한 점은 코드가 제공되지 않은 경우라도 다이어그램으로 정확하게 그려 준다는 점이다. 예를 들어 .Net Framework 2.0의 클래스 다이어그램을 보고 싶다면 클래스 뷰에서 네임스페이스를 선택 한 후 "View Class Diagram" 메뉴를 선택하면 된다.
 | | System.XML 네임스페이스를 클래스 다이어그램으로 표현 |
그러면 클래스 디자이너는 선택 된 네임스페이스의 모든 클래스와 타입들을 한 눈에 알아 볼 수 있는 다이어그램으로 표시해 준다. 이러한 기능은 타인이 작성한 클래스나 자신이 오래 전에 작성하여 기억이 나지 않는 내용들을 파악하는데 많은 도움을 준다. 만약 자신이 대충 대충 클래스를 만들어 사용해 왔다면 비주얼 스튜디오 2005에서는 그런 행위를 자제해야 할 것이다. 그 허술함이 한 눈에 드러날 테니 말이다.
또한 클래스 디자이너는 다이어그램 상에서 필드, 메소드, 이벤트 등에 대한 복사와 붙여넣기를 지원한다. 즉 프로퍼티나 메소드를 선택 한 후 복사 또는 잘라내기를 한 후, 다른 클래스에 이를 붙여 넣는 것이 가능하다. 이 기능을 이용하면 클래스의 리팩토링을 진행하는데 많은 도움이 된다.
예를 들어 비슷한 클래스가 여러 개 있어 베이스 클래스를 상속하는 구조로 변경하려 한다면, 새로운 베이스 클래스를 만든 후 기존 클래스에서 기본이 되는 필드를 잘라내서 옮기면 된다. 그리고 베이스 클래스와 기존 클래스들간의 관계를 상속으로 정해주면 끝이다. 물론 이 과정에서 생긴 모든 변경은 실제 소스 코드에도 자동적으로 반영된다. 멋지지 않은가?
그리고 사소한 기능이기는 하지만 문서를 작성하는 입장에서 꽤 도움이 되는 기능이 있다. 이렇게 만들어진 다이어그램은 문서에 복사되어 첨부 될 수 있는데, "Copy Image" 팝업 메뉴를 이용하여 복사 한 후 마이크로소프트 오피스 프로그램들에 붙여 넣으면 벡터 이미지로 복사 된다. 즉 확대/축소를 해도 전혀 복사된 다이어그램이 깨지거나 하는 일이 없다. 단 그림판과 같이 비트맵만을 받아 들일 수 있는 프로그램에는 여전히 비트맵으로 복사 되게 된다.
클래스 디자이너를 통해 클래스 다이어그램은 개발 과정 전반에 걸쳐 생명력을 가지게 되었다. 실제 코딩 과정에서 발생하는 수 많은 변경들은 자동으로 업데이트 되며, 이제 개발자들은 다이어그램을 100% 신뢰하며 작업을 진행 할 수 있다.
하지만 역시 아쉬운 부분이 있다. 클래스 설계를 진행 할 때 가장 많이 참조하게 되는 것이 아마 디자인 패턴일 것이다. GoF (Gangs of Four)가 디자인 패턴을 모아 출판 한 후, 패턴에 관한 많은 연구가 진행되었고 마이크로소프트 역시 많은 연구를 하고 있다. 패턴이 큰 의미를 가지는 이유는 실무를 진행하는 과정에서 도출된 베스트 프랙티스라는 점이며, 그렇기 때문에 학술적으로만 연구 된 다른 방법론과는 달리 실무에서도 큰 거부감 없이 받아 들여 지고 있다.
그런데 클래스 디자이너는 아직 디자인 패턴에 대한 지원이 없다. 클래스 디자이너의 프로젝트 매니저인 존 스탈로의 인터뷰(http://channel9.msdn.com/Showpost.aspx?postid=55145)를 보면 이러한 부분에 대한 고민이 진행 중이라는 것을 알 수 있지만 이번 버전에서는 지원되지 않는다.
반면에 ALM(Application Lifecycle Management) 시장의 경쟁자인 볼랜드는 그들의 디자인 제품인 Together에서 UML 2.0에 대한 지원과 디자인 패턴 지원 기능을 이미 제공하고 있으며, 필요하다면 패턴을 추가하는 기능 역시 지원한다.
FxCop, VBCommenter등의 다양한 기능을 적극적으로 통합해 온 비주얼 스튜디오 2005이기에 이러한 디자인 패턴 지원의 부재는 상당히 아쉬운 점이다. 하지만 첫술에 배부를 수는 없는 법이니 시간을 두고 지켜 볼 일이다.
지금까지 애플리케이션 아키텍트를 위한 도구들을 알아 보았다. 사실 클래스 디자이너의 경우 아키텍트 뿐만 아니라 개발자에게도 매우 중요한 기능이지만, 설계라는 관점에서 같이 다루었다. 다음 회에는 인프라스트럭처 아키텍트를 위한 기능인 데이터센터 다이어그램과 배포 다이어그램을 다룰 예정이다. 특히 이 기능은 소프트웨어 개발이 아닌 시스템 관리쪽에 더 관계 된 부분으로, 비주얼 스튜디오에 포함되었다는 것이 상당히 이채롭게 느껴지는 기능들이다. 흥미를 가지고 지켜 봐 주시길 바란다.
필자 이병철님은 IT 분야의 개발자로 개발 툴에 대한 남다른 관심이 높다. 실제 프로젝트에 임해서도 툴에 대한 분석력이 높다는 평가를 받고 있다. |
 |
|
|
 |
 |
|
|
|
