Bill Gibson, 프로그램 관리자
Microsoft Corporation

적용 대상 :
  Microsoft Visual Studio 2005 Team System

시스템 디자이너는 배포용으로 응용 프로그램이나 그 외의 시스템의 구성을 디자인하는 경우에 사용됩니다. 시스템을 구성할 수 있다는 의미는 중첩된 복잡한 구성의 시스템을 정의할 수 있다는 것입니다. 여기에서는 시스템 포트폴리오 디자인에 대해 설명하고, 발생 가능한 문제를 보여줍니다.

시스템

Visual Studio Team Edition for Software Architects 는 시스템 정의 모델 (SDM)을 기반으로 합니다. SDM 에는 컴퓨터 시스템구조를 보여주기 위한 형식 시스템이 있습니다. 응용 프로그램 시스템을 디자인하고, 이것을 문서로 표현하기 위해, 응용 프로그램 디자이너와 시스템 디자이너를 조합하여 사용합니다. 응용 프로그램 디자이너는 응용 프로그램 (어셈블리, 구성 파일 및 그 외의 리소스 파일 등의 리소스로 구성되는 원자 시스템)의 정의에 사용합니다. 시스템 디자이너는 (응용 프로그램) 시스템 (응용 프로그램이나 그 외의 시스템 구성) 정의에 사용합니다. 응용 프로그램 정의와 시스템 정의는 버전 스탬프가 뒤따른 개별 SDM 문서에 보존됩니다.

자세한 내용은 「시스템 정의 모델」, 「응용 프로그램과 응용 프로그램 다이어그램」 및 「시스템과 시스템 디자이너」를 참조해 주세요.

시스템을 사용하는 이유

시스템 디자이너의 주요 시나리오는 배포 유효성 검사를 목적으로 간단한 시스템을 조립하는 것 입니다. 이 시나리오에서는 데이터 센터나 데이터 센터의 일부 기능을 호스트하는 응용 프로그램을 기술하는 논리 데이터 센터의 정의가 필요합니다. 배포 유효성 검사는 항상, 특정 시스템의 문맥에서 실행됩니다. 가장 단순한 문맥에서는 응용 프로그램 디자이너에 의해서 자동적으로 작성된 기본값의 시스템을 사용할 수 있습니다. 일부 단순한 사례에서는 이 기본값 시스템에서 충분하지만, 기본값의 시스템은 대규모 배포 기반으로서 사용되도록 고안된 것이 아니며,  배포된 응용 프로그램 구성이 반영하는 개발환경에서 사용되는 사례만을 다룹니다. 기본값의 시스템 사용 방법과 제한 사항의 자세한 내용은 「기본 시스템 이해와 사용」을 참조해 주세요.

기본값 시스템 영역을 넘으려면, 시스템을 명시적으로 디자인해야 합니다. 시스템을 명시적으로 디자인한다 해도 시스템을 엄밀한 형식에서 사용해야 하는 것은 아닙니다. 시스템 다이어그램은 단지 그래픽 문서로서 작성하는 것만으로도 도움이 됩니다. 시스템 다이어그램은 인쇄하거나 문서나 프레젠테이션에 붙일 수 있습니다. 시스템 다이어그램의 이미지를 복사하려면, 가장 외부의 시스템을 선택하고, [Copy]를 사용하여  비트맵 이미지를 복사하거나 [Copy Image] 를 사용하여  고품질확장 가능 벡터 그래픽 이미지로서 복사합니다.

