Visual Studio 2005: Whitehorse를 이용한 개발과 운영간의 연결

Brian A. Randell, Rockford Lhotka

이 문서는 Visual Studio 2005 초기 버전을 바탕으로 제작되었습니다. 여기에 포함된 모든 정보는 변경될 수 있습니다.

---

This article discusses:

Whitehorse SOA 디자이너 Visual Studio 2005 Class Designer 코드에서 다이어그램 생성 다이어그램에서 코드 생성

이 문서에서 사용되는 기술: Visual Basic 및 C#

---

모델링 도구를 사용하여 소프트웨어 시스템을 설명하려 할 때마다 막대한 시간과 비용 투자 문제에 자주 직면하게 됩니다. 대개 결과로 생성되는 다이어그램은 훌륭하게 보이지만 개발이 한창 진행되어 감에 따라 빠르게 잊혀집니다. 다이어그램과 코드 간의 동기화를 제공하는 도구가 판매되고 있지만 이러한 도구를 익히기 위해 드는 비용과 시간 때문에, 직업이 다이어그램을 제작하는 일이 아닌 경우를 제외하고는 대다수는 아니라 하더라도 많은 사용자들이 이 도구에 대해 배우는 일을 미루어 왔습니다.
  이 외에도 추가적으로 시스템 디자인과 이것이 배포되는 환경 특성 사이의 불일치 문제가 있었습니다. 언제나 그러하듯 솔루션이 다이어그램에서 훌륭하게 표현되고 코드화된 다음 배포 시점이 다가올 때쯤이면, 모델이 정확하게 매핑되지 않아서 생기는 문제를 해결하기 위한 작업으로 분주해집니다. 또한 설계자, 디자이너, 개발자 및 인프라 부서 직원의 우선 순위 경쟁으로 인해 충돌이 발생할 수 있습니다. 이러한 경우 대개 충돌에 대한 제약 조건은 시작 단계에서 조정되어야 합니다. 실제 서버 보안과 같은 제약 조건은 새로운 시스템을 성공적으로 배포 및 구현하는 데 장애가 됩니다. 뿐만 아니라 중앙 메인프레임 전용 시스템에서 클라이언트/서버 모델 및 분산 시스템으로 발전한 오늘날의 환경을 더욱 복잡하게 만드는 문제도 이러한 문제에 가세하게 되었습니다.
  오늘날 매우 널리 사용되고 있는 환경은 서비스 지향 아키텍처(SOA)이며, 이 서비스 지향 아키텍처(SOA)는 서비스를 제공하고, 메시지를 사용하여 통신하고, 종종 신뢰할 수 있는 경계선을 넘나드는 느슨하게 결합된 자치 응용 프로그램에서 구축되었습니다. 현재 ASP.NET을 사용하여 구축된 XML 기반 웹 서비스는 이러한 종류의 시스템을 구축하기 위한 플랫폼을 제공합니다. 기술이 발전함에 따라 Microsoft는 사용자가 손쉽게 이러한 시스템을 구축 및 관리할 수 있고 기본 플랫폼의 능력을 확장할 수 있는 다양한 기술을 제공하고 있습니다.
  Visual Studio 2005의 개발 일정 동안, Microsoft는 SOA를 사용하여 시스템을 쉽게 디자인하고 구현할 수 있게 해주는 "Whitehorse"라는 코드명의 새로운 그래픽 디자인 도구 제품군을 소개하고 있습니다. 여기에는 새로운 Class Designer를 비롯해 Distributed System Designers라는 긴밀하게 통합된 네 개의 도구 그룹이 포함되어 있으며, 이들 네 개의 도구 중 Application Connection Designer와 Class Designer는 주요 특성을 공유합니다. 즉, 둘 다 시스템 및 구성 요소의 그래픽 디자인을 지원하며 코드 생성 지원을 포함하고 있는 것입니다. 게다가 이러한 디자이너들은 양방향 동기화를 지원하므로, 다이어그램이 시스템 및 구성 요소를 나타내지 않는다고 해도 염려할 필요가 없습니다. “Whitehorse”는 모델링 시스템의 전형적인 문서 중심의 보기를 능가한다는 점에서 모델링 분야에서의 르네상스라고도 할 수 있습니다. 이 디자이너들은 Visual Studio 셸로 긴밀하게 통합되고, 각 다이어그램은 다른 프로그램 소스와 마찬가지로 솔루션에서 최고 수준의 구조물(artifact)입니다. 따라서 다이어그램은 팀 시나리오를 지원하는 소스 코드 제어에 종속됩니다.
  새로운 Logical Datacenter Designer 도구를 사용하면, 운영 설계자는 대상 환경의 서버 유형에 대한 설명을 제공하고 이러한 서버에 로드된 호스트 소프트웨어 패키지의 구성을 기록할 수 있습니다. 대상 환경에 대해 이러한 자세한 지식과 논리 소프트웨어 모델에 대한 상세 정보가 있으면, 소프트웨어 개발자는 “Whitehorse”를 사용하여 서비스를 서버에 바인딩할 수 있고, 실제로 디자인에서 데이터센터에 성공적으로 배포하도록 유효성 검사 프로세스를 제공할 수 있습니다. 그렇지 않으면, 자체적으로 데이터센터 구성에 변경 사항을 적용해야 한다는 것이 강조 표시됩니다. 이러한 방식으로 조직은 비용이 많이 드는 다운스트림 배포 문제를 피하고 개발 과정의 초기에 픽스를 적용할 수 있습니다.
  서비스 지향 시스템을 디자인하여 이 시스템을 즉각적으로 운영 인프라에 대한 유효성 검사를 실행할 수 있는 능력을, "운영을 위한 디자인(Design for Operations)"이라고 합니다. 응용 프로그램은 대개 하나의 환경에서 디자인되는 경우가 많지만, 그 밖의 다른 환경이나 여러 환경에 배포되도록 계획됩니다. “Whitehorse”와 함께, 대상 데이터센터 모델과 대조하여 디자인 유효성 검사를 수행하는 능력은 배포 과정을 더욱 매끄럽게 만들어 줍니다. “Whitehorse”는 새로운 Microsoft Dynamic Systems Initiative(DSI)의 핵심적인 부분인 동시에 연결된 시스템의 개발, 배포, 운영을 단순화 및 자동화하는 장기적인 업계 이니셔티브로서, 운영 팀은 “Whitehorse”를 사용하여 그들의 관점을 설계자의 관점에 맞출 수 있습니다. 제약 조건은 양쪽 부분에서 모두 강제 실행될 수 있으므로, 프로젝트 시작 단계에서부터 유효성 검사 메커니즘을 통해 의사 소통을 강제함으로써 시스템이 성공적으로 배포되도록 보장할 수 있습니다.
  이 도구를 익힐 수 있는 가장 좋은 방법은 Distributed System Designers를 사용하여 간단한 시스템을 작성해 보는 것입니다.

