UML(Unified Modeling Language)
UML은 다이어그램을 사용하여 시스템이나 데이티베이스를 시각화하는 방법입니다.소프트웨어 개발에서 소프트웨어 시스템을 계획하기 위해 자주 사용됩니다.
📊 UML Diagram Type

📘 UML Class Diagram
UML (Unified Modeling Language) 클래스 다이어그램은 소프트웨어 시스템의 클래스들과 그들 간의 관계를 시각적으로 표현하는 도구입니다. UML 클래스 다이어그램은 주로 객체 지향 소프트웨어 개발 과정에서 사용되며, 시스템의 구조를 분석하고 설계하는 데 중요한 역할을 합니다.
클래스 다이어그램은 시스템의 초기 설계 단계에서 매우 유용하며, 개발자들이 시스템의 구조를 명확하게 이해하고, 객체 간의 상호작용을 쉽게 파악할 수 있게 도와줍니다. 또한, 클래스 다이어그램은 시스템의 문서화 과정에서도 중요한 역할을 하며, 새로운 팀원이나 외부 이해관계자들이 시스템을 더 쉽게 이해할 수 있도록 돕습니다.
✅ Vital components of a Class Diagram
📌 1. Upper Section
UML 클래스 다이어그램에서 클래스는 보통 세 개의 수평 섹션으로 나누어집니다. 이 섹션들은 각각 클래스의 이름, 속성(Attributes), 메소드(Methods)를 나타냅니다. 그중 가장 위에 위치한 섹션을 Upper Section이라고 하며, 여기에는 클래스의 이름이 표시됩니다.
📝 Upper Section의 역할
- 클래스 식별: Upper Section은 해당 클래스의 이름을 표시함으로써, 다이어그램에서 클래스를 식별할 수 있게 합니다. 이 이름은 클래스의 인스턴스가 가질 수 있는 객체 유형을 정의합니다.
- 클래스 범주화: 이름을 통해 클래스가 어떤 종류의 객체들을 나타내는지 명확히 합니다. 예를 들어, “Dog”, “Student”, “Car”와 같은 이름은 각기 다른 범주의 객체들을 나타냅니다.
- 시각적 식별: 다이어그램 상에서 다른 클래스들과 구별하기 쉽게 해주며, 복잡한 시스템에서도 클래스들을 쉽게 찾을 수 있게 돕습니다.
📐 디자인 관례
- 클래스 이름은 대문자로 시작하는 카멜 케이스(CamelCase)를 사용하는 것이 일반적입니다. 예를 들어, "ShoppingCart", "UserProfile"과 같이 표기합니다.
- Upper Section은 간결하고 명확하게 클래스의 이름만을 포함하며, 특별한 상황을 제외하고는 다른 정보는 포함하지 않습니다.
이렇게 Upper Section을 통해 UML 다이어그램에서 클래스의 기본적인 식별 정보를 제공하며, 다이어그램을 읽는 사람들이 각 클래스가 무엇을 나타내는지 쉽게 파악할 수 있도록 합니다.

