책 리뷰 - 객체지향의 사실과 오해6

06 / 객체 지도

 

길을 찾아가는 방법
1. 길을 직접 물어본다.
2. 지도에 표시된 길을 따라간다.

 

지도를 사용하는 이유는 '기능'에 비해 '구조'가 더안정적이다. 기능에 비해 상대적으로 잘 벼하지 않는 안정적인 지형 정보를 기반한다.

 

=> 구조를 기반으로 모델을 구축하는 편이 좀 더 범용적이고 이해하기 쉬우며 변경에 안정적이다.
=> 객체지향은 자주 변경되는 기능이 아니라 안정적인 구조를 기반으로 시스템을 구조화한다.

 

기능 설계 대 구조 설계

 

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

 

훌륭한 기능을 제공하는 동시에 사용자가 원하는 새로운 기능을 빠르고 안정적으로 추가할 수 있어야한다.
-> 깔끔, 단순하며 유지보수하기 쉬운 설계는 사용자의 변하는 요구사항을 반영할 수 있도록 쉽게 확장 가능하다.

 

요구사항은 변경된다.
-> 예측불가능한 요구사항 변경에 유연하게 대처할 수 있는 안정적인 구조를 제공하는 능력을 갖춰야한다.

 

객체지향 접근방법은 자주 변경되지 않는 안정적인 객체 구조를 바탕으로 시스템 기능을 객체 간의 책임으로 분배한다. 구조에 집중, 기능이 객체의 구조를 따르게 한다. 시스템 기능은 더 작은 책임으로 분할되고 객체에게 분배되기 때문에 기능이 변경되어도 구조는 유지된다.
-> 객체를 기반으로 책임과 역할을 식별하고 메시지를 기반으로 객체들의 협력 관계를 구축하는 이유

 

기능과 구조

 

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

 

기능 수집하고 표현하기 위한 기법: 유스케이스 모델링
구조 수집하고 표현하기 위한 기법: 도메인 모델링
두 모델링 결과물 : 유스케스와 도메인 모델

 

도메인 모델

 

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

 

모델: 대상을 단순화해서 표현한 것, 지식을 선택적으로 단순화하고 의식적으로 구조화, 필요한 지식만 재구성 -> 대상을 추상화하고 단순화 한 것

 

도메인 모델 : 사용자가 프로그램을 사용하는 대상 영역에 관한 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태, 소프트웨어가 목적하는 영역 내의 개념과 개념 간의 관계, 다양한 규칙이나 제약 등을 주의 깊게 추상화한 것, 개발과 관련된 이해관계자들이 도메인에 대해 생각하는 관점

 

멘탈 모델

 

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

 

멘탈모델 : 사용자 모델, 디자인 모델, 시스템 이미지
사용자 모델: 사용자가 제품에 대해 가지고 있는 개념
디자인 모델: 설계자가 마음 속에 갖고 있는 시스템에 대한 개념화
시스템 이미지: 최종 제품

 

사용자 모델, 디자인 모델 동일하다면 이상적이지만 사용자와 설계자는 '시스템'을 통해서만 의사소통할 수 있다.
-> 설계자는 디자인 모델을 기반으로 만든 시스템 이미지가 사용자 모델을 정확하게 반영하도록 노력해야한다.

 

객체지향

 

도메인의 구조와 최대한 유사하게 코드를 구조화할 수 있다.
동적인 객체가 가진 복잡성을 극복하기 위해 정적인 타임을 이용해 세상을 단순화할 수 있으며, 클래스라는 도구를 이용해 타입을 코드안으로 옮길 수 있다.
-> 객체지향을 이용하면 도메인에 대한 사용자 모델, 디자인 모델, 시스템 이미지 모두가 유사한 모습을 유지하도록 만드는 것이 가능하다.
=> 연결완전성, 표현적차이

 

표현적 차이

 

