[Software Engineering] Structural Modeling: Class Diagram & Object Diagram

 

 

 

Functional Modeling vs Structural Modeling 비교

소프트웨어 설계는 보통 두 가지 관점에서 시스템을 이해한다.
하나는 무엇을 하는가(Functional), 다른 하나는 무엇으로 구성되는가(Structural) 이다.

초점(Focus)	Functional Modeling- System의 동작(behavior)	Structural Modeling- System의 구조(structure)
핵심 질문	“무엇을 해야 하는가?”	“무엇으로 이루어져 있는가?”
표현 대상	기능(Functions), 프로세스(Process), 흐름(Flow)	객체(Object), 클래스(Class), 관계(Relationship)
대표 다이어그램	Data Flow Diagram, Activity Diagram, State Diagram	Class Diagram, Object Diagram
시간적 성격	동적(Dynamic)	정적(Static)

Functional 모델이 '시스템의 행동'을 설명한다면, Structural 모델은 그 행동을 가능하게 하는 정적 구조를 정의한다.

 

여기서 Functional 모델이 시스템의 '외부 기능(External behavior)' 을 정의한다면, Structural 모델은 시스템 내부의 '정적 구조(Static structure)'를 설계한다.

---

 

 

 

Structural Modeling이란?

Structural Modeling은 시스템을 구성하는 객체(Object)와 클래스(Class), 그리고 이들 간의 관계(Relationship)를 시각적으로 모델링하는 과정이다.

• 시스템 내부에 어떤 데이터나 object가 존재하는지,
• 이들이 어떻게 연결(relationship)되어 있는지,
• 각 클래스가 어떤 속성(Attribute) 과 연산(Operation) 을 가지는지를 표현한다.

 

Conceptual model을 만든다.

• Class diagrams
• Object diagrams

 

과정은 반복적으로 그린다.

 

 

Structural Models의 주요 목적은 문제에 포함되어 있는 key data를 찾고 object의 strucutral model로 표현하는 것에 있다.

 

 

---

 

Classes, Attributes, Operations

• Class: Templates for instaces
• Attributes: 상태를 설명하는 Properties
• Operations: Actions or functions

 

1. Class

• 현실 세계의 객체(Object)를 추상화한 템플릿(Template).
• 객체들이 공통으로 가지는 속성(Attribute) 과 행동(Operation) 을 정의한다.
• 구체적(Concrete) 클래스와 추상(Abstract) 클래스로 구분된다.

 

 

 

클래스의 종류

• Funtional requirements
  • Domain Class — 실제 업무 도메인을 표현 (Customer, Product)
• Non-functional requirements
  • User Interface classes — 사용자와 상호작용 담당 (LoginScreen)
  • Data Structure / File Class — 데이터 저장 구조 담당 (DatabaseFile)
  • System Class(File structure, operationg environment) — 실행 환경 관련 (SessionManager, Config)

 

2. Attribute

• 클래스의 상태를 나타내는 데이터 값.
• 예: Person 클래스의 name, age, address 등.
• 파생 속성(Derived Attribute)은 / 기호로 표현한다.
  • /age = 현재 연도 - birthYear

 

3. Operation 

• 클래스가 수행하는 기능(Function), Actions.
• Common operations(Create, delete instance)는 보이지 않는다.
• 일반적으로 생성자(Constructor), 소멸자(Destructor), 조회(Query), 갱신(Update)로 분류된다.
• 예:
  • + createAccount(username: String, email: String)
  • + getPosts(): List<Post>
  • + deleteAccount(id: Int): void

 

 

 

4. Visibility

• + Public : 모든 클래스에서 접근 가능
• - Private : 해당 클래스 내부에서만 접근 가능
• # Protected : 하위 클래스에서 접근 가능

접근 제한을 통해 데이터 무결성을 유지하고, 캡슐화(Encapsulation)를 강화한다.

 

 

---

 

 

 

Relationships

두 클래스간의 associations이다.

• 관계 이름을 묘사한다.
• 클래스는 그들 스스로 연관되어 있을 수 있다.
• Multiplicity: 클래스 인스턴스 숫자가 다른 클래스 인스턴스와 관계된 수

 

UML에서 세가지 기본 타입으로 나뉜다.

