System Architecture-2

논리적 관점(Logical View) 혹은 디자인 관점(Design View)

논리적 관점에서의 아키텍쳐는 시스템의 주요한 기능적인 요구사항에 대한 것입니다. 그림 19-2는 수강신청 시스템 예제의 논리적인 관점에서의 아키텍쳐를 나타내는 다이어그램입니다.


그림 19-2 수강신청 시스템의 논리적인 아키텍쳐

논리적인 관점의 아키텍쳐와 설계의 주된 차이점은 기능적인 요구사항 하나 하나를 다루는 것이 설계라면 아키텍쳐에서는 전체적인 시스템의 기능에 영향을 미치는 설계 전략(design strategy)을 결정하는 것이 아키텍쳐라고 하겠습니다.

가령, 구현 언어를 결정한다던가 사용할 DB를 결정하는 일, GUI를 결정하는 일은 설계자의 역할이기 보다는 아키텍트 혹은 아키텍쳐를 담당하는 팀의 몫이겠죠.


구현 관점(Implementation View)

구현관점의 아키텍쳐는 실제 소프트웨어 모듈의 조직에 관한 것입니다. 논리적인 것이 아니라 실제로 구동하는 시스템의 모습에 관한 것이죠.

논리적 관점에서의 패키지가 논리적인 기능별 묶음이었다고 하면 구현관점에서의 패키지는 물리적인 묶음으로 변모합니다. 이러한 패키지들은 보통 잘 정의된 인터페이스에 의해 나누어지면서 층(Layer)을 이루게 됩니다. 이러한 층(Layer)은 J2EE와 같은 응용프로그램 개발 프레임워크에서 제시하는 Tier와 일맥상통하는 것이죠.


그림 19-3. J2EE의 응용 프로그램 모델

한편, 설계에서의 하나 이상의 클래스는 구현관점에서 하나 이상의 컴포턴트로 나타내어지게 됩니다. 하나의 클래스가 하나의 컴포넌트가 되기도 하지만, 더러는 패턴을 이루는 클래스들이 하나의 컴포넌트가 되기도 하죠. 최근 불고 있는 디자인 패턴 열풍은 바로 아키텍쳐 관점에서 좋은 소프트웨어 설계를 위한 노력의 일환이라고 볼 수 있습니다.


그림 19-4. 컴포넌트 다이어그램

Rose에서 구현관점은 ‘Component View’ 패키지 내에서 컴포넌트 모델로 표현됩니다.


프로세스 관점(Process View)

프로세스관점은 구현관점과 유사합니다. 다만, 구현관점이 개발 과정에서의 소프트웨어 구조라면 프로세스관점은 실행 시(run-time)를 다룬다는 것이 차이점이죠. 따라서, UML 표현은 구현관점과 프로세스관점 모두 동일한 방식을 취합니다. 모델의 차이는 실제 구현 시에 어떠한 형태를 띄느냐 하는 것이죠. 가령, ‘EXE로 구동하느냐’, 아니면 ‘DLL 형태로 구동하느냐’ 하는 것들이죠.


배포 관점(Deployment View)

배포관점은 그야말로 시스템이 실제 배치되는 모습에 관한 것입니다. 인터넷과 무선 통신 등의 발달로 점차 프로그램이 분산화 되는 측면에서 갈수록 중요성이 강화되는 측면이라고 하겠죠. Rose에서는 ‘Deployment View’라는 다이어그램을 기본적으로 갖고 있어 배포도를 나타내도록 하고 있습니다.


유스케이스 관점(Use Case View)

19-1의 그림을 보면 유스케이스 관점은 다른 관점들을 묶으며 이들 가운데 위치하게 됩니다. 유스케이스 관점의 키워드는 ‘통합’입니다. 앞서 언급한 관점들은 각기 다른 시사점을 제시합니다. 이들 중 어느 하나의 관점을 강조하면 다른 하나의 관점에서는 상대적으로 악영향을 미칠 수가 있습니다. 가령, 성능을 높이기 위해 프로세스 관점에서 변화를 주자 논리적인 관점에서 설계 모델의 유연성이 떨어졌다고 합시다. 이것은 올바른 의사결정인가요?

이러한 관점의 차이에서 오는 마찰을 어떻게 극복할 것인가? 이들을 통합해주는 유스케이스에 그 답이 있다는 것이죠. 시스템의 가치는 유스케이스로 평가 받습니다. 즉, 평가는 고객의 몫이라는 것이지 단순히 성능이나 유연성, 유지보수성 등으로만은 이야기할 수 없습니다. 아키텍쳐에 대한 이들 각각의 관점은 결국 유스케이스 관점에서 평가하고, 검증할 수 있다는 것입니다.