종이에 기록된 모델과 동작하는 소프트웨어 간의 괴리를 어떻게 좁힐것인가?

모델과 코드의 괴리를 좁히는데 여러 설계 방법론에서는 분석 모델의 필요성을 지지한다.

• 분석 모델 (Analysis model) : 소프트웨어 시스템에서 수행할 역할에 대해서는 전혀 고려하지 않은 채 업무 도메인의 개념만을 체계화하고자 해당 업무 도메인을 분석한 결과물
  • 설계와 또렷이 구분되고 다른 사람들이 만든다.
  • 오로지 이해하기 위한 수단으로만 간주되며, 구현 관심사와 섞일 경우 혼란만 초래하는 것으로 여겨진다.
    • 분석 모델은 설계상의 쟁점들을 염두에 두고 만들어진 것이 아니라서
      모델과 설계의 연결을 분석 모델로 진행한다는 것은 매우 비현실적일 가능성이 높다.

• 순수하게 이론에만 치우친 분석 모델
  • 도메인의 이해라는 가장 주된 목표에 미치지 못하기도 하는데, 중요한 발견은 언제나 설계/구현을 위해 노력하는 가운데 나타나기 때문이다. 매우 특이하고 미처 예상치 못한 문제는 늘 일어나기 때문이다.
  • 결과적으로 코딩이 시작되자마자 폐기되고 대부분의 문제를 다시 검토해야 한다.

• How to?
  • 소프트웨어 시스템의 일부를 설계할 때는 도메인 모델을 있는 그대로 반영해서 설계와 모델의 대응을 분명하게 하라
    • (모델) 지식탐구 → (코드) 리팩터링 → …(반복)
      • Ubiquitous Langugage를 지원하는 것과 더불어 분석과 설계 두 가지 측면을 충분히 만족하는 단 하나의 모델을 만들어내야 한다.

Model-Driven Design이 성과를 내려면 인간의 오차 범위 내에서 정확하게 모델이 직접적으로 대응해야 하는데, 이를 만들어낼 수 있는 소프트웨어 도구가 뒷받침되는 모델링 패러다임 내에서 업무를 하는 것이 거의 필수적이다.

그 도구는 OOP. 객체 설계에서의 진정한 도약은 코드가 모델의 개념을 표현할 때 나온다.

반면, Procedural 언어에서는 프로그래머가 도메인의 개념을 생각할 수 있을지언정 프로그램 자체는 데이터를 기술적으로 조작하는 것에 지나지 않기에 의미를 많이 담지 못한다.

• 실제로 사용자가 바라보는 것과 시스템이 불일치한다면 혼란을 일으킬 수도 있고, 최악의 경우 버그를 유발할 수 있다.
  • 왜 사용자가 새로운 모델을 배우게끔 만드는가?

실천적 모델러

Model-Driven Design에서 코드는 모델의 한 표현. 코드의 변경이 곧 모델의 변경. 프로그래머가 곧 모델러!