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

오늘은 6장의 내용을 정리하였다.

 

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

 

기능 설계 vs 구조 설계

기능 측면의 설계

• 제품이 사용자를 위해 무엇을 할 수 있는가에 초점

구조 측면의 설계

• 제품의 형태가 어떠해야 하는지에 초점

-> 기능과 구조 두 측면이 조화를 이루도록 만들어야 한다.

훌륭한 기능이 훌륭한 소프트웨어를 만드는 충분조건이라면 훌륭한 구조는 훌륭한 소프트웨어를 만들기 위한 필요조건

소프트웨어가 사용자에게 가치 있는 이유는 사용자가 필요로 하는 기능을 제공하기 때문이다.

 

객체지향 접근방법

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

안정적인 객체 구조를 바탕으로 시스템 기능을 객체간의 책임으로 분배

 

기능과 구조

기능

• 사용자가 자신의 목표를 달성하기 위해 사용할 수 있는 시스템의 서비스
• 사용자의 목표를 만족시키기 위해 책임을 수행하는 시스템의 행위 표현

->기능을 수집하고 표현하기 위한 기법 유스케이스 모델링

 

구조

• 시스템의 기능을 구현하기 위한 기반으로 기능 변경을 수용할 수 있도록 안정적
• 사용자나 이해관계자들이 도메인에 관해 생각하는 개념과 개념들 간의 관계로 표현

->구조를 수집하고 표현하기 위한 기법 도메인 모델링

유스케이스 모델링 + 도메인 모델링 -> 활동의 결과물 유스케이스와 도메인 모델

 

안정적인 구조 - 도메인 모델

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

• 도메인: 사용자가 프로그램을 사용하는 대상 분야
• 모델: 대상을 단순화해 표현

->복잡성을 관리하기 위해 사용하는 기본적인 도구

 

멘탈 모델

• 사람들이 자기 자신, 다른 사람, 환경, 자신이 상호작용하는 사물들에 대해 갖는 모형
• 도메인 모델은 이해관계자들이 바라보는 멘탈 모델
• 도메인에 대한 사용자 모델, 디자인 모델, 시스템 이미지를 포괄하도록 추상화한 소프트웨어 모델

도메인 모습 담는 객체지향

애플리케이션이 도메인 모델을 기반으로 설계되어야 함

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

-> 도메인 모델의 세 가지 측면

 

표현적 차이/의미적 차이

소프트웨어 객체와 현실 객체 사이의 의미적 거리

- 은유를 통해 현실 객체와 소프트웨어 객체 사이의 차이를 최대한 줄이는 것

소프트웨어 객체를 창조하기 위해 우리가 은유해야 하는 대상 = 도메인 모델

- 소프트웨어를 이해하고 수정하기 쉽게 만들어줌

 

안정적인 도메인 모델

사용자 모델을 기반으로 설계와 코드를 만들면 변경에 쉽게 대처 가능

-> 도메인 모델이 기능을 담을 수 있는 안정적인 구조 제공 의미

 

정리

안정적인 구조를 제공하는 도메인 모델을 기반으로 소프트웨어의 구조를 설계 시 변경에 유연하게 대응할 수 있는 탄력적인 소프트웨어 생성가능

 

불안정적인 기능 - 유스케이스 

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

• 기능적 요구사항: 시스템이 사용자에게 제공해야 하는 기능의 목록을 정리한 것
• 일차 액터: 하나의 목표를 가지고 유스케이스를 시작하는 액터

유스케이스 가치

사용자들의 목표를 중심으로 시스템의 기능적인 요구사항들을 이야기 형식으로 묶을 수 있음

 

유스케이스 특징

• 유스케이스는 사용자와 시스템 간의 상호작용을 보여주는 텍스트 - 다이어 그램이 아닌 사용자과 시스템 간의 상호작용을 일련의 이야기 흐름으로 표현
• 유스케이스는 하나의 시나리오가 아니라 여러 시나리오들의 집합 - 시나리오는 유스케이스를 통해 시스템을 사용하는 하나의 특정한 이야기 또는 경로
• 유스케이스는 단순한 피처 목록과 다음 - 피쳐: 시스템이 수행해야 하는 기능의 목록을 단순하게 나열한 것, 유스케이스는 단순히 기능을 나열한 것이 아닌 이야기를 통해 연관된 기능들을 함께 묶음
• 유스케이스는 사용자 인터페이스와 관련된 세부 정보를 포함하지 않음 - 자주 변경되는 사용자 인터페이스 요소를 배제하고 사용자 관점에서 시스템의 행위에 초점 맞춤
• 유스케이스는 내부 설계와 관련된 정보를 포함하지 않음 - 연관된 시스템의 기능을 이야기하는 형식, 내부 설계를 설명하는 것이 아님

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

-> 객체의 구조나 책임에 대한 어떤 정보도 제공하지 않음

 

기능과 구조의 통합 

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

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

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

 

책임 - 주도 설계

시스템의 기능을 역할과 책임을 수행하는 객체들의 협력관계로 바라보게 함으로써 두 가지 기본 재료인 유스케이스와 도메인 모델 통합

• 유스케이스 - 사용자에게 제공할 기능을 시스템의 책임으로 보게 함으로써 객체 간의 안정적인 구조에 책임을 분배할 수 있는 출발점 제공
• 도메인 모델 - 기능을 수용하기 위해 은유할 수 있는 안정적인 구조 제공
• 책임-주도 설계 - 유스케이스로부터 첫 번째 메시지와 사용자가 달성하려는 목표를 도메인 모델로부터 기능을 수용할 수 있는 안정적인 구조 제공받아 실제로 동작하는 객체들의 협력 공동체를 창조

->안정적인 구조를 기반으로 기능을 책임으로 변환하는 체계적인 절차 필요

 

연결완전성/가역성

연결완전성 -> 도메인 모델링에서 사용한 객체와 개념을 프로그래밍 설계에서의 객체와 클래스로 매끄럽게 변환

가역성 -> 모델에서 코드로의 매끄러운 흐름을 의미하는 연결완전성과 반대로 코드에서 모델로의  매끄러운 흐름을 의미

정리

도메인 모델은 문서나 다이어그램이 아닌 사람들이 머릿속에 들어있는 공유된 멘탈 모델

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