시스템 정의는 응용 프로그램 구성이나 시스템의 구성을 기술 및 관리하기 위해서 아키텍처의 디자인 프로세스 전체에 꼭 필요부분으로서 사용하는 것에 실질적인 가치가 있습니다. 시스템 디자이너는 응용 프로그램 시스템의 복잡한 포트폴리오에 대해 생각하고 이것을 디자인하기 위한 도구를 소프트웨어 아키텍트에 제공합니다. 시스템은 복잡하거나 다양한 수준으로 "중첩된" 시스템을 보관 유지할 수 있습니다. 또, 단지 재사용을 가능 목적으로 한 시스템이나 재사용을 가능하게 하도록 분해되는 시스템도 있습니다. 각 시스템은 기존의 멤버에서 구성하여  상향식(bottom-up)방식에서 정의할 수 있습니다. 또, 먼저 상위 수준의 시스템을 정의한 후 시스템의 구현 방법을 정의하여  하향식(top-down) 방식에서 정의할 수도 있습니다. 또한 두 가지 방식을 혼재시킬 수도 있습니다. 시스템을 하향식(top-down) 방식에서 디자인하는 방법은 「하향식(top-down) 방식의 시스템 디자인」을 참조해 주세요.

시스템 구성

시스템은 다른 시스템의 멤버로서 포함될 수 있습니다. 상위 수준의 시스템 문맥에서 접속되려면, 시스템은 끝점을 공개해야 합니다. 시스템 끝점(endpoint)은 시스템  멤버 위의 끝점에 대한 프록시로  그 끝점의 모든 통신이 위임됩니다.

프록시 공급자 끝점(endpoint)은 다른 시스템이나 응용 프로그램에 서비스를 공개합니다. 끝점(endpoint)을 선택하여 공개하는 것으로  시스템이 있는 측면을 캡슐화해 외부에서 안보이게 하거나 특정 엔트리 포인트만을 공개할 수 있습니다. 모델링에는 모두 문맥에서 공급자 끝점(endpoint)가 접속되어 있어야 한다는 요건은 없습니다. 모든 서비스는 필요에 따라서 사용 가능하도록 설정됩니다.

일반적으로  응용 프로그램의 소비자 끝점(endpoint)은 배포 시에 접속해야 합니다. 소비자 끝점이 접속되어 있지 않은 상태로 응용 프로그램을 배포 할 수 있는데, 이것은 소비자 끝점 ConnectionRequired 설정을 다시 정의(override) 하여 지정할 수 있습니다. 가장 단순한 것은 소비자 끝점을 같은 시스템 내의 다른 멤버 위의 공급자 끝점에 접속하는 것입니다. 아울러, 소비자 끝점은 시스템 외부의 응용 프로그램에 접속하여 해결할 수도 있습니다. 이것을 실시하려면, 두 가지 방법이 있습니다.

첫째는 응용 프로그램의 소비자 끝점에 위임하는 프록시 소비자 끝점을 도입하는 것입니다. 프록시 끝점은 접속의 요건을 확인하여, 접속을 해결할 수 있습니다. 접속은 프록시 끝점을  속해 있는 상위 시스템에 연결하거나 위임함으로써 해결할 수도 있고, 오퍼레이터나 배포 스크랩트의 개입을 통해 해결할 수 있습니다.

둘째는 공급자 끝점의 고정 주소를 정의하는 적절한 외부 응용 프로그램을 시스템에 추가하는 방법입니다. 이 방법은 공급자의 주소를 알고 있고, 시스템 정의에 이 주소를 고정적으로 부여한 경우에 사용할 수 있습니다. 소비자 끝점을 외부 응용 프로그램의 공급자 끝점에 접속하면, 접속이 해결되며, 프록시 끝점을 공개할 필요가 없습니다. 외부 응용 프로그램은 디자인의 어느 수준에서도 추가할 수 있습니다. 그 때문에 소비자 끝점을 하위레벨 시스템의 프록시 끝점으로 공개 후, 상위 수준 시스템에서는 다른 시스템이나 응용 프로그램에 접속하여 시스템 내에서 접속을 해결하거나, 다른 프록시 끝점을 작성하거나 외부 응용 프로그램을 추가하여 요건을 전달할지 결정할 수 있습니다. 외부 응용 프로그램은 Web 서비스, BizTalk 서비스 (특별한 용도의 Web 서비스) 및 데이터베이스용 입니다. 다른 종류의 외부 응용 프로그램은 SDM SDK 를 사용하여  정의할 수 있습니다.

