1. UML 개요
	-> 시스템 관점에서, 운용 때도 관리를 하자.


2. UML 소개
	2.1 사용법
		- 스케치 : 의사소통용, 단순.	-> 개념적 관점
		- 청사진 : 코딩직전, 복잡		-> 명세 관점
		- 프로그래밍 언어					-> 구현관점

	2.2  MDA(Model Driven Architecture) : 사용 가능한 툴이 없다. 개념적인 것만 알아둬도 무방.
		- 컴퓨터 독립적 모델	: 시스템과 별개로, 현업끼리 대화에 사용하는 문서 등을 의미한다. 
		- 플랫폼 독립 모델		: 분석 + 설계 단계. 기술과 독립.
		- 플랫폼 종속 모델		: 구현 단계. 특정 환경에 종속. 리버스 엔지니어링을 사용하면 되므로 잘 사용하지 않는다.
		=> PIM -> PSM = UML -> 프로그래밍 언어

		!!. UML = 로테이션
		!!. 설계중심에서 분석중심으로


3. UML 다이어그램 분류

	3.1 구조 다이어그램
		3.1.1 클래스 			: 핵심. 이것만으로 기본적인 흐름 파악은 가능하다. 70% 정도의 비중
		3.1.2 오브젝트 		: 클래스에 비해 상대적으로 비중이 적다. 클래스의 보조라고 보면 된다.
		3.1.3 복합구조 		: UML2.0 때 추가된 기능으로, 사용빈도는 적다. 실행시간에 클래스 분할과 관련된다.
		3.1.4 배치				: 산출물의 노드(=일반적으로 하드웨어)로의 배치. 분석/설계 단계에선 필요치 않다. 아키텍트 들이 주로 사용한다.
									  (= 시스템을 비즈니스와 아키텍쳐 단위로 나눈다고 쳤을 때, 아키텍쳐에 포함된다.)
		3.1.5 컴포넌트		: 객체지향이 아닌 컴포넌트 기반으로 설계시 사용한다.
		3.1.6 패키지			: 시스템 규모가 너무 클 때, 시스템 분할의 단위(=서브 시스템 수준으로)로 설계시 사용.
									  ex) 영업/상품기획 등의 큰 단위에 사용.
		

	3.2 행위 다이어그램(+상호작용 다이어그램)
		3.2.1 액티비티				: 절차/병렬적 행위로 비정규적 산출물.
											  비추천. 이유 : 비즈니스/내부 로직 그릴 때 사용되기 때문에 중복된다. BPID를 더 추천. 현업이 작성한 파워포인트 순서도가 더 낫다..
		3.2.2 유즈케이스			: 사용자 - 시스템 간의 상호작용. Lotation. 요구사항 정의용. 사용 빈도가 크다.
		3.2.3 상태기계 				: 이벤트 동안의 객체 생명주기 표현. 설계 단계. 1개의 객체에 대해 그린다. 필요성이 낮다. 일반적으로 비정규 산출물.
		3.2.4 상호작용 인터뷰	: 아래 참조.
		3.2.5 시퀀스 					: 흐름에 중점을 둠. 클래스 다이어그램 이후로 가장 많이 쓴다. 20% 정도의 비중
		3.2.6 커뮤니케이션			: 객체의 구조에 중점. 시퀀스와 내용이 동일하며 표기법만 상이하다. 로즈에선 시퀀스 생성시 자동 생성 가능. 전 콜레보레이션 다이어그램
		3.2.7 타이밍					: 사용빈도 적다. 특정 시점의 객체 상호작용.


4. 표기법
	4.1 합법적인 UML
		4.1.1 규범적인(prescriptive) 규칙
		4.1.2 서술적인(descriptive) 규칙 ★ Martin's 추천.

	4.2 불완전성
		4.2.1 모든 것을 표현할 순 없다. 다른 툴을 사용해도 됨.
	
	4.3 아키텍쳐
		4.3.1 4 + 1
			4 : 설계 뷰				- 
				 프로세스 뷰		- 
				 구현 뷰				- 형상관리 포함.
				 배치 뷰				- H/W 반영
			1 : 유스케이스 뷰	- 상단 4개의 뷰에 모두 영향을 미친다. 요구사항 정의이므로 테스트 담당자에게도 제공된다.
										   (즉, 원칙적으론 유스케이스로 테스트가 되어야 한다. 실제론 요구사항이 중간에 변경되기 때문에 테스트케이스는 별도로 만들긴 한다.)


5. 개발 프로세스 개요
	-> 상황에 따라 가변적이므로 합의에 도달 못함.

	5.1			방법론					VS				프로세스
			관리 + 개발 프로세스 					개발 프로세스만 존재
	
	5.2			반복						VS				폭포수				=> 폭포수 안엔 반복이 N개 들어있다.
			
	5.3 예측계획법과 적응계획법
		  : 실제론 예측이 불가능.

	5.4 기민한(Agile) 프로세스
		5.4.1 XP가 가장 유명함. 최고의 가치는 소프트웨어(문서보다. 때문에 한국에 적용이 어렵다.)
		5.4.2 사람 중심이다.	대화가 필수이므로 팀원과 팀워크에 따라 성패 좌우.
										주 40시간 근무를 필수로 한다.
										소스 코드 1 : 1 테스트 코드
		5.4.3. Scrum : 관리 관점으로 최근 주목. 1달 단위로 반복. 추가 요구사항은 1달 후에 반영. 자기조직화(= 개개인의 능력 향상을 위한 배려)
						 

	5.5 RUP - 이하 모두 RUP
		5.5.1 개발 + 관리 방법론.
		5.5.2 도입 -> 발단 -> 구축 -> 전이(transit = delivery)
		5.5.3 하나의 프로세스로 모든 프로젝트를 해결할 순 없으므로, 여러가질 사용. ex)RUP 중심에 필요할 경우에만 애자일 사용하는 방법 추천.


6. UML 맞춤
	6.1 요구사항분석	: 유스케이스 + 클래스
	6.2 설계				: 클래스 + 시퀀스
	6.3 문서화				: 
	6.4 레거시 코드		: UML을 역공학해서 클래스 관계를 파악할 수 있다.


7. UML  개발 생명주기
	7.1 UML은 원칙적으로 개발 Process에 독립적이다.
	7.2 도입 -> 발단 -> 구축 -> 전이
	7.3 특이사항
		7.3.1 비즈니스 유스케이스 모델링이 생략되었다. 원인불명.
		7.3.2 비전문서 : ex) 스마트폰 도입 = 아침에 일어나서 바로 업무 확인 가능
		7.3.3 UI도 분석 단계에 해야 한다.
		7.3.4 관리자가 개발자와 현업 사이에서 커뮤니케이션을 차단하는 것도 일종의 위험관리. 실제로 위험관리는 미비한 경우가 많다.


8. SW 개발 주요사항.
	8.1