응용 프로그램 디자인
  ”Whitehorse” 도구에는 새로운 분산 시스템 솔루션 유형이 도입되었습니다. 새로운 솔루션을 만들 때 접하게 되는 첫 번째 디자이너는 Application Connection Designer입니다. 이 디자이너는 웹 서비스 응용 프로그램 및 클라이언트 웹 또는 Windows 기반 응용 프로그램을 정의하기 위한 디자인 화면을 제공합니다. 이러한 응용 프로그램은 디자인 화면 상에서 바로 만들어질 수 있고, 또는 Application Connection Diagram이 기존 솔루션에 추가되는 경우 다이어그램을 만들기 위해 솔루션을 분석합니다. 이 디자이너를 사용하면 응용 프로그램을 연결할 수 있고 코드 내에서 지원되어야 하는 통신 경로를 정의할 수 있습니다. 또한 구현을 위해 개발자용 기본 골격 구현을 생성하기 전에 응용 프로그램 설정 및 디자인으로 자유롭게 시험해 볼 수 있습니다. 기본적으로 Whitehorse는 코드로 커밋하기 전에 디자인의 "whiteboarding(썼다가 지울 수 있음)"을 지원하므로 시스템 디자인에 대해 조사하고 시험할 수 있습니다.
  Visual Studio 도구 상자는 Windows 기반 응용 프로그램, 웹 서비스 및 데이터베이스를 나타내는 구성 요소 집합을 제공합니다(그림 1 참조). 끌어서 놓기를 사용하여 쉽게 시스템을 배치할 수 있습니다. 예를 들어, 데이터베이스 연결이 필요하다고 지정하려면 ExternalDatabase 구성 요소를 디자인 화면으로 끌어서 놓습니다. 그런 다음 Visual Studio의 표준 속성 창에서 데이터베이스에 대한 연결 문자열을 설정합니다. 데이터 소스가 결정된 경우에는, 웹 서비스의 형식으로 데이터 액세스 층을 추가합니다. 웹 서비스를 디자인 서비스로 끌어온 다음에는, 둘 사이의 연결을 끌어와서 웹 서비스를 이전에 정의한 데이터 소스로 바인딩할 수 있습니다.


