[객체지향의 사실과 오해] 6장 - 객체 지도

[객체지향의 사실과 오해] 5장 - 책임과 메시지

📌이 장에서는...

클라이언트의 요구사항은 언제나 변할 수 있다. 요청 서비스가 개발 중이거나 개발이 완료하고 난 후에도 언제나 발생할 수 있다. 변화하는 요구사항에 대처하기 위해서 우리는 기능보다 구조에 집중을 해야 한다고 책에서 제시하고 있다. 이는 구조적이고 문제 지향적인 접근법으로 불리며 지도에서 길을 찾는 데 필요한 구체적인 기능이 아니라 길을 찾을 수 있는 구조를 제공한다.

 

즉, 자주 변경되는 기능이 아니라 안정적인 구조를 따라 역할, 책임, 협력을 구성하는 것에 대해 설명하는 장이다.

사용자 측면에서의 요구사항을 통해 기능을, 시스템 이해관계자들의 측면에서의 도메인 개념을 통해 구조를 도출함으로써 이를 통합하여 객체지향 세계를 만들어 내, 요구사항 변경에 가변적인 구조 위에서 요구사항을 충족시키는 시스템을 만들어낼 수 있게 도와주는 장이다.

책임-주도 설계 방식으로 객체지향 세계를 만들어내는데 힌트를 얻을 수 있는 장이었다.

---

1. 기능 설계 대 구조 설계

모든 소프트웨어 제품의 설계에는 기능 측면의 설계와 구조 측면의 설계가 있다. 기능 측면의 설계는 제품이 사용자를 위해 무엇을 할 수 있는지에 대해 초점을 맞추는 반면 구조 측면의 설계는 제품의 형태가 어떠해야 하는지에 대해 초점을 맞춘다. 설계의 가장 큰 도전은 기능과 구조의 두 가지 측면을 함께 녹여 조화를 이루게 하는 것이다.

 

훌륭한 소프트웨어를 제공하기 위해서 기능 측면의 설계 고려는 충분조건, 구조 측면의 설계는 필요조건이다. 따라서 훌륭한 소프트 웨어는 구조 측면의 설계를 충분히 고려해 변경되는 요구사항을 충분히 고려하는 소프트웨어가 된다.

 

구조 측면의 설계를 고려하기 위해서는 자주 변경되지 않는 안정적인 객체 구조를 바탕으로 객체 간의 책임을 분배한다. 분배한 책임으로 부터 역할을 식별하고 메시지 기반으로 객체의 협력을 구성해 앞선 장에서 설명했듯이 변경을 받아들일 수 있는 소프트웨어를 설계할 수 있다.

 

2. 두가지 재료: 기능과 구조

객체지향 설계를 위해서 사용자에게 제공할 '기능'과 기능을 담을 '구조'라는 재료가 있어야 한다. 기능과 구조 재료의 조달은 다음과 같은 곳에서 구한다.

• 기능 : 사용자의 목표를 만족시키기 위해 책임을 수행하는 시스템의 행위 (유스케이스)
• 구조 : 사용자나 이해관계자들이 도메인에 관해 생각하는 개념과 개념들 간의 관계 (도메인 모델)

안정적인 재료: 구조 - 도메인 모델

도메인 모델에서 도메인은 소프트웨어를 사용하는 사람들이 자신이 관심을 가지고 있는 특정 분야와 사용자가 프로그램을 사용하는 대상 분야를 말한다. 모델은 대상을 단순화해서 표현한 것으로 지식을 단순화하고 의식적으로 구조화한 형태이다.

도메인 모델은 도메인의 본질을 잘 이해하고 있는 사람들로부터 나오므로 도메인은 쉽게 변하지 않기 때문에 기능보다 더욱 안정적인 구조를 제공할 수 있다.

 

하지만 객체는 이 책의 앞부분에서 말했던 것처럼 현실 세계의 사물과 사람에 완벽히 대응하지 않는다. 예를 들어 물병이 스스로 물을 비울 수 없는 것처럼. 이것의 용어는 표현적 차이 또는 의미적 차이라고 부른다.

도메인 객체의 표현적 차이를 줄이기 위해서 은유를 통해서 도메인 객체를 구성해야 하는데 이것은 바로 사용자가 도메인에 대해 생각하는 개념들이다.

자세한 집합/구성/상속관계를 설정하지 않은 간단한 카페 시스템의 도메인 모델 예시이다.

불안정한 재료: 기능 - 유스케이스

유스케이스란 사용자의 목표를 달성하기 위해 사용자와 시스템 간에 이루어지는 상호작용의 흐름을 나타낸것이다. 여기서 사용자는 외부 시스템이 될 수도 있다.

 

다음은 유스케이스의 특성이다.

• 첫째, 유스케이스는 사용자와 시스템 간의 상호작용을 보여주는 텍스트이다. 다이어그램이 아니다.
• 둘째, 유스케이스는 하나의 시나리오가 아니라 여러 시나리오들의 집합이다.
• 셋째, 유스케이슨느 단순한 피쳐(feature) 목록과 다르다. 연관 기능들을 연관지을 수 있다.
• 넷째, 유스케이스는 사용자 인터페이스와 관련된 세부 정보를 포함하지 말아야 한다.
• 다섯째, 유스케이스는 내부 설계와 관련된 정보를 포함하지 않는다.

한가지 명심해야 할 것은 유스케이스는 설계 기법도, 객체지향 기법도 아니다. 단지 기능적 요구사항을 사용자 관점에서 정리할 수 있고 기능들을 문맥상으로 묶어 정리할 수 있다는 점이 특징이다.

위는 유스케이스의 예시이다. 관계의 명확한 분리는 하지 않고 간단하게 표현해 보았다.

3. 도메인 모델, 유스케이스, 책임-주도 설계

책임-주도 설계는 유스케이스부터 출발한다. 시스템과 사용자의 협력의 텍스트 흐름을 기능으로 변환하고 또 이를 시스템의 책임으로 변경한다. 기능을 담기 위한 구조인 이해 관계자의 도메인 모델을 은유를 통해 얻어낸다.

도메인 모델의 객체에 유스케이스로 부터 도출한 책임을 분할하여 통합함으로써 책임-주도 설계를 완수한다.