정적 모델링

요구 모델링에서 정적 모델링(Static Modeling)은

시간 흐름보다 구조에 집중한다.

즉, 시스템을 구성하는

도메인 개념(클래스)이 무엇이고,

그들 사이의 관계(연관/포함/상속 등)가

어떻게 연결되는지를 그림으로 정리하는 작업이다.

 

UML에서 정적 모델링의 대표 도구는

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

---

정적 모델링이 중요한 이유

클래스 다이어그램은 단순히

개발 문서용 그림이 아니라,

 

1. 우리가 만드는 시스템에서
   핵심 개념(명사)이 무엇인지 합의하고
2. 각 개념이 가진 속성/행동(데이터/기능)을 정리하고
3. 개념들 사이의 관계(소유/포함/의존/상속)를
   구조적으로 고정하는

일종의 도메인 지도 역할을 한다.

즉, 구현 전에 우리가 같은 시스템을

보고 있는지를 맞추는 장치다.

---

분류(Classification): 클래스가 만들어지는 방식

클래스 다이어그램을 그리는 과정은 결국 '개념화'다.
그중 핵심이 분류(classification)인데, 방향이 두 가지가 있다.

 

1. 확장형(Extensional)
여러 개별 사례를 관찰 → 공통점을 뽑아 → 클래스로 묶기

예: TV1, TV2, TV3를 보니 공통으로 채널/볼륨이 있다 → TV 클래스

 

2. 집중형(Intentional)
'TV란 무엇인가?'를 내부 속성/행동으로 정의 → 그 정의를 개별 사례에 적용

예: TV는 채널을 바꾸고 볼륨을 조절한다 → 그 속성과 동작으로 TV를 정의

 

현업에서는 보통 두 방식을 섞어서 간다.
(처음엔 확장형으로 후보를 뽑고, 이후 집중형으로 정의를 다듬는 느낌)

---

객체지향 기본 개념 (정적 모델링의 기반)

클래스 다이어그램은 객체지향의 구조를

시각화하는 도구라서, 아래 개념이 바닥에 깔린다.

 

1) 객체(Object)와 클래스(Class)

• 객체: 상태(속성값) + 동작 + 고유 식별자를 가진 '실체'
• 클래스: 공통 속성과 동작을 공유하는 객체들의 설계도(정의)

예시로 보면 감이 빠르다.

• TV 객체의 상태
  : 채널, 볼륨 (속성값으로 상태가 결정됨)
• TV 객체의 동작
  : 채널변경(), 볼륨조절()
• TV 클래스
  : 모든 TV 객체가 공통으로 가져야 할 속성과 동작 정의

2) 속성(Attribute)과 오퍼레이션(Operation)

• 속성: 객체가 가지는 데이터(상태를 이루는 값)
• 오퍼레이션: 객체가 수행할 수 있는 행동(메서드 관점의 기능)

 

포인트: '변수'는 값을 보관하지만, 스스로 행동하진 못한다.
반면 '객체'는 데이터(속성)와 행동(오퍼레이션)이 함께 묶여 있다.

 

 

3) 캡슐화(Encapsulation) & 정보 은닉(Information Hiding)

캡슐화는 연관된 데이터+기능을 하나로 묶어서 덩어리로 다루는 것이다.

• 학생(학번/이름/주소) + 학생 관련 기능(주소변경/수강신청/평점계산)
  → 따로 흩어놓기보다 Student라는 캡슐로 묶는 게 자연스럽다.

그리고 캡슐 안의 세부 구현을 밖에서

함부로 못 만지게 숨기는 게 정보 은닉이다.
(언어 문법으로는 public / private / protected 같은 접근 제어로 나타남)

 

4) 연관(Association)

객체는 보통 혼자 일하지 않는다.
서로 메시지를 주고받으며 협력하고,

그 협력 관계가 구조적으로 유지되면 연관이라고 본다.

• Customer — Account : 고객이 계좌를 소유/조회/거래한다
• Student — Course : 학생이 과목을 등록한다
• Professor — Course : 교수가 과목을 가르친다

연관에는 보통 따라오는 개념이 하나 더 있다.

• 가시성(Visibility)
  : A가 B와 연관이라면, A가 B를 알고(참조) 접근 가능해야 한다.

5) 포함 관계(Whole–Part): 집합 vs 합성

전체-부분 관계는 강도에 따라 두 가지로 나뉜다.

 

- 집합(Aggregation): 느슨한 포함

• 전체가 사라져도 부분은 독립 존재 가능
• 예: 자동차(Vehicle) — 부품(Part) (부품은 따로 존재 가능)

- 합성(Composition): 강한 포함

• 전체가 삭제되면 부분도 함께 삭제
• 예: 빌딩(Building) — 방(Room) (빌딩이 없으면 방도 의미가 사라짐)

 

6) 상속(Inheritance) & 다형성(Polymorphism)

상속: 상위(일반) 개념의 속성/기능을 하위(구체) 개념이 물려받는다

• Employee → Manager (Manager는 Employee의 확장)

다형성: 같은 메시지(같은 이름의 호출)를 보내도
실제 객체 타입에 따라 다른 동작이 실행되는 성질

TwoDShape shape = new Circle();
shape.getArea(); // Circle의 getArea 실행

shape = new Rectangle();
shape.getArea(); // Rectangle의 getArea 실행

다형성의 장점은

클라이언트 코드를 크게 안 바꾸고

새 클래스를 추가하기 쉬워진다는 것.

---

클래스 다이어그램: 정적 구조를 그리는 대표 도구

