diff --git a/wiki/index.md b/wiki/index.md index a148621..02cb264 100644 --- a/wiki/index.md +++ b/wiki/index.md @@ -41,6 +41,8 @@ updated: 2026-04-30 - [[EOS-ch7-concept-dependence]] — Jackson, Ch7, 개념 의존 다이어그램·BirdSong·Facebook·Safari·Keynote 구조 - [[EOS-ch8-concept-mapping]] — Jackson, Ch8, 개념→UI 매핑·다크 패턴·Gmail 레이블 이슈·라이브 필터링 - [[EOS-part3-principles]] — Jackson, Part III (Ch9–11), 특정성·친숙성·무결성 원칙·과부하·중복·무결성 위반 +- [[EOS-endnotes-formalism]] — Jackson, Endnotes 43–44·64, 개념의 수학적 의미론 — 상태기계·트레이스·조합 의미론·CSP·동적 논리 +- [[EOS-endnotes-context]] — Jackson, Endnotes 1–114, 역사·철학·비교 맥락 — Parnas·DDD·Alloy·기입 이론·설계 비판 ## Patterns — 설계 패턴 diff --git a/wiki/log.md b/wiki/log.md index da962b8..762a226 100644 --- a/wiki/log.md +++ b/wiki/log.md @@ -40,6 +40,26 @@ title: Wiki Operation Log - `wiki/sources/EOS-part3-principles.md` — Part III (Ch9–11): 특정성(중복·과부하 4유형·Facebook like 분석), 친숙성(Twitter follower·PowerPoint section vs Keynote), 무결성(복수심 식당·font format·Google Drive) - `wiki/index.md` Sources 섹션에 생성된 8개 페이지 등록 +## 2026-04-30 (5차) + +- [EOS 엔드노트 컴파일] raw/book/EssenceOfSoftware_Eng 미컴파일 5개 파일 (concepts-181-328) 전량 정독 + - 내용: Acknowledgments + 엔드노트(Ch1–11) + 참고문헌 + 개념·토픽 인덱스 + - `wiki/sources/EOS-endnotes-formalism.md` 신규 생성 + - 개념의 수학적 의미론: 상태기계·트레이스·전제조건·교착 상태 + - 객체 분류: asset/name/value 역할, 가변성, 해석 가능성(순열 불변성) + - 조합 의미론: CSP 기반, 트레이스 인터리빙, 보존 정리 + - 운영 원칙의 동적 논리 형식화 (trash/style/reservation 예시) + - 생성 입력(gen keyword) 의미론 + - `wiki/sources/EOS-endnotes-context.md` 신규 생성 + - 소프트웨어 설계 vs. 공학 (Dijkstra 즐거움 문제) + - Alloy 언어 소개, 개념 모델링 분야 비교 (Fowler, DDD, ADT, OOP) + - 개념의 역사적 기원 (trash/folder/style/reservation 발명 연대표) + - 개념의 8대 특성 요약 (Note 48) + - 분리의 원칙, Déjà Vu 재사용 플랫폼, Latour 기입 이론 + - 오버로딩 4유형, 사회적 오버로딩, 설계 비판 vs. 사용자 테스트 + - Parnas uses 관계 vs. 개념 의존 비교 + - `wiki/index.md` Sources 섹션에 2개 페이지 등록 + ## 2026-04-30 (4차) - `wiki/concepts/additive-programming.md` — "AI 시대에서의 가산적 프로그래밍" 섹션 추가 diff --git a/wiki/sources/EOS-endnotes-context.md b/wiki/sources/EOS-endnotes-context.md new file mode 100644 index 0000000..7c912f4 --- /dev/null +++ b/wiki/sources/EOS-endnotes-context.md @@ -0,0 +1,179 @@ +--- +title: EOS 배경 맥락 — 역사, 철학, 비교 +tags: [source, EOS, context] +source: Daniel Jackson (2021), Endnotes 1–42, 65–114 +updated: 2026-04-30 +--- + +# EOS 배경 맥락 — 역사, 철학, 비교 + +> EOS 엔드노트의 역사적 기원, 철학적 배경, 관련 분야와의 비교를 정리한다. + +## 소프트웨어 설계 vs. 소프트웨어 공학 (Note 5, 8) + +### Dijkstra의 "즐거움 문제" + +Dijkstra는 두 문제를 구분했다: +- **정확성 문제(correctness problem)**: 프로그램이 명세를 만족하는가 → 수학적 형식화 가능 +- **즐거움 문제(pleasantness problem)**: 명세 자체가 적절한가 → "비과학적"이라 간주 + +Jackson의 반박: 즐거움 문제가 오히려 더 중요하다. 이름을 "설계 문제"로 바꾸고, "구현 문제"와 대비해야 했다. Dijkstra의 분리가 소프트웨어 연구를 버그 제거에만 집중하게 만들었다. + +### David Liddle의 정의 + +> "Software design is the act of determining the user's experience with a piece of software. It has nothing to do with how the code works inside." + +설계 = 사용자 경험의 전체 명세. 코드 구조가 아닌 사용자가 경험하는 것이 핵심. + +## Alloy 언어 (Note 3) + +Daniel Jackson이 설계한 언어 및 분석 도구: +- 관계(relation)에 기반한 단순하고 강력한 논리 +- Alloy Analyzer: SAT 솔버로 컴파일, 유한 범위 내 완전 검사 보장 +- 설계 탐색 용도: 속성 검증보다 **시나리오 시뮬레이션**이 더 유용 +- 최신 버전: 선형 시제 논리(LTL) 포함, 무한 모델 체킹 지원 + +## 개념 설계와 관련 분야 비교 (Note 14, 44) + +### 기존 개념 모델링 분야와의 차이 + +| 구분 | 전통적 개념 모델링 | EOS 개념 설계 | +|------|------------------|--------------| +| 목적 | 현실 세계 기술(descriptive) | 소프트웨어 설계·발명(inventive) | +| 초점 | 데이터 모델 (ER 다이어그램) | 행동 중심 | +| 개념 정의 | 엔티티-관계 | 이름+목적+상태+행동+운영원칙 | +| 범위 | 전역 데이터 모델 | 개별 개념에 국소화된 미니 데이터 모델 | + +### Fowler 분석 패턴과의 차이 (Note 14) + +Fowler의 "분석 패턴"은 재사용 가능한 개념 모델 — EOS 개념에 가장 가까운 선행 연구. 차이: 분석 패턴은 구조 중심이고 행동을 코드 레벨로 표현. EOS 개념은 구현 독립적으로 행동을 명세. + +### Domain-Driven Design과의 차이 (Note 14) + +Evans의 DDD: 문제 도메인 모델을 구현 기반으로 사용. +- **Bounded context**: 다른 영역에서 다른 도메인 모델 허용 +- EOS 개념 설계: 각 개념이 자체 데이터 모델을 가짐 → DDD를 더 정밀화 + +### Abstract Types / Objects와의 차이 (Note 48) + +| | 추상 타입 | EOS 개념 | +|--|----------|---------| +| 수준 | 코드 레벨 | 설계 레벨 | +| 상호 참조 | 타입 간 연결 어려움 | 조합(composition)으로 명확히 연결 | +| 의존성 방향 | OOP에서 역전되기 쉬움 | 개념 의존 다이어그램으로 명시적 표현 | + +OOP에서의 문제: `Post`가 `Comment`를 포함하는 구조 → 의존성 역전. 개념 설계에서는 `comment`가 `post`에 의존 (올바른 방향). + +## 개념의 역사적 기원 (Note 48) + +| 개념 | 발명자/기원 | 연도 | +|------|-----------|------| +| **trash** | Apple (Macintosh 팀) | ~1983 | +| **folder/directory** | Multics 프로젝트 (Bell Labs) | 1960s | +| **style** | Larry Tesler, Tim Mott (Xerox PARC, Bravo 편집기) | 1970s | +| **reservation** (레스토랑) | 19세기 대도시 레스토랑 | 1880s | +| **social security number** | 미국 사회보장청 | 1936 | +| **song** (단위 판매) | Apple iPod/iTunes 팀 | 2001 | + +개념은 **발명된다** — 자연계에 개와 고양이처럼 존재하는 것이 아니라 누군가가 특정 목적을 위해 창조한 것. + +## 개념의 핵심 특성 요약 (Note 48) + +1. **발명적(inventive)**: 개념은 발명된다. 세계에 있는 것을 분류하는 것이 아니다. +2. **진화한다(evolving)**: 시간이 지남에 따라 설계가 개선된다. `trash`에서 `group` 개념까지. +3. **목적 지향적(purposive)**: 목적 없는 개념 = 개념이 아니다. +4. **행동 중심(behavioral)**: 행동 없이는 개념 없다. `pixel`은 개념이 아닐 수 있다. +5. **풍부한 상태(rich states)**: 상태 구조가 행동을 가능하게 한다. David Wheeler: "모든 문제는 간접 수준을 추가함으로써 해결 가능." +6. **데이터 모델 국소화**: 각 개념은 자신의 미니 데이터 모델을 갖는다. +7. **일반적(generic)**: 타입 변수로 인스턴스화 가능. `trash`는 파일도, 이메일도. +8. **독립적(freestanding)**: 다른 개념 없이 정의 가능. 가장 중요한 특성. + +## 분리의 원칙 (Note 31) + +Dijkstra가 1974년 명명한 "concerns의 분리": +> "어떤 측면을 고립시켜 그 자체의 일관성을 위해 깊이 연구하는 것." + +**분리 ≠ 분할정복**: 분할정복은 재조합 가능한 문제를 나누는 것. 분리는 서로 다른 관심사를 독립적으로 다루는 것. + +Michael Jackson: 하향식 개발은 개발자가 가장 이해가 부족할 때 (시작 시점에) 가장 결정적인 분해를 강요하기 때문에 보통 실패한다. + +## 개념 재사용 플랫폼 (Note 32) + +**Déjà Vu** (Santiago Perez De Rosso): +- 전스택(full-stack) 개념 재사용 플랫폼 +- GUI + 백엔드 서비스 포함한 개념 +- HTML 변형으로 조합 — 최소한의 프로그래밍으로 조합 가능 +- 액션 동기화로 개념 연결 + +기존 프레임워크의 문제: 너무 작은 컴포넌트(날짜 선택기) 또는 너무 크고 경직된 플러그인. + +## Latour의 기입 이론 (Note 65) + +Bruno Latour의 "inscription(기입)": 기계는 이전에 수동으로 수행되던 작업을 구현한 것. + +소프트웨어 개념에의 적용: 레스토랑 예약, 소셜 미디어 팔로우 등 많은 개념이 원래 인간 프로토콜로 시작해 소프트웨어에 기입된다. 이것은 은유가 아니라 **문자 그대로의 동일한 개념**이다. + +## 설계 비판 vs. 사용자 테스트 (Note 38) + +**Jackson의 입장**: 경험적 평가는 과대평가되어 있다. + +- 사용자 테스트의 한계: 설계 공간 탐색에 너무 비용이 크다. 매개변수화된 설계만 테스트 가능. +- **전문가 비판(critique)**: 경험과 원칙을 기반으로 설계 탐색 중 평가 — 더 비용 효율적. +- 제안: 원칙에 기반한 비판 → 사용자 테스트 순서. 한 번에 하나의 개념씩. + +Google의 Douglas Bowman (첫 시각 디자이너, 2009 퇴사): "모든 결정을 데이터로만 판단하다 보면 회사가 어떤 대담한 설계 결정도 내리지 못하게 된다." + +## 특정성 원칙의 보충 (Note 94-102) + +### 오버로딩의 종류 + +| 오버로딩 유형 | 설명 | 예 | +|------------|------|-----| +| **목적 부정(denied purpose)** | 새 목적이 원래 목적을 약화 | Facebook like → recommendation | +| **창발 목적(emergent purpose)** | 의도치 않은 목적으로 사용 | Twitter star → 읽기 목록 | +| **거짓 수렴(false convergence)** | 다른 두 개념을 하나로 합침 | Epson 용지 크기 + 급지 방향 | +| **편승(piggybacking)** | 기존 개념에 무관한 기능 추가 | Photoshop 크롭 + 리샘플링 | + +**Photoshop 크롭 사례(Note 101)**: `cropping`에 `resampling`이 편승 → CS6에서 분리. 설계 개선의 좋은 예. + +### 사회적 오버로딩 (Note 99) + +대학 멘토 제도: 지원/조언 역할 + 승진 평가 역할 → 근본적 이해충돌. + +학회 논문 심사: 피드백 제공 목적 + 채택 결정 목적 → 상충. + +Kieran Egan: 교육의 세 목적(사회화, 진리 추구, 자아실현)이 근본적으로 양립 불가. + +## 무결성 원칙의 보충 (Note 109-110) + +### 강건한 멘탈 모델의 조건 + +de Kleer & Brown (1981): 사용자가 신뢰할 수 있는 멘탈 모델은 **"구조 속 기능 없음(no-function-in-structure)"** 원칙을 만족해야 한다. + += 컴포넌트 행동 설명이 다른 컴포넌트의 기능을 참조하지 않아야 한다. + +이것이 개념의 독립성 원칙과 정확히 일치한다. + +### 피처 상호작용과 개념 무결성 (Note 110) + +통신 피처 상호작용 정의: "피처 A의 존재가 피처 B의 명세를 더 이상 유효하지 않게 만들 때." + +이것이 정확히 개념 무결성 위반의 정의와 같다. 다만 개념 설계에서는 이를 허용하지 않는다. + +## Parnas의 uses 관계와 개념 의존 (Note 81) + +| | Parnas uses 관계 | 개념 의존 | +|--|----------------|---------| +| 정의 방식 | 코드에서 추론 (A가 B를 호출하면 의존) | 설계자가 선언 | +| 의미 | A의 올바른 실행이 B에 의존 | A를 포함하면 B도 포함해야 일관성 있음 | +| 하위 집합 | 의존에서 도출됨 | 하위 집합이 의존을 정의함 | + +Parnas 방법론: "B 없이 A가 포함되는 합리적인 하위 집합이 없는 경우에만 A가 B를 사용하도록 설계하라." + +## 관련 페이지 + +- [[EOS-endnotes-formalism]] — 개념의 수학적 형식 의미론 +- [[EOS-ch4-concept-structure]] — 개념 구조 본문 +- [[EOS-ch6-concept-composition]] — 개념 조합 본문 +- [[EOS-ch7-concept-dependence]] — 개념 의존 본문 +- [[EOS-part3-principles]] — 특정성·친숙성·무결성 원칙 본문 diff --git a/wiki/sources/EOS-endnotes-formalism.md b/wiki/sources/EOS-endnotes-formalism.md new file mode 100644 index 0000000..90ab16a --- /dev/null +++ b/wiki/sources/EOS-endnotes-formalism.md @@ -0,0 +1,175 @@ +--- +title: EOS 형식 의미론 — 개념의 수학적 기반 +tags: [source, EOS, formalism] +source: Daniel Jackson (2021), Endnotes 43–44, 64 +updated: 2026-04-30 +--- + +# EOS 형식 의미론 — 개념의 수학적 기반 + +> EOS 본문이 직관적 설명에 집중하는 반면, 엔드노트 43–44, 64는 개념의 수학적 의미론을 다룬다. 이 페이지는 그 기술적 보충 내용을 정리한다. + +## 개념의 행동 의미론 (Note 44) + +### 상태 기계로서의 개념 + +개념의 행동은 **상태 기계(state machine)**로 형식화된다. + +- **상태(State)**: 개념이 기억해야 하는 것의 집합. 집합과 관계(relation)로 표현 +- **초기 상태**: 모든 집합·관계가 비어 있는 상태 +- **액션**: 전이 관계(transition relation)로 정의됨 +- **결정론(determinism)**: 동일한 상태와 인수에 대해 최대 하나의 후속 상태만 존재 + +### 트레이스와 상태 함수 + +**트레이스(trace)** = 가능한 액션 인스턴스의 유한 히스토리 + +``` +state: Trace → State +``` + +상태 함수는 각 트레이스에 그것이 생성하는 상태를 대응시킨다. + +``` +state() = {accessible: {}, trashed: {i0}} +state() = {accessible: {}, trashed: {}} +``` + +### 전이 관계, 전제조건, 교착 상태 + +액션 `A` (인수 집합 X)의 의미론: + +``` +trans(A) ⊆ S × X × S +``` + +- **전제조건(precondition)**: 액션이 가능한 (s, x) 쌍의 집합 +- 전제조건이 성립하지 않으면 액션은 실행 불가 +- **교착 상태(deadlock)**: 어떤 상태에서 가능한 액션이 없는 경우 — 설계 결함 + +### Alloy를 이용한 액션 형식화 + +``` +pred reserve (u: User, r: Resource) { + r in available + reservations' = reservations + u -> r + available' = available - r +} +``` + +프라임(`'`)은 Electrum 확장의 약식 표기로 액션 후 값을 나타낸다. + +## 운영 원칙의 형식화 (Note 43, 44) + +### 동적 논리로 표현 + +기본 형식: `[a]p` = 액션 a 수행 후 술어 p가 항상 성립 + +복합 액션 연산자: +- `a;b` — 순차 합성 +- `a*` — 반복 (0회 이상) +- `a or b` — 선택 +- `not a` — a가 아닌 임의 액션 + +**trash 개념의 운영 원칙:** +``` +delete(x) {can restore(x)} +delete(x); restore(x) {x in accessible} +``` + +**reservation 개념:** +``` +reserve(u, r); (not cancel(u, r))* {can use(u, r)} +``` + +**style 개념:** +``` +define(s, f); assign(e1, s); assign(e2, s); define(s, f') {e1.format = e2.format = f'} +``` + +### 운영 원칙 vs. 유스케이스/유저 스토리 + +| 구분 | 운영 원칙 | 유스케이스 | +|------|-----------|-----------| +| 역할 | 개념의 본질 설명 | 기능 전체 기술 | +| 범위 | 개별 개념 단위 | 시스템 레벨 | +| 수량 | 핵심 시나리오 1–2개 | 수십~수백 개 | +| 초점 | 왜 이 개념인가 | 무엇을 할 수 있는가 | + +## 객체 분류 (Note 44) + +### 역할에 의한 분류 + +| 역할 | 정의 | 예 | +|------|------|-----| +| **자산(asset)** | 고유 가치를 지닌 객체 | 사진, 오디오 트랙, 블로그 포스트, 인증서 | +| **이름(name)** | 다른 객체를 식별·위치시키는 객체 | 이메일 주소, 도메인 이름, 파일 경로 | +| **값(value)** | 다른 객체와의 관계에서만 의미를 갖는 객체 | 숫자 80 (나이, 온도, 조회수…) | + +### 가변성(mutability)에 의한 분류 + +- **불변(immutable)**: 개념 간 통신(동기화) 시 공유되는 객체는 반드시 불변이어야 함 + - 가변 객체가 공유되면 숨겨진 통신 발생 → 앨리어싱 문제 +- 개념 내부에서는 가변 객체 해석 가능 + +### 해석 가능성(interpretability)에 의한 분류 + +**비해석(uninterpreted)**: 동등성(equality)만 인식 — 타입 변수처럼 동작 + +**해석(interpreted)**: 객체의 내부 구조나 값을 활용 + +**순열 불변성(permutation invariance)으로 형식화:** +타입 T가 개념 C에서 비해석적이면, T의 임의 순열 p에 대해 p(t)도 C의 트레이스이고 `state(p(t)) = p(state(t))`. + +## 조합의 의미론 (Note 64) + +### 조합 = 트레이스의 인터리빙 + +개념들의 조합은 개별 개념 트레이스의 **모든 가능한 인터리빙(interleaving)**이다. 동기화는 허용되는 인터리빙을 제한한다. + +동기화 형식: +``` +sync action1(x) + action2(e) +``` +의미: 모든 트레이스에서 trigger action1의 모든 발생 직후 반드시 response action2가 발생. + +### 핵심 정리: 조합은 개념 행동을 보존한다 + +> "Composing concepts never changes the behavior of any of the constituent concepts." + +이것이 개념 이해 가능성의 근거다. 개념은 어떤 맥락에서도 동일하게 행동한다. 위반 시 → 개념 무결성(concept integrity) 위반 (Ch11). + +**안전성(safety) vs. 활성성(liveness)**: +- 조합은 안전성 속성은 보존 +- 활성성은 제한 가능 (예: access control 개념이 다른 개념의 액션을 억제) + +### CSP와의 관계 + +개념 조합의 의미론은 Tony Hoare의 CSP(Communicating Sequential Processes)에서 파생. + +차이점: +| | CSP | 개념 조합 | +|--|-----|---------| +| 결정론 | 비결정론적 가능 | 항상 결정론적 | +| 상태 관찰 | 없음 | 동기화 조건에 상태 사용 가능 | +| 동기화 | 공유 액션 | trigger/response 쌍 | + +## 생성 입력 (Note 64) + +액션의 입력에는 두 종류: +1. **생성 입력(generated input)**: 개념 자체가 생성 — `gen` 키워드로 표시 +2. **제공 입력**: 다른 개념이 제공 + +``` +add(gen t: Task) // task는 todo 개념이 생성 +affix(i: Item, gen l: Label) // item은 외부 제공, label은 label 개념이 생성 +``` + +트레이스 제약: `gen`이 아닌 입력은 트레이스의 이전 액션에서 생성 또는 출력된 것이어야 한다. + +## 관련 개념 + +- [[EOS-ch4-concept-structure]] — 개념의 5요소 (informal) +- [[EOS-ch6-concept-composition]] — 개념 조합 전반 +- [[propagation]] — SDF의 전파 모델과 비교 (유사한 수학적 구조)