동적 모델링

[ 동적 모델링 ]

소프트웨어는 정적 뷰와 동적 뷰를 함께 가진다.

• 정적(Static): 시간이 지나도 변하지 않는 구조
  → 클래스/인터페이스/속성/클래스 간 관계(연관, 상속 등)
• 동적(Dynamic): 실행 중에 변하는 동작
  → 객체 간 상호작용, 호출 순서, 상태 변화

정적 모델링이 '뼈대(구조)'를 그리는 작업이라면,
동적 모델링은 '실행 중 실제로 어떻게 움직이는지'를 찍는 작업이다.
(프로그램 실행 장면을 사진으로 찍어 동작 변화를 추적한다고 보면 됨)

---

동적 다이어그램이 필요한 이유

클래스 다이어그램만 보면 '구조'는 보이지만,

• 어떤 객체가 먼저 호출되고
• 어떤 순서로 메시지가 오가며
• 어떤 조건에서 분기/반복이 발생하는지

같은 실행 흐름(런타임 동작)은 보이지 않는다.

그래서 동적 모델링은 정적 모델을 보완한다.

• 클래스 다이어그램: 정적 구조 모델링
• 상호작용 다이어그램: 런타임 동작 모델링
  → '객체가 어떻게 동작해 결과를 완성하는가' 를 보여줌

---

동적 모델링(상호작용 다이어그램)의 사용 목적 2가지

상호작용 다이어그램은

추상화 수준에 따라 두 레벨로 자주 쓰인다.

 

1) 시스템 전체 동작(유스케이스 레벨)

유스케이스를 실현하기 위해 필요한 비즈니스 수준

분석 클래스들이 어떻게 상호작용하는지 모델링한다.

→ '수강신청 유스케이스가 돌아가는 전체 흐름' 같은 것

 

2) 오퍼레이션(메서드 호출 레벨)

특정 오퍼레이션(메서드) 하나가 실행되는 동안
어떤 호출이 어떤 순서로 진행되는지 모델링한다.

→ 'register()가 실행되는 내부 호출 흐름' 같은 것

---

UML이 제공하는 상호작용 다이어그램 2가지

UML은 같은 의미를 두 방식으로 표현하게 해준다.

1. 시퀀스 다이어그램
   (Sequence Diagram)
2. 커뮤니케이션 다이어그램
   (Communication Diagram)

둘은 표현하는 의미는 동일하지만, 강조점이 다르다.

• 시퀀스 다이어그램: 메시지 순서(시간 흐름)가 한눈에 보임
• 커뮤니케이션 다이어그램: 객체 간 구조(링크)가 더 잘 보임

---

1. 시퀀스 다이어그램

시퀀스 다이어그램은 메시지 교환을 시간 축으로 표현한다.

• 세로축(Y): 시간 (위 → 아래로 흐름)
• 가로축(X): 참여 객체들(왼쪽 → 오른쪽 나열)
  ※ 배치 순서는 가독성 목적이고 “의미 있는 순서”는 아님

시퀀스 다이어그램의 핵심 구성 요소

1) 참여 객체(Participating Object)

객체는 보통 이런 형태로 적는다.

• 객체이름:클래스이름
• :클래스이름 (이름 없는 인스턴스)
• 객체이름: (클래스 아직 못 정했을 때)
• 객체 집합(리스트/배열 등) 형태
• <<stereotype>> (예: <<jsp>> LoginPage: 처럼 역할 표시)

객체 이름이 다른 곳에서 다시
언급될 필요가 없다면 클래스 이름만으로도 충분.

 

2) 라이프라인(Lifeline)

객체 아래에 그려지는 수직 점선.
→ 객체가 존재하는 기간을 의미한다.

 

3) 활성 막대(Activation Bar)

라이프라인 위의 얇은 직사각형 막대.
→ 해당 객체의 메서드가 실행 중인 시간을 의미한다.

• 호출이 중첩되면 활성 막대도 중첩되어 표시됨

4) 메시지(Message) & 리턴(Return)

• 메시지: 실선 화살표 (메서드 호출)
• 리턴: 점선 화살표 (생략 가능)

메시지에는 매개변수를 함께 적을 수 있다.
(핵심은 무엇이 전달되는가를 보여주는 것)

 

5) 객체 생성/소멸

• 생성: <<create>> 메시지로 생성 시점 표시
• 소멸: 라이프라인 끝에 X 표시

---

조건/반복 표현: 프레임(Frame)

시퀀스 다이어그램에서 모든 상호작용을 표현하려면
조건 분기와 반복을 표시해야 한다.

 

- alt: 조건 분기