클래스 다이어그램은 시스템의

정적 측면(시간 요소 없는 구조)을 모델링한다.

• 클래스 이름, 속성, 오퍼레이션
• 클래스 사이 관계(연관/상속/의존/구현)
• 다중성(몇 개가 연결되는지), 방향성(탐색 가능 방향)

---

클래스 표기법 기본

모델링 초기엔 이름만 적고,

속성/오퍼레이션은 점진적으로 채워도 된다.

 

1) 클래스 박스(기본 3칸)

• 클래스 이름
• 속성(Attribute)
• 오퍼레이션(Operation)

2) 속성(Attribute) 표기 읽는 법

속성은 보통 이런 정보들을 표현할 수 있다.

• 가시성: +(public), -(private), #(protected)
• 속성명: 명사 형태
• 타입: String, int, 혹은 다른 클래스 타입
• 다중성: 0..*, 1..*, 10..30 등
• 기본값: = 0
• 추가 속성: {ordered}, {readonly} 등

예시)

• -balance: double = 0.0
• -transactionHistory: Transaction[0..*] {ordered}

 

3) 오퍼레이션(Operation) 표기 읽는 법

오퍼레이션은 인터페이스(선언) 관점이다.
구현(메서드 바디)은 보통 클래스 다이어그램에 쓰지 않는다.

• 가시성 + 이름 + (매개변수) + :리턴타입
• 매개변수는 방향(in/out/inout) 이름:타입=기본값 형태로 확장 가능
• {query}는 '상태 변경 없이 값만 조회' 같은 의미로 자주 쓴다

예시)

• +deposit(amount: double): void
• +getBalance(): double {query}

4) 정적(Static) 속성/오퍼레이션

클래스 전체가 공유하는 값/기능은 정적으로 표현한다.
UML에서는 보통 **밑줄(underline)**로 표시해서 인스턴스 멤버와 구분한다.

• 정적 속성: 모든 객체가 공유하는 상수/카운터 등
• 정적 오퍼레이션: 인스턴스 상태에 의존하지 않는 유틸성 메서드 등

---

클래스 사이의 관계 4종 세트

클래스 다이어그램에서 자주 쓰는 관계는 크게 네 가지다.

 

연관(Association)

• 실선
• 구조적으로 연결되어 오래 유지되는 관계
• 방향 화살표가 있으면 한 방향 탐색만 가능
• 끝에 다중성(몇 개 연결되는지) 표시 가능

상속/일반화(Generalization)

• 실선 + 빈 삼각형 화살표
• 구체 → 일반 방향으로 화살표가 향함
• '대체 가능성'이 핵심 (자식은 부모 자리에 들어갈 수 있다)

의존(Dependency)

• 점선 화살표
• 결합이 가장 약한 관계
• '매개변수로 쓰거나, 리턴 타입으로 쓰거나' 같은 수준에서 흔히 발생
• 변경이 전파될 수 있다는 의미

구현(Realization / Implement)

• 점선 + 빈 삼각형 화살표
• 클래스가 인터페이스의 계약(메서드 선언)을 구현한다는 의미

---

다중성(Multiplicity) 빠른 해석법

다중성을 읽을 때는 한 문장으로 습관을 들이면 편하다.

 

'A 한 인스턴스는 B의 y개 인스턴스와 연관될 수 있다.'

 

 

자주 쓰는 표기

• 1 (생략되면 기본 1로 보는 경우가 많음)
• 0..* : 0개 이상
• 1..* : 1개 이상
• 10..30 : 10~30개
• 4, 6, 8, 12 : 특정 개수만 허용

사례: 요구 문장 → 클래스 다이어그램 후보 뽑기

요구(문장)가 주어졌을 때

클래스 다이어그램으로 옮길 때는 보통 이렇게 접근한다.

 

Step 1) 명사 → 클래스 후보

예시 요구(수강신청 시스템)

• Course(과목)
• Student(학생)
• ScheduledCourse(강의일람표/카탈로그 느낌)
• CourseSection(개설 강좌/분반)
• Professor(교수)
• PlanOfStudy(학업이수계획)
• Prerequisite(선수과목 개념 — 또는 Course의 자기 연관으로 처리)

Step 2) 동사/관계 표현 → 연관 후보

• 학생이 강좌를 '신청한다' → Student — CourseSection (등록/신청)
• 교수는 강좌를 '가르친다' → Professor — CourseSection (담당)
• CourseSection은 Course의 '개설분반이다' → Course — CourseSection
• 학생은 신청 전에 PlanOfStudy를 '참조한다' → Student — PlanOfStudy
• 과목은 선수 과목을 '가진다' → Course — Course (자기 연관)

Step 3) 다중성 넣기(현실 제약을 숫자로)

• 학생 1명은 여러 분반을 신청할 수 있다: Student 1 — 0..* CourseSection
• 분반 1개는 여러 학생을 가진다: CourseSection 1 — 0..* Student
• 교수 1명은 여러 분반을 담당할 수 있다: Professor 1 — 0..* CourseSection
• 분반 1개는 교수 1명이 담당한다: CourseSection 1 — 1 Professor

---

마무리

정적 모델링(클래스 다이어그램)은 결국

• 시스템의 핵심 개념을 이름 붙이고
• 개념 간 관계를 구조로 고정해서
• 팀이 같은 그림을 보게 만드는 작업이다.

구현을 시작하기 전에 이걸 한 번만 제대로 맞춰두면,
개발 도중 '말이 통하는 속도'가 확 달라진다.