마틴 파울러는 세가지 차원으로 다이어그램을 구분한다.


- 개념 Concentual

- 명세 Specification

- 구현 Implementation


개념 차원 다이어그램은 소스코드를 정의하지 않는다.

말 그대로 개념만 정의하며 소스코드를 정의해서도 않된다.

반면 명세와 구현은 훨씬 의미가 명확하다.


다이어그램의 종류는 세가지로 나눈다


- 정적 다이어그램

- 동적 다이어그램

- 물리 다이어그램


대표적인 다이어그램은 아래와 같다


- 클래스 다이어그램

- 객체 다이어그램

- 시퀸스 다이어그램

- 협력 다이어그램

- 상태 다이어그램


클래스 다이어그램은 클래스 간의 관계를 나타낸다

객체 다이어그램은 실행 중 객체의 관계를 나타낸다

시퀸스 다이어그램은 메서드가 어떻게 구현되는가에 대해 나타낸다

협력 다이어그램은 시퀸스랑 마찬가지지만 객체 관계 위주로 나타낸다

상태다이어그램은 유한상태기계로 나타낸다


다이어그램은 모델링의 과정 중 하나이다.


코드작성보다 다이어그램작성이 시간적 측면에서 비용이 커지면 무 쓸모이다.

그러므로 다이어그램은 아래와 같은 이유로 사용하는 것이 현명하다


- 팀원들 간의 의사소통을 할 때

- 알고리즘의 세부내용은 오히려 다이어그램보다 소스코드 자체가 낫다

- 그림은 최대한 단순해야한다. 복잡하면 오히려 비효율적이다.

- 도구보다 칠판이나 종이를 사용해라

- 빨리 이해시키고 빨리 코드작성으로 넘어가야한다. 다이어그램에 초점을 두면 생산성이 저하된다.

- 특정한 구조를 이해 시키거나 팀의 의견을 받아야할 때 그려라

- 포괄적인 문서를 만들기 위해 강압적으로 강제적으로 그리지 마라

- CASE도구는 학습비용이 크다. 그러니깐 칠판을 사용해라


문서는 반드시 작성해야한다.

- 복잡한 것들은 당연히 문서화 해야한다

ex) 관계형 DB, 재사용 가능한 복잡한 프레임워크