은유: 객체 사이의 관계를 가장 효과적으로 표현할 수 있는 단어
소프트웨어 객체는 현실 객체가 갖지 못한 특성을 가질 수도 있고 현실객체가 하지 못하는 행동을 할 수도 있다.
소프트웨어 객체는 현실 객체의 특성을 토대로 구축된다.
소프트웨어 객체와 현실 객체의 사이의 의미적 거리를 가리켜 표현적 차이, 의미적 차이라고한다.

 

은유를 통해 투영해야하는 대상: 사용자가 도메인에 대해 상각하는 개념

-> 소프트웨어 객체를 창조하기 위해 우리가 은유해야 하는 대상은 도메인 모델
-> 표현적 차이는 줄어들 것, 사용자의 멘탈 모델이 그대로 코드에 녹아 스며들게 될 것

 

표현적 차이가 중요한 이유는 소프트웨어를 이해하고 수정하기 쉽게 만들어주기 때문이다. , 도메인을 이해하면 코드를 이해하기 수월하다.
도메인 속 개념과 관계가 코드 속에 녹아 있기 때문에 도메인이 알려주는 길을 따라가면 길을 잃지 않는다. -> 지도를 제공한다.

 

안정적인 도메인모델

 

도메인 모델이 제공하는 구조가 상대적으로 안정적이다.
사용자가 도메인을 바라보는 관점을 반영해 소프트웨어를 설계하고 구현한다.
사용자들은 도메인을 구성하는 중요한 개념과 개념 간의 관계를 잘 알고 있는 사람들이다.
본질적: 변경이 적고 비교적 그 특성이 오랜 시간 유지된다는 것
포함된 개념과 규칙은 비교적 변경될 확률이 적기 때문에 사용자 모델을 기반으로 설계와 코드를 만들면 변경에 쉽게 대처할 수 있다.
-> 안정적인 구조를 제공하는 도메인 모델을 기반으로 소프트웨어 구조를 설계하면 변경에 유연하게 대응할 수 있는 탄력적인 소프트웨어를 만들 수 있다.

 

사람들이 정기 예금에 관해 생각하는 개념과 규칙을 모두 포함한다.
정기예금의 정의가 변경되지 않는 한 개념의 정의 ,속성 쉽게 바뀌지 않는다.

 

유스케이스

 

사용자와 시스템 간에 이뤄지는 상호작용의 흐름
일차 액터(primary actor) 서비스 중 하나를 요청하는 이해관계자로, 하나의 목표를 가지고 유스케이스를 시작하는 액터
기능적인 요구사항들을 이야기 형식으로 묶을 수 있다.
->사용자 목표가 유스케이스의 핵심이다. 유스케이스는 공통의 사용자 목표를 통해 강하게 연관된 시나리오의 집합

 

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

 

1.유스케이스는 사용자와 시스템 간의 상호작용을 보여주는 '텍스트' 이다.
2.여러 시나리오들의 집합, 시스템을 사용하는 하나의 특정한 이야기 또는 경로

 

사용자가 바라보는 시스템의 외부 관점만을 표현하다.
내부 구조나 실행 매커니즘에 관한 어떤 정보도 주지 않는다.
사용자가 시스템을 통해 무엇을 얻을 수 있고 어떻게 상호작용할 수 있느냐

 

협력

 

도메인 모델은 안정적인 구조를 개념화하기 위해,
유스케이스는 불안정한 기능을 서술하기 위해 일반적으로 사용되는 도구

 

협력을 완성하는 데 필요한 메시지를 식별하면서 객체들에게 책임을 할당해 나간다. 객체를 구현하기 위해 클래스를 추가하고 속성과 함께 메서드를 구현하면 시스템의 기능이 완성된다.

 

요구사항들을 식별하고 도메인 모델을 생성한 후 소프트웨어 클래스에 메서드를 추가하고, 요구사항을 충족시키기 위해 객체들 간의 메시지 전송을 정의하라

 

