#객사오
- 6장
소프트웨어의 설계에는 '기능'과 '구조'의 두 가지 측면이 있다.
기능: 제품이 사용자에게 무엇을 제공할 수 있는지
구조: 제품의 형태가 어떠해야 하는지
- 요구사항은 변경되기 때문에 변경에 안정적인 소프트웨어를 설계해야 한다(미래의 변경을 예측하고 반영하는 것이 아닌 변경이 일어났을 때 유연하게 대처할 수 있도록 설계한다)
- 구조를 수집하고 표현하는 기법: 도메인 모델링
- 기능을 수집하고 표현하는 기법: 유스케이스 모델링
도메인 모델: 이해 관계자들이 소프트웨어 개발에 대해 생각하는 관점
- 도메인: 사용자가 소프트웨어를 사용하는 대상 분야(ex: 게임, 은행업무)
- 모델: 대상을 추상화하고 단순화 한것(불필요한 정보를 무시하면서 복잡성을 낮춘다)
- 단순 다이어그램이 아니라 개념적 모델
- 표현적 차이: 소프트웨어 객체는 현실 객체의 추상화가 아닌 새롭게 창조하는 은유적 객체 -> 현실객체와 소프트웨어 객체의 간극이 표현적 차이
- 적절한 은유를 통해 표현적 차이를 줄여야 한다
- 도메인 모델은 사용자들이 본질적으로 이해하고 있는 개념으로 변경될 확률이 적어 안정적이다.
-> 안정적인 구조를 제공하는 도메인 모델을 기반으로 구조를 설계하면 변경에 유연하게 대응가능한 소프트웨어를 설계 할 수 있다.
유스케이스: 사용자의 목표를 달성하기 위해 사용자와 시스템간에 이뤄지는 상호작용의 흐름을 정리한 것
- 유스케이스는 사용자와 시스템간의 상호작용을 보여주는 텍스트로 다이어그램그리기가 아닌 시나리오에 집중하자
- 유스케이스는 여러 시나리오(유스케이스 인스턴스)들의 집합
- 유스케이스는 단순한 피처가 아니다; 단순 기능나열이 아니라 시나리오를 통해 연관된 기능들을 묶을 수 있다
- 사용자 인터페이스와 관련된 세부정보를 포함하지 않는다; 사용자 관점에서 시스템의 행위에 초점을 맞춘것
- 내부 설계와 관련된 정보를 포함하지 않는다; 시스템의 기능을 시나리오 형식으로 모으는 것일 뿐이다
안정적인 구조를 개념화 하기 위해 도메인 모델을, 불안정한 기능을 서술하기 위해 유스케이스를 가지고 설계
객체 지향 설계(책임 주도 설계)
1. 시스템의 기능을 시스템의 책임(유스케이스를 통해 책임 확인)으로 변환
2. 큰 책임을 작은 규모의 객체들이 수행하는 작은 규모의 책임으로 세분화한다.
3. 도메인 모델에 포함된 개념을 은유하는 소프트웨어 객체를 선택한다 -> 소프트웨어와 코드사이의 표현적 차이를 최소화
4. 협력을 완성하기 위해 필요한 메시지를 식별하면서 객체들에게 책임을 할당한다
5. 객체를 구현하기 위해 클래스를 추가하기 속성과 메서드를 구현한다
- 도메인 모델의 개념을 자율적인 객체로 생각해 소프트웨어 객체로 구현한다(소프트웨어 세상에선 자율적인 객체가 됨)(표현적 차이)
도메인 모델 -> 소프트웨어(객체와 클래스) : 완전연결성 성립, 도메인 모델 <- 소프트웨어: 가역성 성립
; 코드의 변경으로 도메인 개념의 변경을 유추할 수 있다
; 안정적인 도메인 모델을 기반으로 구현된 시스템이기 때문에 유지보수하기 쉽고 변경에 유연한 객체지향 시스템을 설계 할 수 있다.