모듈화 프로그래밍

• 구조 설계의 "높은 응집·낮은 결합" 원칙을 실제로 판정하는 응집도 7단계와 결합도 6단계의 등급표를 다룸
• 소프트웨어 자격시험 전반에서 최빈출 주제 — 순서 나열·사례 식별 문제가 반복 출제
• 목표: 등급의 이름·순서·대표 예를 정확히 암기

모듈화란

• 모듈화(Modularization) = 큰 프로그램을 독립적인 기능 단위(모듈)로 나누어 만드는 것
• 분할 정복(Divide and Conquer)의 소프트웨어판

장점: ① 분업·병렬 개발 가능 ② 모듈 단위의 시험·디버깅 용이 ③ 재사용 ④ 변경이 모듈 안에 국한되어 유지보수 쉬움 ⑤ 전체 복잡도 감소

모듈의 품질은 두 잣대로 잰다 — 안은 얼마나 뭉쳐 있나(응집도), 밖과는 얼마나 얽혀 있나(결합도).

응집도(Cohesion) — 모듈 안의 단결력, 높을수록 좋다

모듈 내부의 요소들이 하나의 목적을 위해 얼마나 밀접하게 관련되어 있는가. 높은 것부터(좋은 것부터) 7단계:

결합도(Coupling) — 모듈 사이의 의존, 낮을수록 좋다

모듈들이 서로 얼마나 얽혀 있는가. 낮은 것부터(좋은 것부터) 6단계:

정보 은닉과 인터페이스 설계

• 정보 은닉(Information Hiding): 내부 구현(변수·알고리즘)은 감추고 공개 인터페이스(API)만 노출 — 내부를 바꿔도 밖이 안전하다
• C라면 헤더(.h, 공개 API) / 구현(.c) 분리, C++/Python이라면 클래스의 public/private
• 예: 모터 모듈은 motor_set_speed(), motor_get_position()만 공개하고, 내부의 PWM 레지스터·게인 변수는 감춘다 — 사용자가 내부에 손대는 내용 결합을 원천 차단

팬인 · 팬아웃

• 팬인(Fan-in): 그 모듈을 호출하는 상위 모듈의 수 — 높으면 여러 곳이 재사용하는 공통 모듈(좋은 신호, 단 시험은 철저히)
• 팬아웃(Fan-out): 그 모듈이 호출하는 하위 모듈의 수 — 지나치게 크면 한 모듈이 너무 많은 일을 지휘한다는 뜻(복잡도 신호, 적정 수준 유지)

모듈의 물리적 형태 — 라이브러리와 컴포넌트

• 정적 라이브러리(Static Library): 빌드 시 실행 파일에 복사되어 포함 — 배포 간단, 파일 커짐, 교체 시 재빌드
• 동적/공유 라이브러리(Dynamic/Shared, .so/.dll): 실행 시 로드 — 여러 프로그램이 공유, 라이브러리만 교체 가능
• 컴포넌트(Component): 표준 인터페이스를 갖춘 독립 배포 단위 — 미들웨어의 노드/컴포넌트가 이 개념의 로봇판이다 (→ 로봇 미들웨어 구조 설계)

응집도·결합도 스펙트럼

flowchart LR
    subgraph COH["응집도 (높을수록 좋음 →)"]
        direction LR
        C7["우연적"] --> C6["논리적"] --> C5["시간적"] --> C4["절차적"] --> C3["통신적"] --> C2["순차적"] --> C1["기능적 ✅"]
    end
    subgraph COU["결합도 (← 낮을수록 좋음)"]
        direction LR
        D1["자료 ✅"] --> D2["스탬프"] --> D3["제어"] --> D4["외부"] --> D5["공통"] --> D6["내용"]
    end

좋은 모듈의 모습

flowchart TD
    A["상위 모듈"] -- "자료 결합
set_speed(0.5)" --> M["모터 제어 모듈
(기능적 응집)"]
    M -. "정보 은닉:
PWM 레지스터·게인은 비공개" .-> H["내부 구현"]
    B["다른 상위 모듈"] -- "재사용 (팬인 ↑)" --> M

1. 응집도가 가장 높은(가장 바람직한) 것은?

① 시간적 응집 ② 기능적 응집 ③ 논리적 응집 ④ 우연적 응집

2. 결합도를 낮은 것부터 순서대로 옳게 나열한 것은?

① 자료 → 제어 → 스탬프 → 공통 → 외부 → 내용 ② 내용 → 공통 → 외부 → 제어 → 스탬프 → 자료 ③ 자료 → 스탬프 → 제어 → 외부 → 공통 → 내용 ④ 스탬프 → 자료 → 외부 → 제어 → 내용 → 공통

3. 여러 모듈이 전역 상태 변수 robot_state를 직접 읽고 쓰도록 구현했다. 이 모듈들 사이의 결합도는?

① 자료 결합 ② 스탬프 결합 ③ 제어 결합 ④ 공통 결합

4. init_system() 함수 하나에 센서 초기화, 모터 초기화, 통신 초기화를 모두 몰아넣었다. 이 모듈의 응집도는?

① 시간적 응집 ② 기능적 응집 ③ 순차적 응집 ④ 우연적 응집

5. 정보 은닉(Information Hiding)의 목적으로 가장 적절한 것은?

① 코드 실행 속도를 높이기 위해 ② 내부 구현 변경이 다른 모듈에 파급되지 않게 하기 위해 ③ 메모리 사용량을 줄이기 위해 ④ 모든 변수를 전역으로 공유하기 위해

• 로봇 소프트웨어 구조 설계 — 응집·결합 원칙이 놓이는 상위 설계
• 미들웨어 프로세스 관리 — 모듈이 프로세스로 배치된 뒤의 관리
• 객체지향 소프트웨어 설계 — 캡슐화·정보 은닉의 객체지향 관점
• 로봇 액추에이터 펌웨어 구조 — 펌웨어에서의 계층화·모듈화 실제
• _MOC 로봇소프트웨어구조설계