[펌] [안영회의 UML 강좌20] - Iteration 계획

##########0*
앞서 강좌에서도 반복적인 개발에 대해 언급했습니다. RUP를 비롯한 모든 객체지향 방법론은 반복적인 접근법을 선택합니다. 마치 계절이 한번 돌아 한 해가 되듯이 프로젝트는 iteration의 반복으로 구성됩니다. Iteration은 어떻게 나누며 어떠한 순서로 계획해야 하는지 알아보도록 하죠.

이번 강좌에서는 강좌 초기에 말씀 드린 참고문헌 외에 다음 두 권의 서적을 참조했음을 밝힙니다.

 Developing Enterprise Java Applications with J2EETM and UML…Khawar Zaman Ahmed, Cary E. Umrysh, Addison Wesley
 UML User Guide … Grady Booch 외, Addison Wesley


iteration 계획하기

객체지향 분석 및 설계의 대가인 Booch에 따르면 iteration 계획에는 기본적으로 다음의 세 가지 사항이 명시되어야 한다고 말합니다.

 Capabilities being developed
 Risks being mitigated during this iteration
 Defects being fixed during this iteration

첫째로, ‘Capabilities being developed’란 해당 iteration에서 무엇을 발전시켜 나갈 것인가를 정의하는 것입니다. 프로젝트의 초기에는 프로젝트 전체를 통해 만들어낼 것-이를 Capabilities라고 이해할 수 있습니다.-을 명확히 정의해야 합니다. 이를 프로젝트 영역(Project Scope)을 확립한다고 하죠. 이러한 영역을 각각의 iteration에 적절히 할당해야 합니다.

두 번째인 ‘Risks being mitigated during this iteration’는 iteration에서 제거할 위험 요소를 말합니다. 프로젝트 계획 시에는 프로젝트를 실패로 빠뜨릴 주요 위험 요소를 찾아내야 합니다. 프로젝트의 주적을 찾아내는 것이죠. 주적을 찾아내어 각각의 iteration에서 하나씩 제거해 나가면 승리를 하게 되는 것이죠.

마지막으로 ‘defects being fixed during this iteration’는 진화(evolution)하는 측면을 잘 보여줍니다. 지난 iteration에서의 문제점을 파악하고 이번 iteration에서 그러한 문제점을 해결하는 것이죠.

그림 20-1은 iteration 계획 프로세스를 나타낸 것입니다. 초기에 설정한 프로젝트 영역과 위험 요소(initial risks, initial project scope)를 기초로 프로젝트를 계획합니다. 가장 위험한 요소부터 제거하는 방향으로 iteration을 설정한(Define iteration to address the highest risks) 뒤에 iteration을 계획하고 진행하면서 발전시켜 나갑니다(Plan and develop the iteration). 해당 iteration이 종료되면 되짚어 보아야 합니다.(Assess the iteration)

##########1*
그림 20-1. Iteration 계획 프로세스

제거된 위험 요소(Risks eliminated)를 확인한 뒤에 위험 요소를 관리하는 목록을 수정해야 하겠죠(Revise project plan). 그리고 나서 최종적으로 프로젝트 계획서를 수정합니다(Revise project plan). 이렇게 하나의 Iteration이 종료가 되고, 수정된 위험 요소 목록과 프로젝트 계획서는 다음 Iteration을 계획하는 자료가 되는 것이죠.

보통 Iteration을 나눌 때에는 유스케이스에 근거해서 나누게 됩니다. 이들 유스케이스들을 위험 정도, 고객에 있어서의 중요성과 선행 작업 필요성 여부 등을 고려해서 우선순위를 설정합니다. 그런 후에 우선순위가 높은 것부터 초기의 Iteration에서 다루게 되는 것이죠.


UI 설계

요구사항 수집과 업무를 분석하는 과정에서 사용자 인터페이스에 대한 요구가 구체화되어져 가기 마련입니다. 초기에 사용자 마음에 쏙 들고, 사용자의 업무 수행에 딱 들어맞는 인터페이스를 만들 수는 없을 것입니다.

따라서, 프로토타이핑(prototyping) 기법과 같은 것들이 쓰이게 되는 것이죠. 프로토타이핑이란 개발과정에서 최종적인 시스템의 모습의 일부를 보여주는 샘플-프로토타입(prototype)이라고 하죠-을 만드는 것입니다.

주요 UI를 찾아내고 사용자가 UI를 이용해 업무를 수행하는 이동경로의 파악, UI를 통해 시스템과 주고 받는 데이터를 파악하는데 많은 노력이 기울여집니다. 분석 단계에서 논리적인 UI 객체들을 뽑아내는데 설계단계가 되어 구체적인 사용기술이 결정되면 그림 20-2와 같은 모델과 관계가 드러나게 됩니다.

##########2*
그림 20-2. JSP를 사용한 UI 관련 객체 모델링

그림 20-2를 보면 우선 장바구니 화면에서 ‘결제하기’와 같은 메뉴를 선택하면 Checkout이라는 JSP 객체로 링크가 됩니다. Checkout JSP 객체는 ShopingCartBean을 이용해서 장바구니에 담긴 정보를 확인하고, 결제 확인을 위한 클라이언트 페이지를 만들어내게 됩니다. 해당 화면 내에는 결제 정보를 입력할 수 있는 양식(Form)이 포함되어 있겠죠.


클래스 디자인

초기에는 클래스 자체만을 추출하는 개념적인 수준으로 수행하게 됩니다. 이러한 클래스를 Conceptual Class라고 하죠. 일반적으로 사용자와의 상호작용이 많은 시스템의 경우는 MVC 모델을 이용하여 클래스를 추출하는 것이 보편적입니다.

분석 단계에서 해당 업무 영역(Domain)에 적합한 클래스를 뽑아냅니다. 아직까지는 특정 기술에 국한된 것은 아니죠. 이렇게 분석 모델을 도출한 이후에 어떠한 기술을 사용하는 것이 적절한가를 결정한 이후에 이를 적용한 설계 모델을 만들어냅니다.

설계 단계에서의 클래스는 특정한 기술에 한정된 것입니다. 그림 20-2의 경우도 자바기술에 한정된 설계단계의 다이어그램이죠. 개념적인 클래스가 적절히 도출되면 이들 사이의 관계를 묘사합니다. 관계는 집합(Aggregation), 상속(Inheritance)과 의존(Dependency)과 같은 정적인 관계와 메시지를 통한 동적인 관계인 연관(Association)으로 크게 나눌 수 있습니다.

##########3*
그림 20-3. 속성과 오퍼레이션이 추가된 설계 단계의 클래스 다이어그램

클래스가 도출되고 관계가 묘사된 이후에는 속성과 오퍼레이션이 추가되는 순서로 자세한 설계가 진행됩니다. 그림 20-3은 속성과 오퍼레이션이 추가된 이후의 설계 모델의 모습이죠. Rose의 경우에는 위와 같이 기본적인 EJB 오퍼레이션은 자동으로 생성해 줍니다.

[Tools]-[Java/J2EE]-[New EJB] 메뉴를 선택하면 그림 20-4와 같이 EJB Specification 창이 나타납니다. 여기에서 적절히 옵션을 선택하고, BeanName이름을 작성하면 이에 맞춰서 EJB 클래스들이 생성됩니다.

##########4*
그림 20-4. EJB Specification 창