[6장] 객체 지도

유일하게 변하지 않는 것은 모든 것이 변한다는 사실 뿐이다 - 헤라클레이토스

위와 같은 인용문구를 통해 애플리케이션을 개발할때 신경써야 하는 부분은 애플리케이션을 개발함에 있어 사용자의 요구사항은 언제든지 변할 수 있고 그 변화에 대응할 수 있도록 객체지향적 설계를 해야 한다 라는 것입니다.

자주 변경되는 기능이 아니라 안정적인 구조를 따라 역할, 책임, 협력을 구성하여 객체지향 설계를 해야 합니다.

 

기능 설계 대 구조 설계

기능 설계

 - 제품이 사용자를 위해 무엇을 할 수 있는지에 초점을 맞추어 설계 하는것

 - 사용자에게 제공할 기능

구조 설계

 - 제품의 형태가 어떠해야 하는지에 대해 초점을 맞추어 설계 하는것

 - 기능을 담을 안정적인 구조

 

설계는 기능, 구조 설계 이 두가지를 조화롭게 이루도록 설계를 이루는 것이 설계의 목표이다.

훌륭한 기능을 제공하는 동시에 사용자가 원하는 새로운 기능을 빠르고 안정적으로 추가할 수 있다는 것이다.

 

변경에 대비한 설계

 - 미래에 대비하는 가장 좋은 방법은 변경을 예측하는 것이 아니라 변경을 수용할 수 있는 선택의 여지를 설계에 마련해 놓는 것

 

두 가지 재료: 기능과 구조

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

 

안정적인 재료 : 구조

 도메인이란 ? 

 - 특정한 분야의 문제를 해결하기 위한 영역, 애플리케이션에서는 사용자가 애플리케이션을 사용하는 대상 분야를 도메인이라 칭한다.

 Ex) 은행 업무, 게임, 결제, 상품 판매 등 각 분야의 문제를 해결하기 위한 영역

도메인 모델

 - 사용자가 프로그램을 사용하는 대상 영역에 관한 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태

 - 사용자들이 도메인을 바라보는 관점, 설계자가 시스템의 구조를 바라보는 관점인 동시에 소프트웨어 안에 구현된 코드 그 자체

 

불안정한 재료 : 기능

 유스케이스

 - 시스템이 사용자에게 제공해야 하는 기능의 목록을 텍스트로 정리한 것, 기능 요구사항

 - 유스케이스명, 일차 액터, 성공 시나리오, 확장 등 제공해야 하는 목록을 정리 해놓은 것

 

일차 액터 (primary actor)

 - 시스템의 서비스 중 특정 서비스를 요청하는 사용자를 나타낸다

 

유스케이스 특징

 1. 사용자와 시스템 간의 상호작용을 보여주는 텍스트 이다.

 2. 하나의 시나리오가 아닌 여러 시나리오들이 합쳐진 집합이다

 3. 단순한 기능의 목록 나열이 아닌 이야기를 통해 연관된 기능들을 묶어서 확인할 수 있는 것

 4. 자주 변경되는 사용자 인터페이스 요소는 배제하고 사용자 관점에서 시스템의 행위에 초점을 맞춘다.

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

 

유스케이스는 설계 기법도, 객체지향 기법도 아닌 오직 사용자가 시스템을 통해 무엇을 얻을 수 있고 어떻게 상호작용 하느냐에 대한 정보만 기술하는 것이다.

 

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

 - 변경에 유연한 소프트웨어를 만들기 위해서는 유스케이스에 정리된 시스템의 기능을 도메인 모델을 기반으로 한 객체들의 책임으로 분배 하는것을 중점으로 소프트웨어 설계를 해야 한다. (유스케이스 기능 -> 도메인 모델 객체)

 - 시스템에 할당된 커다란 책임은 더 작은 규모의 책임으로 세분화되어 작은 규모들의 객체들이 책임들을 수행하며 협력을 통하여 애플리케이션을 구성해 나아가는 것입니다

 

도메인 모델링에서 사용한 객체와 개념을 프로그램이 설계에서의 객체와 클래스로 매끄럽게 변환할 수 있다.

이와 같은 특성을 연결완정성이라고 한다. 이와 반대로 모델로의 매끄러운 흐름을 의미하는 것을 가역성 이라고 한다.

사람들이 동일한 용어와 동일한 개념을 이용해 의사소통하고 코드로부터 도메인 모델을 유추할 수 있게 하는 것이 도메인 모델의 진정한 목표이다.

 

견고한 객체지향 애플리케이션을 개발하기 위해서는 사용자의 관점에서 시스템의 기능을 명시하고, 사용자와 설계자가 공유하는 안정적인 구조를 기반으로 기능을 책임으로 변환하는 체계적인 절차를 따라야 한다.

결론

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

 

 

 

 

해당 내용은 객체지향의 사실과 오해 를 읽으며 제가 이해한 내용으로 정리한 내용입니다.

자세한 내용과 적확한 내용은 책을 읽어주시길 바랍니다. (책을 읽는것을 추천드립니다)

 

책 : https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=60550259

객체지향의 사실과 오해