객체지향의 사실과 오해 - 6장(객체지도)

책 예시: 길을 모른다는 문제에 부딪혔을때 ?

1. 길을 물어본다: 기능적이고 해결방법 지향적

- 현재의 요구만을 해결할 수 있다.

 

2. 지도를 보고 찾는다: 구조적이고 문제 지향적

- 범용적

- 요구사항은 계속 변하기 때문에 기능보다는 구조에 초점을 맞춰야 한다.

"기능이 아니라 구조를 기반으로 모델을 구축하는 것이 더 범용적이고 이해하기 쉬우며 변경에 안정적이다. 이것이 객체지향의 지향점이다."

 

 

기능설계 VS 구조설계

 

1. 기능 설계

제품이 사용자를 위해 무엇을 할 수 있는지?

- 전통적인 기능 분해: 분해된 기능끼리 서로 밀접하게 연관

2. 구조 설계

제품의 형태가 어떠해야 하는지?

- 자주 변경되지 않는 안정적인 객체 구조를 바탕으로 시스템 기능을 객체간 책임으로 분배

 

두가지 재료: 구조와 기능

- 구조: 사용자나 이해 관계자들이 도메인에 관해 생각하는 개념과 개념들 간의 관계로 표현 -> 도메인 모델링

- 기능: 사용자의 목표를 만족시키기 위해 책임을 수행하는 시스템의 행위로 표현 -> 유스케이스 모델링

 

안정적인 재료: 구조

도메인 모델

- 도메인: 사용자가 프로그램을 사용하는 대상 분야

- 모델: 대상을 선택적으로 의식화하고 구조화 하여 표현

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

 

 

도메인의 모습을 담을 수 있는 객체지향

애플리케이션은 사용자들이 도메인을 바라보는 관점인 도메인모델을 기반으로 설계되어야 한다.

"도메인 모델 = 사용자들이 도메인을 바라보는 관점(멘탈모델) = 설계자가 시스템 구조를 바라보는 관점 = 소프트웨어 안에 구현된 코드 그 자체"가 성립하는 것이 가장 이상적인 시스템이다.

실체를 객체로, 동적 객체를 정적 객체로 표현할 수 있는 객체지향을 통해 할 수 있다.

 

표현적 차이

- 현실 객체를 은유해서 재창조 한것이 소프트웨어 객체이다.

- 현실 객체와 소프트웨어 객체 사이의 차이를 줄이는 것이 지향점이다.

- 소프트웨어 도메인은 현실에 존재하지 않는 경우가 더 많다. 이 경우에 은유해야 할 대상은 현실 객체가 아닌 "도메인 모델"이다. 즉, 사용자가 해당 도메인을 떠올렸을 때 생각하는 "멘탈모델"에 초점을 맞춰야 한다.

 

불안정한 기능을 담는 안정적인 도메인 모델

사용자 모델은 변경될 확률이 적기 때문에 이를 기반으로 설계와 코드를 만들면 변경에 쉽게 대처할 수 있다.

 

 

불완전한 재료: 기능

유스케이스

- 기능적 요구사항을 얻기 위해서는 시스템 간의 "상호작용"관점에서 시스템을 바라보아야 한다.

- 이때 싱호작용의 흐름이 "유스케이스"

- 유스케이스의 핵심은 사용자의 목표이다.

- 유스케이스는 공통의 사용자 목표를 통해 강하게 연관된 시나리오의 집합이다.

 

유스케이스의 특성

- 사용자와 시스템 간의 상호작용을 보여주는 텍스트. 유스케이스는 다이어그램이 아니다.

- 여러 시나리오들의 집합이며, 이 시나리오 각각을 유스케이스 인스턴스라고 한다.

- 단순한 피처의 목록이 아니다. 여러 개의 피처를 하나의 유스케이스로 묶는 것이 의미있다.

- 요구사항이 자주 변경되는 사용자 인터페이스와 관련된 세부 정보는 담지 않는다. 시스템의 행위에 초점을 맞춘다. 이것을 본질적인 유스케이스라고 한다.

- 내부설계와 관련된 정보를 포함하지 않는다.

 

유스케이스는 설계 기법도, 객체지향 기법도 아니다

- 사용자가 시스템을 통해 무엇을 얻을 수 있고 어떻게 상호작용 할 수 있느냐에 대한 정보만 기술한다.

- 기능적 요구사항을 사용자의 목표라는 문맥을 중심으로 묶기 위한 정리기법

- 객체지향과 연관이 없다.

 

 

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

 

도메인 모델, 유스케이스, 그리고 책임-주도 설계

도메인 모델 -> 안정적인 구조를 개념화하기 위해

유스케이스 -> 불안정한 기능을 서술하기 위해

 

변경에 유연한 소프트웨어를 만들기 위해서 유스케이스에 정의된 시스템의 기능(시스템의 책임)을 도메인 모델을 기반으로 한 객체들의 책임으로 분배

 

- 책임-주도 설계는 유스케이스로부터 첫 번째 메시지와 사용자가 달성하려는 목표를, 도메인 모델로부터 기능을 수용할 수 있는 안정적인 구조를 제공받아 실제로 동작하는 객체들의 협력 공동체를 창조한다.

- 책임 할당의 기본 원칙 -> 책임을 수행하는데 필요한 정보를 가진 객체들에게 그 책임을 할당하는 것