1. 개념모델
	1.1 구현보단 인터페이스와 관계가 깊다.
	1.2 도메인 모델 : NOT 데이터 모델. UP. 목표는 실세계의 표기이다.
	1.3 역할 별로 객체를 분류시킬 수 있다.
	1.4 유비쿼터스 = 어디서든지 통용될 수 있다 = 비즈니스 기반.
	1.5 정적 다이어그램 :	
		1.5.1 클래스 다이어그램	-	클래스간의 관계, 인터페이스와 클래스와의 관계 등.
														구성 = Property(분석단계 추출) + Operation(설계단계 추출)
														!!.좋은 클래스? 1)책임 2)역할 3)협력
														Property : attribute(컬럼) + association(연결선. 비즈니스 or 시스템적으로 가치가 있을 때 사용)
														CRC : 담당자A를 찾아서 담당자A가 요구하는 업무의 담당자B를 다시 찾는 방식의 반복.
														NOTE : 일관성을 위해, 일관성에 문제가 생긴경우 주석다는 것처럼 사용하자.
														의존성 : 설계시점에서 표현하기 힘들다. A->B이고, B->C이더라도 A->C라고 볼 수 없다.(이행관계없음)
														집합과 복합의 차이는 결합도의 차이. public A a(B b) 이런게 강결합.
														의존성과 위임의 차이. 위임은 추상클래스(즉 다형성)
														Provides(제공자 인터페이스. List등) VS Required(요청자 인터페이스. Order 등)
														연관관계에서 연관보단 역할이 중요하다. 연관은 너무 복잡해 질 우려가 있다.
														용어 : 리얼라이제이션(언어의 임플리먼트)
		1.5.2 객체 다이어그램		-	클래스 다이어그램 설명용(=예제 = 스냅샷).
														파티복합구조 : 트리를 재귀적으로 표현한다.