UML 언제 써야 하는가?

Clean code의 작가 밥 아저씨의 "UML 실전에선 이것만 쓰인다"의 내용을 발췌했다.

소프트웨어 공학 과목을 들으면서 공감되는 부분이 많아서 가져왔다. 

1. UML이란? 

Unified Modeling Language로 SW에서 설계할 때 쓰이는 Diagram을 만드는 언어이다.  StarUML과 Draw.io를 통해서 그릴 수 있다. 

 

2. Diagram이란

Diagram: 그래픽이나 구조로 대상을 나타내는 이다. 

다이어그램으로 전달하고 시픈 것은 Concept, Specification, Implementation 3가지 이다.

• Concept(개념): 소스코드와 관계가 적다. 자연어 논문과 가깝다.
  • Animal←Dog 해석이 다분함 속한다, 속박한다. 다양한 해석이 가능하다. 
• Specification(명세): 소스코드로 바꾸기 위해 그리는 것
• Implementation(구현): 소스코드를 설명하기 위해 그리는 것

해당 책에서는 아래 2개 Specification과 Implementation을 위한 Diagram에 관해 설명한다. 즉, 아래 내용은 아이디어를 코드 로 옮기거나, 코드를 다른 사람이 이해하기 쉽게 만드는 것이 목적이다. 

3. 종류

• static diagram: class, data structure, object들의 관계를 나타낸다.
• dynamic diagram: 어떻게 변하는지 시간 관점에서 그린 것이다.
• phisical diagram: 파일의 구조 물리적 실체, ex) elf ply file 구조

3.1 Class diagram

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/

• class, association으로 표현된다.
• association
  • 화살표
  • 변수를 담는 이름, 인스턴스 갯수도 적을 수 있음. 컨테이너이다. 
  • 참조를 통해 method 호출

3.2 Object Diagram

https://www.youtube.com/watch?app=desktop&v=3g-pWGssaZ8

• 실행중 어느순간 메모리에 올라간 객체의 관계
• member 변수에 데이터 넣어서 표현

3.3 Sequence Digram

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-sequence-diagram/

• 메세지를 주고 받는 순서를 명확히 한다
• 허수아비(졸라 맨, 액터): 알려지지 않은 method 호출자
• [topNode == null] Gaurd 라고 함. 대괄호 안의 표현식. 어떤 경로로 프로그램이 실행될지 표시
• construction:
• data tocken: o → 모양으로, parameter를 나타냄
• activation (활성 상자): 해당 method가 실행 되는데 얼만큼의 시간이 걸리는지

3.4 Collaboration Diagram

https://agilemodeling.com/style/collaborationdiagram.htm

• 객체사이의 관계를 명확히 함
• association: 화살표, 다른 객체에 메세지를 보낼 수 있다면
• message 위의 이름과 sequence 숫자, 적용되는 Gaurd를 적는다.

3.5 State Diagram

https://blog.sflow.com/2016/09/asynchronous-docker-metrics.html

• finite state machine
• State
• Event
• Transition

4. 왜 UML을 사용하는가?

그리는 것 보다 팀원 전체가 이해 할 수 있는 것이 훨씬 더 중요하다.

4.1 코드로 실험하는 것 보다 uml로 실험 하는 것이 비용이 작을 때 활용한다.

• 그러나 건축이나 항공기처럼 비용이 획기적으로 차이나진 않는다. 오히려 uml이 비용이 더들 수도 있다. 그러므로 SW 설계는 신중히 해야한다. 

4.2 의사소통

• 쉬운 것은 굳이 diagram 화할 필요 없다.
  • ex) bubble sort class를 diagram으로 그리면 그리는데 더 오래걸린다.

4.3 Roadmap

• 시스템 안에서 개발자들이 담아둬야 하는 지식을 그대로 그려놓은 것
• 가장 좋은 방법은 칠판에 그렸다가 지우는 것

5. 언제 그려야하는가?

외우지 말고, 회의하다보면 반복적으로 그려서 결국 적게 될 것이다. 설계제의 의도를 코드보다 잘 표현할 수 있다면 괜찮다.

• 프로젝트의 마지막에 (떠나고 돌아와도, 혹은 누군가 후타가 와도 알 수 있도록)
• 아이디어 회의
• 소통
• 일부 코드 구조 설명 , 코드가 더 쉬울지도 있다는 것을 잊지 말자. 
• 자주 사용되는 설계상 해결방법을 표현하는 것
• 코드에서 알아내기는 힘들지만 꼭 지켜야하는 프로토콜
• 시스템에서 자주 들어나지 않는 영역의 로드맵 제공

6. 언제 그리면 안 되는가?

• 공정에서 그려야 해서 (지금 우리 과목의 상황이다. 과제로 내고 있긴 하지만, 실질적으로 아이디어 공유가 되고 있지 않다.)
• 포괄적인 문서를 만들기 위해 
• 어떻게 코딩해야할지 알려주기 위해서
  • 아키텍트는 자기가 만든 침대라면 누울 수 있다는 것을 보이기 위해, 코딩에 참여해야 한다.

7. 그리는 process

동적 diagram부터 시작해서 정적 diagram까지 어떤 관계인지 생각하면서 코딩 할지 그린다.

UML은 소스 코드가아니다. 모든 method 변수 관계를 선언해선 안된다. 적은 내용으로 keep it simple이다.

Reference

• UML 실전에선 이것만 쓴다.