활동:
|
목적
|
역할: 시스템 분석가 |
빈도: 필요에 따라, 일반적으로 개념화, 구현화 및 구축 단계에서 각 반복당 최소 한 번. |
단계 |
입력물: | 결과물: |
툴 멘토르: |
워크플로우 세부사항: |
유스 케이스 모델 구축의 첫 번째 단계는 둘 이상의 유스 케이스에 공통되는 요구사항을 이해하는 것입니다. 공통점을 기록하면서 각 유스 케이스를 검토하십시오.
중복을 최소화하기 위해 마지막 단계(포함, 확장 및 일반화된 유스 케이스 작성)에 이 기록을 사용하십시오. 목표는 설계로 넘겨지는 기능적 분해물(decomposition)을 정의하는 것이 아니라 요구사항을 좀더 이해하기 쉽고 유지보수하기 쉽게 만드는 것입니다.
새 유스 케이스를 작성한다고 해서 공통 요구사항이 항상 잘 처리되는 것은 아닙니다. 공통 내용을 다른 결과물(예: 유스 케이스에서 필요로 했던 용어집, 추가 스펙)로 이동하는 것을 고려하십시오.
내용이 특정 유스 케이스에 관련되어 있는 경우, 추가 스펙에서 유스 케이스로 이동하는 것도 고려하십시오.
유스 케이스에 결과(결과에 도달하기 위한 메소드가 아님)만이 나머지 유스 케이스에 중요한 작동 세그먼트가 포함되어 있는 경우, 이 작동을 새 포함 유스 케이스로 분리할 수 있습니다. 그러면 원래 유스 케이스는 포함 유스 케이스가 있는 포함-관계에서 기본 유스 케이스가 됩니다. 가이드라인: 유스 케이스 모델 및 가이드라인: 포함-관계도 참조하십시오.
두 유스 케이스 간의 포함-관계는 기본 유스 케이스 설명 다음에 오는 유스 케이스 인스턴스가 포함 유스 케이스 설명 다음에도 와야 관계가 완성됨을 의미합니다.
포함-관계는 다음을 수행하여 유스 케이스를 명확히 하는 데 도움이 될 수 있습니다.
일반적으로, 여분의 유스 케이스 및 포함-관계를 유지보수하기 위해서는 둘 이상의 유스 케이스에 포함 유스 케이스가 포함되어 있어야 합니다.
기본 유스 케이스만이 두 유스 케이스 간의 관계를 인식합니다. 포함 유스 케이스는 다른 유스 케이스가 무엇을 포함하고 있는지 모릅니다.
포함이 삽입될 기본 유스 케이스의 위치뿐 아니라 포함의 목적을 간략히 기술하는 포함-관계를 기술하십시오.
기본 유스 케이스의 이벤트 플로우를 기술할 때 포함이 삽입된 위치에 있는 포함을 참조하십시오.
유스 케이스에 선택적이거나 예외적이고 유스 케이스의 기본 목적을 이해하는 데 도움이 되지 않는 작동 세그먼트가 있으면, 이를 새 확장 유스 케이스로 분리하십시오. 그러면 원래 유스 케이스는 확장 유스 케이스가 확장-관계를 갖는 기본 유스 케이스가 됩니다. 가이드라인: 유스 케이스 모델 및 가이드라인: 확장 관계도 참조하십시오.
기본 유스 케이스 내에 기본 유스 케이스 확장이 이루어질 수 있는 위치를 정의하는 확장 지점을 선언합니다. 가이드라인: 유스 케이스도 참조하십시오.
복잡한 서브플로우 및 선택적 작동이 확장 유스 케이스로 나눌 첫 번째 후보가 됩니다. 종종 이 작동은 설명하기가 너무 복잡하고 어려울 수 있습니다. 유스 케이스 이벤트 플로우에 이를 포함시키면 "정상" 작동이 더 이해하기 어려워질 수 있습니다. 이를 추출하면 유스 케이스의 이해도가 향상됩니다.
기본 유스 케이스의 이벤트 플로우가 확장 유스 케이스를 참조하지 않고 자체만으로도 완벽하고 이해가 가능한지 확인하십시오.
확장 유스 케이스만이 두 유스 케이스 간의 관계를 인식합니다. 기본 유스 케이스는 자신이 갖고 있는 확장 지점만을 인식합니다. 기본 유스 케이스는 어떤 확장 유스 케이스가 확장 지점을 사용하는지 모습니다.
정의한 모든 확장-관계를 간략히 기술하십시오. 확장이 발생하기 위해 충족해야 하는 조건을 정의하십시오. 확장을 삽입할 기본 유스 케이스에 확장 지점을 정의하십시오.
둘 이상의 유스 케이스에 구조 및 작동이 유사한 점이 있으면, 공통 작동을 분리하여 새 상위 유스 케이스를 작성할 수있습니다. 원래 사용 케이스는 일반화-관계에서 상위가 있는 하위 유스 케이스가 됩니다. 하위 유스 케이스는 상위 유스 케이스에 기술된 모든 작동을 상속합니다. 가이드라인: 유스 케이스 모델 및 가이드라인: 유스 케이스 일반화도 참조하십시오.
두 유스 케이스 간의 일반화-관계는 하위 유스 케이스 설명 다음에 유스 케이스 인스턴스가 올 경우 상위 유스 케이스 설명 다음에도 유스 케이스 인스턴스가 와야 관계가 완성될 수 있음을 의미합니다.
일반적으로, 하위와 함께 상위 유스 케이스 및 일반-관계를 유지보수하려면 동일한 상위를 상속하는 하위 유스 케이스가 최소 두 개는 있어야 합니다. 두 개의 유스 케이스 중에서 하나가 다른 하나에서 분화된 것이지만 둘 다 독립적으로 인스턴스화되어야 할 경우에는 예외가 발생합니다.
하위 유스 케이스만이 두 유스 케이스 간의 관계를 알고 있습니다. 상위 유스 케이스는 어떤 하위 유스 케이스가 분화된 것인지 모릅니다.
다른 사람이 모델을 이해할 수 있게 하려면 일반화-관계를 간략하게 기술해야 합니다. 일반화-관계를 작성한 이유를 설명하십시오.
하위 유스 케이스의 이벤트 플로우에서 하위가 새 작동 세그먼트를 삽입하여 상속된 작동 순서를 수정하는 방법을 설명해야 합니다.
액터는 액터-일반화를 사용하여 모델화해야 하는 공통 특성을 갖고 있습니다. 이 작업 파트는 유스 케이스 모델에서 첫 번째 시도를 한 이후에 가장 잘 수행됩니다.
간략한 액터-일반화 설명을 작성한 다음 이를 유스 케이스 다이어그램에 포함시켜 더 명확히 하십시오.
가이드라인: 액터-일반화도 참조하십시오.
계속해서 고객 및 사용자와 함께 포함-, 확장- 및 일반화-관계의 통합에 대해 논의하여 이들이 결과 유스 케이스 및 액터에 대해 명확히 이해하고 있는지와 설명에 동의하는지를 알아야 합니다.
이 단계에서 유스 케이스 모델을 확인하여 작업이 올바른 방향으로 진행되고 있는지를 확인하십시오. 그러나 너무 자세히 검토하지는 마십시오. 고객 및 사용자와 새로 통합된 유스 케이스 및 관계를 검토 및 논의하여 이들이 유스 케이스를 명확히 이해하고 설명에 동의하게 하십시오.
필요한 경우, 유스 케이스를 유스 케이스 패키지로 구성해야 합니다. 이 옵션을 고려해야 할 시기에 대한 자세한 정보는 가이드라인: 유스 케이스 패키지를 참조하십시오.
유스 케이스 모델에 대해 작업하는 동안 유스 케이스에 대한 체크포인트도 고려해야 합니다. 활동: 요구사항 검토에서 특히 액터, 유스 케이스 및 유스 케이스 모델에 대한 체크포인트를 참조하십시오.
Rational Unified Process
|