6장: 객체 지도

서문

길을 찾는 두 가지 방법

• 지나가는 사람에게 물어보는 방법
  • 기능적이고 해결책 지향적인 접근법이다.
  • 일반적이지도, 재사용 가능하지도 않다.
• 지도에 표시된 길을 따라가는 방법
  • 구조적이고 문제 지향적인 접근법이다.
  • 현재의 목적뿐만 아니라 다양한 목적을 위해 재사용될 수 있다. (집으로 가려고 할 때 등)

지도를 사용하는 사람들의 요구사항은 계속 바뀐다. 따라서 기능이 아니라 구조를 기반으로 해야 변경에 안정적이다. 지형은 거의 변하지 않기 때문에 과거의 지도는 현재에도 여전히 유용하게 사용될 수 있다.

---

기능 설계 대 구조 설계

소프트웨어 제품의 설계 또한 기능 설계와 구조 설계로 구분된다.

기능 설계

제품이 사용자를 위해 무엇을 할 수 있는지에 초점을 둔다.

구조 설계

제품의 형태가 어떠해야 하는지에 초점을 둔다.

---

일단 일차적으로 소프트웨어 제품이 존재하는 이유는 요구사항을 충족시키기 위함이다. 따라서 소프트웨어 초기 개발 단계에서는 시스템이 어떤 기능을 제공해야 하는지에 초점을 둬야 한다.

그러나 이후에는 구조가 깔끔해야만 사용자의 변하는 요구사항을 반영할 수 있는 안정적인 소프트웨어를 개발할 수 있다.

소프트웨어는 반드시 요구사항이 변경된다. 미래에 대비하는 가장 좋은 방법은 변경을 예측하는 것이 아니라 변경을 수용할 수 있는 선택의 여지를 설계에 마련해 놓는 것이다.

전통적인 개발방법은 기능 분해 방법으로, 자주 변경되는 기능을 중심으로 설계한 방법이다. 이것은 시스템 기능이 더 작은 기능으로 분해되고 각 기능은 서로 밀접하게 연관되기에 기능이 변경될 경우 소프트웨어가 전체적으로 흔들리게 된다.

그러나 객체지향 접근법은 자주 변경되지 않는 안정적인 구조를 기반으로 설계하기에 시스템 기능을 객체 간의 책임으로 분배한다. 객체지향은 객체의 구조에 집중하고 기능이 객체의 구조를 따르게 한다. 때문에 기능이 변경되더라도 객체 간의 구조는 그대로 유지된다.

---

두 가지 재료: 기능과 구조

기능은 사용자의 목표를 만족시키기 위해 책임을 수행하는 시스템의 행위를 의미한다.

구조는 사용자나 이해관계자들이 도메인(domain)에 관해 생각하는 개념과 개념들 간의 관계로 표현한다.

기능과 구조는 객체지향 세계를 구축하기 위해 필요한 재료들이다. 각각 유스케이스 모델링, 도메인 모델링 작업을 통해 결과물을 얻을 수 있다. (유스케이스 모델, 도메인 모델)

---

안정적인 재료: 구조

도메인이란 사용자가 프로그램을 사용하는 대상 분야를 의미한다.

모델은 대상을 단순화해서 표현한 것을 의미한다.

즉 도메인 모델이란 프로그램을 사용하는 대상 영역에 관한 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태이다.

• 은행 도메인 모델은 고객과 계좌 사이의 돈의 흐름으로 이해한다.
• 중고 자동차 판매상은 구매되는 자동차와 판매되는 자동차의 교환으로 이해한다.

도메인 모델은 이해관계자들이 바라보는 멘털 모델 (Mental Model)이다. 멘털 모델은 사람들이 자기 자신, 다른 사람, 환경, 자신이 상호작용하는 사물들에 대해 갖는 모형이다.

제품을 설계할 때는 제품에 관한 모든 것이 사용자들이 제품에 대해 가지고 있는 멘털 모델과 정확히 일치해야 한다. - 도널드 노먼 (Donald Norman)

 

멘털 모델은 다음과 같이 구성된다.

• 사용자 모델: 사용자가 제품에 대해 가지고 있는 개념들의 모습이다.
• 디자인 모델: 설계자가 마음속에 갖고 있는 시스템에 대한 개념화를 의미한다.
• 시스템 이미지: 최종 제품을 뜻한다.

사용자와 설계자는 직접적으로 상호작용할 수 없고 단지 시스템을 통해서만 상호작용할 수 있기에 설계자는 디자인 모델을 기반으로 만든 시스템 이미지가 사용자 모델을 정확하게 반영하도록 해야 한다.

소프트웨어의 코드는 도메인 모델을 통해 표현되는 도메인 객체들을 은유해야 한다.

