아키텍처의 표현
아직 존재하지 않는 기술이나 상품을 홍보하기 위한 것으로 마키텍처(maketecture)라는 용어가 있다. 시스템의 구조나 동작을 한 페이지로 간략히 보여주기 위하여 작성된 것을 말합니다. 마키텍처는 시스템을 설계하고 구축하고 검토하는 동안 이해 당사자들이 토론할 때 유용하게 쓰이는 도구입니다. 문제를 이해하고 설명하고 더 깊은 분석에 들어가기 전에 출발점으로 이용할 수 있기 때문입니다.
완벽하게 만들어진 아키텍처는 시스템의 추상적인 요약이므로 매우 유용합니다. 대부분의 아키텍처는 개발팀과 관계자들이 이해하기 쉽도록 추상화 합니다. 추상(abstract)의 의미는 불필요한 자세한 것을 생략하고 가장 중요한 문제에 관심을 집중시킨다는 것입니다. 이렇게 표현하려면 아키텍처에서 컴포넌트를 블랙박스로 명시하고 외부에 보일 수 있는 구조적인 속성만 나타내야 합니다.
아키텍처를 표현하는 가장 강력한 방법은 계층적 분할(hierarchical decompositions)이다. 상세 수준에 따라 나누어 표현된 컴포넌트를 더 자세히 나타내기 위하여 분할하는 방법이다. 아래 그림에 있는 아키텍처는 두 개의 계층으로 나누어 있고 두 개의 컴포넌트가 분할되어 있습니다.
계층적으로 분할된 아키텍처는 그 수준에 따라 서로 다른 개발자들이 관심을 갖게 됩니다. 위 그림의 최고층 컴포넌트를 서로 다른 개발팀에서 설계하고 개발한다고 합시다. 브로커 컴포넌트를 더 자세히 분할하여 또 다른 아키텍처 수준을 설계하는데 이 때 비기능적 요구를 다시 분석하여 품질 목표를 설정할 수도 있다. 예를 들면 브로커가 디렉토리 서비스를 위하여 특별한 메시지 라우팅 기능을 제공할 수도 있습니다.
위 그림의 아키텍처에서 클라이언트 컴포넌트는 더 이상 분할되지 않았습니다. 그 의미는 클라이언트의 내부 구조와 동작이 전체 시스템의 비기능적 품질 목표를 달성하기 위하여 그렇게 중요하지 않기 때문입니다. 즉 클라이언트가 서버에 정보를 보내고 받는 것은 아키텍트의 관심 대상이 아니며 자세한 설계를 컴포넌트 개발자들에게 위임한다는 의미이다. 실제 클라이언트가 서버에 정보를 주고받으며 사용자와 인터랙션하는 부분은 꽤 복잡할 수 있습니다. 하지만 이런 부분을 나타내지 않는 것은 컴포넌트 개발팀 내부의 관심이고 전체 아키텍처를 설계하는 관점에서는 축약한다는 의미입니다.
패키지 다이어그램
이전 포스팅에서 설명한 UML을 사용한 모델링에서 클래스 다이어그램이 어느 정도 작성되었으면 품질 목표에 맞는 아키텍처를 찾고 서브시스템으로 분할하는 작업이 이어집니다. 시스템을 설계하는 동안 서브시스템을 찾는 작업은 분석 과정에 객체를 찾는 작업과 매우 유사합니다. 즉 정답이 없는 매우 휴리스틱 한 작업입니다. 서브시스템 분할에도 분석 과정에서 객체를 찾는 것과 같은 Abbott 룰이 적용될 수 있습니다. 하지만 서브시스템 분할은 새로운 문제가 드러나면 계속적으로 변경할 수가 있다. 서브시스템이 하나로 합병될 수도 있고 복잡한 것은 나누어질 수도 있고 새로운 기능이 추가될 수도 있습니다. 서브시스템 분할은 결국 시스템 설계에 많은 변경을 가져올 수 있고 여러 사람들의 머리를 짜내야 한다.
UML에서는 서브시스템을 표현할 때 패키지라는 개념이 도입됩니다. 패키지는 클래스를 의미 있는 관련된 그룹으로 구성하는 메커니즘입니다. 즉 클래스를 논리적으로 그룹화하는 것으로 Java 프로그래밍 언어의 Package 선언으로 매핑 될 수 있습니다. 패키지는 중첩될 수 있다. 최상위층에는 구조적인 개체들, 예를 들면 사용자 인터페이스, 비즈니스 도메인, 서브시스템과 관련된 패키지가 형성되며 하위 층에는 더 작은 개념의 비즈니스 작업, 예를 들면 Video, Inventory와 같은 것들이 표현됩니다.
패키지로 정의하면 복잡한 시스템을 서브시스템으로 나누어 적절히 컨트롤 할 수 있습니다. 패키지 이름을 정하여 알고 있으면 외부에서 패키지 안의 자세한 사항을 몰라도 import 하여 사용할 수 있습니다.
패키지 다이어그램은 소프트웨어 구조를 표현하는데 적합합니다. 패키지가 클래스의 그룹이므로 높은 수준의 추상화된 서브시스템을 표현할 수 있기 때문입니다. 예를 들어 Java의 AWT를 구성하는 클래스들이 매우 많은데 이들을 하나의 패키지로 생각하고 다루면 편리하다. 아래 첫번째 그림의 패키지 다이어그램은 두 서브시스템 사이의 의존 관계를 나타낸 것으로 myGUI가 java.awt에 포함된 내용을 사용하고 있다는 의미입니다.
패키지는 다이어그램 안에서 다시 중첩될 수 있다. 즉 위의 두 번째 그림에 표현된 것처럼 Clerk User Interface 패키지 안에 또 다른 패키지인 Business System Client가 정의되어 있다. 따라서 Clerk User Interface 패키지 안에는 Customer 클래스와 Rental UI 클래스, Business System Client 패키지가 정의되어 하나의 서브시스템을 이룬다는 것을 나타냅니다.
서브시스템을 분할하는 또 다른 휴리스틱은 기능적으로 관련 있는 객체를 같은 서브시스템 안에 모으는 것이다. 사용 사례 하나를 취하여 관련 객체를 같은 서브시스템으로 그룹화합니다. Business System Client와 같은 객체 그룹은 한 서브시스템에서 다른 서브시스템으로 정보를 전달하는데 사용됩니다. 또 한 조화를 이루기 위하여 새 서브시스템을 만들 수도 있고 객체를 생성하는 서브시스템을 지정할 수도 있습니다. 객체를 서브시스템으로 그룹화 하기 위한 휴리스틱은 다음과 같습니다.
- 같은 사용 사례에서 발견된 객체는 같은 서브시스템으로 구분한다.
- 서브시스템 사이에 데이터를 전달하기 위하여 사용되는 객체는 단독 서브시스템으로 만든다.
- 서브시스템 경계에 있는 연관 관계를 최소화한다.
- 같은 서브시스템 안에 있는 모든 객체는 기능적으로 연관이 있어야 한다.
서브시스템으로 분할하면 객체 사이의 의존을 최소화할 수 있어 솔루션 도메인의 복잡성을 줄일 수 있다. Facade 패턴 [Gamma, 1994]은 간결하고 통합된 인터페이스로 서브시스템을 캡슐화 하여 클래스 사이의 의존도를 줄 일 수 있게 한다. 예를 들어 위의 두 번째 그림에서 Business System Client 클래스는 Customer, Rental UI 클래스를 감추는 Facade 클래스이다.
참고자료 출처 : 새로쓴 소프트웨어 공학 (저자 : 최은만)