Figure 1  도구상자

  다음 단계는 웹 서비스 인터페이스를 통해 데이터를 표시하는 것입니다. 이렇게 하려면 기본으로 생성된 웹 서비스의 종점을 클릭한 다음 종점 정보 창에서 공용 진입점을 정의합니다. 응용 프로그램의 기본 골격을 생성하는 경우 웹 서비스에서 마우스 오른쪽 단추를 클릭하면 구현 명령이 제공됩니다. 이 명령을 실행하면 새 웹 서비스 프로젝트가 솔루션에 추가되고, IIS의 로컬 인스턴스가 구성되며 언어별 소스 집합과 구성 파일이 생성됩니다. 솔루션 탐색기에서 Code 폴더를 열면 두 개의 클래스 파일이 표시됩니다. 하나는 웹 서비스의 구현을 위한 것이고 다른 하나는 web.config 파일에 생성되는 데이터베이스 연결 문자열을 검색하는 데 유용한 유틸리티 클래스입니다. 이 시점에서 코드의 공용 진입점에 대해 수정 또는 조정 작업이 이루어질 경우 이러한 변경 사항은 시스템 다이어그램과 자동으로 동기화됩니다.
  초기 디자인을 테스트하는 작업은 Visual Studio의 초기 버전에서 수행된 것처럼 작동하므로 간단히 F5만 누르면 실행됩니다. 모든 것이 잘 작동된다고 가정하고 이제는 프런트 엔드를 웹 서비스에 추가해 봅시다. Application Connection Designer로 돌아와서 ASP.NET 웹 응용 프로그램을 디자이너 화면으로 끌어서 놓습니다. 이전과 마찬가지로 구성 요소를 모두 바인딩해야 합니다. 이것은 표시된 웹 서비스의 진입점을 클릭하고 웹 서비스 및 웹 응용 프로그램 사이의 연결 링크를 끌어옴으로써 완료할 수 있습니다. 그런 다음 웹 응용 프로그램에서 마우스 오른쪽 단추를 클릭하고 구현을 선택합니다. 그러면 Visual Studio가 새 웹 응용 프로그램 프로젝트를 솔루션에 추가하고 웹 서비스에 대한 웹 참조를 만듭니다. 그런 다음 새 항목 추가 명령을 사용하여 이전 버전에서와 마찬가지로 기본 웹 페이지를 추가합니다.


Figure 2  분산 솔루션의 응용 프로그램

  Web Form 디자이너를 사용하여 웹 서비스를 UI(웹 페이지의 GridView 컨트롤)에 연결하는 ObjectDataSource 구성 요소를 추가합니다. ObjectDataSource는 웹 서비스의 표시된 메서드 호출을 처리합니다. 이 경우 어떠한 코드도 작성할 필요가 없습니다. 단지 GridView 컨트롤의 속성을 약간 조정한 다음 웹 브라우저에 있는 웹 서비스에서 데이터를 표시하기 위해 F5를 누르기만 하면 됩니다. 그림 2는 Application Connection Designer에서 완료된 응용 프로그램입니다

