[Java] 객체지향 프로그래밍(OOP) - 2. 모델(Model)이란? 모델링, UML, 클래스 다이어그램, 시퀀스 다이어그램 알아보기

 

모델링 (Modeling)

💡 모델의 역할

모델링은 현실 세계의 시스템을 이해하고, 이를 표현하기 위해 사용되는 추상화(Abstraction) 과정이다.
즉, 복잡한 현실을 단순화하여 표현함으로써 시스템의 구조와 동작을 명확히 파악할 수 있다.

 

- 서로의 해석을 공유해 합의를 이루거나 해석의 타당성을 검토

- 현새 System or 추후 개발할 System의 원하는 모습을 가시화

- System의 구조 + 행위 명세 (틀 제공)

 

- 추상화(관련이 있는 점 부각, 관련 없는 것 무시)에 바탕을 두고 있다.

 

 

모델의 주요 역할

1. 해석의 공유와 합의
   • 개발자, 기획자, 디자이너 등 이해관계자들이 동일한 관점에서 시스템을 바라볼 수 있게 한다.
2. 시스템의 가시화
   • 현재 또는 미래의 시스템 구조를 시각적으로 표현하여 이해를 돕는다.
3. 명세화(Specification)
   • 시스템의 구조 및 행위를 구체적으로 기술한다.
4. 구축의 틀 제공
   • 모델은 시스템을 실제로 구현하기 위한 청사진(설계도) 역할을 한다.

🔹 요약: 모델은 ‘현실의 복잡성을 단순화한 표현’이며, 시스템 개발의 공통 언어다.

 

---

---

 

UML 다이어그램

대표적인 시스템 모델링 언어

UML (Unified Modeling Language)

UML이란?

• UML은 객체지향 시스템을 시각화하고 명세화하기 위한 표준화된 모델링 언어이다.
• 1990년대에 Grady Booch, James Rumbaugh, Ivar Jacobson이 각각의 방법론(OOAD, OMT, OOSE)을 통합하여 만들었다.
• 현재는 UML 2.5가 대표적인 표준이다.

UML의 목적

• 시스템의 구조와 행위를 시각적으로 표현
• 객체 간 관계 및 상호작용을 명확히 정의
• 개발자 간의 의사소통 도구로 활용

 

UML 다이어그램의 종류

분류	다이어그램 유형	목적
구조 다이어그램 (structure diagram)	클래스 다이어그램 (class diagram)	시스템을 구성하는 클래스들 사이의 관계를 표현한다.
	객체 다이어그램 (object diagram)	객체 정보를 보여준다.
	복합체 구조 다이어그램 (composite structure diagram)	복합 구조의 클래스와 컴포넌트 내부 구조를 표현한다.
	배치 다이어그램 (deployment diagram)	소프트웨어, 하드웨어, 네트워크를 포함한 실행 시스템의 물리 구조를 표현한다.
	컴포넌트 다이어그램 (component diagram)	컴포넌트 구조 사이의 관계를 표현한다.
	패키지 다이어그램 (package diagram)	클래스나 유즈 케이스 등을 포함한 여러 모델 요소를 그룹화해 패키지를 구성하고, 패키지들 사이의 관계를 표현한다.
행위 다이어그램 (behavior diagram)	활동 다이어그램 (activity diagram)	업무 처리 과정이나 연산이 수행되는 과정을 표현한다.
	상태 머신 다이어그램 (state machine diagram)	객체의 생명주기를 표현한다.
	유즈 케이스 다이어그램 (use case diagram)	사용자 관점에서 시스템 행위를 표현한다.
	상호작용 다이어그램 - 순차 다이어그램 (interaction diagram - sequence diagram)	시간 흐름에 따른 객체 사이의 상호작용을 표현한다.
	상호작용 다이어그램 - 상호작용 개요 다이어그램 (interaction diagram - interaction overview diagram)	여러 상호작용 다이어그램 사이의 제어 흐름을 표현한다.
	상호작용 다이어그램 - 통신 다이어그램 (interaction diagram - communication diagram)	객체 사이의 관계를 중심으로 상호작용을 표현한다.
	상호작용 다이어그램 - 타이밍 다이어그램 (interaction diagram - timing diagram)	객체 상태 변화와 시간 제약을 명시적으로 표현한다.

 

