E D R , A S I H C RSS

DPSC Chapter2



1. Chatper 2

1.1. Aha!

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되고, μž¬ν™•μΈμ„ μœ„ν•΄ μš”κ΅¬μžμ—κ²Œ λ„λ‘œ 보내진닀.
Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2021-02-07 05:23:04
Processing time 0.0174 sec