ICONIX Process

ICONIX Process

 

ICONIX 프로세스는 사용하기 쉬운 개방형 개체 모델링 프로세스입니다. 최소한의 사용 사례 중심이며 민첩합니다. 이 프로세스는 사용 사례와 코드 사이의 영역에 중점을 둡니다. 시작하는 라이프 사이클의 시점에서 어떤 일이 발생해야하는지에 중점을두고 있습니다. 일부 사용 사례가 시작되었으므로 이제는 우수한 분석 및 설계가 필요합니다.

 

GUI 스토리보드가 먼저 시작되는 것을 볼 수 있다.

 

 

 

간단히 말해서 ICONIX 프로세스 이 섹션에서는 프로세스 자체에 대해 설명합니다. 간단히 말해서, ICONIX 프로세스는 가능한 적은 단계로 유스 케이스에서 코드로 안정적으로 전환하는 방법을 설명합니다. 그림 3-3 은 ICONIX 프로세스의 여러 활동이 어떻게 결합되는지 보여줍니다. 그림 3-3 : ICONIX 프로세스 ICONIX 프로세스는 다음 단계로 나눌 수 있습니다 ( 굵게 표시된 항목 은 각 단계에서 수행하는 구체적 모델링 활동입니다). 1 단계 : 실제 도메인 개체 식별 ( 도메인 모델링 ) 2 단계 : 행동 요구 사항 정의 ( 사용 사례 ) 3 단계 : 견고성 분석 을 수행 하여 사용 사례를 명확하게하고 도메인 모델의 차이를 식별합니다. 4 단계 : 객체에 동작을 할당합니다 ( 시퀀스 다이어그램 ). 5 단계 : 정적 모델을 완료하십시오 ( 클래스 다이어그램 ). 6 단계 : 코드 작성 / 생성 ( 소스 코드 ) 7 단계 : 시스템 및 사용자 수락 테스트를 수행합니다. 이 프로세스를 분석 및 설계 모델링 활동에 대한 서신으로 보내면 프로젝트가 고객의 요구 사항을 충족하고 합리적인 시간 내에이를 수행 할 수있는 좋은 기회가됩니다. 다음 섹션에서 이러한 각 단계를 자세히 살펴보면 프로젝트 계획에서보기 좋게 나타나는 4 가지 주요 이정표에 주목할 것입니다.이 계획은 유용한 계획 체크 포인트이기도합니다. "이 XYZ 작업이 완료되었으므로 이제 다음 단계로 넘어갑니다"라고 말하고 설명하십시오. 이정표 1 : 요구 사항 검토 이정표 2 : 예비 설계 검토 이정표 3 : 상세 / 중요한 설계 검토 이정표 4 : 배달 1 단계 : 실제 도메인 객체 식별 이 단계를 올바르게 수행하는 것은 전체 프로젝트에서 가장 중요한 부분 일 것입니다. 프로젝트의 다른 모든 것 (요구 사항, 디자인, 코드 등)이 절대적으로 구축되는 견고한 기반을 구축하기 때문입니다. 이 단계는 다음 단계로 세분 될 수 있습니다. 실제 도메인 개체와 이러한 개체 간의 일반화 및 집계 관계를 식별하십시오. 높은 수준의 클래스 다이어그램을 그리기 시작하십시오. 가능하다면 제안 된 시스템을 신속하게 프로토 타이핑하거나 리엔지니어링 할 레거시 시스템에 대한 실질적인 정보를 수집하십시오. 이 단계를 마치면 프로젝트의 모든 사용자 (고객, 프로그래머, 분석가, 테스터 및 최종 사용자)가 공통 어휘로 공유하고 사용할 수있는 합리적으로 올바른 도메인 모델이 있어야합니다. 도메인 모델은 프로젝트가 진행됨에 따라 계속 발전하고 성장할 것입니다 (그리고 비즈니스 영역을 캡처하는 더 간단한 것으로 변경 될 수 있기를 바랍니다). 도메인 모델은 문제 영역 엔터티 클래스를 기반으로하는 정적 모델 (클래스 다이어그램)을 솔루션 공간이 아닌 예비 추측입니다. 클래스에는 속성이나 작업이 표시되지 않습니다. 도메인 모델에는 시스템이 해결하도록 설계된 문제와 관련된 실제 사물과 개념이 포함되어 있습니다. 우리는 도메인 모델을 만들 때 비즈니스를 형성하는 개체와 행동의 표현을 만들고 프로젝트가 해결하려는 문제에 중점을 둡니다. 프로젝트에 대해 생성 한 초기 도메인 모델은 완벽하지 않습니다. 문제 영역에 대한 이해가 발전함에 따라 프로젝트 전체에서 발전 할 것입니다. 실제로 도메인 모델로 갈 개체를 어떻게 식별합니까? 여러 가지 기술이 있으며 그중 가장 중요한 것은 단순히 자신의 경험과 판단을 사용하는 것입니다. 그러나 실제로 고착 된 경우 문법 검사 기술 을 사용하는 것이 좋습니다 . [ 6. ] 사용 가능한 관련 자료 (요구 사항, 비즈니스 용어집 등)를 빠르게 통과하면서 명사와 동사를 강조 표시합니다. . 관련 자료에는 고객 및 시스템의 최종 사용자와의 자체 인터뷰도 포함되어야합니다. 이러한 토론은 종종 모호성을 해결하고 추가 도메인 객체를 식별하는 데 도움이됩니다. 작업이 진행됨에 따라 목록을 수정 한 후 명사와 명사구는 클래스와 속성이됩니다. 동사와 동사구는 연산과 연관이됩니다. 소유 어구는 명사가 클래스가 아닌 속성이어야 함을 나타냅니다. 물론 이러한 항목은 일반적인 규칙 만 나타냅니다 (단, 유용한 규칙이지만). 예를 들어, 일부 동사는 결국 조작이 아닌 객체가됩니다 (특히 비즈니스 프로세스를 모델링하거나 관리자 또는 컨트롤러, 클래스를 식별 한 경우). 도메인 모델을 계속 반복하고 세분화해야하지만 이것이 명사와 동사를 무기한으로 계속 연마해야한다는 의미는 아닙니다. 목표는 사용 사례 텍스트 내에서 적절하게 명사 역할을 할 오브젝트 이름 용어집을 작성하는 것 입니다. 초기 도메인 모델을 구축하기위한 시간 예산을 설정하는 것이 좋습니다 (예를 들어, 아침이나 몇 시간까지 걸리는 공동 작업장으로 제한). 도메인 모델은 중요하지만 프로젝트의 나머지 부분이 시작되는 것을 방지하기를 원하지 않습니다! 일반적으로 몇 시간 내에 도메인 클래스의 가장 중요한 80 %를 찾을 수 있습니다. 사용 사례를 진행하면서 나머지 클래스를 발견하므로 완벽하게 얻을 필요는 없습니다. 2 단계 : 행동 요구 사항 정의 지금까지 수집 한 것처럼 ICONIX 프로젝트의 동작 요구 사항은 사용 사례에 의해 정의됩니다. 사용 사례는 높은 수준의 요구 사항 (이전 단계에서 논의 됨)을 확장하고 사용자 상호 작용 측면에서 시스템의 동작 방식을 정의합니다. 이 책의 뒷부분에서 설명 하겠지만,이 단계는 세부적인 상호 작용 디자인 (특히 페르소나 분석, 12 장 참조)으로 보강되는 것이 좋습니다. 이 단계는 다음 단계로 세분 될 수 있습니다. 사용 사례 다이어그램을 사용하여 사용 사례를 식별하십시오. 사용 사례를 그룹으로 구성하십시오. 이 조직을 패키지 다이어그램으로 캡처하십시오. 기능 요구 사항을 사용 사례 및 도메인 오브젝트에 할당하십시오. (이 단계는 프로젝트의 형식에 따라 선택 사항입니다.) 사용 사례에 대한 설명을 작성하십시오 (즉, 이동 빈도가 적은 경로 및 오류 조건에 대한 주류 및 대체 과정을 나타내는 기본 행동 과정). 유스 케이스 모델링을 완료 한 시점을 어떻게 알 수 있습니까? 다음을 달성하면 개발 프로세스의 다음 단계로 넘어갈 준비가되었습니다. 시스템의 원하는 기능 을 모두 설명하는 사용 사례를 구축했습니다 . 각 사용 사례에 대해 적절한 대체 조치 과정과 함께 기본 조치 과정에 대한 명확하고 간결한 설명을 작성했습니다. 앞선을 사용하고 구문 (또는 일반적으로 선호하는 구문)을 사용하여 둘 이상의 사용 사례에 공통적 인 시나리오를 제외했습니다. 이정표 1 : 요구 사항 검토 3 단계 : 도메인 모델에서 사용 사례를 명확하게하고 간격을 식별하기 위해 견고성 분석 수행 이것이 프로젝트의 최종 분석 단계입니다. 이 장의 뒷부분에서 볼 수 있듯이 견고성 분석은 ICONIX 프로세스에서 중요한 역할을합니다. 핵심은 견고성 다이어그램입니다 ( 그림 3-4 참조 ). 그림 3-4 : 견고성 다이어그램 예 견고성 분석에는 유스 케이스의 텍스트를 통해 작업하며, 지금까지 발견 한 오브젝트를 사용하여 특정 유스 케이스를 구현하기 위해 일부 소프트웨어를 설계하는 방법을 미리 살펴 봅니다. 이 액티비티의 주요 목적 중 하나는 필요한 객체가 모두없는 경우를 찾아 클래스 다이어그램에 추가하는 것입니다. 견고성 분석 단계는 다음 단계로 세분됩니다. 견고성 다이어그램을 그립니다. 각 사용 사례 명시된 시나리오를 수행하는 첫 번째 컷 개체를 식별하십시오. UML Objectory 스테레오 타입을 사용하십시오 ( 그림 3-5 참조 ). 그림 3-5 : 견고성 분석 고정 관념 발견 할 때 새 오브젝트 및 속성으로 도메인 모델 클래스 다이어그램을 업데이트하십시오. 견고성 다이어그램과 일치하도록 유스 케이스 텍스트를 업데이트하십시오. 프로젝트의 분석 단계 완료를 반영하도록 클래스 다이어그램 업데이트를 완료하십시오. 이정표 2 : 예비 설계 검토 Ivar Jacobson 은 1991 년 OO의 세계 에 견고성 분석 개념을 도입 했습니다. 견고성 분석에는 각 사용 사례의 설명 텍스트를 분석하고 사용 사례에 참여할 첫 번째 추측 개체 집합을 식별 한 다음이를 분류합니다. 다음 세 가지 객체 유형으로 경계 객체- 액터가 시스템과 통신하는 데 사용합니다. 엔티티 객체 (이라고도 실체 보통), 도메인 모델 객체. 경계 객체와 엔티티 객체 사이의 "접착제"역할을하는 제어 객체 ( 컨트롤러 라고도 함 ). 때때로 이들은 실제 Control 객체이지만 대부분은 단순히 함수에 대한 동사 자리 표시자를 나타냅니다. 이 간단하지만 매우 유용한 기술은 (분석 사이의 중요한 링크 역할을 무엇 )과 디자인합니다 ( 방법 ). 이 책의 뒷부분에서 견고성 분석의 몇 가지 예를 살펴 보겠습니다. 이 세 가지 객체 유형은 MVC (Model-View-Controller) 디자인 패턴으로 잘 변환되며 [ 7. ] 클라이언트-서버 및 GUI 개발에 많이 사용됩니다. 엔터티 개체는 Model에 의해 전달되고 경계 개체는 View 에서 구성되며 Control 개체는 Controller에서 구성 됩니다. 예를 들어, 3 계층 웹 응용 프로그램에서 경계 (또는보기) 개체는 JSP 페이지 일 수 있습니다 (때로는 프레젠테이션 계층 이라고도 함 ). 엔티티 (즉, 데이터)는 데이터베이스, 일반적으로 비즈니스 오브젝트 계층을 통해 제공됩니다. 전체 엔칠 라다를 하나로 묶는 Control 객체는 애플리케이션 서버에 내장 된 비즈니스 로직 계층에 의해 제공됩니다. 리치 클라이언트 GUI 애플리케이션에서 경계 (또는보기) 오브젝트는 테이블 또는 콤보 상자 컴포넌트 (예 : Java Swing, JTable 또는 JComboBox) 일 수 있으며 Model 오브젝트는 다음과 같은 데이터 모델 (예 : DefaultTableModel)입니다. 구성 요소가 표시 할 엔티티를 제공하고 제어 코드는 UI 이벤트 (예 : 테이블을 위아래로 스크롤)를 처리하여 모델에서보기를 표시해야하는 데이터를 판별합니다. 프로젝트의 기능이 향상됨에 따라 (또는 배포 된 시스템에 동시에 액세스하는 사용자 수와 같은 다른 방식으로) 과제를 충족하도록 아키텍처를 확장해야합니다. 이는 종종 기능을 별도의 계층으로 분할 한보다 복잡한 아키텍처로 이어집니다 (예 : 애플리케이션 로직의 다른 영역이 다른 계층으로 분리 될 수 있음). 이것은 BCE (Boundary-Control-Entity) 아키텍처 (또는 MVC 아키텍처)의 확장으로 볼 수 있으므로 ICONIX 프로세스는 여전히보다 복잡한 아키텍처에 쉽게 적용 할 수 있습니다 (즉, 프로세스는 프로젝트). 4 단계 : 객체에 동작 할당 이 단계는 프로젝트의 디자인 단계가 시작되는 곳입니다. 이 단계에서 선택한 주요 다이어그램은 시퀀스 다이어그램 ( 그림 3-6 참조 )이지만 추가 다이어그램 및 활동 (예 : 상태 다이어그램, 활동 다이어그램 또는 엄격한 테스트 중심 방법론에 따른 단위 테스트)을 사용할 수도 있습니다. 제 12 장) 그림 3-6 : 예제 시퀀스 다이어그램 이 단계는 각 사용 사례에 대해 다음 단계로 세분화됩니다. 호출 할 오브젝트와 연관된 메소드간에 전달해야하는 메시지를 식별하십시오. 사용 사례 텍스트가 왼쪽으로 내려 가고 시퀀스 정보가 오른쪽에있는 시퀀스 다이어그램을 그립니다. 클래스 다이어그램을 찾은대로 속성 및 조작으로 계속 업데이트하십시오. 시퀀스 다이어그램에서 클래스에 작업을 할당하지 않으면 인생의 주요 임무는 무시하는 것입니다. 각 사용 사례마다 하나의 시퀀스 다이어그램을 만듭니다. 기억해야 할 중요한 점은 단일 유스 케이스에서 상호 작용을 맵핑하기 위해 많은 다이어그램으로 혼란에 빠지는 것을 원하지 않기 때문입니다. 그렇게하면 분석 마비가 심해지므로 사용 사례에 대해 여러 가지 대안 시나리오가 있더라도 모든 것을 하나의 시퀀스 다이어그램에 배치하십시오. 이것이 유스 케이스 텍스트에 대한 두 단락 규칙의 이유입니다. 모든 것을 하나의 시퀀스 다이어그램에 맞출 수 있습니다. 이 접근법의 결과는 다이어그램이 너무 조각화되는 것을 방지한다는 것입니다. 즉, 단일 다이어그램을 읽으면 전체 사용 사례를 해결했는지 확인할 수 있습니다. 조각이 너무 많으면 모든 사용 사례를 확보하기가 어렵습니다. 5 단계 : 정적 모델 완료 이 단계의 제목에서 알 수 있듯이 여기서 핵심 설계 아티팩트는 하나 이상의 클래스 다이어그램으로 구성된 정적 모델입니다 ( 그림 3-7 참조 ). 그림 3-7 : Part 2에 제시된 맵렛 프로젝트에 대한 예제 클래스 다이어그램 이 단계는 다음 단계로 세분됩니다. 자세한 설계 정보 (예 : 가시성 값 및 패턴)를 추가하십시오. 디자인이 식별 한 모든 요구 사항을 충족하는지 팀과 확인하십시오. 이정표 3 : 상세 / 중요한 설계 검토 정적 모델은 도메인 모델의 더 거칠고 상세한 버전이며 더 자세한 구현 정보가 포함되어 있습니다. 정적 모델에는 매우 상세한 추상화 수준에 있고 시퀀스 다이어그램과 일치하는 자세한 클래스 다이어그램 (아마도 소스 코드에서 리버스 엔지니어링 될 수도 있지만 반드시 필요한 것은 아님)이 있습니다. 모델링 질문 : 정식 모델을 가질 때까지 메인 모델 다이어그램을 재사용하고 간단하게 추가해야합니까? 프로젝트가 하나의 릴리스 (또는 최대 두 개의 릴리스) 만 거치는 것을 알고 있다면이 접근법이 잘 작동합니다. 그러나 짧은 릴리스가 많고 각 릴리스가 시작될 때 도메인 모델링 활동이있는 민첩한 프로젝트에서는 도메인 모델과 클래스 다이어그램에 대해 별도의 다이어그램을 유지해야합니다. 클래스 다이어그램은 여전히 ​​원래 도메인 모델에서 성장하고 발전하지만 (이 접근 방식은 ICONIX 프로세스의 기본), 다이어그램은 별도로 유지됩니다. 도메인 모델은 비즈니스 도메인에 대한 현재의 이해 (예 : 분석 수준 아티팩트)를 반영하는 반면, fleshed out 클래스 다이어그램 (여러 개가있을 수 있음)은 집합 적으로 세부적인 디자인 아티팩트입니다. 비즈니스 도메인에 대한 이해가 발전함에 따라 이전 단계의 설계 세부 사항 (적어도 아직은 아님)을 고려하여 속도 저하없이 도메인 모델을 신속하게 업데이트하고 리팩토링 할 수 있어야합니다. 디자인 단계). 물론 이것은 업데이트 할 추가 다이어그램이 있다는 것을 의미하지만, 절충안입니다. 이점은 도메인 모델을 최신 상태로 유지하는 것이 훨씬 쉽고 읽기가 더 쉽다는 것입니다 (디자인 세부 사항 및 디자인 결정 기록에 의해 혼란 스럽기 때문). 도메인 모델과 클래스 다이어그램이 동일한 다이어그램 인 경우 새로운 비즈니스 이해에 비추어 도메인 모델을 업데이트하기가 더 어렵습니다. 모든 중간 단계를 거치지 않고 세부 설계를 효과적으로 수정하기 때문입니다 ( 견고성 분석, 시퀀스 다이어그램 등). 6 단계 : 코드 작성 / 생성 물론이 단계는 프로그래머가 디자인을 취하고 코드를 작성하기 시작하는 단계입니다. 프로그래머는 모든 설계 단계 (이상적으로는 디자이너도 프로그래머이기도 함)에 참여해야 디자인이 시스템이 구현 될 기술의 현실에 어느 정도 근거가 있어야합니다. 이 단계는 다음 단계로 세분됩니다. 코드를 작성 / 생성하십시오. 단위 및 통합 테스트를 수행하십시오. ICONIX 프로세스를 테스트 중심 접근 방식 (12 장 참조)과 결합하면 단위 테스트가 코드 전에 작성됩니다. 여기서 중요한 점은 프로그래머가 통합 테스트를 포함하여 자체 테스트를 수행하고 있다는 것입니다. 7 단계 : 시스템 및 사용자 수락 테스트 수행 이 단계에서는 프로그래밍 팀과 다른 그룹 (이상적으로는 QA 팀)이 유스 케이스를 후자의 블랙 박스 테스트 케이스로 사용하여 시스템 및 사용자 승인 테스트를 수행합니다. 이정표 4 : 배달 [ 6. ] Kurt Derr, OMT 적용 : 객체 모델링 기법 사용에 대한 실용적인 단계별 가이드 (New York : Cambridge University Press, 1995). [ 7. ] http://java.sun.com/blueprints/patterns/MVC.html을 참조하십시오 .