• Generalization (상속)
  • 속성과 연산을 상속할 수 있다.
  • "a-kind-of"로 관계를 표현한다.
• Aggregation (약한 포함관계)
  • 전체의 부분 관계이다.
  • "a-part-of"를 나타낸다. 
  • Composition: String "a-part-of"를 관계에서 나태내며 포함하는 것이다.
• Association
  • 두 클래스간의 일반적인 연관관계이다.

 

---

 

 

Generalization (상속 관계)

• ~의 한 종류(is-a) 관계를 나타낸다.
• UML 표기: 속이 빈 삼각형(△)
• 상위 클래스(superclass)의 속성과 연산을 하위 클래스(subclass)가 상속받는다.

 

 

Association (연관 관계)

• 어떻게 두 클래스가 서로 관계있는지를 나타낸다.
• UML에서는 실선으로 표현하며, 다중성(Multiplicity)을 함께 명시한다.

 

다중성(Multiplicity) 표기:

1	정확히 하나
0..1	0개 또는 1개
* 또는 0..*	0개 이상
1..*	1개 이상

 

 

Aggregation (집합 관계)

• 전체–부분(Whole–Part) 관계 중 약한 포함(Weak ownership) 관계.
  • "has a"
• 부분 객체는 전체와 독립적으로 존재 가능하다.
  • 아래의 예시에서는 student 인스터스가 school 인스턴스가 없더라도 독립적으로 존재할 수 있다. 
• UML 표기: 속이 빈 다이아몬드(◇)

 

 

Composition (합성 관계)

• Aggregation보다 강한 포함 관계(Strong ownership)
  • "contains a"
• 부분 객체는 전체의 생명주기에 종속된다.
  • 아래에서 Engine이라는 인스턴스는 Car인스턴스가 사라지면 사라진다. 엔진은 자동차의 완전한 일부이다.
• UML 표기: 속이 찬 다이아몬드(◆)

 

 

 

 

위의 코드에서 Car 인스턴스가 사라지면 Engine은 완전히 사라지는 구조이다. 반면에 Driver는 주소만 주기에 Car 인스턴스가 사라져도 유지된다.

 

따라서, Car-Engine은 composition관계이고 Car-Driver는 aggregation 관계이다. 

 

 

예시

A booking is always for exactly one passenger

• No booking with zero passengers

• A booking could never involve more than one passenger

 

A passenger can have anynumber of bookings

• A passenger could have no bookings at all

• A passenger could have more than one booking

 

 

각각의 관계를 다이어그램으로 표현하면 아래와 같다.

 

 

 

 

Association vs Aggregation 구분 기준

Aggregation과 단순 Association은 모델러의 의도(Intent) 에 따라 다르다.

예시: "A student registers a course." → Student와 Course는 서로 관련 있지만, Course는 Student가 없어도 존재할 수 있다.
→ 따라서 이는 Aggregation 또는 단순 Association 으로 표현할 수 있다.

 

결국 "생명주기(Lifetime)의 결합 여부"가 판단 기준이다.

 

 

 

---

 

Association Class (연관 클래스)

두 클래스 간의 관계 자체가 속성을 가질 때 사용한다. 보통 N:M(다대다) 관계에서 등장한다.

 

예시:

• Student ↔ Course 관계의 속성: Grade
• Illness ↔ Symptom 관계의 속성: Treatment

 

즉, Grade는 Student와 Course의 관계(수강)에 대한 속성을 보유한다

 

 

---

 

 

 

Class Diagram이란?

Class Diagram은 시스템의 정적 구조(static structure)를 보여주는 UML 다이어그램이다.
시스템 안의 클래스(Class) 와 이들 간의 관계(Relationship) 를 시각적으로 표현한다.

특징

• 시스템 내부의 객체(Object)들(사람, 장소, 사물 등)을 보여준다.
• 각 클래스는 정보를 저장하고 관리하며, 다음 요소로 구성된다:
  • Attributes: 클래스의 속성(특성)
  • Operations:클래스가 수행할 수 있는 동작
  • Relationships — 클래스 간의 관계(연관, 집합, 합성 등)
