-
[Software Engineering] Behavioral Modeling: 시스템의 내부 동작과 객체 협력 이해하기CS/Software Engineering 2025. 10. 27. 18:20
오늘은 Behavioral Modeling, 즉 시스템 내부의 동작과 객체 간 협력 관계를 모델링하는 방법을 살펴본다. 이 모델은 단순히 "무엇을 하는가"가 아니라, 시스템 내부의 객체들이 어떻게 협력하고 변화하는가를 보여주는 데 초점을 맞춘다.
Introduction
Behavioral Model은 시스템 내부의 동작을 설명한다. 즉, 외부에서 보이는 기능이 아니라 내부 객체들이 서로 어떻게 협력하고 상태가 변하는지를 보여주는 모델이다.
주요 유형
Behavioral Model은 크게 두 가지로 나눌 수 있다.
- 첫째, Interaction Diagram은 Use Case로 식별된 프로세스의 내부 논리를 표현하며, 객체 간 메시지 교환을 보여준다.
- 둘째, State Machine은 시간의 흐름에 따라 객체의 상태가 어떻게 변화하는지를 시각화한다.
핵심: 시스템의 동적 관점(dynamic view) 을 표현하며, 구현 세부보다는 행동의 흐름에 초점을 둔다.
1. Interaction Diagrams
Interaction Diagram은 객체들이 메시지를 주고받으며 Use Case의 흐름을 실현하는 과정을 표현한다. 즉, "시스템이 실제로 Use Case를 내부적으로 어떻게 실행하는가"를 보여주는 동적 모델이다.
- Sequence Diagram: 메시지의 순서(sequence) 에 초점
- Communication Diagram: 메시지의 흐름(flow) 에 초점
기본 구성요소
- Objects: 클래스의 인스턴스(instantiation of a class)
→ 모델링의 중심 - Attributes: 클래스의 속성(characteristics)
- Operations: 클래스가 수행할 수 있는 동작(behaviors or actions)
- Messages: 객체 간 동작을 요청하는 정보
→ 한 객체에서 다른 객체로의 함수 호출(function call)
Sequence Diagrams
- 단일 Use Case 안에서 참여하는 객체들(objects)을 보여준다.
- Dynamic Model:
- 객체 간 전달되는 메시지의 순서(sequence)를 표현
- 복잡한 Use Case나 실시간 시스템(real-time specifications)의 이해를 돕는다.
- Generic Sequence Diagram: Use Case의 가능한 모든 시나리오 표현
- Instance Sequence Diagram: 한 가지 구체적인 시나리오 표현


Sequence Diagram Syntax
이제 Sequence Diagram을 구성하는 주요 요소를 살펴보자. 아래 표는 UML 표기법 기준으로 각 구성요소가 어떤 역할을 하는지를 정리한 것이다.
Actors 모델링되는 시스템과 상호작용하는 외부 엔티티 (external entities that interact with the system) Objects 상호작용에 참여하는 클래스의 인스턴스 (instances of classes that participate in the interaction) Lifelines 상호작용 중 객체가 존재하는 시간 (existence of an object over time) Execution Occurrence / Activation Box 객체가 활성 상태(메시지 송·수신 및 연산 수행)인 기간 Messages 한 객체에서 다른 객체로 전달되는 정보 Guard Conditions 메시지 전송이 일어나기 위한 조건 Object Destruction 객체가 소멸되었음을 나타냄 Frame 다이어그램의 문맥(context) 또는 조건(scope)을 명시 Object Destruction Example
이러한 구성요소를 실제 상황에 적용하면 다음과 같다. 아래 예시는 주문 처리 과정에서 객체의 생성과 소멸을 보여주는 간단한 시나리오이다.

Actors: Customer
Objects: Order, PaymentGateway- Customer가 주문을 제출한다.
- 시스템은 주문을 처리하고 Payment Gateway에 결제 요청을 보낸다.
- Payment Gateway는 결제 결과를 반환한다.
- 주문이 완료되면, Order 객체는 더 이상 필요 없으므로 소멸된다.
Referencing included Use Cases
→ 다른 Use Case를 참조할 수 있다.

Guidelines for Creating Sequence Diagrams
- 메시지는 위에서 아래, 왼쪽에서 오른쪽으로 순서화
- 동일한 의미를 가진 object와 Name actor는 일관되게 유지
- 시나리오의 시작자(Initiator) 는 왼쪽에 배치
- 동일 클래스의 여러 객체는 이름으로 구분
- Return value는 명확하지 않은 경우에만 표시
→ 예: return_val := message(args) - 메시지 이름은 화살표 끝(arrowhead) 근처에 작성하여 가독성 향상
Building Sequence Diagrams
- Context 설정
→ 어떤 Use Case, 어떤 시나리오인지 정의 - Actors 및 Objects 식별
→ Use Case 시나리오에 참여하는 모든 주체 - Lifeline 추가
→ 각 객체가 존재하는 시간 축을 점선으로 그림 - Messages 추가
→ 객체 간 전달되는 메시지와 파라미터 표현
→ Return 값은 명백할 경우 생략 - Execution Occurrence 추가
- Validation 수행
→ 프로세스의 모든 단계를 빠짐없이 표현했는지 확인
Functional → Behavioral Modeling 예시
예시: Library Book Borrowing System
- Flow of Events
- Borrower가 Librarian에게 책과 ID카드를 제시
- Librarian이 ID카드를 검증 (학생/교직원/게스트 DB 확인)
- Librarian이 Borrower의 Overdue 및 Fines 확인
- 조건이 충족되면 Checkout 처리


