[book] UML Distilled

일종의 UML 입문서 겸 사용법 설명서
저자는 UML문법에 집착하지 말고 원하는대로 쓰면 된다고 함.
UML을 스케치로서 사용하며 시스템의 이해를 돕거나 설계를 돕는 식으로 사용하는 것을 강조.
그를 위해서는 UML정의나 문법 등에 얽매이지 않아도 된다고 하고 있다.
-> 맞는 말인듯.

개발공정으로는
반복 방식을 추천.
폭포수 방식(분석-설계-개발-테스트)와 다르게 프로젝트를 기능의 부분집합으로 나누어서 분석-설계-개발-테스트를 여러 번 반복하는 것.
각 반복 단계가 끝나면 필요한 기능의 1/n을 제공하는 시스템이 완성.
물론 매 반복이 끝날 때마다 시스템을 구축하지 않을 수 있지만, 완성품 수준의 품질을 가지고 있어야 함.
반복 단계마다 시스템을 구축하면 그로부터 피드백을 얻을 수 있다. -> 다음 반복 때는 더 나은 품질로 향상 가능.
폭포수 방식은 각 단계의 지연을 숨기기가 쉬우므로 반복 방식을 추천. 최소한 단계별 출시를 사용하기를 권장.
-> 내 경험으로는 어떤 프로젝트 최초의 개발 시에는 폭포수를, 그 후 고도화 시에는 반복 방식을 사용하는 듯 함.

시간구획
반복 작업을 위한 기술. 정해진 시간 안에 작업을 하도록 하는 것.
만약 해당 기간 내에 다 못할 것 같으면, 기능을 미뤄야지 기간을 지연 시켜서는 안 됨.
-> 경험상, 고객과의 의사소통이 잘 이루어지면 가능한 듯.

UML을 공정에 적용하기
1. 요구사항 분석
2. 유스 케이스 작성 : 사용자와 시스템의 상호작용을 보여줌
3. 개념적인 관점에서 그려진 클래스 다이어그램 : 도메인의 정확한 어휘를 구성하는 좋은 방법
-> 빼도 괜찮을 듯
4. 액티비디 다이어그램 : 각각의 업무가 어떤 식으로 처리되는가의 흐름도를 보여줌. 복잡한 유스 케이스에 대해서 작성.
5. 상태 다이어그램 : 어떤 개념이 다양한 상태와 그 상태를 변경하는 이벤트로 구성되어 흥미로운 생명 주기를 가지고 있을 때
  추가적으로 이해를 돕기위해 작성. 상태표가 유용할 듯.
6. 설계
7. 소프트웨어 관점에서의 클래스 다이어그램
8. 시퀀스 다이어그램 : 유스 케이스로부터 가장 중요하고 흥미로운 시나리오를 찾아내고 그에 대해 작성.
  소프트웨어에서 무엇이 일어나는지 알아내는 좋은 접근 방식
9. 소프트웨어의 구조를 큰 단위로 나타내는 패키지 다이어그램
10. 복잡한 생성 이력을 가지는 클래스들에 대한 상태 다이어그램
11. 소프트웨어의 물리적인 레이아웃을 보여주는 배치 다이어그램

-> 3, 4, 5, 9, 10, 11은 필요할 때만 작성하면 되지 않을까 싶다.

실제의 표기법에 대해서는 책을 참고하고, 위에서 말한대로 정의나 문법이 가장 중요한 건 아니니까 모든 작성법을 익힐 필요는 없을 듯.
어디까지나 이해하는게 중요하고 UML은 그 이해를 돕는 수준으로 사용하는 것이 옳은 듯.
개인적으로는 유스 케이스가 가장 중요하고, 그 외엔 클래스 다이어그램이랑 시퀀스 다이어그램 정도 익혀놓으면 될 듯.