UML에서 2.4 문서는 다음과 같이 액터를 정의UML 유스 케이스 - 액터는 누구입니까?
배우 사용자 또는 대상과 상호 작용하는 임의의 다른 시스템에 의해 재생하는 역할을 지정.
필자의 경우이 주제는 축구 협회가 제공하는 웹 서비스입니다. 서비스 운영은 중간에 4 개가 있습니다. 이제 웹 사이트 (또는 웹 응용 프로그램)는 시스템 (웹 서비스)과 실제로 상호 작용하지만 실제로는 자체적으로 수행하지 않습니다. 사용자가 필요합니다.
그럼 누가 배우입니까?
아래 다이어그램이 어떻게 생겼는지 예를 들어 보았지만 그 정확성에 대해서는 의문의 여지가 있습니다.
내가 한 말을 가지고, 그것은 '정보의 사용 사례를 요구'제목에 관하여이다. 바깥 쪽 사각형은 시스템 경계이므로 '정보 시스템 요구하기'가 더 편리 할 것입니다. 실제로 유스 케이스는 아니며 설명하는 전체 시스템입니다.
편집 : 다이어그램 변경 후 : '방문 웹 페이지'유스 케이스와 다른 사용 사례를 '포함'(방문 웹 페이지 유스 케이스에서 멀리 가리키는 화살표)로 관계를 만들 것입니다. 그럼 나는 그것에 동의하는 경향이 있습니다.
오 그래, 나는 파일을 업로드 한 후에 패키지 이름이 잘못되었다는 것을 알아 냈다. 아마 패키지를 지울 수는 있겠지만 ... 다이어그램이 잘 수행되었다는 단 한 번의 발언 만있다는 사실은 사실인가? 팬이 주연이며 웹 페이지를 방문하는 것은 유스 케이스입니까? –
기상청이 일기 예보를 시스템에서 꺼낼 예정입니까? :) –
날씨 웹 서비스를 제공하는 배우이기 때문에 기상청이 있습니다. 적어도 그것이 내가 생각하는 것입니다. –
필자는 유스 케이스 다이어그램을 두 개의 다이어그램으로 분리했습니다. 하나는 웹 응용 프로그램 용이고 다른 하나는 웹 서비스 용입니다.
첫 번째 다이어그램에는 팬과 웹 서비스의 두 가지 액터가 있습니다.
두 번째 다이어그램에는 웹 응용 프로그램, 축구 협회 및 기상청의 세 가지 시스템 액터가 있습니다.
이 분할은 웹 서비스의 세부 사항을 파악하지 않고도 웹 응용 프로그램의 사용 사례를 더 많이 생각할 수 있다는 장점이 있습니다.이 두 가지는 독립적 인 시스템이어야합니다.
"축구 클럽 웹 페이지 방문"은 유스 케이스가 아닙니다. 팬이 웹 페이지를 방문 할 때의 목표는 무엇입니까? 조명기리스트 나 결과 또는 라이브 스코어 또는 사다리 위치를 얻는 것입니다. 웹 사이트를 방문하는 것만으로도 목표를 달성하지 못하면 시간 낭비 일뿐입니다. 따라서 "축구 클럽의 웹 페이지 방문"을 제거하고 팬 배우와 4 개의 주요 목표 지향 유스 케이스에 대한 직접적인 연관을 갖습니다. – chimp
3 명이 모두 액터입니다. –
그리고 이것을 어떻게 표현해야합니까? –