6. 큰 문제들 해결하기

큰 문제 해결 하기 위한 방법

• 큰 문제는 여러 개의 기능별 조각들로 나누고 각 조각들을 개별적으로 풀어감으로써 해결할 수 있습니다.
• 큰 문제를 바라보는 가장 좋은 방법은 여러 기능의 조각들로 나누어 보는 것입니다.
• 각 조각들을 풀어야 할 개별 문제로 다룰 수 있고, 크기가 작은 개별 문제에는 이미 알고 있는 도구들을 적용할 수 있습니다.

* 도메인 분석
기존 시스템과 개발 이력, 도메인 전문가들로부터 얻은 지식, 기반이론, 그리고 도메인에서 새로 등장하는 기술을 기반으로 도메인 관련 정보를 찾아내고, 모으고, 구조화하고, 나타내는 프로세스.

방법 설명

• 요구 사항과 유스케이스부터 시작하는 것도 좋습니다.
   그런데 우리가 지금까지 시스템에 대해 정말 무엇을 알죠? 시스템에 대해 좀 더 알아낼 수 있는 방법 중의 하나는 비슷한 시스템을 알아내는 것입니다. 또 다른 방법은 시스템과 상관없는 것을 알아내는 것입니다. 이렇게 하면 시스템에서 신경쓰지 않아도 되는 부분을 결정하는데 도움이 됩니다.
  
  
• 특징들을 찾아 내세요.
   특징은 시스템이 해야 할 일에 대해 추상적으로 설명한 것입니다. 고객과 대화를 통해 시스템의 특징들을 얻어냅니다. 대개의 경우, 하나의 특징을 얻고 그 특징을 만족시키기 위한 여러 개의 요구 사항들이 나옵니다. 그래서 시스템의 특징들을 알아내는 것은 요구 사항을 얻는 좋은 방법입니다.
  개발 시스템에 대해 정보가 많지 않고, 어디서부터 시작해야 할지 감이 잡히지 않는 경우, 시스템의 규모가 커다란 프로젝트인 경우에는 시스템의 특징부터 시작하는 것이 정말 도움이 됩니다.
  주의 : 특징과 요구사항의 차이점에 너무 얽매이지 마세요.
  
  
• 유스케이스 다이어 그램을 그리세요.
   가끔 시스템이 하는 일을 알아야 하지만 유스케이스 작성에 필요한 세세한 내용까지 다루고 싶지 않을 때가 있습니다. 이러한 상황에서는 유스케이스 다이어그램을 사용할 수 있습니다. 유스케이스 다이어그램은 여러분의 시스템에 대한 청사진 입니다. 항상 세부 내용은 늦출 수 있을 때까지 최대한 늦추세요.
  특징 리스트를 사용해서 유스케이스 다이어그램에 빠진 것이 없게 만드세요.
  특징 또는 요구 사항 리스트로 시스템이 해야 할 큰 일을 알아내세요.
  
  
• 도메인 분석을 하세요.
   도메인 분석을 통해 디자인을 확인할 수 있고, 고객이 사용하는 용어를 사용할 수 있습니다.
  시스템에 대해 알아 낸 모든 내용을, 우리의 고객이 실제 이해하는 방식으로 모아보고 봅시다. 이것은 도메인 분석이라고 하는 프로세스이고, 고객이 이해하는 용어로 문제를 설명하는 것입니다.
  도메인 분석을 하면 여러분이 만들 필요가 없는 시스템의 부분을 만들지 않는 데 도움이 됩니다.
  
  
• 큰 문제를 기능의 작은 조각들로 나누기.
   이제 큰 문제를 쪼개어 기능의 작은 조각들로 나눌 때입니다. 청사진과 기능 리스트를 가지고 큰 프로그램을 각각의 기능을 가진 여러 개의 작은 조각들로 나눌 수 있습니다.
  
  
• 작은 문제들의 해결에 디자인 패턴을 적용합니다.

 

OOA&D 도구 상자

요구사항

• 좋은 요구 사항은 시스템이 고객이 기대한 대로 동작하도록 합니다.
• 여러분의 요구 사항이 시스템의 유스케이스의 모든 단계들을 담고 있는지 확인하세요.
• 유스케이스를 사용해서 고객이 잊고 얘기하지 않았던 것들을 찾아내세요.
• 유스케이스는 시스템에 추가되어야 할 불완전하거나 빠진 요구 사항들을 분명하게 합니다.
• 요구 사항은 항상 끊임없이 변화합니다.(그리고 성장합니다.).

분석과 설계

• 잘 디자인된 소프트웨어는 변경과 확장이 쉽다.
• 기본적인 캡슐화와 상속 같은 객체지향 원리를 사용하여 소프트웨어를 좀 더 유연하게 만드세요.
• 디자인이 유연하지 않으면, 변경하세요. 변경해야 하는 것이 여러분의 디자인이더라도, 결코 나쁜 디자인을 고수하지는 마세요.
• 여러분의 각 클래스의 응집도를 높게 하세요. 여러분의 클래스 각각은 하나의 일을 정말 잘하는 것에 중점을 두어야 합니다.
• 소프트웨어 디자인을 진행하면서, 항상 높은 응집도를 위해 노력하세요.

객체지향 원리

• 변하는 것을 캡슐화하라.
• 구현에 의존하기보다는 인터페이스에 의존하도록 코딩하라.
• 각 클래스는 변경 요인이 오직 하나이어야 한다.
• 클래스는 행동과 기능에 관한 것이다.

큰 문제들 해결하기 정리

1. 고객의 말에 귀 기울여, 여러분이 만들어 주길 바라는 것이 무엇인지 알아낸다.
2. 특징 리스트를 고객이 이해하는 용어를 사용하여 작성한다.
3. 작성한 특징 리스트가 고객이 실제로 원하는 것인지 확인한다.
4. 유스케이스 다이어그램을 사용하여 시스템의 청사진을 만든다.
5. 큰 시스템을 여러 개의 작은 섹션으로 나눈다.
6. 디자인 패턴을 시스템의 작은 섹션에 적용한다.

 

핵심 정리

• 큰 문제를 바라보는 가장 좋은 방법은 작은 문제들의 집합으로 보는 것입니다.
• 작은 프로젝트들에서처럼 큰 프로젝트에서도 특징과 요구 사항들을 모으는 것부터 시작합니다.
• 특징은 보통 시스템이 하는 "큰"일이지만 "요구 사항"과 같은 뜻으로도 사용될 수 있습니다.
• 공통점과 차이점은 새로운 시스템을 여러분이 이미 알고 있는 것과 비교하여 바라보는 시각을 제공합니다.
• 유스케이스는 세부 사항에 중점을 두고 있습니다. 유스케이스 다이어그램은 큰 그림에 보다 중점을 두고 잇습니다.
• 유스케이스 다이어그램이 시스템의 모든 특징들을 설명해야 합니다.
• 도메인 분석은 시스템을 고객이 이해하는 용어를 사용하여 표현하는 것입니다.
• 액터는 시스템과 상호작용하지만 시스템의 일부는 아닌 모든 것입니다.