링크 - http://yimay.kr/t499o6dfsz

03 모델과 구현의 연계

MODEL-DRIVEN DESIGN(모델 주도의 설계)

• 분석 모델
  • 설계와 구분
  • 소프트웨어에서 수행할 역할 고려 X
  • 업무 도메인 개념만 체계화, 업무 도메인 분석의 결과물
  • 이해하기 위한 수단
• 설계와 도메인 모델이 대응 되어야 한다.
• 복잡한 대응은 이해가 어렵고 유지보수가 어렵다.
• 도메인 모델을 설계와 밀접하게 연관시키는 원칙을 강제시, 모델 중 유용한 것을 선택하는 또 하나의 기준이 된다.
• 설계시, 도메인 모델을 있는 그래도 반영, 설계와 모델의 대응을 분명하게 하라.
• 모델에서 사용한 용어들을 설계에서 사용.
• 개발은 모델, 설계 코드를 단일한 활동으로 정제하는 반복적인 과정이 된다.

모델링 패러다임과 도구 지원

• 모델과 구현이 직접적으로 대응
• 객체 설계에서의 진정한 도약은 코드가 모델의 개념을 표현할 때 나온다.
• 언어별 MODEL-DRIVEN DESIGN 을 적용하기 어려운 언어가 있다.
• 설계는 한 번에 나타나는 것이 아니라, 리팩토링과 지식탐구의 과정이 수차례 반복

내부 드러내기 : 왜 모델이 사용자에게 중요한가

• 사용자가 바라보는 것과 시스템이 불일치, 혼란 야기
• MODEL-DRIVEN DESIGN 에서는 (모든 단일 컨텍스트 내에서) 오로지 하나의 모델을 다룰 것을 요구한다.
• 설계가 사용자와 도메인 전문가의 기본적인 관심사를 반영한 모델에 기반을 두면, 설계가 더 큰 범위에 걸쳐 사용자에게 드러날 수 있다.

HANDS-ON MODELER(실천적 모델러)

• 분석과 모델링, 설계, 프로그래밍에 대한 책임을 지나치게 구분하는 것은 MODEL-DRIVEN DESIGN 과 상충한다.
• 모델의 구현과 기술과의 상호작용에 대한 피드백이 간접적이어서는 안된다.
• 코드는 작성한느 사람이 모델에 책임을 느끼지 못하거나 애플리케이션을 대상으로 모델이 동작하게 만드는 법을 모른다면, 그 모델은 소프트웨어와 무관해진다.
• 코드의 변경이 곧 모델의 변경
• 설계자가 구현을 하지 못해 단절이 생기면, 숙련된 설계자의 노하우는 결코 다른 개발자에게 전해지지 못한다.
• 프로그래머가 곧 모델러다.

• 코드를 변경하는 책임이 있는 모든 이들은 코드를 통해 모델을 표현하는 법을 반드시 배워야한다.

• 규모가 큰 프로젝트에서는 가장 어렵거나 중요한 의사결정을 내리는 것을 돕는 기술적 측면의 리더가 필요하다.

• 모데인 주도 설계는 모델을 동작하게 만들어 애플리케이션의 문제를 해결한다.