시스템 범위 설정

시스템은 크게 정의해야 하거나 필요 이상 크게  할 필요는 없습니다. 시스템은 함께 배포해야 할 시스템이나 응용 프로그램 패키지에 버전을 붙여 정의한 것입니다. 이러한 시스템이나 응용 프로그램은 각각, 개별적으로 정의되어 버전이 관리됩니다. 시스템에 정의되어 있는 멤버의 메이저 버전이 변화할 때마다, 그 시스템 정의 버전도 변경이 필요합니다.

시스템 사이의 불필요한 커플링을 줄이려면, 커플링 관점에서 필요한 만큼만 가급적 작게 시스템을 디자인합니다. 밀접한 관계가 있고 함께 버전 관리가 되어야 하는 멤버들을 묶어 하나의 수준으로 시스템을 설계하고, 이러한 시스템을 조합하여 또 다른 수준으로 시스템을 설계하는 것이 타당합니다.

서비스 지향 아키텍처의 디자인시에 장점을 얻기 위해서 이 방법을 사용할 수 있습니다. 서비스는 그 소비자와 느슨해야 할 필요가 있지만, 내부를 한없이 복잡하게 하거나 느슨한 또는 정밀 결합(tightly coupled) 되는 다수의 요소로 구성할 수도 있습니다. 시스템을 사용하여  서비스의 범위를 정의하면, 서비스의 경계를 눈에 보이는 형태로 명확하게 한다는 요구에 대처할 수 있습니다. 정밀결합된 요소 (데이터베이스를 공유하고, 구현 정보를 공유하도록 디자인된 응용 프로그램 등)를 함께 패키지화하여  서비스의 자율성을 향상합니다. 명시적인 경계도 자율성도 서비스의 바람직한 특성입니다. 자세한 내용은 「시스템을 사용한 서비스 지향 아키텍처(SOA) 서비스 표현」을 참조해 주세요.

느슨한 된 서비스로 구성되는 시스템을 디자인할 때는 구현대신, 계약과 메시지 스키마에 근거하여 결합을 실행합니다. 이것은 플랫폼간의 상호 운용성을 최대한으로 활용하는 바람직한 특성으로  서비스의 구현을 소비자에 영향을 주지 않고 변경할 수 있는 것을 의미합니다. 느슨함에 의해 구현은 변경 가능하지만, 새로운 구현을 포함한 상위 수준 시스템의 문맥에서는 여전히, 일부 시스템의 버전 변경이 필요합니다.

시스템의 대규모 포트폴리오 관리

시스템의 대규모 포트폴리오를 관리하는 경우, 모든 것을 포함한 1 개의 "엔터프라이즈" 시스템의 루트로  시스템의 단일 버전 트리를 보관 유지하는 것은 현실적이지는 않습니다. 보다 실용적인 솔루션으로 하려면, 시스템의 중요한 기능 그룹을 나타내는 1 개의 시스템을 루트로 하는 시스템의 다수의 트리를 관리하도록 합니다. 그 후, 이러한 시스템 사이의 접속을 도구에 포함되지 않는 다른 방법을 사용하여  관리할 수 있습니다. 아마, 다양한 소 그룹간의 상호작용 방법을 보이는 다수의 서로 겹친 시스템 정의를 사용하여, 시스템 사이의 관계를 눈에 보이도록 하는 것도 의미가 있습니다. 이러한 서로 겹친 시스템 다이어그램은 배포를 엄밀하게 기술하는 것에는 사용되지 않는다 해도 유용한 문서로서 보관 유지할 수 있습니다.

다른 종류의 시스템 접속 시각화

