[객체지향의 사실과 오해] 6장 내용정리

2022.03.01 - [IT 책 독서록] - [객체지향의 사실과 오해] 5장 내용정리

[객체지향의 사실과 오해] 5장 내용정리

1 ~ 5장까지의 내용은 결국 책임 주도 설계에 대해 다뤘다고 해도 과언이 아닐만큼 모든 내용이 책임주도 설계로 이어졌다. 책에서 직접 언급했듯, 책임은 결국 소프트웨어의 기능이다. 따라서 1 ~ 5장까지는 기능을 바탕으로 어떻게 설계해야 하는지 이야기 했다. 각 기능을 더 작은 기능으로 구분하고 그것을 적절한 객체에 책임이라는 이름으로 부여하는 것이 1 ~ 5장까지의 내용이다. 6장에서는 구조를 바탕으로 시스템을 분할하는 측면에 대해 이야기 한다.

 

기능설계 vs 구조설계

소프트웨어의 설계는 두가지 측면이 존재한다.

1. 기능 측면의 설계 : 제품이 사용자를 위해 무엇을 할 수 있는지가 초점
2. 구조 측면의 설계 : 제품의 형태가 어떠해야 하는지가 초점

요구사항은 언제나 변경되고 예측할 수 없다. 다만 대비할 수 있을 뿐이다. 따라서 설계의 일차적인 목표는 나중에 있을 변경에 소요되는 비용을 낮추는 것이다. 

변경에 대비하고 변경의 여지를 남겨놓는 가장 좋은 방법은 기능이 아닌 안정적인 구조를 중심으로 설계하는 것이다.

 

기능 : 사용자가 자신의 목표를 달성하기 위해 사용할 수 있는 시스템의 서비스.

구조 : 시스템의 기능을 구현하기 위한 기반으로, 기능변경을 수용할 수 있도록 안정적이여야 한다.

 

기능은 사용자의 목표를 만족시키기 위해 책임을 수행하는 시스템의 행위로 표현되고, 구조는 사용자나 이해관계자들이 도메인에 관해 생각하는 개념과 개념들 간의 관계로 표현한다.

구조 설계

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

모델 : 대상을 단순화 해서 표현한 것. 지식을 선택적으로 단순화하고 의식적으로 구조화 한 형태. => 대상을 추상화하고 단순화 한 것.

도메인 모델 : 사용자가 프로그램을 사용하는 대상 영역에 관한 지식을 선택적으로 단순화하고 의식적으로 구조화 한 형태. 소프트웨어 개발과 관련된 이해관계자들이 도메인에 대해 생각하는관점. 이해관계자들이 바라보는 멘탈모델이다.

멘탈 모델 : 사람들이 자기 자신, 다른 사람, 환경, 자신이 상호작용하는 사물들에 대해 갖는 모형.

설계자는 도메인에 대한 디자인모델을 기반으로 만든 시스템 이미지가 사용자 모델을 정확하게 반영하도록 노력해야 한다. 즉, 설계자가 만든 시스템이 사용자가 생각하는 시스템을 정확히 반영하도록 해야 한다. 도메인 모델은 이를 모두 포괄하도록 하는 멘탈모델이다.

 

결국, 최종 제품은 사용자의 관점을 반영해야 한다. 이는 곧 애플리케이션이 도메인 모델을 기반으로 설계돼야 한다는 것을 의미한다. → 도메인 모델을 사용하는 첫번째 이유

 

객체지향을 이용하면 도메인에 대한 사용자 모델, 디자인 모델, 시스템 이미지 모두가 유사한 모습을 유지하도록 만드는 것이 가능하다. 이걸 연결완전성 혹은 표현적 차이 라 한다.

 

도메인 모델을 객체로

 

소프트웨어 객체는 현실 객체를 은유를 기반으로 재창조 한 것이다. 무엇을 은유해야 하는가? 도메인 모델을 은유해야 한다.

도메인 모델은 사용자가 도메인을 바라보는 시선이다. 따라서 도메인 모델을 기반으로 설계하고 구현하는 것은 곧 사용자가 도메인을 바라보는 관점을 그대로 코드에 반영할 수 있게 하는 것이다.

코드는, 도메인 모델의 개념과 관계를 은유해야 한다. 

 

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

 