alt [조건] 형태로 조건이 참일 때
실행되는 메시지 묶음 표현

 

- loop: 반복

loop [반복 조건] 형태로 반복 호출 묶음 표현

---

시퀀스 다이어그램 작성 과정(3-Step)

시퀀스 다이어그램은 유스케이스 이벤트 흐름을

객체 메시지 교환으로 바꾸는 작업이다.

 

Step 1) 참여 객체 파악

유스케이스의 상세 이벤트를 읽고
상호작용에 참여하는 객체를 찾는다.

 

Step 2) 객체 배치(왼쪽→오른쪽)

배치 원칙이 있다.

• UI 객체(경계/Boundary): 맨 왼쪽
• 제어 객체(Control): 가운데 (비즈니스 흐름 담당)
• 엔티티(Entity): 오른쪽 (데이터/저장 담당)

Step 3) 이벤트 순서대로 메시지 연결

액터 → UI → Control → Entity 순으로
메시지 호출을 위에서 아래로 쌓아간다.

---

사례: 수강신청 유스케이스 흐름

수강신청 유스케이스를 시퀀스로 보면

보통 이런 메시지가 들어간다.

1. 학생이 UI에서 신청 과목 선택
2. Control이 CourseSection에 등록 가능 여부 요청
3. 선수과목 확인을 위한 메시지 포함
4. 조건 통과 시 Registration 생성
5. Registration을 Student / CourseSection에 연결하면 완료

이런 식으로 유스케이스의 문장이
객체 간 메시지 호출로 바뀌는 것이 포인트다.

---

클래스 다이어그램과 반드시 연결되어야 함

시퀀스 다이어그램에서 어떤 메시지 호출이 나오면:

• 그 메시지는 호출 대상 클래스의
  오퍼레이션으로 존재해야 하고
• 메시지를 보내려면 두 클래스 사이에
  연관(또는 접근 경로)이 있어야 한다

즉,

시퀀스 다이어그램에서 발견된 메시지/관계는
클래스 다이어그램에도 반영되어야 한다.

---

2. 커뮤니케이션 다이어그램

커뮤니케이션 다이어그램은 기능적으로

시퀀스 다이어그램과 동일하지만,

객체 간 정적 구조(링크)를 더 잘 보여준다.

 

구성은 다음 두 개의 조합이다.

1. 객체 다이어그램 + 객체 간 링크(연결 인스턴스)
2. 그 링크 위로 오가는 메시지

메시지 순서 표현 방식의 차이

• 시퀀스: 위→아래 위치가 순서
• 커뮤니케이션: 메시지 앞의 번호(십진수)가 순서

예: 2.3.4
→ 2.3 메시지 안에서 발생한
→ 4번째 하위 호출이라는 중첩 구조를 의미

 

정리하면

• 시퀀스 = 순서가 직관적 (시간 흐름)
• 커뮤니케이션 = 구조가 직관적 (링크 관계)

---

3. 상태 다이어그램(State Diagram)

상태 다이어그램은 시스템/객체의 동작을
이벤트(외부 자극)와 상태 전환으로 모델링한다.

예를 들어 도서관 시스템의 “책”은

• 대출됨
• 반납됨
• 연체됨

같은 상태를 이동한다.
이 이동 경로를 보여주는 게 상태 다이어그램이다.

---

상태 다이어그램의 핵심 요소

• 초기 상태: 시작점(●)
• 상태(State): 둥근 사각형
• 전환(Transition): 화살표
• 최종 상태: 종료점(◎ 또는 끝 표시)

전환(Transition)은 보통 이런 형태로 레이블을 단다.

이벤트(e) [가드조건(exp)] / 액션(a1, a2)

 

의미

• 이벤트가 발생하고
• 가드조건이 참이면
• 전환이 일어나며
• 액션이 수행된다

---

상태 모델링할 때 던져야 하는 질문 3가지

• 어떤 외부 자극(이벤트)이 중요한가?
• 상태에 따라 객체 반응이 어떻게 달라지는가?
• 상태를 판단하는 조건(속성 조건)은 무엇인가?

상태 다이어그램은 결국
어떤 상태에서 어떤 이벤트로 인해

어떤 상태로 바뀌는가가 핵심이다.

---

마무리 정리

정적 모델링이 구조(뼈대)라면
동적 모델링은 실행 흐름(움직임)이다.

• 클래스 다이어그램으로는 흐름이 안 보인다
• 그래서 시퀀스/커뮤니케이션/상태 다이어그램이 필요하다

그리고 제일 중요한 연결 규칙

동적 다이어그램에서 발견된 메시지/관계는
정적 클래스 다이어그램에도 반영되어야 한다.