출처: http://users.nagafix.co.uk/~mark/025.html

ICONIX Process in a Nutshell In this section, we describe the process itself. In a nutshell, ICONIX Process describes how to get from use cases to code reliably, in as few steps as possible. Figure 3-3 shows how the different activities in ICONIX Process fit together. Figure 3-3: ICONIX Process ICONIX Process can be broken down into the following steps (the items in bold are the concrete modeling activities that you perform at each step): Step 1: Identify your real-world domain objects (domain modeling). Step 2: Define the behavioral requirements (use cases). Step 3: Perform robustness analysis to disambiguate the use cases and identify gaps in the domain model. Step 4: Allocate behavior to your objects (sequence diagrams). Step 5: Finish the static model (class diagram). Step 6: Write/generate the code (source code). Step 7: Perform system and user-acceptance testing. If you follow this process to the letter for your analysis and design modeling activities, then your project will stand a good chance of meeting the customer’s requirements—and doing so within a reasonable time frame. As we walk through each of these steps in detail in the sections that follow, we’ll note four key milestones that tend to look good on a project plan (they’re also useful planning checkpoints, as they provide key stages where you can both say and demonstrate that “this XYZ work is done, so now we’re moving on to the next stage”). Milestone 1: Requirements Review Milestone 2: Preliminary Design Review Milestone 3: Detailed/Critical Design Review Milestone 4: Delivery Step 1: Identify Your Real-World Domain Objects Getting this step right is possibly the most important part of the whole project, because it establishes a solid foundation upon which absolutely everything else in the project (requirements, design, code, and so forth) is built. This step can be further subdivided into the following steps: Identify your real-world domain objects and the generalization and aggregation relationships among those objects. Start drawing a high-level class diagram. If it’s feasible, do some rapid prototyping of the proposed system, or gather whatever substantive information you have about the legacy system you’re reengineering. When this step is finished, you should have a reasonably correct domain model, which everyone on the project (the customer, the programmers, the analysts, the testers, and even the end users) can share and use as a common vocabulary. The domain model will continue to evolve and grow (and hopefully be whittled down to something simpler that still captures the business domain) as the project progresses. The domain model is a preliminary guess at the static model (class diagrams) based strictly on problem-domain entity classes—no solution-space stuff. No attributes or operations are shown on the classes. The domain model contains real-world things and concepts related to the problem that the system is being designed to solve. When we create a domain model, we’re creating a representation of the objects and actions that form the business and are focused on the problem that the project is attempting to solve. The initial domain model that you create for any project will never be perfect. It will evolve throughout the project as your understanding of the problem domain evolves. How do you actually identify objects to go in the domain model? There are a number of techniques, the most important of which is simply to use your own experience and judgment. A good starting point if you’re really stuck, however, is to use the grammatical inspection technique:[6.] quickly pass through the available relevant material (requirements, business glossaries, and so forth), highlighting nouns and verbs as you go. Note that the relevant material should also include your own interviews with the customer and end users of the system. Often these discussions help more than anything else to resolve ambiguities and identify further domain objects. After refining the lists as work progresses, you should find that Nouns and noun phrases become classes and attributes. Verbs and verb phrases become operations and associations. Possessive phrases indicate that nouns should be attributes rather than classes. These items represent only a general rule, of course (though a darned useful one). You might well find, for example, that some verbs eventually become objects rather than operations (particularly if you’re modeling a business process, or if you’ve identified a manager, or controller, class). You should continue to iterate and refine the domain model, but this doesn’t mean that you should keep grinding nouns and verbs indefinitely. The goal is to build a glossary of object names that will serve as the nouns, as appropriate, within your use case text. It’s worth establishing a time budget for building your initial domain model (e.g., restrict it to a collaborative workshop taking no more than a morning, or even just a couple of hours). The domain model is important, but you don’t want it to prevent the remainder of the project from ever getting started! You can generally find the most important 80% of your domain classes within a couple of hours—and that’s good enough to get going. You don’t have to get it perfect, because you’ll discover the remaining classes as you work through the use cases. Step 2: Define the Behavioral Requirements As you’ve probably gathered by now, the behavioral requirements in an ICONIX project are defined by use cases. The use cases expand on the high-level requirements (discussed in the previous step) and define how the system will behave in terms of user interactions. As we’ll discuss later in this book, this step benefits from being augmented with detailed interaction design (especially persona analysis; see Chapter 12). This step can be further subdivided into the following steps: Identify your use cases using use case diagrams. Organize the use cases into groups. Capture this organization in a package diagram. Allocate functional requirements to the use cases and domain objects. (This step is optional depending on the formality of the project.) Write descriptions of the use cases (i.e., basic courses of action that represent the mainstream and alternative courses for less frequently traveled paths and error conditions). How do you know when you’ve finished use case modeling? You’re ready to move to the next phases of the development process when you’ve achieved the following: You’ve built use cases that together account for all of the system’s desired functionality. You’ve produced clear and concise written descriptions of the basic course of action, along with appropriate alternative courses of action, for each use case. You’ve factored out scenarios common to more than one use case, using the precedes and invokes constructs (or whichever constructs you generally prefer using). Milestone 1: Requirements Review Step 3: Perform Robustness Analysis to Disambiguate the Use Cases and Identify Gaps in the Domain Model This is the final analysis step in the project. As you’ll see later in this chapter, robustness analysis plays a key role in ICONIX Process. At its core is the robustness diagram (see Figure 3-4). Figure 3-4: Example robustness diagram Robustness analysis involves working through the text of a use case and taking a preliminary peek at how you might design some software to implement a given use case, using the objects you’ve discovered up to this point. One of the main purposes of this activity is to discover when you don’t have all the objects you need, and then add them to your class diagram. The robustness analysis step is further subdivided into the following steps: Draw robustness diagrams. For each use case Identify a first cut of objects that accomplish the stated scenario. Use the UML Objectory stereotypes (see Figure 3-5). Figure 3-5: Robustness analysis stereotypes Update your domain model class diagram with new objects and attributes as you discover them. Update (disambiguate) the use case text so that it matches the robustness diagram. Finish updating the class diagram so that it reflects the completion of the analysis phase of the project. Milestone 2: Preliminary Design Review Ivar Jacobson introduced the concept of robustness analysis to the world of OO in 1991. Robustness analysis involves analyzing the narrative text of each of your use cases and identifying a first-guess set of objects that will participate in the use case, and then classifying these objects into the following three object types: Boundary objects, which actors use in communicating with the system. Entity objects (also referred to as entities), which are usually objects from the domain model. Control objects (also referred to as controllers), which serve as the “glue” between Boundary objects and Entity objects. Sometimes these are real Control objects, but most of the time they simply represent verb placeholders for functions. This simple but highly useful technique serves as a crucial link between analysis (the what) and design (the how). We’ll walk through several examples of robustness analysis later in this book. These three object types translate well into the Model-View-Controller (MVC) design pattern,[7.] which is used heavily in both client-server and GUI development. Entity objects are delivered by the Model, Boundary objects form the View, and Control objects form the Controller. For example, in a three-tier web application, a Boundary (or View) object could be a JSP page (sometimes also referred to as the presentation layer); the entities (i.e., the data) would be served up by a database, usually via a business object layer; and the Control object that binds the whole enchilada together would be provided by a business logic layer housed in an application server. In a rich-client GUI application, a Boundary (or View) object could be a table or combo box component (e.g., in Java Swing, a JTable or JComboBox), the Model object would be the data model (e.g., DefaultTableModel) that serves up the entities to be displayed by the component, and the Control code would handle the UI events (e.g., scrolling up and down through the table) to determine which data from the model the view needs to display. As projects grow in functionality (or in other ways, such as the number of users accessing the deployed system concurrently), the architecture must scale up to meet the challenge. This often leads to a more complex architecture, typically with functionality divided into separate layers (e.g., different areas of application logic might be separated out into different layers). This can be viewed as an extension of the Boundary-Control-Entity (BCE) architecture (or the MVC architecture), so ICONIX Process can still readily be applied to more complex architectures (i.e., the process can scale up to meet the demands of your project). Step 4: Allocate Behavior to Your Objects This step is where the design phase of the project begins. Our main diagram of choice for this step is the sequence diagram (see Figure 3-6), although you might also use additional diagrams and activities (such as state diagrams, activity diagrams, or unit tests following a strict test-driven methodology; see Chapters 12) as you see fit. Figure 3-6: Example sequence diagram This step is further subdivided into the following steps for each use case: Identify the messages that need to be passed between objects and the associated methods to be invoked. Draw a sequence diagram with use case text running down the left side and design information on the right. Continue to update the class diagram(s) with attributes and operations as you find them. If you’re not allocating operations to classes on the sequence diagram, you’re ignoring its primary mission in life. For each use case, you create one sequence diagram. This is an important point to remember, because you don’t want to end up getting bogged down with many diagrams just to map out the interaction in a single use case. Doing so would give you a nasty case of analysis paralysis so, even if you have multiple alternative scenarios on your use cases, put everything on the one sequence diagram. This is the reason for the two-paragraph rule on use case text: you can fit the whole thing on one sequence diagram. The net result of this approach is that it prevents the diagrams from becoming too fragmented. It means you can validate that you’ve addressed the whole use case by reading a single diagram. Too many fragments make it hard to be sure you got all of the use case. Step 5: Finish the Static Model As the title of this step suggests, the key design artifact here is the static model, which is made up of one or more class diagrams (see Figure 3-7). Figure 3-7: Example class diagram for the mapplet project presented in Part 2 This step is further subdivided into the following steps: Add detailed design information (e.g., visibility values and patterns). Verify with your team that your design satisfies all the requirements you’ve identified. Milestone 3: Detailed/Critical Design Review The static model is the grittier, more detailed version of the domain model, and it contains more implementation details. The static model has detailed class diagrams (perhaps even reverse engineered from the source code, but not necessarily) that are at a very detailed abstraction level and match the sequence diagrams. MODELING QUESTION: SHOULD WE REUSE THE DOMAIN MODEL DIAGRAM AND SIMPLY KEEP ADDING TO IT UNTIL WE HAVE OUR STATIC MODEL? If you know that your project is going to go through only one release (or a couple of releases at most), this approach serves nicely. However, in an agile project with lots of short releases and with domain modeling activities at the start of each release, it pays to keep separate diagrams for the domain model and class diagrams. The class diagram still grows and evolves from the original domain model (this approach is fundamental to ICONIX Process), but the diagrams are kept separate. The domain model reflects our current understanding of the business domain (i.e., it’s an analysis-level artifact), whereas the fleshed-out class diagrams (there may be several) are collectively a detailed design artifact. As our understanding of the business domain evolves, we need to be able to quickly update and maybe also refactor the domain model, without getting slowed down by having to consider design details from previous iterations (at least not yet—that comes when we get to the design stage). Of course, this means that you have an extra diagram to update, but it’s a trade-off. The benefit is that it’s much easier to keep the domain model up to date, and it’s easier to read (because it’s uncluttered by design details and records of design decisions). If the domain model and the class diagram are the same diagram, it’s also more difficult to update the domain model in light of new business understanding, because you’re in effect modifying the detailed design without going through all the intermediate steps to get there (robustness analysis, sequence diagrams, and so forth). Step 6: Write/Generate the Code This step is, of course, where the programmers take the design and start to code from it. The programmers should have been involved in all the design steps (ideally the designers are also the programmers), so that the design has some grounding in the reality of the technologies in which the system will be implemented. This step is subdivided into the following steps: Write/generate the code. Perform unit and integration testing. If you are combining ICONIX Process with a test-driven approach (see Chapter 12), then the unit tests will be written before the code. An important point here is that the programmers are doing their own testing, including integration testing. Step 7: Perform System and User-Acceptance Testing For this stage, a different group from the programming team (ideally a separate QA team) performs system and user-acceptance testing, using the use cases as black-box test cases for the latter. Milestone 4: Delivery [6.]Kurt Derr, Applying OMT: A Practical Step-By-Step Guide to Using the Object Modeling Technique, (New York: Cambridge University Press, 1995). [7.]See http://java.sun.com/blueprints/patterns/MVC.html.