[UML Distilled] 7장

7장. 패키지 다이어그램

• 패키지는 UML의 어떤 구성 요소라도 더 높은 수준의 단위로 묶을 수 있도록 하는 묶음 구조이다.
• UML 모델에서 각각의 클래스는 단일 패키지의 멤버이다.
• 패키지도 다른 패키지의 멤버가 될 수 있다.
• 최상위 패키지를 하위 패키지로 나누고, 하위 패키지를 다시 하위 패키지로 나누는 것을 계속하여 클래스까지 내려가는 계층 구조를 얻을 수 있다.
• 패키지는 네임스페이스(namespace) 를 나타낸다.
• 모든 클래스가 자신이 속한 패키지 내에서 유일한 이름을 가져야 한다는 것을 뜻한다.
  • 완전한 이름(fully qualified name) : 소속된 패키지 구조를 보여주는 이름 예) System::Date

그림 7.1 다이어그램에서 패키지를 표현하는 방법

• UML에서는 패키지 내의 클래스가 public 또는 private일 수 있다.
  • public 클래스는 패키지의 인터페이스의 한 부분이다.
  • private 클래스는 보이지 않는다.
• 패키지의 public 클래스와 연관된 오퍼레이션 중 작은 부분만을 노출하는 방법으로 패키지의 인터페이스를 줄여야한다.
• 모든 클래스를 private로 하여 같은 패키지의 클래스만 서로 볼 수 있도록 하고, public 행동을 위한 public 클래스를 더하는 방법으로 하면 된다.

어떤 패키지에 어떤 클래스를 넣을지를 어떻게 정해야 할까?

• 공통 폐쇄 원칙(Common Closure Principle)
  • 한 패키지의 클래스들을 변경하는 이유는 서로 유사해야 한다.
• 공통 재사용 원칙(Common Reuse Principle)
  • 한 패키지의 클래스들이 함께 재사용 되어야만 한다.

패키지와 의존

• 패키지 간의 의존은 패키지 내용들 간의 의존을 요약한다.
• 좋은 패키지 구조는 의존의 흐름을 명확하게 보여준다.
• 보통 모든 의존이 한 방향으로 흐를 때에 흐름이 명확하다고 생각할 수 있다. 이것은 시스템이 잘 구성되었는지에 대한 좋은 지표이지만, 예외는 존재한다.

그림 7.2 엔터프라이즈 어플리케이션을 위한 패키지 다이어그램

• 의존에는 사이클이 없어야 한다.
• 의존이 많아질수록 패키지의 인터페이스는 더 견고해야 한다. 인터페이스가 조금이라도 변경되면 그것에 의존하는 모든 패키지에 영향을 주기 때문이다. (Stable Dependencies Principle)
• 패키지가 더 견고할수록 인터페이스와 추상 클래스의 비율이 높은 경향이 있다. (Stable Abstractions Principle)
• 너무 많은 곳에서 쓰이는 패키지는 <<global» 키워드를 붙인다.

패키지 측면

• 그림 7.2를 그림 7.3처럼 두 가지 측면을 분리해서 차이를 더 분명하게 만들 수 있다.

그림 7.3 그림 7.2를 두 개의 측면으로 구분한 예

패키지 구현하기

그림 7.4 하나의 패키지가 여러 개의 패키지들에 의해 구현되는 예

• 실현 관계(realization relationship) 는 데이터베이스 게이트웨이가 인터페이스를 정의하고 다른 게이트웨이 클래스들이 구현을 하는 것을 나타낸다.
• 인터페이스와 그것의 구현이 서로 다른 패키지에 있는 것은 아주 흔한 일이다.

그림 7.5 클라이언트 패키지에서 필요한 인터페이스를 정의한다.

언제 패키지 다이어그램을 사용하는가

• 거대한 크기의 시스템에서 주요 요소들 간의 의존에 대한 전체적인 관계를 이해하는데 유용하다.
• 어플리케이션의 의존을 통제하는데 도움이 된다.
• 패키지 다이어그램은 컴파일 시(complie-time) 에 그룹을 짓는 기법이다.