[객사오] Chapter 6

• 객체지향 개발 방법은 안정적인 구조에 변경이 빈번하게 발생하는 기능을 종속시키는 방법
  • 길을 물어보면 → 지도를 준다
  • 범용적이고 재사용성이 높으며 변경에 안정적인 이유
• 자주 변경되는 기능이 아닌 안정적인 구조를 기반으로 시스템 구조화

기능 설계 vs 구조 설계

• 기능 측면의 설계: 제품이 사용자를 위해 무엇을 할 수 있는지에 초점
• 구조 측면의 설계: 제품의 형태가 어떠해야 하는지에 초점
  • 기능과 구조라는 두 측면을 함께 녹여 조화를 이루도록 만들어야 한다.
• 설계의 목표: 변경에 소요되는 비용을 낮추는 것

• 전통적인 기능 분해: 자주 변경되는 기능을 중심으로 설계한 후 구조가 기능에 따라간다.

  → 변경에 취약

  • 시스템 기능은 더 작은 기능으로 분해 → 각 기능은 서로 밀접하게 관련된 하나의 덩어리를 이룸
• 객체지향 접근 방법: 자주 변경되지 않는 안정적인 객체 구조를 바탕으로 시스템 기능을 객체 간 책임으로 분배
  • 구조에 집중하고 기능이 객체의 구조를 따라간다.
  • 객체를 기반으로 책임과 역할 식별
  • 메시지를 기반으로 객체들의 협력 관계 구축

  → 변경을 수용할 수 있는 유연한 소프트웨어를 만들 수 있는 기반 제공

기능과 구조

• 기능: 사용자의 목표를 만족시키기 위해 책임을 수행하는 시스템의 행위로 표현
  • 유스케이스 모델링: 기능을 수집하고 표현하기 위한 기법
• 구조: 사용자나 이해관계자들이 도메인에 관해 생각하는 개념과 개념들 간의 관계로 표현
  • 시스템의 기능을 구현하기 위한 기반
  • 기능 변경을 수용할 수 있도록 안정적이어야 한다.
  • 도메인 모델링: 구조를 수집하고 표현하기 위한 기법

구조

• 도메인: 사용자가 프로그램을 사용하는 대상 분야
• 모델: 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태
  • 대상을 추상화하고 단순화한 것
  • 복잡성을 관리하기 위해 사용하는 기본적인 도구
• 도메인 모델: 사용자가 프로그램을 사용하는 대상 영역에 관한 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태
  • 소프트웨어 개발과 관련된 이해관계자들이 도메인에 대해 생각하는 관점
• 애플리케이션은 도메인 모델을 기반으로 설계돼야 한다
  • 객체 지향을 이용할 경우 사용자들이 이해하고 있는 도메인 구조와 최대한 유사하게 코드를 구조화할 수 있다.
• 객체지향 패러다임은 사용자의 관점, 설계자의 관점, 코드의 모습을 모두 유사한 형태로 유지할 수 있게 하는 유용한 사고 도구와 프로그래밍 기법을 제공

  • 도메인에 대한 사용자 모델, 디자인 모델, 시스템 이미지가 모두 유사한 모습을 유지

    → 객체지향의 연결 완전성

• 객체는 도메인 모델을 통해 표현되는 도메인 객체들을 은유해야 한다.
  • 사용자가 도메인을 바라보는 관점을 그대로 코드에 반영
• 도메인 모델이 제공하는 구조는 상대적으로 안정적

기능

• 사용자는 자신의 목표 달성을 위해 시스템과 상호작용
  • 이러한 사용자와 시스템 간 상호작용의 흐름을 텍스트로 정리한 것 → 유스케이스
• 유스 케이스
  • 시스템의 이해관계자들 간 계약을 행위 중심으로 파악
  • 일차 액터의 요청에 대한 응답으로 다양한 조건에 있는 시스템의 행위 서술
• 가치
  • 사용자들의 목표를 중심으로 시스템의 기능적인 요구사항들을 이야기 형식으로 묶을 수 있다는 점
• 특성
  1. 사용자와 시스템 간의 상호작용을 보여주는 텍스트
     • 유스케이스 안에 포함되어 있는 상호작용의 흐름이 중요한 것
  2. 하나의 시나리오가 아닌 여러 시나리오들의 집합
     • 시나리오: 유스케이스를 통해 시스템을 사용하는 하나의 특정한 이야기 또는 경로
  3. 단순한 피처 목록과 다르다.
     • 피처: 시스템이 수행해야 하는 기능의 목록을 단순하게 나열한 것
     • 이야기를 통해 연관된 기능들을 함께 묶어야 한다.
  4. 사용자 인터페이스와 관련된 세부 정보를 포함하지 말아야 한다.
     • 자주 변경되는 사용자 인터페이스는 배제하고 사용자 관점에서 시스템의 행위에 초점을 맞춘다.
  5. 내부 설계와 관련된 정보를 포함하지 않는다.

유스케이스는 설계 기법도, 객체지향 기법도 아니다

• 유스케이스는 사용자가 시스템을 통해 무엇을 얻을 수 있고 어떻게 상호작용할 수 있느냐에 관한 정보만 기술
  • 내부 구조를 유추할 수 있는 방법이 없다.

기능과 구조의 통합

• 도메인 모델은 안정적인 구조 개념화, 유스케이스는 불안정한 기능을 서술하기 위해 사용되는 도구
• 유스케이스에 정리된 시스템의 기능을 도메인 모델을 기반으로 한 객체들의 책임으로 분배해야 함
• 시스템이 수행해야 하는 책임 → 시스템 안의 작은 크기의 객체들의 협력을 통해 구현
  • 책임-주도 설계 적용
  • 첫 번째 메시지는 시스템의 기능을 시스템의 책임으로 바꾼 후 얻어진 것
  • 시스템의 책임 → 작은 규모의 객체들이 수행해야 하는 더 작은 규모의 책임
    • 어떤 객체를 선택해야 하는가? → 도메인 모델 등장
• 도메인 모델에 포함된 개념을 은유하는 소프트웨어 객체를 선택해야 한다.
  • 협력을 완성하는데 필요한 메시지 식별 → 객체들에게 책임 할당

도메인 모델을 구성하는 요소의 특징

1. 비즈니스가 없어지거나 완전히 개편되지 않는 한 안정적으로 유지
2. 개념 간 관계는 비즈니스 규칙을 기반으로 하기 때문에 비즈니스 정책이 크게 변경되지 않는 한 안정적으로 유지