Before launching into our descriptions of specific design patterns, we present a case study of sorts, involving multiple patterns. In the Design Pattern preface, the Gang of Four speak about moving from a "Huh?" to an "Aha!" experience with regard to understanding design patterns. We present here a little drama portraying such a transition. It consists of three vignettes: three days in the life of two Smalltalk programmers who work for MegaCorp Insurance Company. We are listening in on conversations between Don (an object newbie, but an experienced business analyst) and Jane (an object and pattern expert). Don comes to Jane with his design problems, and they solve them together. Although the characters are fictitious, the designs are real and have all been part of actual systems written in Smalltalk. Our goal is to demonstrate how, by careful analysis, design patterns can help derive solutions to real-world problems.

(중간중간 구라에 가까운 의역이라는. --;;;)

디자인 패턴에 대한 구체적인 설명에 들어가기 전에 우리는 다양한 패턴들이 포함된 것들에 대한 예시들을 보여준다. 디자인 패턴 서문에서 GoF는 디자인 패턴을 이해하게 되면서 "Huh?" 에서 "Aha!" 로 바뀌는 경험에 대해 이야기한다. 우리는 여기 작은 단막극을 보여줄 것이다. 그것은 3개의 작은 이야기로 구성되어있다 : MegaCorp라는 보험회사에서 일하는 두명의 Smalltalk 프로그래머의 3일의 이야기이다. 우리는 Don 과(OOP에 대해서는 초보지만 경험있는 사업분석가) Jane (OOP와 Pattern 전문가)의 대화내용을 듣고 있다. Don 은 그의 문제를 Jane에게 가져오고, 그들은 같이 그 문제를 해결한다. 비록 여기의 인물들의 허구의 것이지만, design 은 실제의 것이고, Smalltalk로 쓰여진 실제의 시스템중 일부이다. 우리의 목표는 어떻게 design pattern이 실제세계의 문제들에 대한 해결책을 가져다 주는가에 대해 설명하는 것이다.

Chapter 2

Aha!

2.1 Scene One : State of Confusion
Our story begins with a tired-looking Don approaching Jane's cubicle, where Jane sits quietly typing at her keyboard.
우리의 이야기는 지친표정을 지으며 제인의 cubicle (음.. 사무실에서의 파티클로 구분된 곳 정도인듯. a small room that is made by separating off part of a larger room)로 가는 Don 과 함께 시작한다. 제인은 자신의 cubicle에서 조용히 타이핑하며 앉아있다.

Don : Hey, Jane, could you help me with this problem? I've been looking at this requirements document for days now, and I can't seem to get my mind around it.
Jane~ 이 문제좀 해결해주실래요? 오늘 하루종일 이 요구문서를 쳐다봤지만, 도무지 아이디어가 안떠오르네요.

Jane : That's all right. I don't mind at all. What's the problem?
좋아요. 어떤문제인가요?

Don : It's this claims-processing workflow system I've been asked to design. I just can't see how the objects will work together. I think I've found the basic objects in the system, but I don't understand how to make sense from their behaviors.
제가 디자인부탁하는 것은 바로 이 요구-진행 작업흐름시스템 입니다. (그냥 영어 그대로 써도 될것 같은데.. 대체할 용어가 생각안난다. 아, 어휘 딸려라. --;) 이 개체들이 어떻게 같지 작용해야 할지 모르겠어요. 제가 생각하기론, 이 시스템에서의 기본적인 개체들은 찾은 것 같은데, 각 개체들의 행위들을 어떻게 이해해야 할지 모르겠어요.

Jane : Can you show me what you've done?

Don : Here, let me show you the section of the requirements document I've got the problem with:
여기요. 요구문서에서 문제의 부분입니다.

1. Data Entry. This consists of various systems that receive health claims from a variety of different sources. All are logged by assigning a unique identifier. Paper claims and supporting via OCR (optical character recognition) to capture the data associated with each form field.
   
   
   
2. Validation. The scanned and entered forms are validated to ensure that the fields are consistent and completely filled in. Incomplete or improperly filled-in forms are rejected by the system and are sent back to the claimant for resubmittal.
   
   
3. Provider/Plan Match. An automated process attempts to mach the plan (the contract unser which the claim is being paid) and the health care provider (e.g., the doctor) identified on the claim with the providers with which the overall claim processing organization has a contract. If there is no exact match, the program identifies the most likely matches based on soundex technology (an algorithm for finding similar-sounding words). The system displays prospective matches to knowledge workers in order of the likeinhood of the match, who then identify the correct provider.
   
   
4. Automatic Adjudication. The system determines whether a claim can be paid and how much to pay if and only if there are no inconsistencies between key data items associated with the claim. If there are inconsistencies, the system "pends" the claim for processing by the appropriate claims adjudicator.
   
   
5. Adjudication of Pended Claims. The adjudicator can access the system for a claim history or a representation of the original claim. The adjudicator either approves the claim for payment, specifying the proper amount to pay, or generates correspondence denying the claim.
   
   

Data Entry. 이것은 다양한 form으로부터 health claims 를 받는 다양한 시스템으로 구성된다. 모두 고유 id 가 할당되어 기록되며, Paper claims OCR (광학문자인식) 로 캡쳐된 데이터는 각 form field 들에 연관되어있다.

Validation. 스캔되고 입력되어진 form들은 각 필드들에 대해 일관성보증과 모든 폼이 완전히 채워졌는지에 대한 보증을 위해 검증작업을 거친다. 불완전하거나 적절치 못한 입력은 시스템에 의해 reject되고, 재확인을 위해 요구자에게 도로 보내진다.