---

클래스 다이어그램 (Class Diagram)

정의

클래스 다이어그램은 시스템의 정적인 구조(Static Structure)를 표현하는 다이어그램이다.
즉, 시스템을 구성하는 클래스, 그 속성, 연산(메서드), 그리고 클래스 간의 관계를 나타낸다.

🧠 정적 구조란?
시간에 따라 변하지 않는 시스템의 기본 구성 요소와 그 관계를 의미한다.

 

- System의 "정적"인 구조 표현

- 시간에 따라 변하지 않는다

- Class와 그들 간의 관계 표현

 

※ Class 1) 동일 속성을 가지고 동일 행위를 수행하는 object의 집합 2) object를 생성하는 설계도

 

클래스의 개념

• 동일한 속성과 행위를 가진 객체들의 집합
• 객체를 생성하기 위한 설계도(Blueprint) 역할을 한다.

UML에서의 클래스 표현

UML에서는 클래스를 다음과 같은 3구역 박스(Box)로 표현한다.

가장 윗 부분(상단)	클래스 이름 (Class Name)	학생
중간 부분 (중단)	속성 (변수, 데이터) (Attributes)	- 이름 - 전공 - 학번 - 과목	속성은 그 객체마다 특정 값을 갖고 있다. - type : string, integer, float, Boolean - operation의 signature
마지막 부분 (하단)	연산 (메서드, 기능) (Operations)	+수강하다()

 

접근 제어자 : public, private, protected, package

실용적으로 클래스 표기하는 법

: 실제로는 속성과 operation을 모두 적지 않아도 상관 없다.

 

예시 :

┌─────────────────────┐
│ Student             │
├─────────────────────┤
│ -name : String      │
│ -studentId : int    │
├─────────────────────┤
│ +registerCourse()   │
│ +viewGrades()       │
└─────────────────────┘

접근제어자 표기법

+	public (공개)
-	private (비공개)
#	protected (상속 허용)

실제 UML 다이어그램에서는 모든 속성과 연산을 명시하지 않아도 된다.
시스템 이해에 필요한 핵심 정보만 표현해도 충분하다.

---

클래스 간 관계 (Relationships)

객체지향 시스템은 단일 클래스가 아닌, 여러 클래스가 상호작용하여 동작한다.
따라서 클래스 간의 관계를 올바르게 표현하는 것이 중요하다.

 

객체지향 system은 상호 관계를 맺는 여러 클래스에서 생성된 객체들이 기능을 수행한다.

 

