[UML 실전에서는 이것만 쓴다 :: 2장] 다이어그램으로 작업하기

• 왜 모델을 만들어야 하는가?

엔지니어는 자기 설계가 실제로 잘 작동할지 알아보려고 모델을 만든다. 여기에서 모델은 반드시 시험해 볼 수 있어야 한다는 의미가 함축되어 있다. 모델을 시험할 때 적용할 만한 기준이 하나도 없다면 그 모델은 만들 필요가 없다. 

'모델을 만드는 비용이 실제 물건을 만드는 비용보다 훨씬 적을 경우에 모델을 만들어서 설계를 검사해 본다.'

 

• 왜 소프트웨어 모델을 만드는가?

UML 다이어그램에는 확고한 시험 기준이 없다. UML 다이어그램을 그리는 일은 소프트웨어를 작성하는 일보다 비용이 적긴 하지만, 소스코드를 바꾸기가 더 쉬운 경우도 있다. 시험해볼 구체적인 것이 있고, 그것을 코드로 시험하는 것보다 UML로 시험해보는 쪽이 비용이 덜 들 때 UML을 사용한다.

 

• 반드시 코딩을 시작하기에 앞서 포괄적인 설계를 해야 하는가

설계는 미리 계획을 짜고 수행하는 것이 훨씬 비용이 적게 들기 때문에 하는 일이다. 

잘못된 설계를 버리는 것은 쉽지만, 잘못된 설계가 들어간 생산품을 버리는 일은 비용이 크다.

그러나 소프트웨어의 경우는 코드를 작성하는 것보다 UML 다이어그램을 그리는 것이 훨씬 비용이 적은지 명확하지 않다.

코드를 작성하기에 앞서 포괄적인 UML 설계를 만들면 드는 비용만큼 효과가 있는지 명확하게 바로 알 수는 없다.

 

---

 

• UML을 효과적으로 사용하기
  • 다른 사람과 의사 소통하기 : 다이어그램은 코드의 구조가 어떻게 생겼는지 매우 분명하게 보여준다. 반면, 알고리즘의 세부 내용을 전달하는 목적에는 UML이 유용하지 않다.
  • 로드맵 : UML은 대규모 소프트웨어 구조의 로드맵을 만들 때 유용하다. 어떤 클래스가 다른 클래스에 의존하는지 개발자가 빨리 파악할 수 있게 해주고 전체 시스템의 구조에 대한 참조 도표로도 쓸 수 있다.
  • 벡엔드(back-end) 문서 : 설계에 대한 문서를 작성하기에 가장 적당한 때는 프로젝트 막바지에 팀의 마지막 작업으로 하는 것이 가장 좋다. 작성한 문서가 팀이 프로젝트를 떠나는 시점의 설계 상태를 정확하게 반영할 것이므로, 다음에 이 프로젝트를 맡을 팀에게도 분명히 유용하다. 주의 깊게 생각한 끝에 그릴것. 어지럽게 그리지 말것!
  • 무엇을 보관하고 무엇을 버려야 하는가(저장해 두는 편이 좋은 다이어그램) 
    • 시스템 안에서 자주 사용되는 설계상의 해결 방법
    • 코드에서 알아내기는 힘들지만 꼭 지켜야 하는 복잡한 절차(protocol)
    • 시스템에서 자주 드나들지 않는 영역의 로드맵
    • 설계자의 의도를 코드보다 더 잘 표현할 수 있는 방식

 

• 반복을 통해 다듬기
  • 행위를 제일 먼저
  • 구조를 점검하기
  • 코드를 마음속으로 그려보기
  • 다이어그램의 진화
  • 미니멀리즘

 

• 다이어그램을 그려야 하는 경우
  • 여러 사람이 동시에 작업을 해서 모두 설계에서 특정한 부분의 구조를 이해해야 할 때
  • 두 명 이상이 특정 요소를 어떻게 설계해야할지 의견을 달리하고, 팀의 의견을 모을 필요가 있을 때
  • 어떤 설계 아이디어로 이것저것 시도해 보고 싶을 때
  • 누군가에게 또는 나 자신에게 코드 일부분의 구조를 설명할 때
  • 프로젝트 마지막에 가깝고 고객이 다른 사람을 위한 문서에 포함하기 위해 다이어그램을 요구할 때
• 다이어그램을 그리지 말아야 하는 경우
  • 공정에서 다이어그램을 그려야 한다고 해서
  • 다이어그램을 안 그리면 죄책감을 느끼거나, 훌륭한 설계자는 누구나 다이어그램을 그린다고 생각할 때
  • 코딩을 시작하기에 앞서 설계 단계의 포괄적인 문서를 만들기 위해서
  • 다른 사람에게 어떻게 코딩을 해야 할지 알려 주기 위해서

 

• 결론
  • UML
    • 반드시 반복적 방식으로 만들어야하고, 반복 주기도 짧아야 한다.
    • 동적 시나리오를 먼저 생각하고, 어떤 정적 구조를 함축하는지 결정할 것.
    • 동적 다이어그램과 정적 다이어그램을 5분 이하 주기로 반복하며, 서로 발판 삼아 동시에 발전시킬 것.
  • UML CASE 도구 
    • 생산성에 정말 도움이 될지 먼저 실험해보고 결정할 것.

 

남용하지 말고 아껴서 사용할 것. '늘 절제하는 마음가짐으로 사용하라'