get real! : 2장 - 다이어그램으로 작업하기

왜 모델을 만들어야 하는가?
- 모델은 반드시 시험해 볼 수 있어야 한다는 의미를 함축
- 모델을 만드는 비용이 실제 물건을 만드는 비용보다 훨씬 적을 경우 모델을 만들어서 설계를 검사해 본다.
1. 왜 소프트웨어 모델을 만드는가?
  - 시험해 볼 구체적인 것이 있고, 그것을 코드로 시험해 보는 것보다 UML로 시험해 보는 쪽이 비용이 덜 들 때 UML를 사용한다.
2. 반드시 코딩을 시작하기에 앞서 포괄적인 설계를 해야 하는가?
  - 미리 계획을 짜는 것이 비용이 훨씬 적게 든다.
  - 하지만 소프트웨어 분야는 분명치 않다; UML을 그리는 것이 훨씬 비용이 적은지는 명확하지 않다.
UML을 효과적으로 사용하기
1. 다른 사람과 의사 소통하기: UML은 아이디어 초점에 맞춰 의사 소통하기에 매우 좋다.
  - 그러나 알고리즘의 세부 내용을 전달하는 목적에는 UML이 유용하지 않다.
2. 로드맵
  - 대규모 소프트웨어 구조의 로드맵을 만들 때 유용하다.
  - 어떤 클래스가 다른 클래스에 의존하는지 개발자가 빨리 파악할 수 있게 해주고 전체 시스템의 구조에 대한 참조 도표도로 사용된다.
  - 하지만, 모든 팀 구성원이 머뭇거리지 않고 칠판에 이런 다이어그램을 바로 그릴 수 있어야 한다.
3. 백엔드 문서
  - 문서작성을 프로젝트의 막바지에 팀의 마지막 작업으로 사용하는 것이 좋다.
  - 그러면 작성한 문서가 팀이 프로젝트를 떠나는 시점의 설계 상태를 정확하게 반영할 것이므로 다음에 이 프로젝트를 맡을 팀에게도 분명히 유용할 것이다.
  - 우리가 원하는 것은 시스템의 핵심 내용을 짚어서 기술하는 핵심 다이어그램 몇 개다.
4. 무엇을 보관하고 무엇을 버려야 하는가?
  - 다이어그램을 오래 기록되는 매체에 기록하지 않는 습관을 기르는 것이다.
  - 칠판이나 종이 조각에 다이어그램을 그려라
  - 일반적으로 CASE 도구나 그림을 그리는 프로그램을 사용하지 마라. (학습곡선이 크고 댑부분 그렇게 길지 않기 때문이다.)
  - 그러나, 오래 보관할 가치가 있는 다이어그램들만 보관해야 한다.
반복해서 통해 다듬기
- 작은 단계를 하나씩 밟아 나가면서 iteration이 되어야 한다.
1. 행위를 제일 먼저
  - 간단한 시퀀스 다이어그램으로 그리며 그 문제를 풀기 시작한다. (책에서는 collaberation diagram으로 예제를 설명함)
2. 구조를 점검하기
  - 위에서 그린 클래스/협력 다이어그램을 클래스 다이어그램으로 그려본다.
  - 가장 중요한 것은 연관/집합이 아니라 의존관계를 분석하는 것이다.
3. 코드를 마음속으로 그려보기
  - 지금 하는 작업을 당장 중단하고 어떻게 그 다이어그램을 코드로 바꿀 수 있는지 찾아내라.
  - 언제나 지금 다이어그램으로 나타내는 코드가 어떤 것인지 여러분 스스로 확실히 알고 있어야 한다.
  - (그렇다면 결국 Design Pattern의 지식을 알고 있는 경우가 많이 유리한 것 같다. 다이어그램을 보고 코드가 연상이 되어야 한다니... 큰 도전이다.)
4. 다이어그램의 진화
  - 클래스 다이어그램과 시퀀스/협력 다이어그램 사이를 아주 짧은 주기로 함께 발전 시킨다.
5. 미니멀리즘
  - 다이어그램이 가장 유용한 때는 다른 사람과 의사 소통을 할 때와 여러분이 설계에 관한 문제점을 푸는 일에 도움이 될 때다.
언제 다이어 그램을 그려야 하며, 어떻게 그려야 하는가?
1. 페이지 54 ~ 55 읽어볼 것, 주옥같은 말.
2. 다이어그램을 그려야 할 경우
  - 모든 사람이 동시에 특정한 부분의 구조를 이해해야 할 때
  - 설계에 다른 의견이 발생할 때. 이때 논쟁의 시간을 제한을 둔다.
  - 설계에 대한 아이디어로 이것저것 시도해 보고 싶을 때. 그리고 코드로 옮겨보고 만족스러울 때 종결
  - 누군가에게 일부분의 구조를 설명할 때
  - 프로젝트에서 문서를 요구할 때
3. 다이어그램을 그리지 말아야 할 경우
  - 공정에서 다이어그램을 그려야 한다고 단정 짓지 말 것.
  - 다이어그램을 안 그리면 죄책감을 느끼거난, 훌륭한 설계자는 누구나 다이어그램을 그린다는 생각이 든다고 다이어그램을 그리지 마라.
  - 설계 단계의 포괄적인 문서를 만들기 위해서 다이어그램을 그리지 마라
  - 다른 사람에게 어떻게 코딩을 해야 할지 알려주기 위해 다이어그램을 그리지 마라.
4. CASE 도구
5. 하지만 문서는 어떻게 합니까?
  - 소프트웨어의 문서는 반드시 짧고 핵심을 찔러야 한다.
  - 소프트웨어 문서의 가치는 그 분량에 반비례한다.
  - 문서에는 "고차원 구조에 대한 UML 다이어그램", "관계형 스키마의 ER당어그램", "시스템 빌드하는 방법", "테스트 방법 설명" 그리고 "소스 콘트롤 방법 설명" 등이 포함되면 좋다.
결론
- 동적 시나리오(시퀀스/협력 다이어그램)를 먼저 생각해보고 이것들이 어떤 정적구조(클래스 다이어그램)를 함축하는지 결정하는 전략이 가장 좋다.
- 동적 다이어그램과 정적 다이어그램을 5분이나 더 짧은 주기로 반복하며, 서로 발판삼아 동시에 발전시키는 것이 중요하다.
- UML을 필요한지 판단하고 행동으로 옮기기 전에 먼저 생각하라
- UML은 도구일 뿐 그 자체가 목적이 되어서는 안된다.
- 늘 절제하는 마음가짐으로 UML을 사용하라.