사용자는 누구보다도 도메인의 본질적인 측면을 가장 잘 이해하고 있다. 본질적이라는 것은 변경이 적고 비교적 그 특성이 오랜기간 유지된다는 것을 의미한다. 즉, 도메인 모델을 이용하면 변경에 유연하게 대응할 수 있는 시스템이 만들어진다. → 도메인 모델을 사용하는 두번째 이유

 

유스케이스 

 

도메인 모델이 도메인과 관련된 중요한 개념과 관계를 보여준다고 해도, 결국 사용자에게 제일 중요한 것은 기능이다.

이 기능을 기술하기 위해 유스케이스라는 기법을 사용한다.

 

유스케이스 : 사용자의 목표를 달성하기 위해 사용자와 시스템 간에 이뤄지는 상호작용의 흐름을 텍스트로 정리한 것.

앨리스터 코어번에 의해 체계화된 유스케이스 설명

유스케이스는 시스템의 이해관계자들 간의 계약을 행위 중심으로 파악한다. 유스케이스는 이해관계자들 중에서 일차 액터라 불리는 행위자의 요청에 대한 시스템의 응답으로서, 다양한 조건하에 있는 시스템의 행위를 서술한다. 일차 액터는 어떤 목표를 달성하기 위해 시스템과의 상호작용을 시작한다. 시스템은 모든 이해관계자들의 요구에 응답하고 이해관계를 보호해야 한다. 특별한 요청과 관계되는 조건에 따라 서로 다른 일련의 행위 혹은 시나리오가 전개될 수 있다. 유스케이스는 이렇게 서로 다른 시나리오를 묶어 준다[Cockbum 2000].

일차 액터 : 시스템의 서비스 중 하나를 요청하는 이해관계자. 하나의 목표를 가지고 유스케이스를 시작하는 액터.

유스케이스 예시

유스케이스명: 중도 해지 이자액을 계산한다.

일차 액터: 예금주

주요 성공 시나리오

1. 예금주가 정기예금 계좌를 선택한다.

2. 시스템은 정기예금 계좌 정보를 보여준다.

3. 예금주가 금일 기준으로 예금을 해지할 경우 지급받을 수 있는 이자 계산을 요청한다.

4. 시스템은 중도 해지 시 지급받을 수 있는 이자를 계산한 후 결과를 사용자에게 제공한다.

 

확장:

3a. 사용자는 해지 일자를 다른 일자로 입력할 수 있다.

유스케이스의 특성

1. 유스케이스는 사용자와 시스템간의 상호작용을 보여주는 '텍스트'다. 다이어그램이 아니다.
2. 유스케이스는 하나의 시나리오가 아니라 여러 시나리오들의 집합이다.
3. 유스케이스는 단순한 기능 목록과 다르다. 여러기능을 포함하는 이야기를 제공하여 문맥을 얻을 수 있다.
4. 유스케이스는 사용자 인터페이스와 관련된 세부 정보를 포함하지 말아야 한다.
5. 유스케이스는 내부 설계와 관련된 정보를 포함하지 않는다.

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

유스케이스는 단지 사용자가 바라보는 시스템의 외부 관점을 표현하는 것 뿐이다. 내부 구조나 실행 메커니즘등에 관한 어떤 정보도 제공하지 않는다. 단지 기능적 요구사항을 사용자의 목표라는 문맥을 중심으로 묶기 위한 정리 기법일 뿐이다. 유스케이스는 객체의 구조나 책임에 대한 어떤정보도 제공하지 않는다.

 

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

시스템의 책임은 유스케이스로부터 나온다.

책임을 어떤 객체에게 부여할 것인가는 도메인모델로부터 나온다.

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

 

꼭 도메인모델과 유스케이스를 사용해야 하는 것은 아니다. 중요한 것은 견고한 객체지향 애플리케이션을 개발하기 위해서는 사용자의 관점에서 시스템의 기능을 명시하고, 사용자와 설계자가 공유하는 안정적인 구조를 기반으로 기능을 책임으로 변환하는 체계적인 절차를 따라야 한다는 것이다. 다만, 객체지향 프로그래밍은 도메인을 모델링하기 위한 기법과 도메인을 프로그래밍하기 위해 사용하는 기법이 동일하다기 때문에 도메인 모델링에서 사용한 객체와 개념을 프로그램이 설계에서의 객체와 클래스로 매끄럽게 변경할 수 있어서 적도메인 모델링은 객체지향에 적합하다.

실세계에서는 수동적인 존재라도, 소프트웨어 객체로 구현될 때는 스스로 판단하고 행동하는 자융적인 존재로 변한다.

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