• 관계(Relationship)는 선(line) 으로 표시되고, Multiplicity(다중성) 은 "몇 개의 객체가 연결될 수 있는가"를 나타낸다.

 

Sample Class Diagram (샘플 예시)

 

 

---

 

 

Object Diagram이란?

Object Diagram은 Class Diagram의 스냅샷이다. 즉, 클래스가 실제로 인스턴스화(instantiation) 되었을 때 특정 시점의 객체들과 그 관계를 그대로 찍어 보여준다. 따라서 실제 시스템이 돌아가는 모습에 대해 그려진다고 볼 수 있다.

• "Doctor 클래스" 대신 실제 객체 Dr. Smith: Doctor 같은 구체 인스턴스를 만든다.
• 각 attribute(속성) 에 실제 값을 채워 넣는다.
• 설계 중 빠진 속성·관계·연산을 발견하거나 잘못 배치된 요소를 찾아내는 데 유용하다.

 

위의 Class diagram을 Object diagram으로 구현한 것이다. 

Object Diagram은 "값이 들어간 실물 샷"이라, 누락된 속성/잘못된 관계를 잡아내는 데 특히 효과적이다. 

 

참고로 Object Diagram은 Operation(연산)은 표시하지 않는다.

 

 

 

Object Identification (객체 식별)

현실 문제를 객체로 뽑아내는 과정은 보통 다음 두 축으로 시작

• Textual Analysis of Use Cases:
  • 명사(Nouns) → Classes 후보
  • 동사(Verbs) → Operations 후보
  • 이렇게 만든 초안(first cut)으로 object list를 만든다.
• Brainstorming:
  • 팀이 아이디어를 자유롭게 던지며 초기 클래스(객체) 목록을 정리
  • 2차 라운드에서 attributes/operations/relationships를 할당한다.

또한 Common Object Lists를 활용하면 빠르게 후보를 넓힐 수 있다.

• Physical things, Incidents, Roles, Interactions

Patterns: 공통 문제에 대한 재사용 가능한 클래스 집합이다.

 

 

Patterns(패턴)으로 분석 가속화

반복적으로 등장하는 객체·관계 묶음을 패턴으로 재사용할 수 있다.

 

• 위의 그림에서 많은 거래(Transactions) 는 거의 항상 Transaction, Transaction Line Item, Item, Place, Participant로 구성된다.
  → 이를 재사용하면 빠르고 완전하게 시스템 구조를 정의할 수 있다.

 

• 문서의 Figure 5-3은 분석 단계에서 유용한 패턴 묶음을 보여주며, 서로 다른 패턴을 merge해 재사용 가능한 Class Diagram으로 확장할 수 있음을 설명한다.

따라서 패턴은 "빈 종이에서 시작"하는 시간을 줄여주고, 누락과 중복을 줄이는 안전망 역할을 한다.

 

 

---

 

 

 

복잡한 Class Diagram을 단순화하는 3가지 방법

실무 시스템의 완전한 Class Diagram은 대개 매우 복잡하다. 다음 방법으로 가독성을 높인다.

1. Show only concrete classes: 추상 클래스는 뷰에서 일시적으로 감추고 구현 실체 중심으로 본다.
2. View mechanism: 특정 관심 하위집합(subset)만 보여주는 뷰를 사용한다.
3. Packages: 관련 요소들을 패키지(aggregation of elements) 로 묶어 계층 구조를 만든다.

 

 

7 Steps to Structural Models 

1. Identify objects: 유즈케이스/텍스트 분석·브레인스토밍으로 객체 후보 도출
2. Review & find gaps: 빠진 클래스/속성/연산/관계 보완
3. Look for breakdowns: 세분화·분해가 필요한 곳을 찾아 새 객체 생성/재배치
4. Create the class diagram: 초안(Class Diagram) 작성
5. Review the class diagram: 불필요/오류 요소 제거: ID는 속성으로, 외부 부서는 액터로, 범위 밖 미디어 제거
6. Incorporate patterns: 관련 분석 패턴을 맞춤 치환하여 구조 보강
7. Review & validate: 최신 구조로 검증하고, 다른 산출물과의 정합성을 다시 맞춘다.

 

 

출처: 경북대학교 손정주 교수님, “소프트웨어설계” 강의 자료