UML
UML은 Undefined Modeling Language의 약자이다.
1997년 OMG(Object Management Group)에서 표준으로 채택된 통합 모델링 언어이다.
실험해볼 구체적인 것이 있고, 그것을 코드로 시험해보는 것보다 UML로 시험해 보는 쪽이 비용이 덜 들때 주로 사용한다.
UML은 구조 다이어그램 7개, 행위 다이어그램 7개로 총 14종류의 다이어그램이 있다.
이 중에서 클래스 다이어그램의 클래스 간 관계에 대해 알아보려한다.
클래스 다이어그램
시스템을 구성하는 클래스 간의 관계를 표현하는 다이어그램이다.
클래스, 스테레오 타입, 추상 클래스로 구성된다.
클래스 간 관계
클래스 간의 관계를 표기하는 방법은 다음과 같다.
Generalization (일반화)
슈퍼(부모) 클래스와 서브(자식) 클래스 간의 상속(Inheritance) 관계를 나타낸다.
여기서 Generalization란 서브 클래스가 주체가 되어 서브 클래스를 슈퍼 클래스로 Generalize하는 것을 말한다.
반대의 개념은 슈퍼 클래스를 서브 클래스로 Specialize(구체화) 하는 것이다.
상속은 슈퍼 클래스의 필드 및 메서드를 사용해 구체화하여 필드 및 메서드를 추가하거나 필요에 따라 메서드를 오버라이딩하여 재정의 한다.
또는 슈퍼 클래스가 추상 클래스인 경우에는 인터페이스의 메서드 구현과 같이 추상 메서드를 반드시 오버라이딩하여 구현해야 한다.
Realization (실체화)
인터페이스의 spec(명세, 정의)만 있는 메서드를 오버라이딩하여 실제 기능으로 구현하는 것을 말한다.
Realization을 표현하는 방법은 2가지가 있다.
첫 번째는 인터페이스를 클래스처럼 표기하고 스테레오 타입을 추가하고 점선과 비어있는 삼각형으로 연결한다.
두 번째는 인터페이스를 원으로 표기하고 인터페이스의 이름을 명시한 후 실선으로 연결해준다.
자바에서는 implements 키워드를 사용하여 인터페이스를 구현한다.
// interface
public interface CheckLogin {
public boolean isTrue();
}
// interface를 상속 받은 class
public class CheckLoginImpl implements CheckLogic {
@Override
public boolean isTrue() {
return true;
}
}
Dependency (의존)
어떤 클래스가 다른 클래스를 참조하는 것을 의미하고 클래스 다이어그램에서 일반적으로 제일 많이 사용하는 관계이다.
메서드 내에서 대상 클래스의 객체 생성, 객체 사용, 메서드 호출, 객체 리턴, 매개변수로 해당 객체를 받는 것 등을 말한다.
그러나 해당 객체의 참조를 계속 유지하지는 않는다.
추가로 어떠한 목적의 Dependency인지 의미를 명확하게 하고싶을 땐 다음과 같이 스테레오 타입으로 명시할 수 있다.
Association (연관) Directed Association (방향성 있는 연관)
클래스 다이어그램에서의 Association은 보통 다른 객체의 참조를 가지는 필드를 의미한다.
Association과 Directed Association의 차이는 방향성의 유무로 나눌 수 있다.
방향성 있는 연관
Directed Association이라고 한다.
표기법은 클래스를 실선으로 연결 후 실선 끝에 화살표를 추가한다.
User에서 Grade 쪽으로 화살표가 있으므로 User가 Grade를 참조하는 것을 의미한다.
화살표 옆에 있는 -grade는 역할명(Role Name)을 나타내고 Grade가 User클래스에서 참조될 때 어떤 역할을 가지고 있는지를 의미한다.
*는 개수(Multiplicity)를 나타내는데 대상 클래스의 가질 수 있는 인스턴스 개수 범위를 의미한다.
0...1과 같이 점으로 구분하여 앞에 값은 최소값, 뒤에 값은 최대값을 의마한다.
*은 0...*과 같은 의미로 객체가 있을 수도 있고 수가 정해지지 않는 여러 개일 수도 있다는 것을 의미한다.
방향성 없는 연관
일반적인 Association의 표기법이다. 실선 하나로 클래스를 연결한다.
User가 Grade를 참조할 수도, Grade가 User를 참조할 수도, 또는 둘 다 일 수도 있는 것을 의미한다.
Aggregation (집합)
Shared Aggregation이라고도 한다.
Composition과 함께 Association 관계를 조금 더 특수하게 나타낸 것으로 whole(전체)와 part(부분)의 관계를 나타낸다.
Association은 집합이라는 의미를 내포하고 있지 않지만, Aggregation은 집합이라는 의미를 가지고 있다.
표기법은 위와 같이 whole과 part를 실선으로 연결 후 whole쪽에 비어있는 다이아몬드를 표기한다.
다이아몬드가 이미 방향성을 표현하고 있기 때문에 part쪽에는 화살표를 명시해도 되고 명시하지 않아도 된다.
자바로 작성된 Aggregation 코드는 Association의 코드와 똑같다.
Association과 Aggregation은 집합이라는 개념적인 차이는 있지만 코드로는 이 차이를 구분하기 힘들다.
UML은 집합이라는 개념 외에 명확한 Aggregation의 정의를 제공하지 않는다.
그래서 여러 프로그래머나 분석가, 설계사가 Aggregation 관계에 대해 각자의 정의를 내렸기 때문에 혼란이 생겼다.
따라서 Aggregation은 사용하지 않는 것이 좋다고 한다.
Composition (합성)
Aggregation과 비슷하게 whole(전체)와 part(부분)의 집합 관계를 나타낸다.
하지만 개념적으로 Aggregation보다 더 강한 집합을 의미한다.
표기법은 Aggregation과 비슷하지만 다이아몬드의 내부가 채워져 있따는 점만 다르다.
Aggregation과 차이점은 강한 집합이라고 했다.
여기서 강한 집합이란 part가 whole에 종속적이어서 part가 whole의 소유라는 의미이다.
반면 Aggregation은 part가 whole에 대해 독립적이어서 whole이 part를 빌려 쓰는 것과 비슷하다.
이러한 의미때문에 Aggregation과는 다르게 명확하게 나타나는 점이 있다.
• part를 가지는 whole 인스턴스가 part 인스턴스의 전체 수명을 책임진다.
• part에 해당하는 인스턴스는 공유될 수 없다.
whole 인스턴스가 part 인스턴스의 수명을 책임진다는 의미는 다음과 같다.
• whole 인스턴스가 part 인스턴스를 생성한다.
• whole 인스턴스가 소멸되면 part 인스턴스도 함께 소멸한다.
• whole 인스턴스가 복사되면 part 인스턴스도 함께 복사된다.
Aggregation 관계와 Composition 관계를 UML 툴에서 그린 후 Code Generation을 하면 똑같은 코드가 생성된다.
하지만 Composition에서는 개발자가 추가해야 할 부분이 몇 가지 있다.
part 인스턴스가 공유되지 않게 하기 위한 Deep Copy 구현한다.
그리고 part 인스턴스의 수명 전체를 책임져야 하기 때문에 whole 클래스의 생성자 또는 기타 메서드 내에서 part 인스턴스를 생성해야한다.
그리고 외부에서 part 객체를 생성하지 못하도록 whole 클래스에는 part 인스턴스에 대한 setter가 있으면 안된다.
자바에서 Garbage Collector가 객체 소멸을 수행하므로 part 인스턴스의 소멸은 신경쓰지 않아도 된다.
전체 관계 정리
참고 사이트
https://www.nextree.co.kr/p6753/
UML: 클래스 다이어그램과 소스코드 매핑
불과 몇 년 되지 않은 학생 시절... 처음으로 UML을 접했고, UML의 기초적인 그리는 법과 사용법을 배웠습니다. 개인적으로 쉽지 않은 수업이었는데 그 중 가장 많이 사용되는 클래스 다이어그램에
www.nextree.co.kr
'📚개발지식 > 디자인패턴' 카테고리의 다른 글
| [디자인패턴] 생성 패턴 - 팩토리 메서드 패턴 (Factory Method Pattern) (0) | 2024.02.06 |
|---|
댓글