시스템에 속한 스케줄러가 주간 전자 메일을 사용자에게 보내는 작업을 담당합니다. "스케줄러"를 액터로 취급해야합니까? 아니면 유스 케이스로 모델링해야합니까?스케쥴러가 유스 케이스 다이어그램의 액터가되어야합니까?
배우를 선택하기위한 지침 : : 실제 사람이 시스템과 상호 작용하는 경우. "예"인 경우 해당 액터 Else : 시스템 내에서 변경할 수있는 것입니까? "아니오"인 경우 해당 액터
스케줄러는 사람이 아닙니다. 그리고 어떻게 작동하는지 변경할 수 있습니다. 그러나 내 직감은 이것이 배우가 될 수 있다고 말한다. 작은 도움이 좋을 것입니다.
더 높은 수준의 지침 : 설계를 이해하는 데 도움이된다면 다이어그램에 포함 시키십시오. 불필요한 소음이 들리는 경우에는 그대로 두십시오.
더욱 높은 수준의 지침 : 상식을 사용하여.
저는 종종 스케줄러와 기타 시간 관련 외부 에이전트를 액터로 모델링합니다. 그것은 이해할 만하 며 UML 또는 OO 모델링의 일반적인 관행과 모순되지 않으며 대부분의 구현 전략에 적합합니다.
@CesarGon 위험 요소는 요구 사항 기술이 아닌 설계 기술로 유스 케이스 (다이어그램)를 사용하는 위험이 있습니다. 요구 사항 기술의 초점은 시스템과 상호 작용하는 시스템 및 사용자에 대한 사용자 목표에 초점을 맞 춥니 다. TIME 배우에게는 시스템에 대한 사용자 목표가 없으므로 시스템에 대한 목표 또는 관심을 가진 배우를 찾으려고합니다. 주간 이메일이 발송되지 않을 때 누가 신경 쓰나요? TIME 배우 2 차 배우로 추가합니다. TIME 배우는 '실제'배우가 사용자 목표에 도달하도록 도와줍니다.
요구 사항 기술보다는 디자인 기법으로 유스 케이스 (다이어그램)를 사용하는 것이 위험 할 수 있습니다. 필자는 요구 사항을 캡처하기 위해 사례를 선호합니다. – onknows