TIL
🌱 난 오늘 무엇을 공부했을까?
📌 객체지향의 사실과 오해 - 객체지도
📍 기능설계 대 구조설계
🔗 기능
- 사용자가 자신의 목표를 달성하기 위해 사용할 수 있는 시스템의 서비스.
- 사용자의 목표를 만족시키기 위해 책임을 수행하는 시스템의 행위로 표현한다.
🔗 구조
- 시스템의 기능을 구현하기 위한 기반으로, 기능변경을 수용할 수 있도록 안정적이어야 한다.
- 사용자나 이해관계자들이 도메인에 관해 생각하는 개념과 개념들 간의 관계로 표현한다.
기능을 수집하고 표현하기 위한 기법을 유스케이스 모델링이라함
구조를 수집하고 표현하기 위한 기법으르 도메인 모델링이라함
두 가지 모델링 활동의 결과물을 각각 유스케이스와 도메인 모델이라고 한다.
📍 안정적인 재료: 구조
🔗 도메인 모델
- 도메인 모델에서 모델이란 대상을 단순화해서 표현한 것이다.
- 사용자가 프로그램을 사용하는 대상 영역에 관한 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태다.
- 소프트웨어가 목적하는 영역 내의 개념과 개념 간의 관계, 다양한 규칙이나 제약 등을 주의 깊게 추상화한 것이다.
- 소프트웨어 개발과 관련된 이해관계자들이 도메인에 대해 생각하는 관점이다.
예) 은행 업무에 종사하는 사람들은 은행 도메인을 고객과 계좌 사이의 돈의 흐름으로 이해한다.
- 소프트웨어 객체와 현실의 객체에는 표현적 차이 또는 의미적 차이가 존재한다. 이러한 표현적 차이가 존재하기 때문에 소프트웨어에 대한 이해와 수정이 어려울 수 있다.
- 표현적 차이를 줄이기 위해 그 대상이 현실적인지, 현실적이지 않은지에 상관 없이 도메인 모델을 통해 표현되는 도메인 객체들을 은유하면, 이해하기 쉽고 수정하기 쉬운 소프트웨어 객체를 창조할 수 있다.
- 도메인 모델은 안정적인 구조를 기반으로 자주 변경되는 기능을 배치함으로써 기능의 변경에 대해 안정적인 소프트웨어를 구현할 수 있다.
📍 불안정한 재료: 기능
🔗 유스케이스
- 사용자의 목표를 달성하기 위해 사용자와 시스템 간에 이뤄지는 상호작용의 흐름을 텍스트로 정리한 것을 유스케이스라고 한다.
- 유스케이스의 특성
- 사용자와 시스템 간의 상호작용을 보여주는 '텍스트'다.
- 하나의 시나리오가 아니라 여라 시나리오들의 집합, 시나리오는 유스케이스를 통해 시스템을 사용하는 하나의 특정한 이야기 또는 경로
- 유스케이스는 단순한 feature 목록과 다르다, feature는 시스템이 수행해야하는 기능의 목록을 단순하게 나열한 것이다.
- 유스케이스는 사용자 인터페이스와 관련된 세부 정보를 포함하지 말아야 한다. 자주 변경되는 사용자 인턴페이스 요소는 배제하고 사용자 관점에서 시스템의 행위에 초점을 맞춘다.
- 유스케이스 내부 설계와 관련된 정보를 포함하지 않는다.
- 단지 사용자가 시스템을 통해 무엇을 얻을 수 있고 어떻게 상호작용할 수 있느냐에 관한 정보만 기술된다.
📍 재료합치기: 기능과 구조의 통합
🔗 도메인 모델, 유스케이스, 그리고 책임-주도 설계
- 도메인 모델은 안정적인 구조를 개념화하기 위해, 유스케이스는 불안정한 기능을 서술하기 위해 가장 일반적으로 사용되는 도구다.
- 책임-주도 설계는 유스케이스로부터 첫 번째 메시지와 사용자가 달성하려는 목표르르 도메인 모델로부터 기능을 수용할 수 있는 안정적인 구조를 제공받아 실제로 동작하는 객체들의 협력 공동체를 창조한다.
I Am Groot