📌 2. Middle Section
UML 클래스 다이어그램의 Middle Section은 클래스의 속성을 나열하는 부분으로, 속성은 클래스의 인스턴스가 가지는 데이터 필드를 의미합니다. 이 섹션은 객체의 상태를 정의하며, 각 속성에는 명시된 데이터 타입이 있어 객체가 저장하고 관리할 수 있는 정보의 유형을 표시합니다.
🔢 Middle Section의 주요 요소:
- 속성 이름: 각 속성의 이름을 명시합니다.
- 데이터 타입: 속성이 저장할 수 있는 데이터의 종류를 나타냅니다. 일반적인 데이터 타입으로는 String, int, double 등이 있습니다.
- 디폴트 값: 필요한 경우, 속성의 디폴트 값을 설정할 수 있습니다. 이는 객체가 생성될 때 해당 속성이 초기화되는 값을 제공합니다.
📝 역할과 기능:
- 객체의 상태 정의: 속성들은 객체의 현재 상태를 기술하는 정보를 담고 있으며, 이 정보는 객체의 행동에 직접적인 영향을 미칩니다.
- 데이터 관리: 속성들은 클래스가 처리할 데이터를 구체적으로 명시함으로써, 객체가 어떤 정보를 관리하고 처리할 수 있는지를 정의합니다.
- 타입 안정성 제공: 각 속성에 데이터 타입을 명시함으로써, 해당 데이터 타입에 맞는 값만을 속성에 할당할 수 있도록 합니다. 이는 데이터의 정확성과 프로그램의 안정성을 향상시킵니다.
📐 디자인 관례:
속성을 표현할 때 일반적인 형식은 다음과 같습니다:
- 접근 제어자: 속성의 접근성을 제어합니다 (+ for public, - for private, # for protected).
- 이름: 속성의 이름을 나타냅니다.
- 타입: 속성이 저장할 데이터의 타입을 나타냅니다.
- 디폴트 값: 선택적으로, 속성이 디폴트로 가질 값을 명시할 수 있습니다.
🎯예시:
- - name: String = "Unknown" — 이름을 저장하는 private 문자열 속성으로, 디폴트 값은 "Unknown"입니다.
- + age: int — 나이를 저장하는 public 정수 속성
- # studentID: String — 학생 ID를 저장하는 protected 문자열 속성
이렇게 Middle Section을 통해 클래스의 구조적인 특성과 데이터 관리 방식이 명확하게 드러나며, 개발자는 객체가 어떤 정보를 내포하고 있는지 쉽게 이해할 수 있습니다.

📌 3. Lower Section
UML 클래스 다이어그램의 Lower Section은 클래스의 메소드(Methods)를 나열하는 부분입니다. 이 섹션은 클래스 인스턴스의 행동이나 기능을 정의하는 메소드를 포함하며, 객체가 수행할 수 있는 작업들을 나타냅니다.
🔢 Lower Section의 주요 요소:
- 메소드 이름: 각 메소드의 이름을 명시합니다.
- 파라미터: 메소드가 받아들이는 입력 값들을 나타냅니다. 파라미터는 괄호 안에 표시되며, 각 매개변수의 이름과 데이터 타입을 포함합니다.
- 리턴 타입: 메소드가 실행 후 반환하는 데이터의 타입을 명시합니다. 이는 메소드의 결과를 나타내며, 어떤 타입의 값을 반환할지를 지정합니다.
📝 역할과 기능:
- 행동 정의: 메소드는 클래스의 행동을 정의합니다. 예를 들어, "Dog" 클래스의 bark() 메소드는 개가 짖는 행동을 구현할 수 있습니다.
- 상호작용 구현: 메소드는 클래스가 다른 객체나 시스템의 다른 부분과 상호작용하는 방식을 구현합니다. 이를 통해 객체 간의 커뮤니케이션 및 데이터 교환을 가능하게 합니다.
- 기능 제공: 객체가 수행할 수 있는 구체적인 작업이나 계산 등을 제공합니다. 이는 객체가 어떤 서비스나 기능을 외부에 제공할 때 중요합니다.
📐 디자인 관례:
메소드를 표현할 때 일반적인 형식은 다음과 같습니다:
- 접근 제어자: 메소드의 접근성을 제어합니다 (+ for public, - for private, # for protected).
- 이름: 메소드의 이름을 나타냅니다.
- 파라미터: 메소드에 전달되는 인자의 타입과 이름을 포함합니다.
- 리턴 타입: 메소드가 실행 후 반환할 데이터의 타입을 명시합니다.
🎯 예시:
- + bark(): void — 개가 짖는 행동을 수행하며, 반환 값이 없습니다 (void).
- + eat(food: String): boolean — 개가 음식을 먹는 행동을 수행하며, 성공적으로 먹었는지 여부를 boolean 값으로 반환합니다.
- # calculateAgeInDogYears(): int — 개의 나이를 "개의 해"로 계산하여 정수로 반환합니다.
Lower Section을 통해 클래스의 객체가 어떤 작업을 수행할 수 있는지, 그리고 어떻게 다른 객체와 상호작용할 수 있는지 명확하게 이해할 수 있으며, 개발자는 이를 통해 객체의 행동을 적절하게 설계하고 구현할 수 있습니다.

📌 4. Return Type

📌 5. Access Modifier


📌 6. Method Parameter Direction

📘 RelationShips between classes in UML
클래스간의 관계를 보여주는 7가지의 주요 표기 유형이 있습니다.

📘 Association(연관 관계)
📌 1. UML Association이란?
Association(연관 관계) 는 UML 다이어그램에서 클래스(Class)들 간의 논리적 연결(relationship) 을 나타내는 가장 기본적인 관계입니다.
- 두 클래스가 서로 연관되어 있음을 표현.
- 실제 시스템 내에서 한 객체가 다른 객체를 알고 있는 관계(참조 관계) 를 나타냄.
- 자바에서는 필드(멤버 변수)나 참조(reference)를 통해 구현됩니다.
✅ 핵심 정의
Association: "A 객체가 B 객체를 참조(알고 있다)" 는 의미.
📌 2. Association의 구성 요소
구성 요소 | 의미 |
---|---|
연관 라인 | 두 클래스 사이를 연결하는 선 |
이름 (optional) | 연관 관계에 이름을 붙일 수 있음 |
역할(Role) | 각 클래스가 연관 관계에서 어떤 역할을 하는지 |
다중성(Multiplicity) | 한 객체가 다른 객체를 몇 개나 참조하는지 |
방향성(Directionality) | 한 쪽만 참조하는지, 양방향 참조인지 |
navigability(탐색 가능성) | 어느 방향으로 접근 가능한지 |
📌 3. Association의 종류
종류 | 설명 | 예시 |
---|---|---|
단방향 Association | A → B 로만 참조 가능 | A가 B를 참조하지만, B는 A를 모름 |
양방향 Association | A ↔ B 서로 참조 가능 | A도 B를 알고, B도 A를 참조 |
Self Association | 클래스가 자기 자신과 연관 | Tree 구조에서 Node ↔ Node |
📌 4. Association의 다중성(Multiplicity)
다중성은 객체가 참조하는 인스턴스의 수를 제한합니다.
표기법 | 의미 |
---|---|
0..1 |
0개 또는 1개 (Optional 관계) |
1 |
정확히 1개 (필수 관계) |
0..* 또는 * |
0개 이상 (제한 없음) |
1..* |
1개 이상 (반드시 하나는 존재) |
0..n |
0개 이상 n개 이하 (명시적 제한) |
✅ 예시:
Customer
-Order
(0..*)- 고객은 주문을 0개 이상 할 수 있다.
Company
-CEO
(1)- 회사는 반드시 1명의 CEO가 있어야 한다.
📌 5. Navigability (탐색 가능성)
Association은 항상 탐색 방향(→) 을 명시할 수 있습니다.
표기법 | 의미 |
---|---|
→ | 단방향 참조 (A에서 B만 접근 가능) |
↔ | 양방향 참조 (A ↔ B 서로 접근 가능) |
UML 표기에서 화살표 머리를 통해 navigability를 명시합니다.
📌 6. Role (역할 이름)
- 연관 관계에서 각 클래스가 어떤 역할을 하는지 명시.
- 자바 코드에서는 필드명 으로 대응됨.
✅ 예시:
Customer ---------------------------> Order
(places)
- Customer가 Order를
places
한다는 의미. - 코드로 표현하면:
Order[] orders;
📌 7. Association과 Aggregation, Composition의 차이
관계 | 포함 의미 | 생명주기 | UML 표기 |
---|---|---|---|
Association | 단순 참조 | 독립적 | 실선 |
Aggregation | 부분-전체 (느슨한 포함) | 독립적 | 빈 마름모 |
Composition | 강한 포함 (생명주기 종속) | 종속적 | 채워진 마름모 |
✅ 비유로 쉽게
관계 | 예시 |
---|---|
Association | 학생 ↔ 수업 (단순 수강) |
Aggregation | 팀 ↔ 선수 (선수는 팀 없이도 존재 가능) |
Composition | 집 ↔ 방 (방은 집 없이는 존재 불가) |
📌 8. 코드로 보는 Association
✅ 단방향 Association 예제
class Customer {
private Order order; // Association (단방향)
}
class Order {
// 아무것도 없음 (Customer 모름)
}
✅ 양방향 Association 예제
class Customer {
private Order order;
}
class Order {
private Customer customer;
}
📌 9. UML Association 예시 다이어그램
+----------------+ +----------------+
| Customer | | Order |
+----------------+ +----------------+
| - name: String | | - number: int |
+----------------+ +----------------+
| + placeOrder() | | + cancel() |
+----------------+ +----------------+
| ^
| places |
+-----------------------------+
0..* 1
- Customer는 0개 이상 Order를
places
할 수 있음. - Order는 반드시 1명의 Customer와 연관됨.
📌 10. UML Association 요약
개념 | 설명 |
---|---|
Association | 객체 간 참조 관계 |
단방향/양방향 | 참조 가능 방향 |
다중성 | 0, 1, *, n 개수 제한 |
navigability | 탐색 가능성 (화살표) |
역할(Role) | 연관에서 각 클래스가 수행하는 역할 |
Aggregation/Composition | 포함/생명주기 종속성 |
🧬 Generalization
UML (Unified Modeling Language)에서 Generalization은 객체 지향 프로그래밍의 상속 개념을 표현하는 방법입니다. Generalization는 한 클래스(하위 클래스 또는 자식 클래스)가 다른 클래스(상위 클래스 또는 부모 클래스)의 속성과 행동을 상속받는 관계를 나타냅니다. 이를 통해 코드 재사용성을 높이고, 시스템의 계층적 구조를 명확하게 만들어, 유지보수와 확장성을 개선합니다.
⭐ Generalization의 주요 특징
- 계층적 관계: Generalization은 클래스 간의 계층적 관계를 설립합니다. 상위 클래스는 공통의 속성과 메소드를 정의하며, 하위 클래스는 이를 상속받아 추가적인 특성이나 행동을 구현할 수 있습니다.
- 재사용성 및 확장성: 상위 클래스의 코드를 재사용하여 각 하위 클래스가 필요로 하는 특수한 기능만 추가함으로써, 개발 시간을 절약하고 시스템의 확장성을 향상시킬 수 있습니다.
- 타입 계층: 하위 클래스는 상위 클래스의 타입을 유지합니다. 이는 다형성을 가능하게 하여, 상위 클래스 타입의 변수가 하위 클래스의 인스턴스를 참조(is a)할 수 있게 합니다. 이로 인해 더 일반적인 코드 작성이 가능해지며, 다양한 실행 시 시나리오에서 유연성을 제공합니다.
- 추상화: 종종 상위 클래스는 추상 클래스로 구현됩니다. 추상 클래스는 인스턴스화될 수 없으며, 하나 이상의 추상 메소드를 포함할 수 있습니다. 이러한 메소드는 하위 클래스에서 구현되어야 합니다.
- UML 표기법: UML 다이어그램에서, Generalization 관계는 하위 클래스에서 상위 클래스로 향하는 빈 화살표(삼각형 화살표)로 표현됩니다. 이 화살표는 일반적으로 하위에서 상위로의 상속을 나타내며, "is a" 관계를 설명합니다.
🎯 Generalization의 사용 예
예를 들어, "Shape"이라는 상위 클래스가 있고, "Square", "Rectangle", "Circle"라는 하위 클래스가 있다고 가정해봅시다. 여기서 " Shape" 클래스는 모든 도형이 공통적으로 갖는 속성과 메소드(예: 면적, 꼭지점 등)를 정의할 수 있고, 각 하위 클래스는 이를 상속받아 자신만의 특성을 추가로 정의할 수 있습니다.
Generalization은 시스템의 설계를 단순화하고 코드의 재사용을 극대화하는 중요한 방법으로, 객체 지향 설계의 핵심 요소 중 하나입니다. 이를 통해 개발자는 보다 깔끔하고 관리하기 쉬운 코드를 작성할 수 있습니다.

📘 Realization
UML (Unified Modeling Language)에서 Realization은 한 요소가 다른 요소의 사양이나 계약(인터페이스를 계약이라고도 함)을 구현할 때 사용되는 관계를 나타냅니다. 가장 흔히 인터페이스와 그 인터페이스를 구현하는 클래스 사이의 관계로 표현됩니다. 이 관계는 클래스가 인터페이스의 모든 메소드를 구현해야 함을 의미합니다.
⭐Realization의 주요 특징
- 인터페이스의 구현: Realization은 클래스가 인터페이스의 사양을 구현한다는 것을 나타냅니다. 인터페이스는 메소드의 시그니처만을 제공하고, 실제 메소드의 본체는 클래스에서 정의됩니다.
- 계약 준수: 클래스는 인터페이스에 정의된 모든 메소드를 구현해야 하며, 이는 클래스가 인터페이스가 요구하는 "계약"을 준수해야 함을 의미합니다.
- 다형성 지원: 인터페이스를 사용하면 다양한 클래스가 동일한 인터페이스를 구현할 수 있으므로, 다형성을 통해 코드의 유연성과 재사용성을 높일 수 있습니다. 이는 다양한 객체가 같은 인터페이스를 공유할 수 있으므로, 코드 내에서 객체를 교체하기 쉬워집니다.
- UML 표기법: UML 다이어그램에서, Realization 관계는 점선으로 된 화살표와 함께 화살표 끝에 빈 삼각형을 사용하여 표현됩니다. 화살표는 구현 클래스에서 인터페이스로 향합니다.
🎯 Realization의 사용 예
예를 들어, Vehicle라는 인터페이스가 start(), stop() 같은 메소드를 정의하고 있을 때, Car, Motorcycle, Bus 등 다양한 클래스가 이 Vehicle 인터페이스를 구현할 수 있습니다. 각 클래스는 start()와 stop() 메소드를 자신의 특성에 맞게 구현합니다. 이렇게 하면 Vehicle 인터페이스를 사용하는 코드는 어떤 특정 클래스의 객체가 사용되는지 몰라도 이 메소드들을 호출할 수 있습니다.
❗Realization의 중요성
- 유연성과 확장성: 인터페이스의 구현은 코드의 유연성을 높이고, 새로운 클래스가 시스템에 쉽게 추가될 수 있도록 합니다.
- 유지보수성: 인터페이스를 통해 시스템의 다양한 부분을 독립적으로 개발하고 수정할 수 있어 유지보수가 용이해집니다.
- 재사용성: 인터페이스를 구현하는 새로운 클래스를 만들 때 기존의 인터페이스를 재사용할 수 있으므로, 코드 중복을 줄이고 전체적인 프로젝트의 일관성을 유지할 수 있습니다.
이처럼 Realization은 객체 지향 설계의 중요한 부분으로, 클래스의 기능을 모듈화하고, 시스템의 다양한 구성 요소 간에 명확한 계약을 설정하여, 전체적인 시스템 설계의 품질을 향상시킵니다.

📘 Dependency
UML (Unified Modeling Language)에서 Dependency는 두 모델 요소 간의 관계를 나타내며, 한 요소가 다른 요소에 의존하는 경우 사용됩니다. 의존성은 주로 한 요소의 변경이 다른 요소에 영향을 줄 수 있음을 의미합니다. 이 관계는 일반적으로 임시적이거나 약한 결합을 나타내며, 변경의 전파 가능성을 표현합니다.
⭐Dependency의 주요 특징
- 약한 결합(Loose Coupling): Dependency는 시스템 내의 다른 요소들 사이의 약한 결합을 나타냅니다. 의존하는 요소는 의존 대상 요소 없이는 그 기능을 완전히 수행할 수 없습니다.
- 변경 전파: 한 요소가 변경될 때 의존하고 있는 다른 요소에도 영향을 미칠 수 있습니다. 예를 들어, 한 클래스가 다른 클래스의 메서드를 호출하면, 호출되는 클래스의 메서드에 변경이 생길 경우 호출하는 클래스도 영향을 받을 수 있습니다.
- 방향성: Dependency는 방향성을 가집니다. 이는 한 요소가 다른 요소에 의존한다는 것을 나타내며, UML 다이어그램에서는 점선 화살표로 표현됩니다. 화살표는 의존하는 요소에서 의존 받는 요소로 향합니다.
- 사용 시나리오: Dependency는 보통 다음과 같은 경우에 사용됩니다:
- 사용(Use): 한 클래스가 다른 클래스의 인스턴스를 사용하는 경우.
- 생성(Create): 한 클래스가 다른 클래스의 인스턴스를 생성하는 경우.
- 호출(Call): 한 클래스의 메서드가 다른 클래스의 메서드를 호출하는 경우.
- 파생(Derive): 한 요소의 값이 다른 요소의 값에 의해 파생되는 경우.
Dependency의 UML 표기법
UML 다이어그램에서 Dependency는 점선 화살표(---->)로 표현되며, 화살표 끝은 개방형 화살표로 되어 있습니다. 이는 다이어그램을 보는 사람에게 한 요소가 다른 요소의 구현이나 행동에 직접적으로 의존한다는 것을 명확하게 보여줍니다.
❗Dependency의 중요성
Dependency는 시스템 설계에서 중요한 요소 간의 관계를 명확히 하고, 시스템의 설계를 이해하며 리팩토링이나 확장시 결정을 내리는 데 중요한 역할을 합니다. 시스템의 유연성과 유지보수성을 높이기 위해 종종 의존성을 최소화하는 방향으로 설계를 고려합니다. 이런 관계를 명확하게 모델링하고 관리함으로써, 시스템 내의 요소들이 서로 어떻게 상호작용하는지, 그리고 어떤 요소가 시스템의 다른 부분에 어떤 영향을 미칠 수 있는지 이해할 수 있습니다.

📘 Aggregation
UML (Unified Modeling Language)에서 Aggregation(집합)은 특별한 형태의 연관 관계로, 전체-부분(whole-part) 관계를 나타냅니다. 이 관계는 한 객체가 다른 객체를 포함하지만, 포함되는 객체가 독립적인 생명주기를 갖는다는 것을 의미합니다. 즉, 전체 객체가 소멸해도 부분 객체는 그대로 존재할 수 있습니다.
⭐Aggregation의 주요 특징
- 전체와 부분의 관계: Aggregation은 객체 간에 전체와 부분의 관계를 나타내며, 이는 한 객체(전체)가 다른 하나 또는 여러 객체(부분)를 포함하는 것을 말합니다. 예를 들어, '도서관'과 '책' 사이에는 Aggregation 관계가 있을 수 있습니다. 도서관(전체)은 여러 책(부분)을 포함하지만, 책은 도서관이 없어도 존재할 수 있습니다.
- 독립적인 생명주기: Aggregation에서는 부분 객체가 전체 객체에 속해 있지만, 자신의 생명주기를 독립적으로 갖습니다. 이는 부분 객체가 전체 객체와 함께 생성되거나 소멸할 필요가 없다는 것을 의미합니다.
- 공유 가능성: Aggregation은 부분 객체가 여러 전체 객체에 공유될 수 있음을 나타낼 수 있습니다. 예를 들어, 한 프로그램 내의 여러 프로젝트가 동일한 데이터베이스 인스턴스를 사용할 수 있습니다.
- UML 표기법: UML 다이어그램에서 Aggregation은 점선 또는 실선과 함께 빈 다이아몬드로 표시되는 화살표로 나타냅니다. 화살표는 전체 객체에서 부분 객체로 향하며, 빈 다이아몬드는 전체 객체의 끝에 위치합니다.
⚔️ Aggregation vs. Composition
Aggregation과 자주 혼동되는 또 다른 연관 관계인 Composition도 전체-부분 관계를 나타내지만, Composition에서는 부분 객체가 전체 객체의 생명주기에 완전히 의존합니다. 즉, 전체 객체가 소멸하면 부분 객체도 함께 소멸합니다. 이와 대조적으로 Aggregation은 부분 객체가 전체 객체 없이도 독립적으로 존재할 수 있다는 점에서 차이가 있습니다.
🎯 예시
교육 기관과 학과의 관계를 예로 들 수 있습니다. 하나의 교육 기관(전체)은 여러 학과(부분)를 포함할 수 있습니다. 각 학과는 교육 기관에 속해 있지만, 교육 기관이 없어져도 학과는 다른 형태로 존재할 수 있습니다.
Aggregation은 시스템 설계에서 객체 간의 관계를 명확하게 정의하고, 객체의 구조와 상호작용을 효율적으로 관리하기 위해 중요한 모델링 도구입니다. 이를 통해 시스템의 설계자와 개발자는 객체들 간의 관계를 더 잘 이해하고, 시스템의 구조를 효과적으로 계획할 수 있습니다.



📘 Composition
UML (Unified Modeling Language)에서 Composition은 객체 간의 강한 전체-부분 관계를 나타냅니다. 이 관계는 Aggregation보다 강한 형태로, 부분 객체가 전체 객체의 생명주기와 완전히 종속되어 있음을 의미합니다. 즉, 전체 객체가 소멸하면 그와 연결된 부분 객체들도 함께 소멸합니다.
⭐Composition의 주요 특징
- 강한 전체-부분 관계: Composition은 전체 객체와 부분 객체 간에 강한 의존성을 나타냅니다. 부분 객체는 전체 객체에 속해 있으며, 전체 객체 없이는 존재할 수 없습니다.
- 독점적 소유: 전체 객체는 부분 객체를 독점적으로 소유합니다. 부분 객체는 다른 어떤 전체 객체와도 공유되지 않습니다.
- 생명주기의 종속성: 부분 객체의 생성과 소멸은 전체 객체의 생성과 소멸에 직접적으로 연결되어 있습니다. 이는 전체 객체가 관리하는 자원이나 구성 요소가 전체 객체와 동일한 생명주기를 갖는다는 것을 의미합니다.
- UML 표기법: UML 다이어그램에서 Composition은 실선과 함께 채워진 검은 다이아몬드로 표시되는 화살표로 나타냅니다. 화살표는 전체 객체에서 부분 객체로 향하며, 채워진 다이아몬드는 전체 객체의 끝에 위치합니다.
⚔️ Composition vs. Aggregation
Composition과 비교하여, Aggregation은 부분 객체가 전체 객체 없이도 독립적으로 존재할 수 있는 더 약한 형태의 전체-부분 관계를 나타냅니다. Aggregation에서는 부분 객체가 여러 전체 객체와 공유될 수도 있지만, Composition에서는 부분 객체가 전체 객체에 완전히 종속되며, 다른 어떤 객체와 공유되지 않습니다.
🎯 예시
예를 들어, "Orders"과 "Order_Details"의 관계를 생각해 볼 수 있습니다. 주문 객체가 생성될 때 주문 항목도 함께 생성되며, 주문 객체가 소멸하면 모든 주문 항목도 함께 소멸합니다. 이러한 관계는 주문 항목이 주문 없이는 의미가 없기 때문에 Composition으로 모델링하는 것이 적절합니다.
❗Composition의 중요성
Composition은 시스템 설계에서 전체 객체와 그에 속하는 부분 객체 간의 강력한 연결을 명확히 할 필요가 있을 때 사용됩니다. 이러한 모델링은 시스템의 구조적 무결성을 보장하고, 객체 관리와 자원 해제를 더욱 효과적으로 할 수 있게 도와줍니다. 시스템의 유지보수와 확장성에 중대한 영향을 미치며, 개발자가 객체 간의 관계를 더 명확하게 이해하고 정확히 구현할 수 있도록 합니다.



정적인 뷰[Static View]이란 클래스 다이어그램에서 사용되는 용어로, 애플리케이션의 구조와 구성 요소들이 어떻게 상호 연결되어 있는지를 시간에 따라 변하지 않는 방식으로 나타내는 것을 의미합니다. 즉, 시스템의 동작이나 프로세스의 흐름보다는 시스템을 구성하는 클래스들의 속성, 메소드, 상속 관계 등이 어떻게 구성되어 있는지를 보여주는 것입니다. 이 정적인 뷰는 시스템의 실행 상태나 동적인 행동을 나타내지 않고, 대신에 시스템의 설계와 아키텍처를 명확하게 파악할 수 있도록 돕습니다. 클래스 다이어그램은 객체 지향 프로그래밍에서 클래스 간의 관계와 각 클래스의 역할을 설명하는 데 주로 사용되며, 소프트웨어의 초기 설계 단계에서 중요한 역할을 합니다.
📘 Abstract Classes
추상 클래스의 표기법은 일반 클래스와 유사하지만 클래스 이름이 이탤릭체로 작성된다는 점이 다릅니다. 주어진 메서드에 대한 구현이 포함되어 있지 않기 때문에, 여러 객체와 함께 추상 클래스를 사용하는 것이 가장 좋습니다.
예를 들어, _displacement_라는 이름의 추상 클래스가 있고 그 안에 drive()라는 메서드가 선언되어 있다고 가정해 봅시다. 이제 이 추상 클래스 메소드는 자동차, 자전거, 스쿠터, 사이클 등 어떤 객체에 의해서든 구현될 수 있습니다.

📘 UML 다이어그램 예시
이 관계는 클래스가 인터페이스의 규약을 준수하며 해당 인터페이스에 정의된 모든 기능을 실제로 구현하겠다는 약속을 의미합니다. UML에서는 이를 위해 클래스와 인터페이스 사이에 실선과 빈 화살표를 사용하여 명확하게 나타냅니다.
How to draw a Class Diagram?
클래스 다이어그램은 소프트웨어 애플리케이션을 구축하는 데 가장 널리 사용됩니다. 이는 시스템의 정적인 뷰뿐만 아니라 애플리케이션의 모든 주요 측면을 대표합니다. 클래스 다이어그램의 컬렉션은 전체 시스템을 나타냅니다.
클래스 다이어그램을 그릴 때 염두에 두어야 할 몇 가지 주요 사항은 다음과 같습니다:
- 시스템의 완전한 측면을 설명하기 위해 클래스 다이어그램에 의미 있는 이름을 지정하는 것이 좋습니다.
- 객체와 그들의 관계는 사전에 인식되어야 합니다.
- 각 클래스의 속성과 메서드(책임)를 알아야 합니다.
- 원하지 않는 속성이 많으면 다이어그램이 복잡해지므로 원하는 속성의 최소한의 수를 지정해야 합니다.
- 개발자가 다이어그램의 측면을 설명할 필요가 있을 때 언제든지 메모를 사용할 수 있습니다.
- 최종 버전을 생성하기 전에 다이어그램을 여러 번 다시 그리고 수정해야 합니다.
Class Diagram Example
아래에 판매 주문 시스템을 설명하는 클래스 다이어그램이 제공됩니다.

이 UML 클래스 다이어그램은 다양한 클래스 간의 관계를 보여줍니다. 각 관계 유형과 이들이 의미하는 바를 상세히 설명하겠습니다:
1. Customer와 Order
- Multiplicity: 1 대 0..* (One-to-Many)
- Description: 하나의 고객(
Customer
)은 여러 개의 주문(Order
)을 가질 수 있습니다. 이는 고객이 여러 번 주문을 할 수 있다는 것을 나타냅니다. 주문은 특정 고객에게 속하며, 각 주문은 하나의 고객에게 연결됩니다.
2. Order와 OrderDetail
- Multiplicity: 1 대 1..* (One-to-Many)
- Description: 하나의 주문(
Order
)은 하나 이상의 주문 세부사항(OrderDetail
)을 포함할 수 있습니다. 이 관계는 주문이 여러 개의 주문 항목을 포함할 수 있음을 의미합니다. 각 주문 세부사항은 특정 주문에 연결되어 있습니다.
3. OrderDetail와 Item
- Multiplicity: 1 대 0..* (One-to-Many)
- Description: 하나의 주문 세부사항(
OrderDetail
)은 여러 개의 아이템(Item
)을 참조할 수 있습니다. 이는 각 주문 항목이 여러 개의 다른 상품을 포함할 수 있음을 나타냅니다. 각 아이템은 하나 이상의 주문 세부사항과 관련될 수 있습니다.
4. Order와 Payment
- Multiplicity: 1 대 1 (One-to-One)
- Description: 하나의 주문(
Order
)은 하나의 결제(Payment
)와 연결됩니다. 이는 각 주문이 단일 결제와 직접적으로 연결되어 있음을 나타냅니다.
5. Payment와 그 서브클래스 (Cash, Check, Credit)
- Generalization/Inheritance:
- Description:
Payment
클래스는Cash
,Check
,Credit
의 슈퍼클래스로서, 이는 결제가 현금, 수표 또는 신용카드를 통해 이루어질 수 있음을 나타냅니다. 각 서브클래스는 결제 방법의 특정한 구현을 제공합니다.
- Description:
이 다이어그램은 주문 시스템의 각 엔티티 간의 관계를 명확하게 보여주어, 어떻게 각 컴포넌트가 서로 상호작용하는지 이해하는 데 도움을 줍니다. 이러한 관계들은 객체 간의 데이터 흐름 및 의존성을 정의하며 시스템의 전체 구조를 설명합니다.