- Activity Diagram
- Validate ID → Check Overdue/Fines → Check Out Books
- [Valid Card], [No Overdue Books & No Fines] 등 조건 사용

- Sequence Diagram
- Student → Librarian: CheckOutBooks()
- Librarian → Registrar’s DB: ValidID()
- Librarian → BookCollection: FindBook()
CRUDE Analysis
CRUDE = Create, Read (or Refer), Update, Delete, Execute
- 객체 간 상호작용을 분석하기 위한 매트릭스 기법
- 각 셀은 행:열 관계를 나타내며,
한 클래스(또는 Actor)가 다른 클래스에 수행하는 작업을 의미함

- CRUDE 분석을 통해 각 객체의 상호작용 빈도와 역할을 파악할 수 있다. 특히 Create, Update, Delete가 많은 클래스일수록 복잡한 생명주기를 가지므로, 이들은 이후 단계에서 State Machine으로 세밀하게 모델링할 후보가 된다.
Why Behavioral Modeling Is Iterative
Campus Housing System & CRUDE Analysis Example
소프트웨어 분석 과정에서 Behavioral Modeling(행위적 모델링) 은 한 번에 끝나는 일이 거의 없다. 그 이유는 모델을 구체화하는 과정에서 새로운 객체나 Actor의 존재가 드러나기 때문이다. 이를 잘 보여주는 예시가 바로 Campus Housing System이다.

이 매트릭스는 각 Actor와 클래스 간의 상호작용을 정리한 것이다.
- Owner → Apartment Class: Create, Delete
- Student → Apartment / Owner Class: Read
일단 첫번째 표에서 C(생성)부분 없이 R(읽기)부분만 있으면 뭐가 잘못되었다고 인지해야한다.
CRUDE 분석을 진행하면서 "Staff Member" 라는 새로운 역할이 필요함을 발견했다. 건물주 대신 등록을 담당하거나, 관리자가 직접 삭제를 수행할 수도 있기 때문이다.
Iterative Process
이 예시가 보여주는 핵심은 바로 이것이다.
"모델링은 한 번에 완성되지 않는다." CRUDE, Sequence Diagram, State Machine 등 세부 모델을 작성하다 보면 새로운 관계나 객체가 드러나고, 이전 모델을 다시 수정하게 된다.
이 과정을 반복하면서 모델은 점점 현실에 가까워진다. 그래서 Behavioral Modeling은 Iterative(반복적)이다.

위의 예시에서 CRUDE가 없으면 현재의 시스템에서는 쓸모가 없는 거 일 수 있다.
다음으로 Behavioral State Machine을 살펴보자.
Behavioral State Machines
특징
- 주로 복잡한 객체(Complex Objects) 에 사용
- 객체는 이벤트에 따라 상태(State)가 변함
- 단일 객체가 수명주기 동안 거치는 상태 변화를 표현 (하나의 object에 대해 그려짐)
- 각 상태는 객체의 속성 값 및 다른 객체와의 관계 로 정의됨
예시: Patient 상태
- New Patient → 아직 진료받지 않음
- Current Patient → 현재 진료 중
- Former Patient → 진료 종료
구성요소
States 객체의 속성과 관계의 특정 시점 상태 Events 객체의 상태 변화를 유발하는 사건 Transitions 한 상태에서 다른 상태로의 이동 Guard Conditions transition이 허용되기 위한 Boolean 조건식 
State Machine 예시

- 나가는 transition이 없이 계속 머무는 blackhole, 연관관계 없이 일어날 수 없는 miracle을 주의해야한다.
States vs Subclasses
- Freshman, Sophomore, Junior, Senior 는 Undergraduate의 하위 클래스(subclass) 인가, 아니면 하나의 객체가 거치는 상태(state) 인가?
→ 상태(state)이다.
Undergraduate 객체는 수명 동안 여러 상태를 거치기 때문이다.

Guidelines for Behavioral State Machines
- 복잡한 객체에만 사용
- 초기 상태: 왼쪽 위 / 최종 상태: 오른쪽 아래
- 상태 이름은 간결하고 설명적으로
- Black hole(진입만 있고 탈출 없음) / Miracle(이유 없는 발생) 금지
- Guard 조건은 상호 배타적(mutually exclusive)
- 모든 전이는 message나 operation과 연결되어야 함
Building State Machine
- Context 설정
→ 어떤 객체를 모델링할지 결정 - States 식별 (Initial / Final / Stable)
- Layout 구성
→ 좌→우로 자연스러운 순서 배치 - Transitions 추가
- Trigger (이벤트)
- Action (전이 결과로 수행)
- Guard Condition (조건)
- Validation
→ 모든 상태가 도달 가능해야 함
Verifying & Validating Behavioral Models
- 모든 Actor 는 모델 간 일관되어야 함
- CRUDE 매트릭스의 각 항목은 실제 메시지 전송을 의미
- C/U/D 항목이 존재하면 → State Transition과 연결되어야 함
- 모든 상태 전이는 Sequence Diagram의 메시지와 일치해야 함
정리
Behavioral Models Use Case를 지원하는 객체 간 협력을 자세히 표현 Interaction Diagrams Sequence Diagram을 통해 객체 간 메시지 흐름 표현 Behavioral State Machines 복잡한 객체의 상태 변화를 시간에 따라 표현 Verification & Validation 모델의 완전성과 일관성을 보장 출처: 경북대학교 손정주 교수님, “소프트웨어설계” 강의 자료
'CS > Software Engineering' 카테고리의 다른 글