06.객체 지도

기능 설계 대 구조 설계

• 기능 분해 방법의 경우 시스템 기능은 더 작은 기능으로 분해되고 각 기능은 서로 밀접하게 관련된 하나의 덩어리를 이루기 때문에 기능이 변경될 경우 기능의 축을 따라 설계된 소프트웨어가 전체적으로 요동치게 된다.

• 객체지향 접근방법은 자주 변경되지 않는 안정적인 객체 구조를 바탕으로 시스템 기능을 객체 간의 책임으로 분배한다.객체의 구조에 집중하고 기능이 객체의 구조를 따르게 만든다. 시스템 기능은 더 작은 책임으로 분할되고 적절한 객체에게 분배되기 때문에 기능이 변경되더라도 객체 간의 구조는 그대로 유지된다.

두 가지 재료: 기능과 구조

• 객체지향 세계를 구축하기 위해서는 사용자에게 제공할 기능과 기능을 담은 안정적인 구조라는 재료가 준비되어 있어야 한다.

  • 기능 : 사용자가 자신의 목표를 달성하기 위해 사용할 수 있는 시스템의 서비스

  • 구조 : 시스템의 기능을 구현하기 위한 기반, 기능 변경을 수용할 수 있도록 안정적이어야 함

• 기능과 구조를 표현하기 위해 일관되게 적용할 수 있는 기법

  • 기능은 사용자의 목표를 만족시키기 위해 책임을 수행하는 시스템의 행위로 표현

  • 구조는 사용자나 이해관계자들이 도메인에 관해 생각하는 개념과 개념들 간의 관계로 표현

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

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

안정적인 재료: 구조

도메인 모델

• 사용자가 프로그램을 사용하는 대상 분야를 도메인

• 도메인 모델은 이해관계자들이 바라보는 멘탈 모델(Mental Model)이다.

  • 멘탈 모델이란 자기 자신, 다른 사람, 환경, 자신이 상호작용하는 사물들에 대해 갖는 모형

• 도메인 모델은 도메인에 대한

  • 사용자 모델(사용자가 제품에 대해 가지고 있는 개념들의 모습)

  • 디자인 모델(설계자가 마음 속에 갖고 있는 시스템에 대한 개념화)

  • 시스템 이미지(최종 제품)

  • 를 포괄하도록 추상화한 소프트웨어 모델이다.

• 도메인 모델은 소프트웨어에 대한 멘탈 모델이다.

도메인의 모습을 담을 수 있는 객체지향

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

• 객체지향 패러다임은 사용자의 관점, 설계자의 관점, 코드의 모습을 모두 유사한 형태로 유지할 수 있게 하는 유용한 사고 도구와 프로그래밍 기법을 제공

• 위 특징을 연결완전성 또는 표현적 차이라고 한다.

표현적 차이

• 소프트웨어 객체가 현실 객체를 왜곡한다고 하더라도 소프트웨어 객체는 현실 객체의 특성을 토대로 구축된다.

• 소프트웨어 객체와 현실 객체 사이의 의미적 거리를 가리켜 표현적 차이 또는 의미적 차이 라고 한다.

• 소프트웨어 객체는 도메인 모델을 통해 표현되는 도메인 객체들을 은유해야 한다.

불안정한 기능을 담는 안정적인 도메인 모델

• 도메인 모델이 제공하는 구조가 상대적으로 안정적이다.

• 사용자 모델에 포함된 개념과 규칙은 비교적 변경될 확률이 적기 때문에 사용자 모델을 기반으로 설계와 코드를 만들면 변경에 쉽게 대처할 수 있을 가능성이 커진다.

• 안정적인 구조를 제공하는 도메인 모델을 기반으로 소프트웨어의 구조를 설계하면 변경에 유연하게 대응할 수 있는 탄력적인 소프트웨어를 만들 수 있다.!

불안정한 재료: 기능

유스케이스

• 기능적 요구사항이란 시스템이 사용자에게 제공해야 하는 기능의 목록을 정리한 것.

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

• "사용자 목표가 유스케이스의 핵심이다. 유스케이스는 공통의 사용자 목표를 통해 강하게 연관된 시나리오의 집합이다"

유스케이스의 특성

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

   • 유스케이스의 핵심은 사용자와 시스템 간의 상호작용을 일련의 이야기 흐름으로 표현하는 것

2. "유스케이스는 하나의 시나리오가 아니라 여러 시나리오들의 집합이다."

   • 시나리오는 유스케이스를 통해 시스템을 사용하는 하나의 특정한 이야기 또는 경로다.

   • 시나리오를 유스케이스 인스턴스라고도 한다.

3. 유스케이스는 단순히 피처(feature) 목록과 다르다.

   • 피처는 시스템이 수행해야 하는 기능의 목록을 단순하게 나열한 것

4. 유스케이스는 사용자 인터페이스와 관련된 세부 정보를 포함하지말아야 한다.

   • 본질적인 유스케이스라고도 한다.

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

   • 유스케이스에서 객체 설계로의 전환은 경험과 상식과 의사소통을 기반으로 한 창조 작업이다.

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

• 유스케이스에는 단지 사용자가 시스템을 통해 무엇을 얻을 수 있고 어떻게 상호작용할 수 있느냐에 관한 정보만 기술

• 단지 기능적 요구사항을 사용자의 목표라는 문맥을 중심으로 묶기 위한 정리 기법일 뿐

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

도메인 모델, 유스케이스, 그리고 책임-주도 설계

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

• 사용자에게 시스템이 수행하기로 약속한 기능은 결국 시스템의 책임으로 볼 수 있다.

• 시스템에 할당된 커다란 책임은 이제 시스템 안의 작은 규모의 객체들이 수행하야 하는 더 작은 규모의 책임으로 세분화된다.

• 이제 우리는 도메인 모델에 포함된 개념을 은유하는 소프트웨어 객체를 선택해야 한다.

  • 협력을 완성하는 데 필요한 메시지를 식별하면서 객체들에게 책임을 할당해 나간다.

• 협력에 참여하는 객체를 구현하기 위해 클래스를 추가하고 속성과 함께 메서드를 구현하면 시스템의 기능이 완성!

• 객체 설계는 가끔(?) 아래와 같이 표현

요구사항들을 식별하고 도메인 모델을 생성한 후,
소프트웨어 클래스에 메서드들을 추가하고,
요구사항을 충족시키기 위해 객체들 간의 메시지 전송을 정의하라.

• 유스케이스는 사용자에게 제공할 기능을 시스템의 책임으로 보게 함으로써 객체 간의 안정적인 구조에 책임을 분배할 수 있는 출발점을 제공

• 도메인 모델은 기능을 수용하기 위해 은유할 수 있는 안정적인 구조를 제공

• 책임-주도 설계는 유스케이스로부터 첫 번째 메시지와 사용자가 달성하려는 목표를, 도메인 모델로부터 기능을 수용할 수 있는 안정적인 구조를 제공받아 실제로 동작하는 객체들의 협력 공동체를 창조

기능 변경을 흡수하는 안정적인 구조

• 도메인 모델을 기반으로 객체 구조를 설계하는 이유는 도메인 모델이 안정적이기 때문

• 비즈니스 정책이나 규칙이 크게 변경되지 않는 한 시스템의 기능이 변경되더라도 객체 간의 관계는 일정하게 유지

  • 기능적인 요구사항이 변경될 경우 책임과 객체 간의 대응 관계만 수정될 뿐.