UML - 클래스 다이어그램과 의존

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

- 의존

한 요소가 다른 요소에게 영향을 미칠 때 두 요소 사이에는 의존이 존재한다고 얘기한다. 한 클래스가 다른 클래스에 메시지를 보내거나, 다른 클래스를 매개변수로 사용하거나, 다른 클래스 데이터의 일부를 갖고 있을 수 있다.

 

어플리케이션의 규모가 커질수록 의존에 신경을 써야한다. 의존을 제어하는데 실패하면 프로젝트 초반에는 별 영향이 없겠지만, 후반부로 갈수록 기능 하나를 개발하거나 변경하는데 드는 공수가 걷잡을 수 없이 커진다.

위 다이어그램은 어플리케이션에서 흔히 볼 수 있는 의존구조이다. Benefits Window는 Employee 클래스에 의존하고 있다. Benefits Window 는 표현 (presentation) 계층이며, Employee는 핵심 (비즈니스) 계층이다. Benefits Window 가 변경되어도 Employee 는 변경되지 않는다.

---

- 의존의 다양성

클래스 다이어그램에서 의존을 나타낼 때, 보통은 화살표만 이용하여 표기한다. 하지만 꼼꼼한 성격이라거나 특별히 해당 의존을 자세히 표현하고자 한다면 키워드를 사용할 수 있다.

 

아래 설명에서 소스는 화살표가 출발하는 방향이며, 타겟은 화살표가 가리키는 방향이다. 예를 들면 위 다이어그램에서 Benefits Window가 소스이며, Employee가 타겟이다.

• <<call>>: 소스가 타겟의 오퍼레이션을 호출
• <<create>>: 소스가 타겟의 인스턴스를 생성
• <<derive>>: 소스가 타겟으로부터 파생된다.
• <<instantiate>>: 소스가 타겟의 인스턴스
• <<permit>>: 소스가 타겟의 private에 접근 가능
• <<realize>>: 소스가 타겟에서 정의한 명세 또는 인터페이스 구현
• <<substitute>>: 소스는 타겟과 치환 가능
• <<trace>>: 클래스에 대한 요구사항을 추적하거나, 한 모델의 변경사항이 다른 곳에 영향을 주는지 추적할때 사용
• <<use>>: 구현을 위해 소스가 타겟을 필요로 한다. 

---

- 의존과 설계

기본적으로 어플리케이션 설계시 의존을 줄이도록 노력해야 한다. 특히 의존관계에 사이클이 일어났다면 없애도록 해야 한다. (컴포넌트 결합 ADP - ocwokocw.tistory.com/36 참조)

 

또한 클래스다이어그램을 작성할 때 모든 의존관계를 표현하겠다는 생각으로 임하는 것은 좋지 못한 생각이다. 지금 당장 내가 임하는 프로젝트의 모든 클래스 파일에 대해 의존관계를 표현한 다이어그램이 있다고 생각해보자. 이 다이어그램을 보았을 때 이해할 수 있는가? 클래스간에 존재하는 의존은 너무 많을 뿐만 아니라 수시로 변한다. 특별히 신경써야 하는 이슈나 중요한 부분에 한하여 표현하도록 하자. 의존을 표현하는 적절한 수준은 클래스 다이어그램 레벨이 적당하다.