6장. 내 이름은 아트 반델리... 나는 건축가예요

6장. 내 이름은 아트 반델리... 나는 건축가예요

6.1 큰 문제 해결하기

작은 문제를 푼 것과 똑같은 방식으로 큰 문제도 해결해야 합니다.
1000개의 이상의 클래스를 사용하는 프로그램을 만든다고 하더라도, 3단계가 적용된다.
위대한 소프트웨어를 만드는 3단계
1. 여러분의 소프트웨어가 고객이 원하는 기능을 하도록 하세요.
2. 객체지향의 기본 원리를 적용해서 소프트웨어를 유연하게 하세요.
3. 유지보수와 재사용이 쉬운 디자인을 위해 노력하세요.

큰문제를 바라보는법.
- 큰문제를 여러 개의 기능별 조각들로 나누고 각 조각들을 개별적으로 풀어감으로써 해결할 수 있습니다.
- (= 여러 기능의 조각들로 나누어 보는 것)
- (= 큰문제를 작은 문제로 바꾸는 것)

작은문제를 해결하는 방법은 이미 배웠죠?
OOA&D복습!
변하는 것을 캡슐화하여, 프로그램을 더 유연하고 변경하기 쉽게 만든다.
좋은 요구사항을 얻는 가장 좋은 방법은 시스템이 해야할 일을 이애하는 것이다.
구현에 맞추어 코딩하는 것보다 인터페이스에 맞추어 코딩하면 소프트웨어의 확장이 더 쉬워진다.
위대한 소프트웨어는 변경과 확장이 쉽고 고객이 원하는 일을 합니다.
분석은 실세계에서 잘 동작하도록 만드는 데 도움이 됩니다.

객체지향 개발 원칙(헤드퍼스트 디자인패턴중에서..)
바뀌는 부분은 캡슐화 한다.
상속보다는 구성을 활용한다
구현이 아닌 인터페이스에 맞춰서 프로그래밍한다.
서로 상호작용을 하는 객체 사이에서는 가능하면 느슨하게 결합하는 디자인을 사용해야한다.
클래스는 확장에 대해서는 열려있지만 변경에 대해서는 닫혀있어야한다.(OCP)
추상화 된 것에 의존하라.구상 클래스에 의존하지 않도록 한다.
친한 친구들하고만 이야기한다.
먼저 연락하지 마세요. 저희가 연락드리겠습니다.
어떤 클래스가 바뀌게 되는 이유는 한기지 뿐이어야만 한다.

6.2 게리게임즈 (특징 또는 요구사항)

게리게임즈는...
무엇을 먼저할까요?
- 덕의 강아지문처럼 요구사항과 유스케이스부터 만들어야한다.
- 비전기술서에는 시스템이 해야 할 일에 대한 내용이 없다. 더 알아야한다.
  - 더많은 정보를 알아내는 방법.(= 실무 미팅)
  - 1. 공통점 : 자신 알고있는 시스템과 무엇이 비슷한지 찾아내고.
  - 2. 차별점 : 자신이 알고있는 시스템과 무엇이 다른지 찾아낸다.
  - 3. 특징(Feature)찾기 : 고객으로부터 시스템의 특징들을 얻어내고 나서, 그 특징을 구현하기 위해 필요한 요구사항들을 알아내세요.
    특징찾기
    하나의 특징에선 그 특징을 만족시키기 위한 여러 개의 요구사항들이 나온다.
    그래서 시스템의 특징들을 알아내는 것은 요구 사항을 얻는 좋은방법입니다.
  - 그러나, 특징과 요구사항의 "차이점"에는 너무 얽매이지 마라.
    {info:title=쌍둥이 엄마도 구분못하는 특징과 요구사항의 구별법}
    특징 : "각 패들을 모으면 점수가 오르는 시스템".
    요구사항 : "고도리 5점, 오광 15점, 청단 3점, 홍단 3점등.."

하나의 특징에 여러개의 요구사항이 나왔습니다.
그럼 우리는 이 요구사항을 기준으로 기능을 구현하면 됩니다.

6.3 게리게임즈

유스케이스는

유스케이스 다이어그램은...
- 시스템을 나타내는 가장 자세한 설계도는 아니지만,
- 시스템이 할 모든 내용을..
  - 1. 간단하고
  - 2. 읽기 쉬운 형태로