시스템 디자이너는 응용 프로그램 시스템을 모델링 하는 것에 중점을 두어 있지만, 경우에 따라서는 디자인의 응용 프로그램 시스템의 범위 밖에 있어도 이 시스템과 상호작용하여, 디자인시의 결정에 영향을 주는 시스템을 보여주는데 도움이 될 수 있습니다. 시스템 디자이너는 모델 주도이며  적절한 기반 모델이 정의되어 있다면 어떤 타입의 어떤 응용 프로그램이라도 포함하거나, 연결할 수 있습니다. 다른 종류의 시스템을 나타내려면, 응용 프로그램 디자이너로 지원되는 일반 응용 프로그램의 종류를 사용하거나 SDM SDK 를 사용하여  사용자 지정 응용 프로그램의 종류를 정의할 수 있습니다. 일반 끝점을 사용하여  모든 종류의 접속을 나타내거나 사용자 지정 끝점의 종류를 정의해 적절한 응용 프로그램의 종류에 관련지어 응용 프로그램 접속을 정의할 수 있습니다. 이러한 방법을 사용하면, 수동 시스템, 물리 시스템, 시스템 정의내의 소프트웨어 시스템을 포함하여, 지원되지 않은 소프트웨어 응용 프로그램이나 다른 종류의 시스템을 포함할 수 있습니다. 자세한 내용은 「수동 시스템, 물리 시스템, 그 외 종류의 시스템과 접속 표현」을 참조해 주세요.

SDM 문서 관리

SDM 형 시스템의 특성과 SDM 컴파일러를 사용하면, 일반적인 소프트웨어 개발 프로세스에 요구되는 요건이 아키텍처의 디자인 프로세스에 부여됩니다. SDM 문서 관리는 소프트웨어 개발로 이미 사용되는 성과물 관리프로세스의 확장으로 생각할 수 있습니다.

SDM 문서 버전 관리의 경우는 어셈블리의 버전 관리를 실시할 때와 같은 규칙을 사용합니다. SDM 정의는 소스 코드나 다른 성과물의 정의와 같이 분기 합니다. 또, SDM 디자인 문서 관리에 소스 관리 시스템의 같은 소스 트리내의 소프트웨어 성과물에 적용되는 고려사항을 적용시킵니다.

배포 리포트 생성의 일환으로서 컴파일된 SDM 문서가 출력되지만 이러한 문서는 응용 프로그램 디자이너나 시스템 디자이너로 열리거나 참조하거나 할 수 없습니다. 응용 프로그램이나 시스템을 열거나 참조하거나 하는 경우는 소스 SDM 문서를 로드해야 합니다. 지원되는 응용 프로그램의 경우, 그 응용 프로그램을 다른 시스템에 포함하려면, 관련하는 프로젝트, 소스 코드 및 일반적으로  SDM 소스 문서에 액세스해야 할 필요가 있습니다. 소스 코드에 액세스 필요 여부에 따라 일부 재사용 시나리오가 제한됩니다.

장기적으로는 SDM 메타데이터 정의와 그 정의가 보여주는 성과물과의 긴밀한 통합이 예상됩니다. 이번 출시에서는 코드와 동기되는 SDM 응용 프로그램 정의가 응용 프로그램의 루트 프로젝트에 배포됩니다. 장기적으로 보면, 어셈블리의 SDM 정의를 메타데이터로서 어셈블리에 포함하거나 다른 리소스의 정의를 직접 그 리소스에 포함하는 기능에 의해, 모델과 모델이 나타내는 성과물의 상관관계가 보다 알기 쉬워집니다.

요약

아키텍트는 시스템 디자이너를 사용하여 시스템의 복잡한 포트폴리오를 보다 엄밀한 방법으로 디자인을 검토할 수 있습니다. 이것에는 소프트웨어의 소스 코드에 사용되는 것과 같은 규칙으로 디자인 문서를 관리해야 합니다.