배포 주기
  다음 단계에서는 배포 환경 내 네트워크의 논리 모델과 실제적인 서버 유형을 정의해야 하는데, 이 단계는 이미 운영 팀에서 완료했을 수 있습니다. 이러한 경우, 데이터센터의 응용 프로그램 호스팅 기능에 대한 논리 모델을 표현하는 다이어그램을 만드는 데 이용되는 Logical Datacenter Designer를 사용할 수 있습니다. 이 디자이너를 사용하면 인프라 설계자가 데이터베이스 서버, 웹 서버, 논리 보안 영역 및 통신 끝점과 같은 시스템 엔터티를 표시하여 데이터센터 토폴리지를 지정할 수 있습니다. 또한 제약 조건은 데이터센터의 요구 사항을 기반으로 한 응용 프로그램 구성에 대해 적용될 수 있습니다.


Figure 3  유형

  기존 솔루션에서 새로운 Logical Datacenter Diagram을 추가해 보겠습니다. 이전과 마찬가지로 도구 상자에 표시된 이 디자이너의 특정 요소를 사용합니다. 그림 3은 현재의 논리 서버 목록 및 지원되는 끝점 유형을 보여줍니다. 이제 다이어그램에, 첫 번째 영역은 DMZ(demilitarized zone)을 나타내고 두 번째 영역은 네트워트의 보안 내부 영역을 나타내는 두 개의 영역을 추가하겠습니다. 그런 다음 DMZ에 견고한 IIS 웹 서버를 정의하고, 내부 영역에는 "AppServer"라는 IIS 웹 서버와 SQL Server를 실행하는 컴퓨터를 추가합니다. IIS 웹 서버의 경우 미리 정의된 입력 및 출력 끝점이 있습니다. 연결 도구를 사용하면 AppServer와 SQL Server 컴퓨터 사이의 연결을 포함한 다양한 입력 및 출력 채널을 연결할 수 있습니다. 그림 4는 완료된 논리 데이터센터 다이어그램입니다.


Figure 4  완료된 논리 시스템 아키텍처

  다이어그램을 정의하고 나면 논리 서버에 제약 조건을 추가할 수 있습니다. 예를 들어 AppServer가 가장 및 SSL을 사용하도록 해야 할 수도 있는데, 그림 5에서 볼 수 있는 것처럼 AppServer를 선택한 후 Settings and Constraints 편집기를 열면 됩니다.


