다이어그램을 그려야 할 경우
다이어그램을 그리지 말아야 할 경우
하지만 문서화는 어떻게 합니까복잡한 통신 프로토콜은 문서화해야 한다. 복잡한 관계형 데이터베이스의 스키마도 문서화해야 한다. 재사용 가능한 복잡한 프레임워크도 마찬가지다. 백만 줄의 자바 코드로 된 프로젝트에 12명이 일하는 팀이라면, 모두 합쳐 25쪽에서 200쪽 사이의 영구 문서로 충분하다고 생각한다.
정적인 내용,클래스 사이의 관계를 표기할 수 있다. 클래스의 멤버변수,멤버함수를 보여줄 수 있고, 그 클래스가 다른 클래스에서 상속되었는지, 다른 클래스를 참조하는지도 알 수 있다. 한 마디로, 소스코드에 나타나는 클래스 사이의 의존 관계를 모두 표기할 수 있다.
UML class diagrams allow us to denote the static contents of, and relationships between classes. In a class diagram we can show the member variables, and member functions of a class. We can also show whether one class inherits from another, or whether it holds a reference to another. In short, we can depict all the source code dependencies between classes. This can be valuable. It can be much eaiser to evaluate the dependency structure of a system from a diagram than from source code. Diagrams make certain dependency structures visible. We can see dependency cycles, and determine how best to break them. We can see when abstract classes depend upon concrete classes, and determine a strategy for rerouting such dependencies. .
- 로버트 마틴, UML 실전에서는 이것만 쓴다, p.36 -
final 키워드는 클다에서 {read Only}라고 표시한다. public은 +로, private은 -로 표현한다.