최근 OOP 를 공부함에 따라 UML 그리는 법부터 다시 공부를 하기 시작했다.
필자가 개인적으로 OOP 코딩을 잘 못하는 관계로 이번 문서는 100% 신뢰를 보장하지 않는다 -_-.. 개인 공부 목적용일뿐..
아래 자료는 홍익대학교 컴퓨터 정보통신공학 OOP 수업자료 관련한 PDF 파일에서 발최한 그림이다.
클래스 다이어그램을 그리기전 클래스를 규명해줘야 한다.
맨위에는 클래스명이 들어가고, 그 아래 칸은 각각의 속성과 타입, 그아래는 연산자가 들어가게 된다.
각각 메소드나 변수면 앞에붙는 문자의 의미는 다음과 같다.
+는 public 로써 모든 클래스에서 접근 가능하다.
-는 private 로써 상속받은 클래스간에만 접근이 가능하다.
#은 protected 로써 자기 자신에게밖에 접근 할 수 없다.
다이어그램에서의 상속관계는 다음과 같이 표현한다.
추상클래스같은 경우 MyDerivedClass 에서 상속받아 그 함수를 재정의해야 하므로 연관관계 세모 모양은 위로 향하게 된다.
이 관계가 한국인들에게는 좀 헤깔릴 수 있는 관계이만 필자만의 노하우를 말하면 삼각형의 방향을 > < 의 부등식으로 보면 좀더 이해하기가 좋다.
예를들어
MyDerivedClass -> MyAbstractClass 라고 생각을 하면 myDerivedClass 는 MyAbstractclass 를 사용하기에 더 큰 개념이다. 이러한 경우 그대로 MyDerivedClass - ▷ MyAbstractClass 라고 표현해 주면 된다.
부모자식 관계는 별개의 방식으로 생각하여 여러개의 클래스가 extends 로 상속 받을수 있으므로, 여러 자식은 한 부모를 가져야 한다. 라는 개념으로 보면 MyDerivedClass 가 자식이되고 MyAbstractClass 가 부모가 된다.
이번엔 구현(implement)부를 보면 interface는 객체를 상속받는 것이 아니지만 type과 이름만으로 선언된 것을 하위 클래스에게 전하여 규약을 만든다.
때문에 extends 보다 조금더 느슨한 느낌이라고 보면 되기에 점선으로 표시한다.
다음은 aggregation(집합관계) 과 composition(구성관계) 이다.
우선 위에 그림에도 나와 있지만 집합관계는 투명한 다이아몬드 모양으로 표시하고 구성관계는 검은색 다이아 몬드로 사용 된다.
이 두가지 차이가 애매하다. 특히나 번역을 빌리면 더욱 난감해지는데 개발자들은 코드로 대화한다고 하지 않던가! 코드를 보면 보다 간결하다.
우선 집합관계(aggregation)은 자식 클래스가 부모클래스와 독립적으로 작용한다.
구성관계(composition)은 자식클래스가 부모클래스에 종속된다.
main(){
Greet g = new Greet(new ArrayList<String>()); Greet gt = new Greet(); }
public Greet(List l){ this.l = l; //집합 관계 }
public Greet(){ this.l = new Greet(); //구성관계 } |
따라서 부모 클래스가 제거되었을 때 aggregation의 자식 클래스는 살아남는다. 하지만, composition의 자식 클래스는 제거된다.
http://sonsooresoon.tistory.com/18 의 글을 빌어 한번 다시 설명하면 ,
역사수업 을 듣는 학생들이 있다고 가정하자. 그럼 역사 수업안에는 학생들이 있지만 학생들이 없다고 역사 수업이 없는 것은 아니다. 이러한 것을 집합 관계라고 한다.
하지만 자동차를 속 엔진을 비교해 보면 자동차 엔진이 없으면 자동차는 굴러 가지를 않는다.
이를 구성 관계라고 한다.
외우기 쉬운 노하우로는 차를 구성하는 부품은 구성관계이고 그외의 추가적인 옵션들은 부속품이므로 집합 관계가 된다.
그 다음 각 다이어그램간 연관 관계에 대해서 보겠다.
위 그림에서는 고용주와 피고용인을 대상으로 보았다.
분명 고용주는 소수이다. 그리고 피 고용인은 다수이다. 각 다이어그램간 숫자의 해석은 다음과 같다.
1 ..3 : 1명으로 시작해서...... 3명까지는 될껄?
1 ..n , 1 ..* : 한명으로 시작해서..... 많이 많이 될껄?
* * : 그냥 많이 많이 될껄?
이런 느낌이다.
마지막으로 예시를 통하여 한번 복습해보자.
고객 메일 어플리케이션을 보면 한명의 소비자는 메일 어플리케이션을 가져야 한다. 하지만 메일 계정이 반드시 고객이 구성성분은 아니므로 집합 관계이다. 고로 투명한 다이아 몬드로 표시해 준다.
DelinquentCustomer 나 MoutaionCustomer 나 Regular Customer 세 부류의 고객들은 전부다. 각자 타입에 맞는 어플리 케이션을 사용 할수 있어야 한다. 하지만 이는 implement 로 interface만을 제공해 주겠다고 한다.
각 고객들은 customer 를 상속받아 사용해야 하므로 화살표 방향은 customer 족으로 향하게 되는 것이다.
이처럼 상속받는 것이 작은 개념, 상속 하는 것이 큰 개념으로 시작되면 UML 그리기는 이해하기가 편하다.