Figure 5  Settings and Constraints 편집기

  Whitehorse에서 지원되는 몇 가지 제약 조건 유형들로는 Constraint 대화 상자, 사용자 정의 제약 조건 및 암시적(또는 기본 제공) 제약 조건 등이 있습니다. Constraint 대화 상자(그림 5 참조)는 예를 들어, ASP.NET 구성원 또는 웹 사이트 구성과 같은 특정 유형의 설정을 논리적으로 그룹화합니다. 이들 대화 상자에는 제약 조건을 정의하기 위해 특정 설정 조합을 사용할 수 있도록 기본 제공되는 편집 규칙이 내재되어 있습니다. 사용자 정의 제약 조건을 이용하면 사용자가 논리 서버 또는 응용 프로그램에서 사용 가능한 모든 설정에 대해 원하는 값과 범위를 완전히 제어할 수 있습니다. 암시적 제약 조건은 모델에서 제공되며 사용자가 명시적 작업(유효성 검사 이외의 작업)을 수행하지 않아도 적용됩니다. 예를 들어, .soap 및 .asmx 스크립트 맵이 IIS에서 제거되면 웹 서버는 웹 서비스를 지원할 수 없게 됩니다. 실제 배포 환경의 정확한 웹 서버 모델이 제약 조건 평가에 사용되도록 기존 서버에서 설정을 가져올 수도 있다는 점에 유념하십시오.
  프로세스의 마지막 단계는 이전에 정의한 응용 프로그램을 새로 정의한 논리 시스템 아키텍처로 매핑하는 작업입니다. 개발 환경에서 사용된 구성이 배포에 필요한 구성이라고 전제하고 시험 배포(Trial Deployment)가 되는 대상을 정의할 수도 있고, 혹은 계획한 배포에 맞는 특정한 설정을 구성할 수 있는 새로운 시스템을 명시적으로 만들 수도 있습니다. 대부분의 경우 먼저 시험 배포(Trial Deployment)를 통하여 가장 심각한 문제들을 제거한 다음 구성을 고정시키는 최종 단계로 시스템을 만듭니다. 그러면 시스템이 좀더 복잡한 정의로 구성될 수 있어 대규모의 아키텍처 디자인에서 다시 사용될 수 있습니다.
  이제 시험 배포(Trial Deployment)를 만들어 보겠습니다. Application Connection Diagram에서 시험 배포 정의(Define Trial Deployment)를 선택한 다음, 팝업 대화 상자에서 이전에 만든 Logical Datacenter 디자인을 선택합니다. Deployment Designer는 논리 데이터센터를 배경으로 나타내는 새로운 배포 다이어그램을 통해 열립니다. 그러면 Deployment Designer를 사용해 각 응용 프로그램을 논리 서버로 바인딩하여 배포할 서버의 유형을 나타낼 수 있습니다. 이렇게 하려면 간단한 개요 컨트롤 또는 Application Connection Diagram에서 직접 응용 프로그램을 끌어서 놓으면 됩니다. 만약 바인딩하려는 응용 프로그램과 서버가 호환되지 않는다면 no-drop 기호가 표시될 것입니다. 프로세스가 각 응용 프로그램에서 반복되면서 시스템의 가상 배포를 만듭니다. 일단 모든 구성 요소를 해당 호스트로 매핑하면 그림 6에 나타난 대로 매핑의 유효성을 검사할 수 있습니다.


Figure 6 하위 시스템 매퍼

  유효성 검사는 모든 바인딩을 검사하여 양쪽 다이어그램에 정의된 제약 조건을 확인하고, 응용 프로그램에 필요한 경로와 프로토콜을 지원하는 논리 데이터센터에 통신 경로가 있는지를 확인합니다. 오류가 발생할 경우 작업 항목이 Visual Studio 작업 목록에 추가됩니다. 오류 목록에서 해당 항목을 두 번 클릭하면 잘못된 다이어그램과 구성 요소로 이동하게 됩니다. 예를 들어, AppServer가 ASP.NET 가장을 사용하도록 하기 위해 Logical Datacenter Designer에 제약 조건을 설정합니다. 이 때 유효성 검사를 실행하면 오류가 발생하는데, 작업을 두 번 클릭하면 선택한 끝점이 잘못되어 있는 Application Connection Designer로 가게 됩니다. Settings 편집기에서 정확한 속성을 조정한 후, 값이 자동으로 web.config 파일에 기록되고 유효성을 다시 검사하면 모든 작업이 완료됩니다. 이러한 과정을 통해 실제로 운영하기 전 극도의 압박감에 시달리는 기간 동안이 아니라, 배포하기 전에(가능하면 핵심 개발이 시작되기 전에) 배포 관련 문제점을 발견할 수 있는 이점을 얻을 수 있습니다.
  이 시점에서, 다음 단계는 시스템의 외부와 내부를 세밀하게 계획하기 위해 Class Designer를 사용하여 작업할 수 있는 개발자에게 디자인 작업을 넘겨줄 차례입니다.