No.	관계	설명
1	연관 관계 (association)	- 클래스들이 개념상 서로 연결되었음을 나타낸다. - 연관된 클래스 상에 실선이나 화살표를 그어 표시하며,보통은 한 클래스가 다른 클래스에서 제공하는 기능을 사용하는 상황일 때 표현한다. - 연관 관계 이름    두 클래스 상이의 관계가 명확한 경우 이름을 사용하지 않아도 된다. - 연관 관계에서 각 Class Object(객체)의 역할 (이름)    클래스 바로 옆 연관 관계를 나타내는 선 가까이에 기술한다.   👉 역할 이름은 연관된 class의 object들이 서로를 참조할 수 있는 속성의 이름으로 활용한다.         = 객체가 서로를 가리키는 참조 field(속성) 이름으로 그대로 쓴다. - 다중성 (multiplicity)  한 객체가 반대편 객체를 몇 개까지 가질 수 있는지  연간 관계의 Class Object의 역할 이름과 겹치지 않게 마찬가지로 선 가까이에 표기한다. 하단에 위의 표를 보강하여 작성하였음. - 연관 클래스 (Association Class)   연관 관계에 추가할 속성이나 행위가 있을 때 사용.    예: “성적(Grade)”은 Student와 Course 간의 연관 자체에 존재하는 정보이다. 사건 이력(event history) 표현,  ?? - 재귀적 연관 관계 (Recursive Association)   동일한 클래스에 속한 객체들 사이의 연관 관계   예: 직원(Employee) 클래스가 상위 관리자와 하위 직원을 표현할 때.   역할을 클래스로 할 떄 문제가 발생 ??
2	일반화 관계 (generalization)	객체지향 개념의 상속 관계다. 한 클래스가 다른 클래스를 포함하는 상위 개념일 때의 IS-A 관계를 UML에서는 일반화 관계로 모델링하며, 속이 빈 화살표로 표시한다. - 상위 클래스의 속성과 연산을 하위 클래스가 물려받는다. - "is a kind of" 관계로 해석된다. 예 : 가전제품(상위) - 세탁기, TV, 식기세척기(하위)
3	집합 관계 (composition, aggregation)	클래스들 사이의 전체-부분(Part-Whole) 관계를 나타낸다. 집약(aggregation) 관계와 합성(composition) 관계가 존재한다.
4	의존 관계 (dependency)	한 클래스가 다른 클래스의 기능을 잠깐 사용하는 관계를 나타낸다. 연관과 비슷하지만 보통 한 메서드 실행 동안만 유지되는 매우 짧은 수명이며, 점선 화살표로 표시한다.
5	실체화 관계 (realization)	인터페이스의 책임들을 실제로 구현한 클래스와의 관계를 나타낸다. 상속과 유사하지만 빈 삼각형 머리에 점선을 사용해 표시한다.

 

+) 연관 관계

  👉 역할 이름은 연관된 class의 object들이 서로를 참조할 수 있는 속성의 이름으로 활용한다.
        = 객체가 서로를 가리키는 참조 field(속성) 이름으로 그대로 쓴다.

의 예시

 

class Customer {
    // 역할 이름 orders → 다중성 0..* → 컬렉션 타입
    private final List<Order> orders = new ArrayList<>();
}

class Order {
    // 역할 이름 customer → 다중성 1 → 단일 참조
    private Customer customer;
}

 

 

표 1-5 다중성 표시 (보완한 버전)

다중성 표기	의미(범위)	관계	읽는 법	예시
1	정확히 1	A(1) — B(1) = 1⟷1	사용자 1명은 프로필 1개를 가진다	필수 단일 관계
0..1	0 또는 1	A(1) — B(0..1) = 1⟷0..1	사용자 1명은 추천인이 없을 수도/있을 수도 있다	선택적 단일(optional)
* 또는 0..*	0 이상, 상한 없음	A(1) — B(0..) = 1⟷	사용자 1명은 주문을 0개 이상 가진다	상한 미정 시 보통 ‘*’ 사용
1..*	1 이상, 상한 없음	A(1) — B(1..) = 1⟷1..	주문 1건은 주문항목을 최소 1개 이상 가져야 한다	“최소 1개” 강제
n	정확히 n개	A(1) — B(n)	삼인방 1개는 참가자 정확히 3명을 가진다	고정 카디널리티
m..n	m 이상 n 이하	A(1) — B(m..n)	팀 1개는 팀원을 2~5명 가진다	범위 제약
값 집합 예: 1, 2, 6	명시된 값 중 하나	A(1) — B(1,2,6)	패키지 1개는 아이템을 1개/2개/6개만 담을 수 있다	불연속 허용(표준 표기 확장)
혼합 예: 1, 3..5	1 또는 3~5개	A(1) — B(1,3..5)	행사 1개는 좌석을 1개 또는 3~5개 예약한다	불연속+구간 혼합(표준 표기 확장)

끝단 조합으로 읽는 법 요약

• 1 — 1: 일대일(One-to-One)
• 1 — *: 일대다(One-to-Many)
• * — 1: 다대일(Many-to-One)
• *— *: 다대다(Many-to-Many)

사용 팁

