출처 : UML 실전에서는 이것만 쓴다
로드맵
- UML은 대규모 소프트웨워 구조의 로드맵을 만들 때 유용하다. 이런 로드맨은 어떤 클래스가 다른 클래스에 의존하는지 개발짜가 빨리 파악할 수 있게 해주고 시스템의 구조에 대한 참조 도표로도 사용된다. 굳이 문서로 저장 안해도 된다
반복을 통해 다듬기
- 행위를 제일 먼저 시작하는 것이 좋다. 간단한 시퀀스 다이어그램으로 문제를 풀어나간다. 이후 협력 다이어그램을 작성한 후 구조를 점검하여 클래스 다이그램을 다듬어 나간다. 이때 클래스 간에 의존관계를 최소화하기 위해 적절한 패턴을 사용하는 것이 좋다.
미니멀리즘
- UML은 의사소통을 위해 존재하는 것이지 예쁘게 꾸미기 위해 존재하는 것이 아니다. 다이어그램 한 장에 많은 세부사항을 그려 넣지 말아야 한다. UML다이어그램은 메서드나 변수, 관계를 선언하는 장소로 취급해서는 안된다.
클래스다이어그램
연관
클래스 사이의 연관은 다른 객체의 참조를 가지는 인스턴스 변수를 의미한다. 프로그램 안에서 실제로 일어나는 일을 정확히 설명하는 "~와 연결된다" 와 같은 용어이다
집합
부분/전체 관계를 내포하는 특별한 형태. 집합에 대해 여러 정의가 내려져 있기때문에 혼란을 가져다 준다. 가급적 피하는 것이 좋다. 집합의 규칙은 전체는 자신이 될수 없고(자기참조), 어떤 객체가 자신의 부분이 될수 없고, 두 객체가 서로 상대 객체의 부분이 될수 없다. 그리고 세 객체가 전체/부분 관계의 고리를 만들 수 없다.
합성
집합과 동일한 규칙을 가지고 있으면서 몇가지 규칙이 추가된다.
피보호자의 한 인스턴스를 두 주인이 소유하지 못한다. 하지만 객체 다이어그램과 대응하는 클래스 다이어그램은 문제 없다.
주인은 피보호자의 수명 전체에 책임을 진다. 주인이 소멸되면, 피보호자도 함께 소멸되어야 한다. 즉 주인 객체에서 내에 생성된 피보호 객체는 주인 객체가 메모리에서 해제될때 같이 해제되어야한다.
시퀀스다이어그램
- 시퀀스 다이어그램은 모든 시나리오에서 공통으로 나오는 것을 찾아 초점을 맞춰야한다. 공통된 주제와 공통된 실천 방법을 보이기 위해 다이어그램을 사용해야한다. 사소한 차이점까지 모두 문서로 만들기 위해 다이어그램을 사용하지 마라. 메시지 흐름을 설명하기 위해 시퀀스 다이어그램을 꼭 그려야 한다면 간결하고 절재해서 그려야한다.
첫째. 시퀀스 다이어그램이 정말 필요한지 확인하라. 코드가 의사전달하기 더 쉽고 경제적인 경우가 많다.
둘째. 시퀀스 다이어그램이 필요하다면 여러 시나리오로 쪼갤 수 있는지 확인하라. 거대한 시퀀스 다이어그램은 읽기 쉬운 작은 시퀀스 다이어그램 여러개로 나눌수 있다.
세째. 무엇을 그려야하는지 생각해봐야한다.저차원 연산에 대한 세부사항과 고차원의 개괄인지 생각하여야 한다. 대부분의 경우 고차원 다이어그램이 더 쓸모있다.
로드맵
- UML은 대규모 소프트웨워 구조의 로드맵을 만들 때 유용하다. 이런 로드맨은 어떤 클래스가 다른 클래스에 의존하는지 개발짜가 빨리 파악할 수 있게 해주고 시스템의 구조에 대한 참조 도표로도 사용된다. 굳이 문서로 저장 안해도 된다
반복을 통해 다듬기
- 행위를 제일 먼저 시작하는 것이 좋다. 간단한 시퀀스 다이어그램으로 문제를 풀어나간다. 이후 협력 다이어그램을 작성한 후 구조를 점검하여 클래스 다이그램을 다듬어 나간다. 이때 클래스 간에 의존관계를 최소화하기 위해 적절한 패턴을 사용하는 것이 좋다.
미니멀리즘
- UML은 의사소통을 위해 존재하는 것이지 예쁘게 꾸미기 위해 존재하는 것이 아니다. 다이어그램 한 장에 많은 세부사항을 그려 넣지 말아야 한다. UML다이어그램은 메서드나 변수, 관계를 선언하는 장소로 취급해서는 안된다.
클래스다이어그램
연관
클래스 사이의 연관은 다른 객체의 참조를 가지는 인스턴스 변수를 의미한다. 프로그램 안에서 실제로 일어나는 일을 정확히 설명하는 "~와 연결된다" 와 같은 용어이다
집합
부분/전체 관계를 내포하는 특별한 형태. 집합에 대해 여러 정의가 내려져 있기때문에 혼란을 가져다 준다. 가급적 피하는 것이 좋다. 집합의 규칙은 전체는 자신이 될수 없고(자기참조), 어떤 객체가 자신의 부분이 될수 없고, 두 객체가 서로 상대 객체의 부분이 될수 없다. 그리고 세 객체가 전체/부분 관계의 고리를 만들 수 없다.
합성
집합과 동일한 규칙을 가지고 있으면서 몇가지 규칙이 추가된다.
피보호자의 한 인스턴스를 두 주인이 소유하지 못한다. 하지만 객체 다이어그램과 대응하는 클래스 다이어그램은 문제 없다.
주인은 피보호자의 수명 전체에 책임을 진다. 주인이 소멸되면, 피보호자도 함께 소멸되어야 한다. 즉 주인 객체에서 내에 생성된 피보호 객체는 주인 객체가 메모리에서 해제될때 같이 해제되어야한다.
시퀀스다이어그램
- 시퀀스 다이어그램은 모든 시나리오에서 공통으로 나오는 것을 찾아 초점을 맞춰야한다. 공통된 주제와 공통된 실천 방법을 보이기 위해 다이어그램을 사용해야한다. 사소한 차이점까지 모두 문서로 만들기 위해 다이어그램을 사용하지 마라. 메시지 흐름을 설명하기 위해 시퀀스 다이어그램을 꼭 그려야 한다면 간결하고 절재해서 그려야한다.
첫째. 시퀀스 다이어그램이 정말 필요한지 확인하라. 코드가 의사전달하기 더 쉽고 경제적인 경우가 많다.
둘째. 시퀀스 다이어그램이 필요하다면 여러 시나리오로 쪼갤 수 있는지 확인하라. 거대한 시퀀스 다이어그램은 읽기 쉬운 작은 시퀀스 다이어그램 여러개로 나눌수 있다.
세째. 무엇을 그려야하는지 생각해봐야한다.저차원 연산에 대한 세부사항과 고차원의 개괄인지 생각하여야 한다. 대부분의 경우 고차원 다이어그램이 더 쓸모있다.
'UML,OOP,Pattern, TDD' 카테고리의 다른 글
Strategy pattern VS Brigde Pattern (0) | 2011.10.09 |
---|---|
TDD - 계약에 의한 설계(DbC, Design by Contract) (0) | 2011.04.19 |
TDD Tip (0) | 2011.04.19 |
객체지향 개발 관련 팁 (0) | 2011.04.19 |
객체지향 개발 원칙 (0) | 2011.04.19 |