포스팅에 앞서, 공부한 내록을 기록하며 적절한 사진을 찾아 보충하려다가 어떤 글에 필요한 모든 사진이 있었다. 약간 오래되었지만 너무나도 잘 설명된 글이다.
UML: 클래스 다이어그램과 소스코드 매핑
불과 몇 년 되지 않은 학생 시절... 처음으로 UML을 접했고, UML의 기초적인 그리는 법과 사용법을 배웠습니다. 개인적으로 쉽지 않은 수업이었는데 그 중 가장 많이 사용되는 클래스 다이어그램에
www.nextree.co.kr
객체지향 프로그래밍이 무엇인지, 객체지향 프로그래밍에서 중요한 것은 어떠한 것이고 특성이 무엇이지 등 객체지향에 대해 이해했더라도 객체지향을 잘 지킨 프로그램을 만드는 것은 그 다음의 일이다. 객체지향 프로그래밍은 프로그램의 기능들을 잘게 나눠 객체들에게 책임을 맡긴다. 이러한 객체지향 프로그래밍을 잘 만들기 위해 객체지향적인 설계를 추구해야하고, 객체지향 설계를 말하기 위해선 두가지를 말할 수 있다.
- 객체를 어떻게 구분하는가.
- 객체간의 연관관계가 어떠한가.
이 두 가지로 개발자가 다른 개발자에게 프로그램이나 시스템에 대해서 말할 때 이해가 가도록 설계가 가능하다. 이걸 바탕으로 설명하기 위한 언어를 UML (Unified Modeling Language)이라고 한다. UML은 여러가지가 종류가 있다. Usecase Diagram, Sequence Diagram, Package Diagram 등이 있지만 객체지향 프로그램의 설명을 위해 주로 Class Diagram을 사용할 수 있다. draw.io, startuml.io 등의 툴을 사용해서 UML을 그릴 수도 있고, 파워포인트, 그림판 등으로도 충분하게 할 수 있다.
클래스 다이어그램
클래스 다이어그램에서 클래스는 네모이고, 네모 안에 제일 위에 클래스 이름을 쓴다. 이 두가지는 필수사항이다. 이름 밑에 필드 영역, 메서드 영역을 넣어서 객체의 구성을 나타낼 수 있다. 둘을 분리해서 필드, 메서드로 나눌 수도 있고, 한 번에 쓸 수도 있고, 안 쓸 수도 있다.
일반화와 실체화
Java로 코드를 쓰면 상속을 위한 extends와 인터페이스를 구현하기 위한 implements를 자주 접한다. 이를 Java로 구현하기 전, 다이어그램으로 표현할 때 일반화와 실체화로 표시할 수 있다.
상속은 실선에 빈 화살표로 나타낼 수 있다. UML에선 이를 일반화(Generalization)이라고 한다. 하위 객체가 화살표로 가리키고 있는 상위 객체로 일반화 될 수 있기 때문이다. 상속 관계에서 부모 객체는 자식 객체보다 더 넓은 범위의 일반적인 객체이다.
구현은 점선에 빈 화살표로 나타낼 수 있다. UML에선 이를 실체화(Realization)이라고 한다. 하위 객체가 상위 객체를 구현함으로써 추상적인 상위 객체의 실체를 만들어주기 때문이다.
화살표의 방향은 하위 객체가 상위 객체를 가리킨다.
연관
A와 B라는 객체들이 있을 때 둘 중 하나가 다른 하나를 어떤 방식으로던 소유하고, 필드로 들고있다면 연관(Association)이라고 한다. A가 B를 소유하거나, B가 A를 소유 할 수도 있다. 혹은, 양쪽이 서로를 소유하고 있는 관계일 수도 있다.
여기서도 화살표를 사용해 연관 관계를 더 명확하게 명시가 가능하다. A가 B를 소유하고 있다면 A → B, B가 A를 소유하고 있다면 B → A. 이게 직접 연관(Direct Association)이다.
집합과 합성
A가 B를 구성 요소로 가지고 있을 수 있지만, 가지고 있지 않을 수도 있다면? A쪽에 다이아몬드를 만들어 빈 칸으로 두면 된다. 이것을 집합(Aggregation)이라고 한다. 연관 관계에서 구체적으로 소유의 관계를 표현한다.
없으면 안돼! 반대로 반드시 소유해야만 한다면? 다이아몬드를 칠한다. 이것을 합성(Composition)이라고 한다.
의존
일반화, 실체화, 직접 연관, 집합, 합성 등의 관계를 보면 화살표가 존재한다. 화살표는 구체적인 객체가 추상적인 객체를 가리키거나, 또는 소유하거나 사용하는 객체가 소유되거나 사용되는 객체를 가리키고 있다. 즉, 화살표가 출발하는 지점의 객체가 화살표가 향하고 있는 객체를 어떠한 방식으로던 참조하고 있기 때문에 의존하고 있다. 참조 당하는 객체는 참조하고 있는 객체가 변하던 상관이 없다. 하지만 참조하고 있는 객체는 가리키고 있는 객체의 변화에 따라 같이 변화가 있을 수도 있다.
가끔 컴퓨터가 맘대로 OS 업데이트 되는 경우가 있다. 그러면 나는 OS에서 바뀐 점이 있다면 그걸 알아야 제대로 사용할 수 있다. 하지만 OS는? 사용자가 어떻던 업데이트 될 수 있다. 사용자는 OS에 의존하고 있다.
UML에서 위의 화살표를 사용한 관계들이 의존성의 방향을 뜻하고 있다. 하지만 어떤 관계로 표현하기가 애매하거나 구체적인 관계가 아니라 단지 의존하고 있음만 나타낼 수도 있다. A와 B 두 클래스가 존재할 때, A 클래스가 B 클래스를 어떤 방식으로던 알고있다면 A는 B를 알아야만 하고, A는 B에 의존하고 있다. 점선에 화살표를 이용해 의존(Dependency)를 표현할 수 있다.
위에서도 언급했듯이, 의존 관계는 추상화를 표현할 수도 있고, 소유를 표현할 수도 있으며, 사용을 표현할 수도 있다.
References
https://www.nextree.co.kr/p6753/
UML: 클래스 다이어그램과 소스코드 매핑
불과 몇 년 되지 않은 학생 시절... 처음으로 UML을 접했고, UML의 기초적인 그리는 법과 사용법을 배웠습니다. 개인적으로 쉽지 않은 수업이었는데 그 중 가장 많이 사용되는 클래스 다이어그램에
www.nextree.co.kr
프로그래머스 데브코스 - 프로그래머스를 위한 Java
'객체지향 프로그래밍' 카테고리의 다른 글
| Open-Closed Principle: 개방 폐쇄 원칙 (0) | 2024.07.18 |
|---|---|
| 객체지향의 특성 - 다형성 (0) | 2024.05.24 |
| 객체지향의 특성 - 추상화 (0) | 2024.05.22 |
| 객체지향의 특성 - 상속 (0) | 2024.05.21 |
| 객체지향의 특성 - 캡슐화 (정보은닉) (0) | 2024.05.21 |