• 다중성은 “양 끝”에 각각 표기한다. 예: 주문(1) — (1..*) 주문항목.
• “*”는 상한 무한을 뜻한다. 상한이 있으면 정수나 구간으로 명시하자.
• 모델 제약을 엄밀히 전달해야 하면 m..n 또는 값 집합 표기를 활용한다.

다중성에 따라 구현 타입이 달라진다.

1 -> 단일 참조 (Customertype)

0..1 -> Optional or nullable

 

0..* -> List 등 Collection

1..* -> List<...> + "비어 있지 않음" 제약

 

---

 

여기서부터 봐야됨

 

 

5️⃣ 집합 관계 (Aggregation / Composition)

구분의미생명주기UML 표기

Aggregation (집약)	전체와 부분의 관계, 부분이 독립적	독립적	빈 마름모(◇)
Composition (합성)	전체가 사라지면 부분도 사라짐	종속적	채워진 마름모(◆)

예시:

 

Company ◇── Employee (집약) House ◆── Room (합성)

---

6️⃣ 의존 관계 (Dependency)

• 한 클래스가 다른 클래스를 잠시 사용하는 관계(임시적 관계)
• 예: 메서드의 매개변수, 지역 변수로 참조될 때
• UML에서 점선 화살표(→) 로 표현

예시:

 

Order → PaymentProcessor

---

7️⃣ 인터페이스와 실체화 관계 (Interface & Realization)

• 인터페이스는 특정 기능의 “책임”을 정의한 추상적 개념이다.
• 실체화(Realization) 관계는 인터페이스의 기능을 실제로 구현한 클래스를 나타낸다.
• “can do this” 관계로 해석된다.

예시:

 

interface RemoteControl { void powerOn(); void powerOff(); } class Television implements RemoteControl { ... }

---

시퀀스 다이어그램 (Sequence diagram)

개념

시퀀스 다이어그램은 객체들이 시간의 흐름에 따라 메시지를 주고받는 과정을 표현한다.
즉, **시스템의 동적인 행위(Behavior)**를 시각화하는 다이어그램이다.

 

❖ 객체들이 어떻게 교류하는지 보여줌
- Dimension - time
❖ 객체, 실선 화살표로 그려지는 메시지 그리고 수직 진
행 상황을 나타내는 시간으로 구성되어 있다.

- 객체

❖생명선(lifeline) - 각 객체로부터 아래로 뻗어가는 쇄선 ❖실행(activation) - 객체가 수행하는 오퍼레이션

- 메시지

호출(call) 메시지 - 수신 객체가 오퍼레이션을 수행할 때까지 송신 객체는 기다리고 있다.  - 호출 메시지와 답신 메시지

- 시간

수직 방향으로 나타낸다

구성 요소

요소설명

객체(Object)	다이어그램 상단에 위치, 이름 아래에 수직선 표시
생명선(Lifeline)	객체의 존재 기간을 나타내는 점선
활성 구간(Activation)	객체가 작업을 수행하는 구간 (직사각형 블록)
메시지(Message)	객체 간 호출 또는 반환을 나타내는 화살표
시간(Time)	위에서 아래로 흐르는 시간의 진행

---

예시

자동차 키로 자동차 잠금 기능을 수행하는 시나리오

1. CarOwner가 CarKey의 lock() 메서드를 호출한다.
2. CarKey는 Car의 lockDoor() 메서드를 실행한다.
3. Car는 문을 잠그고, 라이트를 깜박이며, 경적 소리를 낸다.

시퀀스 다이어그램:

CarOwner → CarKey : lock()
CarKey → Car : lockDoor()
Car → Car : blinkLight()
Car → Car : beepSound()

---

🔍 핵심 요약

구분내용

모델링	시스템의 구조와 동작을 추상화하여 표현하는 과정
UML	객체지향 시스템을 시각화하고 명세화하는 표준 언어
클래스 다이어그램	시스템의 정적 구조를 표현
시퀀스 다이어그램	객체 간 메시지 교환의 순서를 표현
관계의 종류	연관, 일반화, 집약, 합성, 의존, 실체화 등

---