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 관리자가 개발자와 현업 사이에서 커뮤니케이션을 차단하는 것도 일종의 위험관리. 실제로 위험관리는 미비한 경우가 많다.