3장 요약

  • 고객의 요구는 계속해서 변한다. 따라서 아무리 좋은 유즈케이스를 작성했다 하더라도, 새로운 요구사항에 맞게 빠르게 소프트웨어를 수정할 수 있어야 한다.
  • 유즈케이스가 복잡해지면 Main Path와 Alternate Path로 분리
  • 유즈케이스의 시작 부터 끝까지 통과한 것 하나를 시나리오라고 한다.
    • 시나리오와 유즈케이스 개념을 어떻게 가져가는 것이 좋을까?
      • 시나리오는 유즈케이스의 인스턴스?
    • 대부분의 유즈케이스들을 몇몇 시나리오를 가지고 있다. 그러나 그들 모두 공통의 사용자 요구를 달성하기 위한 목적을 가지고 있다.
      • 이 부분을 읽으니 시나리오가 유즈케이스라는 클래스의 인스턴스라는 가설이 좀 더 그럴 듯하게 느껴진다.
  • 요구사항 목록을 반영한 유즈케이스를 작성해야 하고, 그 반대도 마찬가지다.
  • 중복되는 코드가 발생하면 일단 고민의 시간을 가져야 한다.
  • 요구사항의 변경은 기존에 미처 깨닫지 못했던 시스템의 문제를 밝혀주기도 한다.
  • 변화는 항상 존재하기 떄문에 이것을 일을 계속 할 수록 시스템이 계속 진화해야 한다.

4장 요약

  • 분석은 시스템이 실제 세상에서도 적용될 것이라는 것을 확인하는데 도움을 준다.
    • 문제 분석
    • 해결책 세우기
  • 유즈케이스가 당신과 상사 그리고 고객에게 유용하도록 작성하라.
  • 분석과 유즈케이스는 고객, 관리자 그리고 개발자들에게 시스템이 어떻게 실제 세상에서 동작할지 보여줄 것이다.
  • 위임 Delegation은 애플리케이션이 Loosely coupled 한 상태를 유지하는데 도움이 된다.
  • Textual Analysis를 통해서 클래스, 메소드, 필드를 뽑아낸다.
  • 좋은 유즈케이스
    • 쉽게 이해할 수 있는 언어로..
    • 분명하고 정확하게 시스템이 무엇을 하는지 설명한다.
  • 좋은 유즈케이스를 갖춘 뒤에 Textual Analysis를 통해서 빠르고 쉽게 시스템의 클레스를 뽑아낼 수 있다.

느낀점

  • 유즈케이스가 꼭 동그라미 네모 사람모양으로 표시되는 것은 아닌다 보다.
  • 오히려 번호를 붙인 텍스트로 적은 것이 그림보다 더 도움이 될 수 있겠다.
  • 그러나 일일히 모든 요구사항에 대한 모든 유즈케이스를 관리하려면 정말 힘들겠다.
    • 저걸 언제 다 저렇게 적으며 관리할까?
    • 당연히 해야할 일인가.. 흠..
    • 중요한 것만 하겠지?