깜장 블로그

먼저, Sequence Diagram 으로 문제를 풀기 시작하자. Sequence Diagram 을 통해 어떻게 협력을 만드는지 알게 되었고,  이 과정에서 여러 객체를 만들었다.

다음으로, 이 Diagram 을 기반으로 Class Diagram 을 그려보자. 객체를 위한 Class 및 Class 들의 관계 사이에 Interface 를 넣는 등의 작업을 하면 된다. 이 때, 코드를 마음속에서 그려볼 수 있는 힘은 다이어그램 작업을 하는데 매우 중요하다. 긴 코드 대신 다이어그램을 이용하는 것이지, 다이어그램으로 코드를 대신하려는 것이 아니다. 다이어그램을 그려놓고 그 다이어그램이 나타내는 코드를 마음속으로 그려 볼 수 없다면, 지금하는 작업을 중단하고 어떻게 그 다이어그램을 코드로 바꿀수 있는지 찾아내라.

여기서 다이어그램은 단순하고 깔끔하게 유지하라. 세부적으로 할 수록 복잡할 뿐이지 생산성에 오히려 저해가 된다. 다이어그램은 다른 사람과 의사 소통을 할 때, 설계에 관한 문제점을 풀 때 도움이 되는 것이다.

언제 다이어 그램을 그릴 것인가?
- 모든 것을 다이어그램으로 그려야 한다는 규칙을 만들지 마라.
- 설계 아이디어가 분분할 경우, 의견을 모으거나 여러 설계 아이디어를 시도해보고 싶을 때 다이어그램을 그려보라.
- 누군가에게 코드 일부분의 구조를 설명할 때 다이어그램을 그려라.

다이어그램을 그리지 말아야 할 경우 ( ? : 잘 와닿지는 않는다. )
- 코딩시작전에 설계 단계의 포괄적인 문서를 만들기 위해서 다이어그램을 그리지 마라. 이런 문서는 거의 언제나 하등 쓸모가 없으며 시간만 엄청나게 잡아 먹는다.
- 다른 사람에게 어떻게 코딩을 해야 할지 알려주기 위해 다이어그램을 그리지 마라.

문서화는 어떻게 할까?
- 문서화는 정말 중요하지만, 양이 너무 지나칠 경우 문서의 바다에서 해맬수가 있다. 복잡한 프로토콜, 복잡한 관계형 데이터베이스의 스키마, 재사용가능한 복잡한 프레임워크도 마찬가지다. 하지만, 이것들이 모두 UML을 몇백 쪽이나 요구하지는 않다. 소프트웨어의 문서는 반드시 짧고 핵심을 찔러야 한다. S/W 문서의 가치는 그 분량에 반비례한다.
- 문서에는 중요한 모듈의 고차원 구조에 대한 UML 다이어그램, 관계형 스키마의 ER 다이어그램, 한 쪽이나 두 쪽 분량의 시스템을 빌드하는 방법, 테스트 방법 설명, 소스 코드 컨트롤 방법 설명 등이 포함.
- javadoc 도구가 문서만드는데 훌륭한 도구.

사각형은 클래스를 나타내고, 화살표는 관계를 나타내는데, 여기서 이 화살표는 연관( Association ) 관계를 나타낸다. 연관 관계는 한쪽 객체가 다른 쪽 객체를 참조하고, 그 참조를 통해 그 객체의 메소드를 호출함을 나타내는 단순한 데이터 관계이다.

연관 위에 쓴 이름은 참조를 담는 변수의 이름과 대응 된다. 즉, topNode 를 통해 TreeMap 은 TreeMapNode 객체를 참조하여, 해당 메소드를 호출 한다.

화살표 옆에 쓴 숫자는 인스턴스의 개수를 나타낸다. 만약, 이 숫자가 1보다 크다면 어떤 컨테이너를 사용한다는 뜻인데, 컨테이너로 보통 배열을 사용한다.

UML은 대규모 소프트웨어 구조의 로드맵을 만들 때 유용하다. 어떤 클래스가 다른 클래스에 의존하는지 개발자가 빨리 파악할 수 있다.