The Class Designer
  대부분의 개체 지향 개발자들은 자신의 응용 프로그램 디자인의 다이어그램을 만들고자 하며 이러한 다이어그램에는 UML(Unified Modeling Language) 문서 양식이 종종 사용됩니다. UML은 응용 프로그램을 모델링하는 데 사용할 수 있는 여러 유형의 다이어그램을 정의합니다. 일반적으로 가장 많이 사용되는 다이어그램 유형은 응용 프로그램의 각 클래스와 함께 기타 다른 클래스에 대한 관계를 표시하는 클래스 다이어그램입니다. 일반적으로 각 클래스는 필드 및 메서드가 나열된 상자에 표시됩니다.
  하지만 불행히도 UML은 .NET Framework와 같은 현재의 기술에 뒤쳐지고 있습니다. 예를 들어, UML에는 Visual Basic .NET 및 C#의 내부 범위와 Friend에 대한 규정이 없습니다. 또한 .NET 클래스에 대한 인터페이스의 핵심적인 부분인 속성 메서드 또는 이벤트를 나열하기 위한 적절한 방법도 없습니다.
  코드 및 다이어그램을 동기화 상태로 유지한다는 것은 어려운 일입니다. 몇몇 UML 다이어그램 작성 도구를 사용하면 다이어그램에서 코드를 생성할 수 있고 코드에서 다이어그램을 생성할 수는 있지만 여기에는 제한 사항이 있습니다. 이로 인해 대부분의 개발자들은 코드 생성의 사용을 피해야 하는데, 이것은 곧 개발자들이 시간 경과에 따라 다이어그램과 코드를 수동으로 동기화 상태로 유지시켜야 한다는 것을 뜻합니다.
  이러한 문제를 해결하기 위해 Microsoft는 Visual Studio 2005의 일부분으로 출시될 예정인 Class Designer 도구를 개발 중에 있습니다. Class Designer는 .NET을 사용하는 프로그래머들이 사용할 수 있는 모든 디자인 개념을 지원하는 기능이 추가되어 있어, UML 클래스 다이어그램과 유사한 다이어그램을 만들 수 있습니다. 이 외에도 Class Designer는 Visual Studio 2005에 완전히 통합되어 있으므로 여기서 만든 다이어그램은 코드와 함께 프로젝트의 일부분이 될 수 있습니다.
  Visual Studio 2005와의 통합은 편리성을 제공할 뿐만 아니라, Class Designer가 실시간으로 코드를 생성하고 코드에서 다이어그램을 생성할 수 있다는 것을 뜻하기도 합니다. 간단히 말해서, 코드가 변경되면 다이어그램이 즉시 업데이트되고, 다이어그램이 변경되면 코드가 즉시 업데이트됩니다. 그림 7에는 다이어그램을 위해 생성된 일치하는 코드와 함께, Visual Studio 2005의 Class Diagram 도구가 나와 있습니다. 다이어그램이나 코드 중 어떤 것을 변경해도 괜찮습니다. 양쪽 모두가 자동으로 동기화 상태로 유지됩니다.
  Figure 7 에는 다이어그램을 위해 생성된 일치하는 코드와 함께, Visual Studio 2005의 Class Diagram 도구가 나와 있습니다. 다이어그램이나 코드 중 어떤 것을 변경해도 괜찮습니다. 양쪽 모두가 자동으로 동기화 상태로 유지됩니다.
  Class Designer를 사용하려면 Visual Studio 2005에서 Class Diagram을 프로젝트에 추가해야 합니다. 이렇게 하려면 새 항목을 프로젝트에 추가하고 Class Diagram 템플릿을 선택하면 됩니다.
  프로젝트에 클래스를 이미 포함시킨 경우, 클래스를 Class View 창에서 해당 다이어그램의 디자이너 화면으로 끌어오면 클래스가 다이어그램에 추가됩니다. 이렇게 하면 Class Designer가 클래스를 다이어그램에 추가하고 클래스의 모든 메서드, 필드, 속성 및 이벤트를 나열합니다. 이러한 클래스에 대한 예는 그림 8에 나와 있습니다. 다이어그램 자체에 표시된 클래스의 세부 사항 뿐만 아니라, 클래스를 다이어그램에서 선택하면 세부 사항이 화면 하단의 Class Details 창에 나타난다는 점에 유의하십시오.