- 알려준다.

세부내용은 늦출 수 있을 때까지 최대한 늦추세요.

1. 유스케이스의 작성을 시작할 때, 시스템이 해야할 일을 살펴본다.
2. 그러다가 시스템 전체에 대한 큰그림을 잃어버린다.
3. 그래서 자신이 무엇을 만들지 파악하는데 도움이 되지않는다.

6.4 고객과 대화하기.

도메인분석? 기존 시스템과 개발 이력, 도메인 전문가들로 부터 얻은 지식, 기반이론, 그리고 도메인에서 새로 등장하는 기술을 기반으로 도메인 관련 정보를
- 1. 찾아내고
- 2. 모으고
- 3. 구조화하고
- 4. 나타내는
  프로세스
쉽게 이야기하면, 고객이 이해하는 용어를 문제를 설명하는 것
도메인 분석을 통해 디자인을 확인할 수 있고, 고객이 사용하는 용어를 사용할 수 있습니다.
도메인 분석이 필요한 이유
- 대부분의 사람들은 고객에게
  - 프로그램의 프레임웍을 만드는방법
  - 위 방법에 대한 클래스 정보
  - 위 방법에 의한 패키지 다이어그램
  - 위 방방에 의한 코드 수준의 세부정보
- 를 주기때문에 고객은 전혀 이해하지 못하므로 근본적인 문제의 설명이 되지않는다.
- 우리가 고객에게 제공하는 정보는 고객에 수준에 맞는 정보여야 한다.
- 고객이 이해하는 언어로 작성된 우리의 특징리스트 ===================> 유스케이스
  {info:title=도메인분석을 하는 가장 큰 장점}
  도메인 분석을 하면 여러분이 만들 필요가 없는 시스템의 부분을 만들지 않는 데 도움이 됩니다.
  (당신의 고객이 누구인지 확실히 알 수 있습니다.)
  (당신은 게임 디자이너를 위한 프레임웍을 만드는 것이지, 실제 게임을 만드는 것이 아닙니다.)

6.5 세분화 하여 해결하기

게리게임즈의 큰산을 보았으니 작은 단위로 세분화해보자
- 시대적배경: com.games.game
- 타일들: com.games.board
- 지형타입들: com.games.board
- 유닛들: com.games.units
- 기타 공통: com.games.controller, com.games.utilities

6.6 "OOA&D와 약간의 상식의 힘"으로 큰문제를 해결하기.

0. 고객이 큰문제를 가져옵니다. (= 게리)
1. 고객의 말에 귀를 기울이고, (= 게리게임즈 비전기술서)
2. 우리가 시스템을 이해하는지 확인했습니다. (= 유스케이스 작성)
3. 우리가 만드는 시스템에 대한 청사진(설계도)를 그렸습니다. (= 유스케이스 다이어그램 작성)
4. 큰 문제를 기능의 작은 조각들로 나누었습니다. (= 세분화 시키고, 팩키지를 나눔)
5. 작은 문제들의 해결에 디자인 패턴을 적용합니다. (= 디자인패턴의 적용으로 유연성과 재사용성 증대)

6.7 OOA&D 도구상자

큰 문제들 해결하기

고객의 말에 귀 기울여, 여러분이 만들어 주길 바라는 것이 무엇인지 알아낸다.

특징 리스트를 고객이 이해하는 용어를 사용하여 작성한다.

작성한 특징 리스트가 고객이 실제로 원하는 것인지 확인한다.

유스케이스 다이어그램(과 유스케이스들)을 사용하여 시스템의 청사진을 만든다.

큰 시스템을 여러 개의 작은 섹션으로 나눈다.

디자인 패턴을 시스템의 작은 섹션에 적용한다.

문서에 대하여

최초작성자 : 장선웅
최초작성일 : 2008년 06월 20일
이 문서는 Head First Object-Oriented Analysis & Design을 정리한 내용 입니다.
이 문서는 오라클클럽 자바 웹개발자 스터디 모임에서 작성하였습니다.
이 문서를 다른 블로그나 홈페이지에 게재할 경우에는 출처를 꼭 밝혀 주시면 고맙겠습니다.~^\^

6장. 내 이름은 아트 반델리... 나는 건축가예요 (by sjjang) [2009.04.30]