외국도서

>

컴퓨터

>

인터넷/웹 개발

• 
• 제휴몰 주문 시 고객보상, 일부 이벤트 참여 및 증정품 증정, 하루/당일 배송에서 제외되므로 참고 바랍니다.

• 
• 도서  > 외국도서  > 컴퓨터  > 인터넷/웹 개발
• 도서  > 외국도서  > 컴퓨터  > 프로그래밍
• 도서  > 외국도서  > 컴퓨터  > 그래픽/3D 애니메이션
• 도서  > 외국도서  > 컴퓨터  > 엔지니어링

• 
• 
• About the Authors Preface 1 Introduction 1 1.1 The Touchstones: Lean and Agile 1 1.2 Lean Architecture and Agile Feature Development 4 1.3 Agile Production 7 1.3.1 Agile Builds on Lean 7 1.3.2 The Scope of Agile Systems 7 1.3.3 Agile and DCI 8 1.4 The Book in a Very Small Nutshell 10 1.5 Lean and Agile: Contrasting and Complementary 11 1.5.1 The Lean Secret 14 1.6 Lost Practices 14 1.6.1 Architecture 15 1.6.2 Handling Dependencies between Requirements 15 1.6.3 Foundations for Usability 16 1.6.4 Documentation 16 Code Does Not Stand Alone 17 Capturing the "Why" 19 1.6.5 Common Sense, Thinking, and Caring 19 1.7 What this Book is Not About 21 1.8 Agile, Lean - Oh, Yeah, and Scrum and Methodologies and Such 22 1.9 History and Such 24 2 Agile Production in a Nutshell 27 2.1 Engage the Stakeholders 27 2.2 Define the Problem 29 2.3 Focusing on What the System Is: The Foundations of Form 30 2.4 Focusing on What the System Does: The System Lifeblood 32 2.5 Design a...nd Code 33 2.6 Countdown: 3, 2, 1 34 3 Stakeholder Engagement 35 3.1 The Value Stream 35 3.1.1 End Users and Other Stakeholders as Value Stream Anchors 36 3.1.2 Architecture in the Value Stream 37 3.1.3 The Lean Secret 38 3.2 The Key Stakeholders 41 3.2.1 End Users 43 Psyching Out the End Users 44 Don't Forget Behavior 46 The End User Landscape 47 3.2.2 The Business 47 A Special Note for Managers 48 3.2.3 Customers 50 ...As Contrasted with End Users 50 "Customers" in the Value Stream 52 3.2.4 Domain Experts 52 No Ivory Tower Architects 53 Experts in Both Problem and Solution Domains 54 3.2.5 Developers and Testers 55 3.3 Process Elements of Stakeholder Engagement 57 3.3.1 Getting Started 58 3.3.2 Customer Engagement 60 3.4 The Network of Stakeholders: Trimming Wasted Time 61 3.4.1 Stovepipe Versus Swarm 61 3.4.2 The First Thing You Build 64 3.4.3 Keep the Team Together 65 3.5 No Quick Fixes, but Some Hope 66 4 Problem Definition 67 4.1 What's Agile about Problem Definitions? 68 4.2 What's Lean about Problem Definitions? 68 4.3 Good and Bad Problem Definitions 70 4.4 Problems and Solutions 72 4.5 The Process Around Problem Definitions 73 4.5.1 Value the Hunt Over the Prize 73 4.5.2 Problem Ownership 74 4.5.3 Creeping Featurism 75 4.6 Problem Definitions, Goals, Charters, Visions, and Objectives 76 4.7 Documentation? 77 5 What the System Is, Part 1: Lean Architecture 79 5.1 Some Surprises about Architecture 80 5.1.1 What's Lean about This? 82 Deliberation and "Pull" 83 Failure-Proof Constraints or Poka-Yoke 83 The Lean Mantras of Conservation, Consistency, and Focus 84 5.1.2 What's Agile about Architecture? 84 It's All About Individuals and Interactions 84 Past Excesses 85 Dispelling a Couple of Agile Myths 86 5.2 The First Design Step: Partitioning 88 5.2.1 The First Partition: Domain Form Versus Behavioral Form 89 5.2.2 The Second Partitioning: Conway's Law 90 5.2.3 The Real Complexity of Partitioning 93 5.2.4 Dimensions of Complexity 94 5.2.5 Domains: A Particularly Interesting Partitioning 94 5.2.6 Back to Dimensions of Complexity 96 5.2.7 Architecture and Culture 100 5.2.8 Wrap-Up on Conway's Law 100 5.3 The Second Design Step: Selecting a Design Style 100 5.3.1 Contrasting Structuring with Partitioning 102 5.3.2 The Fundamentals of Style: Commonality and Variation 104 5.3.3 Starting with Tacit Commonality and Variation 105 5.3.4 Commonality, Variation, and Scope 108 5.3.5 Making Commonalities and Variations Explicit 111 Commonality Categories 112 Next Steps 114 5.3.6 The Most Common Style: Object Orientation 114 Just What is Object Orientation? 115 5.3.7 Other Styles within the Von-Neumann World 117 5.3.8 Domain-Specific Languages and Application Generators 120 The State of the Art in DSLs 121 DSLs' Place in Architecture 121 5.3.9 Codified Forms: Pattern Languages 122 5.3.10 Third-Patry Software and Other Paradigms 124 5.4 Documentation? 127 5.4.1 The Domain Dictionary 128 5.4.2 Architecture Carryover 128 5.5 History and Such 129 6 What the System is, Part 2: Coding It Up 131 6.1 The Third Step: The Rough Framing of the Code 131 6.1.1 Abstract Base Classes 133 6.1.2 Pre-Conditions, Post-Conditions, and Assertions 137 Static Cling 142 6.1.3 Algorithmic Scaling: The Other Side of Static Assertions 144 6.1.4 Form Versus Accessible Services 146 6.1.5 Scaffolding 147 6.1.6 Testing the Architecture 149 Usability Testing 149 Architecture Testing 149 6.2 Relationships in Architecture 153 6.2.1 Kinds of Relationship 153 6.2.2 Testing the Relationships 155 6.3 Not Your Old Professor's OO 155 6.4 How much Architecture? 159 6.4.1 Balancing BUFD and YAGNI 159 6.4.2 One Size Does Not Fit All 160 6.4.3 When Are You Done? 160 6.5 Documentation? 162 6.6 History and Such 163 7 What the System Does: System Functionality 165 7.1 What the System Does 166 7.1.1 User Stories: A Beginning 166 7.1.2 Enabling Specifications and Use Cases 167 7.1.3 Helping Developers, Too 169 7.1.4 Your Mileage may Vary 170 7.2 Who is Going to Use Our Software? 171 7.2.1 User Profiles 171 7.2.2 Personas 171 7.2.3 User Profiles or Personas? 172 7.2.4 User Roles and Terminology 173 7.3 What do the Users Want to Use Our Software for? 173 7.3.1 Feature Lists 173 7.3.2 Dataflow Diagrams 174 7.3.3 Personas and Scenarios 174 7.3.4 Narratives 174 7.3.5 Behavior-Driven Development 175 7.3.6 Now that We're Warmed Up 175 Prototypes 176 Towards Foundations for Decisions 176 Known and Unknown Unknowns 176 Use Cases as a Decision Framework 177 7.4 Why Does the User Want to Use Our Software? 177 7.5 Consolidation of What the System Does 178 7.5.1 The Helicopter view 181 Habits: The Developer View and the User View 182 Trimming the Scope 185 7.5.2 Setting the Stage 186 7.5.3 Play the Sunny Day Scenario 187 Business Rules 191 7.5.4 Add the Interesting Stuff 193 7.5.5 Use Cases to Roles 200 Roles from the Use Case 201 Bridging the Gap between the Business and the Programmer 202 7.6 Recap 203 7.6.1 Support the User's Workflow 203 7.6.2 Support Testing Close to Development 203 7.6.3 Support Efficient Decision-Making about Functionality 204 7.6.4 Support Emerging Requirements 204 7.6.5 Support Release Planning 204 7.6.6 Support Sufficient Input to the Architecture 205 7.6.7 Support the Team's Understanding of What to Develop 205 7.7 "It Depends": When Use Cases are a Bad Fit 206 7.7.1 Classic OO: Atomic Event Architectures 206 7.8 Usability Testing 208 7.9 Documentation? 209 7.10 History and Such 211 8 Coding It Up: Basic Assembly 213 8.1 The Big Picture: Model-View-Controller-User 214 8.1.1 What is a Program? 214 8.1.2 What is an Agile Program? 215 8.1.3 MVC in More Detail 217 8.1.4 MVC-U: Not the End of the Story 217 A Short History of Computer Science 218 Atomic Event Architectures 219 DCI Architectures 220 8.2 The Form and Architecture of Atomic Event Systems 220 8.2.1 Domain Objects 221 8.2.2 Object Roles, Interfaces, and the Model 221 Example 223 8.2.3 Reflection: Use Cases, Atomic Event Architectures, and Algorithms 224 8.2.4 A Special Case: One-to-Many Mapping of Object Roles to Objects 225 8.3 Updating the Domain Logic: Method Elaboration, Factoring, and Re-factoring 226 8.3.1 Creating New Classes and Filling in Existing Function Placeholders 227 Example 228 8.3.2 Back to the Future: This is Just Good Old-Fashioned OO 229 8.3.3 Analysis and Design Tools 229 8.3.4 Factoring 231 8.3.5 A Caution about Re-Factoring 231 8.4 Documentation? 231 8.5 Why All These Artifacts? 232 8.6 History and Such 233 9 Coding it Up: The DCI Architecture 235 9.1 Sometimes, Smart Objects Just Aren't Enough 235 9.2 DCI in a Nutshell 236 9.3 Overview of DCI 238 9.3.1 Parts of the User Mental Model We've Forgotten 239 9.3.2 Enter Methodful Object Roles 240 9.3.3 Tricks With Traits 242 9.3.4 Context Classes: One Per Use Case 243 9.4 DCI by Example 246 9.4.1 The Inputs to the Design 246 9.4.2 Use Cases to Algorithms 247 9.4.3 Methodless Object Roles: The Framework for Identifiers 250 9.4.4 Partitioning the Algorithms Across Methodful Object Roles 253 Traits as a Building Block 253 In Smalltalk 253 In C++ 254 In Ruby 256 Coding it Up: C++ 257 Coding Up DCI in Ruby 259 9.4.5 The Context Framework 261 The Ruby Code 263 The C++ Code 265 Making Contexts Work 267 Habits: Nested Contexts in Methodful Object Roles 277 9.4.6 Variants and Tricks in DCI 283 Context Layering 283 Information Hiding 283 Selective Object Role Injection 284 9.5 Updating the Domain Logic 285 9.5.1 Contrasting DCI with the Atomic Event Style 286 9.5.2 Special Considerations for Domain Logic in DCI 287 9.6 Context Objects in the User Mental Model: Solution to an Age-Old Problem 290 9.7 Why All These Artifacts? 294 Why not Use Classes Instead of "Methodful Object Roles"? 295 Why not Put the Entire Algorithm Inside of the Class with which it is Most Closely Coupled? 295 Then Why not Localize the Algorithm to a Class and Tie it to Domain Objects as Needed? 296 Why not Put the Algorithm into a Procedure, and Combine the Procedural Paradigm with the Object Paradigm in a Single Program? 296 If I Collect Together the Algorithm Code for a Use Case in One Class, Including the Code for All of its Deviations, Doesn't the Context Become Very Large?' 296 So, What do DCI and Lean Architecture Give Me? 297 And Remember 297 9.8 Beyond C++: DCI in Other Languages 297 9.8.1 Scala 298 9.8.2 Python 299 9.8.3 C# 299 9.8.4 ...and Even Java 29 9.8.5 The Account Example in Smalltalk 300 9.9 Documentation? 300 9.10 History and Such 301 9.10.1 DCI and Aspect-Oriented Programming 302 9.10.2 Other Approaches 302 10 Epilog 305 Appendix A Scala Implementation of the DCI Account Example 307 Appendix B Account Example in Python 311 Appendix C Account Example in C# 315 Appendix D Account Example in Ruby 321 Appendix E Qi4j 327 Appendix F Account Example in Squeak 331 F.1 Testing Perspective 333 F.2 Data Perspective 333 F.2.1 BB5Bank 333 F.2.2 BB5Savings Account 334 F.2.3 BB5Checking Account 334 F.3 Context Perspective 335 F.3.1 BB5Money Transfer Context 335 F.4 Interaction (Role Trait) Perspective 336 F.4.1 BB5Money Transfer Context Transfer Money Source 336 F.4.2 BB5Money Transfer Context My Context 337 F.4.3 BB5Money Transfer Context Transfer Money Sink 337 F.5 Support Perspective (Infrastructure Classes) 337 F.5.1 BB1Context (common superclass for all Contexts) 337 F.5.2 BB1Role Trait (all Role Traits are instances of this class) 339 Bibliography 341 Index 351
• 