Figure 8  클래스를 Class View에서 Class Diagram으로 끌기

  Class Details 창에서 클래스의 인터페이스를 보고 변경할 수 있습니다. 이러한 작업에는 메서드, 필드, 속성 및 이벤트의 추가 및 제거가 포함됩니다. 또한 이러한 요소들의 범위, 매개변수 및 반환 형식을 변경할 수도 있습니다. Class Details 창에서 이루어진 모든 변경 사항은 코드에 즉시 적용됩니다.
  Class Details 창의 Summary 열을 눈여겨 보십시오. 이 열에는 코드에서 XML 문서의 인터페이스 요소에 대한 요약 정보가 표시됩니다. 또한 이 열을 편집하여 코드에서 XML 문서를 변경할 수 있습니다. 이 뿐만 아니라 이 열을 선택하면 더 많은 XML 문서를 편집할 수 있는 대화 상자를 불러오기 위해 단추를 사용할 수 있습니다.
  Visual Basic .NET 결과 주석은 다음 코드 조각에서 볼 수 있는 것처럼 코드에 자동으로 추가됩니다.

''' <summary>
''' Returns the ID value of the product.
''' </summary>
Public ReadOnly Property ID() As Guid
  Get
    Return mID
  End Get
End Property

   C#, C++ 또는 J# 코드에 대해서는 모두 true로 동일합니다(C++에 대해서는 몇 가지 제한이 있음). 다이어그램의 변경 사항은 프로젝트의 코드에 즉시 반영되고, 이와 마찬가지로 코드의 변경 사항도 다이어그램에 반영됩니다. 예를 들어 그림 9에서 C# 코드로 시작한다고 가정해 봅시다. 이 클래스를 Class View에서 Class Diagram으로 끌면 그림 10과 같이 나타납니다.


Figure 10  MTS

  사용자는 자신의 클래스를 끌어서 놓을 수 있을 뿐만 아니라, 자신의 어셈블리에 의해 참조된 다른 어셈블리로부터 클래스를 끌어서 놓을 수도 있습니다. 이렇게 하면, 외부 클래스가 직접적으로 현재 어셈블리의 일부분이 되지는 않으므로 외부 클래스가 읽기 전용 모드로 다이어그램에 표시됩니다. 그러면 사용자는 자신의 클래스 및 참조된 어셈블리의 클래스 사이의 관계를 나타내는 보다 포괄적인 다이어그램을 제공할 수 있습니다.
  또한 어셈블리의 모든 항목을 다이어그램에 표시하려는 경우, 전체 프로젝트를 솔루션 탐색기에서 다이어그램으로 끌어서 놓을 수도 있을 것입니다. 처음에는 다이어그램에 새로 추가된 요소를 위해 제공된 자동 서식이 없지만, 아마 나중에는 그러한 기능이 도구가 출시되기 전에 추가될 것으로 기대합니다.
  코드가 변경될 때 다이어그램이 업데이트되는 방법을 나타내려면 다음 속성을 클래스에 추가하면 됩니다.

int _id;

public int ID
{
  get { return _id; }
  set { _id = value; }
}

다이어그램은 새로 추가된 ID 속성 및 필드를 표시하기 위해 즉시 업데이트됩니다.
  또한 코드가 아닌 다이어그램을 사용하여 시작하는 것도 가능합니다. Class Diagram Designer가 열리면, 요소들을 도구 상자에서 다이어그램으로 끌어서 놓을 수 있습니다. Class Diagram Designer는 자동으로 관련 코드 파일을 생성하고 항목을 다이어그램에 추가합니다. 도구 상자를 사용하여 클래스(추상적 및 구체적 클래스 모두), 열거, 인터페이스, 구조, 대리자 정의 및 Visual Basic .NET 모듈을 비롯한 가장 일반적인 코딩 구조를 추가할 수 있습니다.
  또한 도구 상자를 사용하여 다이어그램에 있는 요소 간의 상속 및 연결 관계를 추가할 수 있습니다. 이러한 관계는 코드에 즉시 반영됩니다. 예를 들어, Association 도구를 클릭한 다음 Product 클래스에서 InventoryQOH 클래스로 마우스로 끌어 놓으면 Product 클래스 파일에 다음 코드가 생성됩니다.

Public Property InventoryQOH() As Inventory.InventoryQOH
  Get

  End Get
  Set(ByVal Value As Inventory.InventoryQOH)

  End Set
End Property

   이러한 새로운 InventoryQOH 속성은 Product 클래스에서 속성으로 나타나지 않는데, 그 이유는 InventoryQOH 속성이 다이어그램에서 Product 클래스와 InventoryQOH 클래스 사이의 연관 표시선(association line)으로 그래픽으로 표시되기 때문입니다. 마찬가지로, 두 클래스 간의 상속 관계를 추가할 경우 적절한 상속 관계가 코드에 추가됩니다.
  또한 도구 상자에서 임의의 주석을 다이어그램 자체에 추가할 수도 있습니다. 이러한 주석은 다이어그램의 일부만 될 수 있으며 프로젝트의 코드에 대한 영향은 받지 않습니다. 이것은 다이어그램의 각 코드 요소와 연관된 XML 문서와 다른 것으로, 다이어그램과 코드의 일부분이 됩니다.
  프로젝트의 Class Diagram 파일에는 .cd 파일 확장명이 포함되어 있습니다. 이것은 다이어그램의 각 요소에 대한 세부 사항이 포함된 간단한 XML 파일입니다. 다이어그램에 있는 대부분의 데이터가 코드에서 직접 나오기 때문에, XML 파일 자체에 저장된 정보는 많지 않습니다. 예를 들어, 앞에서 표시된 Product 클래스에는 Figure 11에 표시된 XML이 포함되어 있습니다.
  이 요소의 핵심은 클래스 이름과 실제 클래스 파일에 대한 포인터가 포함된 요소입니다. 요소를 통해 디자이너는 클래스 파일을 읽어 클래스 자체에 대한 대부분의 세부 사항을 끌어낼 수 있습니다. 요소는 다이어그램에서 항목의 위치를 나타냅니다.
  또한 요소도 있습니다. 이 요소는 그림 7에서처럼 다이어그램에 Product 및 InventoryQOH 사이의 연결이 있기 때문에 존재하게 됩니다. 이러한 관계가 다이어그램에 반영되므로, XML에는 연결을 생성하는 Product 클래스 내의 특정 속성에 대한 참조가 포함됩니다.
  Class Diagram으로 돌아오면, 연관 표시선(association line)을 마우스 오른쪽 단추로 클릭하고 Show as Property 옵션을 선택합니다. 이 옵션을 선택하면 Product 및 InventoryQOH 클래스 간의 연관 표시선(association line)이 다이어그램으로부터 제거되고, InventoryQOH 속성은 Product 클래스 자체 내에서 속성으로 표시됩니다. 프로세스를 되돌리려면, Product 클래스의 InventoryQOH 속성에서 마우스 오른쪽 단추를 클릭하고 "Show as Association" 메뉴 옵션을 선택합니다.
  "Show as Association" 옵션의 선택을 취소하여 다이어그램을 변경하였으나, 코드는 변경하지 않았습니다. 다시 말해, Product 및 InventoryQOH 간의 연결은 변경되지 않고 표시에만 영향을 미칩니다. 이것은 요소가 XML의 Product 엔트리로부터 제거되었기 때문에 다이어그램에 대한 XML에 반영됩니다.

결론
  Class Designer는 Visual Studio 2005를 사용하는 개체 지향 디자이너와 개발자를 위한 아주 좋은 도구입니다. Class Designer는 Microsoft .NET 환경에서 Visual Basic .NET 및 C#의 모든 언어 기능을 반영할 수 있는 UML과 유사한 클래스 다이어그램을 제공합니다. 이 Class Designer를 사용하면 정확한 다이어그램을 만들 수 있을 뿐만 아니라 실시간으로 다이어그램과 코드의 동기화를 유지할 수 있습니다. 이제 코드를 완벽하게 반영하는 클래스 다이어그램을 기대하셔도 좋습니다. 다이어그램에서 코드로 그리고 코드에서 다이어그램으로 이동할 수 있는 능력이 여러분의 멋진 그림을 단순히 어떤 존재를 유지할 수 있는 기억 이상을 넘어서, 사실상 작동 시스템의 정확한 지도가 될 수 있도록 보장해줄 것이기 때문입니다.