코드의 구조가 도메인의 구조를 반영하게 되면 도메인을 이해했을 때 코드를 이해하기 쉬워진다.

또한 도메인 모델을 기반으로 코드를 작성해야 하는 이유는 도메인 모델이 제공하는 구조가 상대적으로 안정적이기 때문이다. 그 이유는 사용자 모델에 포함된 개념과 규칙은 비교적 변경될 확률이 적으며 사용자들이 도메인의 본질적인 측면을 가장 잘 이해하고 있기 때문이다.

결론적으로는 소프트웨어는 결국 사용자들의 도메인 모델을 충분히 은유할 수 있어야 하기에, 그들이 가지고 있는 도메인 모델을 코드에 녹여낼 수 있도록 해야 한다.

---

불안정한 재료: 기능

훌륭한 기능적 요구사항을 얻기 위해서는 목표를 가진 사용자와 사용자의 목표를 만족시키기 위해 일련의 절차를 수행하는 시스템 간의 ‘상호작용’ 관점에서 시스템을 바라봐야 한다.

유스케이스는 사용자의 목표를 달성하기 위해 사용자와 시스템 간에 이뤄지는 상호작용의 흐름을 텍스트로 정리한 것을 뜻한다. 유스케이스는 공통의 사용자 목표를 통해 강하게 연관된 시나리오의 집합이다.

 

• 사용자들의 목표를 중심으로 시스템의 기능적인 요구사항들을 이야기 형식으로 묶을 수 있다.
• 요구사항을 기억하고 관리하는 데 필요한 다양한 정신적 과부하를 줄인다.
• 유스케이스는 사용자 인터페이스와 관련된 세부 정보를 포함하지 말아야 한다. 사용자 인터페이스는 자주 변경될 여지가 있기 때문이다.
• 유스케이스는 내부 설계와 관련된 정보를 포함하지 않는다.

유스케이스는 단지 사용자가 바라보는 시스템의 외부 관점만을 표현한다. 사용자가 시스템을 통해 무엇을 얻을 수 있고 어떻게 상호작용할 수 있느냐에 관한 정보만 기술된다. 그렇기 때문에 유스케이스를 통해 객체의 구조를 쉽게 추출할 수 있다는 것은 틀린 말이다!

 

ex) 이자액 계산 유스케이스

유스케이스명: 중도 해지 이자액을 계산한다.
일차 액터: 예금주
주요 성공 시나리오:
    1. 예금주가 정기예금 계좌를 선택한다.
    2. 시스템은 정기예금 계좌 정보를 보여준다.
    3. 예금주가 금일 기준으로 예금을 해지할 경우 지급받을 수 있는 이자 계산을 요청한다.
    4. 시스템은 중도 해지 시 지급받을 수 있는 이자를 계산한 후 결과를 사용자에게 제공한다.
확장:
    3a. 사용자는 해지 일자를 다른 일자로 입력할 수 있다.

---

재료 합치기: 기능과 구조의 통합

위에서 언급한 도메인 모델 (구조)과 유스케이스 (기능)의 통합을 통해 변경에 유연한 소프트웨어를 설계할 수 있다.

즉 유스케이스에 정리된 시스템의 기능을 도메인 모델을 기반으로 한 객체들의 책임으로 분배해야 한다.

이는 책임-주도 설계와 결합된다. 책임-주도 설계는 유스케이스로부터 첫 번째 메시지와 사용자가 달성하려는 목표를, 도메인 모델로부터 기능을 수용할 수 있는 안정적인 구조를 제공받아 실제로 동작하는 객체들의 협력 공동체를 창조한다. 견고한 애플리케이션을 개발하기 위해서는 사용자의 관점에서 시스템의 기능을 명시하고, 사용자와 설계자가 공유하는 안정적인 구조를 기반으로 기능을 책임으로 변환하는 체계적인 절차를 따라야 한다.

객체의 이름은 도메인 모델에 포함된 개념으로부터 차용하고, 책임은 도메인 모델에 정의한 개념의 정의에 부합하도록 할당하라.

---

요약

• 소프트웨어를 설계할 때는 변경에 덜 취약한 구조를 기반으로 설계해야 한다. 사용자들의 기능 요구사항은 변경될 여지가 빈번하기 때문이다.
• 도메인 모델과 유스케이스 모델을 기반으로 기능과 구조를 모두 담아내는 소프트웨어를 설계해야 한다. 도메인 모델은 사용자들이 생각하고 있는 도메인에서의 개념을 의미하기에 우리는 그것을 코드로 은유할 수 있어야 한다.
• 유스케이스 모델은 시스템 차원에서의 기능 (책임)을 제공하며, 우리는 그것을 책임-주도 개발로 개발해 나가야 한다.
• 유스케이스에 정리된 시스템의 기능을 도메인 모델을 기반으로 한 객체들의 책임으로 분배하라.