• James O. Coplien [저]

• 전체 0개의 구매후기가 있습니다.
• 

인터파크도서는 고객님의 단순 변심에 의한 교환과 반품에 드는 비용은 고객님이 지불케 됩니다. 단, 상품이나 서비스 자체의 하자로 인한 교환 및 반품은 무료로 반품 됩니다. 교환 및 반품이 가능한 경우 상품을 공급 받은 날로부터 7일이내 가능 공급받으신 상품의 내용이 표시, 광고 내용과 다르거나 다르게 이행된 경우에는 공급받은 날로부터 3개월 이내,    혹은 그사실을 알게 된 날 또는 알 수 있었던 날로부터 30일 이내 상품에 아무런 하자가 없는 경우 소비자의 고객변심에 의한 교환은 상품의 포장상태 등이 전혀 손상되지 않은 경우에 한하여 가능 교환 및 반품이 불가능한 경우 구매확정 이후(오픈마켓상품에 한함) 고객님의 책임 있는 사유로 상품 등이 멸실 또는 훼손된 경우    (단, 상품의 내용을 확인하기 위하여 포장 등을 훼손한 경우는 제외) 시간이 지남에 따라 재판매가 곤란할 정도로 물품의 가치가 떨어진 경우 포장 개봉되어 상품 가치가 훼손된 경우 다배송지의 경우 반품 환불 다배송지의 경우 다른 지역의 반품을 동시에 진행할 수 없습니다. 1개 지역의 반품이 완료된 후 다른 지역 반품을 진행할 수 있으므로, 이점 양해해 주시기 바랍니다. 중고상품의 교환 중고상품은 제한된 재고 내에서 판매가 이루어지므로, 교환은 불가능합니다. 오픈마켓 상품의 환불 오픈마켓상품에 대한 책임은 원칙적으로 업체에게 있으므로, 교환/반품 접수시 반드시 판매자와 협의 후 반품 접수를 하셔야하며,    반품접수 없이 반송하거나, 우편으로 보낼 경우 상품 확인이 어려워 환불이 불가능할 수 있으니 유의하시기 바랍니다.

