81a4d0a2fe
raw/book/EssenceOfSoftware_Eng/ — Daniel Jackson (2021) 원본 11개 폴더 추가 wiki/sources/ EOS 챕터별 한국어 페이지 8개: - EOS-overview: 전체 개요, 설계 3수준, 핵심 원칙 - EOS-part1: Ch1-3 동기 (Backblaze/Dropbox 사례, 개념 역할) - EOS-ch4: 개념 구조 (5요소: 이름·목적·상태·행동·운영 원칙) - EOS-ch5: 개념 목적 (좋은 목적 4기준, 미스피트 사례) - EOS-ch6: 개념 조합 (동기화, 시너지, 과잉/과소 동기화) - EOS-ch7: 개념 의존 (의존 다이어그램, 제네릭 개념) - EOS-ch8: 개념 매핑 (다크 패턴, UI 매핑 딜레마) - EOS-part3: 원칙 Ch9-11 (특정성·친숙성·무결성) wiki/index.md Sources 섹션 EOS 8개 등록, wiki/log.md 기록 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
119 lines
5.2 KiB
Markdown
119 lines
5.2 KiB
Markdown
---
|
|
title: "EOS Ch4 — 개념의 구조"
|
|
tags: [source, EOS]
|
|
source: "The Essence of Software, Daniel Jackson (2021)"
|
|
chapter: "Ch4 Concept Structure"
|
|
updated: 2026-04-30
|
|
---
|
|
|
|
# EOS Ch4 — 개념의 구조
|
|
|
|
## 핵심 아이디어
|
|
|
|
개념(concept)은 다섯 가지 구성 요소로 정밀하게 정의할 수 있다: 이름(name), 목적(purpose), 상태(state), 행동(actions), 운영 원칙(operational principle). 이 구조는 개념을 서로 독립적으로 이해·설계·구현할 수 있게 하며, 재사용성의 토대가 된다. Jackson은 *trash*, *style*, *reservation* 세 개념을 예시로 구조를 설명한다.
|
|
|
|
## 개념 정의의 5요소
|
|
|
|
| 요소 | 설명 |
|
|
|------|------|
|
|
| **이름(name)** | 개념 이름과 타입 파라미터 (제네릭) |
|
|
| **목적(purpose)** | 개념이 존재하는 이유를 한 문장으로 |
|
|
| **상태(state)** | 개념이 기억하는 데이터 구조 |
|
|
| **행동(actions)** | 상태를 변경하는 동작과 전제 조건 |
|
|
| **운영 원칙(operational principle)** | 목적이 실제로 달성되는 전형적 사용 시나리오 |
|
|
|
|
운영 원칙은 가장 단순한 시나리오가 아니라, **목적의 성취를 증명하는 최소 시나리오**다.
|
|
|
|
## 예시 1: trash 개념
|
|
|
|
Apple이 1982년 Lisa 컴퓨터를 위해 발명한 *trash* 개념.
|
|
|
|
**목적**: 삭제의 취소(undoing of deletions)를 허용한다.
|
|
|
|
**상태**: `accessible` (접근 가능한 아이템 집합), `trashed` (삭제됐지만 영구 제거 전 아이템 집합)
|
|
|
|
**주요 행동**:
|
|
- `delete(x)` — x를 accessible에서 trashed로 이동 (전제: x가 accessible에 있을 것)
|
|
- `restore(x)` — x를 trashed에서 accessible로 이동
|
|
- `empty()` — trashed의 모든 항목 제거
|
|
|
|
**운영 원칙**:
|
|
```
|
|
after delete(x), can restore(x) and then x in accessible
|
|
after delete(x), can empty() and then x not in accessible or trashed
|
|
```
|
|
|
|
> "The real innovation… is not that you can move things *into* the trash, but that you can then move them *out*."
|
|
|
|
### Trash 개념의 설계 결함과 수정
|
|
|
|
- **문제 1**: macOS에 trash가 하나뿐이라, 외장 드라이브의 파일을 지워도 영구 삭제가 안 됨. OS X El Capitan(2015)에서 "즉시 삭제" 액션으로 해결.
|
|
- **문제 2**: trash 안 파일을 삭제 날짜순으로 정렬할 수 없었음. OS X Lion(2011)에서 "added date" 정렬로 해결 (folder 개념의 synergy).
|
|
|
|
## 예시 2: style 개념
|
|
|
|
Adobe InDesign, Microsoft Word 등 문서 편집 도구의 *style* 개념.
|
|
|
|
**목적**: 요소들의 일관된 서식(formatting) 적용을 쉽게 한다.
|
|
|
|
**상태**:
|
|
- `assigned: Element -> one Style` (요소에 할당된 스타일)
|
|
- `defined: Style -> one Format` (스타일에 정의된 서식)
|
|
- `format: Element -> one Format = assigned.defined` (파생 상태)
|
|
|
|
**주요 행동**:
|
|
- `assign(e, s)` — 요소 e에 스타일 s 할당
|
|
- `define(s, f)` — 스타일 s의 서식을 f로 정의 (생성 또는 업데이트)
|
|
|
|
**운영 원칙**: s를 서식 f로 정의하고, e1·e2에 s를 할당한 뒤 s를 f'로 재정의하면, e1과 e2 모두 f'로 변경된다.
|
|
|
|
### Style이 아닌 것들
|
|
|
|
- Apple color picker: 색상 수정 불가 → 운영 원칙 실패 → *style* 개념 아님
|
|
- Apple TextEdit의 "style": 스타일을 적용해도 단락에 지속적으로 연결되지 않음 → *style* 개념 아님
|
|
|
|
## 예시 3: reservation 개념
|
|
|
|
소프트웨어 이전부터 존재하는 *reservation* 개념.
|
|
|
|
**목적**: 한정된 자원의 효율적 사용을 관리한다.
|
|
|
|
**상태**:
|
|
- `available: set Resource`
|
|
- `reservations: User -> set Resource` (1:다 매핑)
|
|
|
|
**주요 행동**:
|
|
- `reserve(u, r)` — r이 available일 때, u에게 r을 예약
|
|
- `cancel(u, r)` — u의 r 예약 취소, r을 available로 반환
|
|
- `use(u, r)` — u가 예약한 r 사용
|
|
|
|
**운영 원칙**: `after reserve(u, r) and not cancel(u,r), can use(u, r)`
|
|
|
|
### 설계 이슈들
|
|
|
|
- 자원은 시간대에 종속될 수 있음 (레스토랑 좌석 예약)
|
|
- no-show 처리 — 계정 정지 등
|
|
- 충돌 예약 방지 (같은 날 밤 두 레스토랑 동시 예약)
|
|
- 철도 신호 시스템, 네트워크 RSVP 프로토콜에도 동일 개념 적용
|
|
|
|
## 개념의 제네릭성
|
|
|
|
개념 이름 옆의 타입 파라미터(예: `trash [Item]`)는 개념이 제네릭임을 나타낸다. *trash*의 Item은 파일 시스템에서는 파일, 이메일 클라이언트에서는 메시지가 된다. 제네릭성은:
|
|
- 재사용을 가능하게 한다
|
|
- 개념을 본질로 추출하도록 강제한다
|
|
|
|
## 핵심 인용
|
|
|
|
> "A concept definition includes its name, purpose, state, actions and operational principle. The operational principle, showing how the behavior fulfills the purpose, is the key to understanding a concept."
|
|
|
|
> "Most concepts in widespread use have undergone extensive development and refinement over time."
|
|
|
|
> "Concepts can be designed and understood independently of one another, simplifying software design by allowing a design to be broken into distinct subproblems."
|
|
|
|
## 관련 개념
|
|
|
|
- [[EOS-ch5-concept-purposes]] — 목적(purpose)에 대한 심층 논의
|
|
- [[EOS-ch6-concept-composition]] — 개념 조합과 동기화
|
|
- [[EOS-part3-principles]] — 특정성·친숙성·무결성 원칙
|
|
- [[EOS-overview]] — 전체 개요
|