최초 23/11/13
동기
UML은 diagram 종류가 많은데 class diagram 하나만 해도 여러 관계들이 있어 서로 뭐가 다르고 왜 쓰는지 애매한 점이 있었다. 이번 기회에 각 관계에 대해 명확하게 정리해서 다시 검색하는 일이 없도록 하고싶다.
문제 상황
특정 기능을 설계할때 어떤 부분을 뭉치고 어떤 부분을 나눌지 문제가 됨. 이를테면 자주 쓰이는 기능을 묶어 재사용하지 않으면 그 기능을 수정할 때 여러곳을 찾아서 수정해야 하고 그 과정에서 아다리(?)가 안맞는 실수가 생김. 아니면 다른 모듈을 사용할때 해당 모듈의 많은 부분에 의존할수록 연결을 수정하다가 아다리(?) 안맞는 실수가 생기기 쉬움. 이런 cohesion, decoupling 문제는 유지보수가 쉬운 설계에서 가장 중요한 이슈. 이와 같이 기능을 어떻게 쪼개고 연결할지에 대한 표현을 담당하는게 class diagram.
전체 개요
UML에 속하는 diagram은 generalization, realization, association, aggregation, composition, dependency가 있음. 이들을 의미적으로 구분하면 is-a(generalization, realization), has-a(association, aggregation, composition), 그 외(dependency)임. 또다른 구분 기준은 관계가 얼마나 결합되있느냐임.
is-a & 강한 결합
generalization. 클래스의 관계가 상속에 의한 부모-자식 관계임. 필드와 메서드 모두 의존하므로 가장 의존적. 따라서 한번 부모 클래스를 정하면 이미 자식 클래스에서 필드, 메서드를 사용하고 있는 상황에서 부모 클래스를 수정하기 어려움. is-a 관계는 빈 화살표를 의존하는 대상을 가리키게 표현하고 강한 결합 관계는 실선으로 표현.
is-a & 약한 결합
realization. 클래스의 관계가 상속에 의한 부모-자식 관계인 점에서는 generalization과 같지만 부모 클래스가 인터페이스인 점에서 약한 결합. is-a 관계를 generalization과 동일하게 빈 화살표로 표현하고 메서드 시그니처에만 의존하는 약한 결합 관계는 점선으로 표현.
has-a & 강한 결합
association, aggregation, composition. is-a 관계는 클래스간의 관계인데 비해 has-a 관계는 객체간의 관계. 클래스의 정의 뿐 아니라 객체의 개수와 상태에 의존적임. 따라서 is-a와 달리 객체의 가능한 개수도 표시함. has-a 관계는 개수가 1인 객체쪽에 다이아몬드로 표현. 양쪽 다 1인 경우는 다이아몬드를 표현하지 않음(association). 또한 양쪽의 라이프사이클이 관련 없는 경우 빈 다이아몬드를(aggregation), 완성품 객체가 사라질 때 부품 객체가 같이 사라지는 경우 속을 채운 다이아몬드를(composition) 사용.
dependency & 약한 결합
has-a 관계와 마찬가지로 dependency 관계도 객체간의 관계. has-a 관계와 다른점은 1:1 관계이고 상태에 의존하지 않음. 상태 관계없이 로직만 가져다 쓴다고 생각하면 될듯. dependency 관계는 뚜껑없는 빈 화살표로 의존하는 대상을 가리키게 표현하고 메서드 시그니처에만 의존하는 약한 결합은 점선으로 표현.
참고
웹사이트 비주얼 패러다임
https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-uml/
https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-class-diagram/