배송예정일 안내 인터파크 도서는 모든 상품에 대해 배송완료예정일을 웹사이트에 표시하고 있습니다. <인터파크 직배송 상품> 상품은 월~토요일 오전 10시 이전 주문분에 대하여 당일 출고/당일 배송완료를 보장하는 상품입니다. 상품은 서울지역/평일 주문분은 당일 출고/익일 배송완료를 보장하며, 서울외지역/평일 주문분의 경우는 오후 6시까지 주문분에 대하여 익일 배송완료를 보장하는 상품입니다. (단, 월요일은 12시까지 주문에 한함) 상품은, 입고예정일(제품출시일)+택배사배송일(1일)에 배송완료를 보장합니다. ~ 상품은 유통특성상 인터파크에서 재고를 보유하지 않은 상품으로 주문일+기준출고일+택배사배송일(1일)에 배송완료를 보장합니다.(토/공휴일은 배송기간에 포함되지 않습니다.) ※기준출고일:인터파크가 상품을 수급하여 물류창고에서 포장/출고하기까지 소요되는 시간 <업체 직접배송/오픈마켓 상품> ~ 상품은 업체가 주문을 확인하고, 출고하기까지 걸리는 시간입니다. 주문일+기준출고일+택배사배송일(2일)에 배송완료를 보장합니다.(토/공휴일은 배송기간에 포함되지 않습니다.) ※5일이내 출고가 시작되지 않을시, 오픈마켓 상품은 자동으로 주문이 취소되며, 고객님께 품절보상금을 지급해 드립니다. 배송비 안내 도서(중고도서 포함)만 구매하시면 : 배송비 2,000원 (1만원이상 구매 시 무료배송) 음반/DVD만 구매하시면 : 배송비 1,500원 (2만원이상 구매 시 무료배송) 잡지/만화/기프트만 구매하시면 : 배송비 2,000원 (2만원이상 구매 시 무료배송) 도서와 음반/DVD를 함께 구매하시면 : 배송비 1,500원 1만원이상 구매 시 무료배송) 도서와 잡지/만화/기프트/중고직배송상품을 함께 구매하시면 : 2,000원 (1만원이상 구매 시 무료배송) 업체직접배송상품을 구매시 : 업체별로 상이한 배송비 적용    * 세트상품의 경우 부분취소 시 추가 배송비가 부과될 수 있습니다.    * 북카트에서 배송비없애기 버튼을 클릭하셔서, 동일업체상품을 조금 더 구매하시면, 배송비를 절약하실 수 있습니다. 해외배송 안내 인터파크도서에서는 국내에서 주문하시거나 해외에서 주문하여 해외로 배송을 원하실 경우 DHL과 특약으로 책정된 요금표에    의해 개인이 이용하는 경우보다 배송요금을 크게 낮추며 DHL(www.dhl.co.kr)로 해외배송 서비스를 제공합니다. 해외배송은 도서/CD/DVD 상품에 한해 서비스하고 있으며, 다른 상품을 북카트에 함께 담으실 경우 해외배송이 불가합니다. 해외주문배송 서비스는 인터파크 도서 회원 가입을 하셔야만 신청 가능합니다. 알아두세요!!! 도매상 및 제작사 사정에 따라 품절/절판 등의 사유로 취소될 수 있습니다. 오픈마켓업체의 배송지연시 주문이 자동으로 취소될 수 있습니다. 출고가능 시간이 서로 다른 상품을 함께 주문할 경우 출고가능 시간이 가장 긴 기준으로 배송됩니다. 유통의 특성상 출고기간은 예정보다 앞당겨지거나 늦춰질 수 있습니다. 택배사 배송일인 서울 및 수도권은 1~2일, 지방은 2~3일, 도서, 산간, 군부대는 3일 이상의 시간이 소요됩니다.