객체의 이름은 도메인 모델에 포함된 개념으로부터 차용하고, 책임은 도메인 모델에 정의한 개념의 정의에 부합하도록 할당한다.
이자를 계산하는 책임을 가진 객체는 이자율, 이자는 이자율에 의해 생성
-> 책임을 수행하는데 필요한 정보를 가진 객체에게 그 책임을 할당

 

도메인 모델이 안정적인 이유

 

1.도메인 모델을 구성하는 개념은 비즈니스가 없어지거나 완전히 개편되지 않는 한 안정적으로 유지된다. 정기예금 도메인에서 정기예금과 계좌, 이자율, 이자란 개념은 정기예금이란 금융상품이 없어지거나 완전히 개편되지 않는 한 안정적으로 유지되는 개념이다.

 

2.도메인 모델을 구성하는 개념간의 관계는 비즈니스 규칙을 기반으로 하기 때문에 비즈니스 정책이 크게 변경되지 않는 한 안정적으로 유지된다. 정기예금 도메인에서 이자는 정기예금이 만기가 되거나 중도 해지를 하는 경우에 한해서 단 한 번 지급된다. 따라서 계좌와 이자 간의 0..1 관계는 이와 같은 핵심적인 비즈니스 규칙이 변경되지 않는 한 동일하게 유지될 것이다.

=> 도메인 모델을 중심으로 객체 구조를 설계하고 유스케이스의 기능을 객체의 책임으로 분배한다.
기능적인 요구사항이 변경될 경우 책임과 객체 간의 대응 관계만 수정됨

 

요약

 

핵심적인 클래스와 클래스 간의 관계는 그대로 유지된다. 변경되거나 추가돼도 대부분의 클래스 구조가 그대로 유지되는 이유는 도메인 구성하는 기본적인 개념과 관계를 포함하는 도메인 모델을 기반으로 시스템의 기능을 대응시켰기 때문

 

안정적인 도메인 모델을 기반으로 시스템의 기능을 구현할 경우 시스템의 기능이 변경되더라도 비즈니스의 핵심 정책이나 규칙이 변경되지 않는 한 전체적인 구조가 한 번에 흔들리지 않는다.

 

도메인 모델은 문서나 다이어그램이 아니다. 공유된 멘탈 모델이다.
사람들이 동일한 용어와 동일한 개념을 이용해 의사소통하고 코드로부터 도메인 모델을 유추할 수 있게 하는 것이 도메인 모델의 진정한 목표이다.

 

=> 안정적인 도메인 모델을 기반으로 시스템의 기능을 구현하라. 도메인 모델과 코드를 밀접하게 연관시키기 위해 노력하라.
=> 유지보수하기 쉽고 유연한 객체지향 시스템을 만든다.

 

회고

 

최근 수업때 사용자의 요구사항을 보고 도메인모델도 작성해보고 유스케이스도 작성해보았다. 사용자가 필요한 기능에대해 개념들을 뽑아 내서 정리한 후 유스케이스를 작성했다.
상품 재고관리 프로그램에 대해 각 케이스별로 액터와 시나리오를 작성했다. 예를 들어 입출고 담당자라는 액터가 '신제품 입고'에 대해
1.납품업체에 제품 입고를 요구한다.
2.입출고 담당자는 주문한 제품이 맞는지 확인한다.
3.제품 상태를 확인한다.
4. 제품을 입고하고 제품 목록을 현황 관리 담당자에게 알린다.
와 같이 시나리오를 짰다.

 

이 책을 읽기전까지 그냥 유스케이스 예시에 맞춰 작성했지만, 중요한건 본질적(변경이 적고 비교적 그 특성이 오랜시간 유지되는것)이다.
신제품 입고에 대해서 입고 도메인, 업체, 입출고 담당자 도메인은 쉽게 변하지 않는다. 프로그램을 구현한다면 핵심 정책이나 규칙이 변경되지 않는 한 전체적인 구조가 한 번에 흔들리지 않을 것같다.

 

시켜서 해봤던 과제에 대해서 모델의 필요성을 더 느꼈고, 프로그램 개발에 있어서 도메인 모델은 꼭 필요하다고 생각했다.