UML - 패키지 다이어그램 - 구현

- 이 글은 UML Distilled (마틴 파울러)책을 기반으로 작성하였습니다.

- 패키지 구현(Realization)

특정 패키지가 인터페이스를 정의하고 다른 몇 개의 패키지들이 구현하는 경우가 있다. 

위의 다이어그램에서 데이터베이스 게이트웨이 패키지에서 인터페이스를 정의하고 나머지 Oracle, SQL Server, Test Stub 이 이를 구현하였다.

 

이렇게 사용자와 클래스 사이에 인터페이스가 낀다는건 의존성을 끊는다는 의미가 된다. 만약 여러가지 물건의 전원을 켜고 끄는 리모컨을 개발한다고 생각해보자. 여러가지 물건에 대해 작동이 되어야 하지만 의존성이 생기는것은 원하지 않을것이다.

위의 다이어그램에서 Button과 CheckBox는 OnOff 인터페이스에 의존하여 난로와 조명기구의 전원을 제어한다. 만약 OnOff 인터페이스가 없었다면 Button과 CheckBox는 난로와 조명기구에 직접 의존해야 한다. 이렇게 되면 고수준의 컴포넌트라 추상화가 되어야 하는 Control 패키지가 더 구체적인 난로와 조명기구에 의존하게 된다.

 

이때 Control 패키지에서 OnOff 인터페이스를 정의하고 난로와 조명기구가 이를 구현하게 하면 의존성의 방향이 완전히 뒤바뀌게 된다. 더 고수준의 컴포넌트에 의존하게 되므로 안정된 추상화의 원칙을 지킬 수 있게 되고, 난로와 조명기구도 인터페이스 규약만 지키면 구현을 마음대로 변경해도 Control에 영향을 주지 않는다.

---

- 패키지 다이어그램과 어플리케이션

패키지 다이어그램은 규모가 큰 시스템의 의존관계를 이해하는데에 도움을 준다. 패키지 다이어그램은 컴파일시 그룹을 짓는 기준이 된다. 만약 현재 단일배포를 하고 있더라도 패키지 의존성을 잘 관리해두면, 나중에 어플리케이션 규모가 커져서 다중배포를 할 때 패키지 기준으로 나누면 된다.