유스케이스 다이어그램의 본질

Question

학교 과제를 위해 유스케이스 다이어그램을 만들어야 합니다.그러나 우리가 가지고 있는 문서는 그다지 확장되지 않았습니다.유스케이스가 어떤 구성 요소로 구성되어 있는지와 한 가지 예만 설명합니다.
우리는 도서관 시스템에 대한 활용 사례를 만들어야 합니다.우리는 11개의 사용 사례를 찾았지만 모든 사례에 대해 설명하지는 않겠습니다.

IIRC, 유스케이스는 시스템의 일반적인 사용법을 설명합니다. 그렇죠?그렇다면 유스케이스 다이어그램에는 어떤 것들이 속하며 어떻게 서로 연결됩니까?

현재 우리에게는 4명의 행위자(회원, 직원, 관리자, 회계사)가 있습니다.우리가 가장 문제가 되는 것은 회원과 직원입니다.
직원은 시스템을 사용하는 사람입니다.회원이 여전히 여기에 배우로 속해 있나요?

우리가 가지고 있는 일부 사용 사례는 다음과 같습니다.

• 회원이 도서관에 가입합니다.
• 회원이 자신의 기록을 변경합니다.
• 회원이 책을 빌립니다.
• 회원이 라이브러리를 분할합니다(구독 취소).
• 회원이 기사를 예약합니다.
• 회원은 책을 반환합니다.
• 회원은 수수료 및 벌금의 (일부)를 지불합니다.

이는 다이어그램의 사용 사례가 됩니다.그러나 직원이 회원 번호를 입력하고 직원이 도서 번호를 입력하는 등의 사용 사례가 더 있어야 합니다(사용?).

누구든지 이것에 대해 밝힐 수 있습니까?

편집하다:일련의 행동은 어떻게 설명됩니까?반복되는 일종의 루틴에 대한 메소드 호출과 같은 사용 연관을 볼 수 있다고 들었습니다.이게 옳은 거니?그리고 확장은 어떻게 사용되나요?

Answer 1

IIRC, Usecase는 시스템의 일반적인 사용법을 설명합니다.그러나 usecase 다이어그램에 어떤 얇은 [g]가 속한 것과 어떻게 연결됩니까?

사용 사례 다이어그램(예, 일반적인 프로젝트에는 둘 이상의 다이어그램이 있습니다)은 아마도 UML 제품군에서 가장 간단한 다이어그램이어야 합니다.이는 귀하가 정의한 액터/역할을 시스템의 사용 사례에 직접 매핑해야 합니다.실제로, 주로 단일 액터에 초점을 맞춰야 하며, 특정 사용 사례에 참여해야 하는 경우에만 다른 액터를 포함해야 합니다.

다음은 Google에서 가져온 예입니다.

샘플 사용 사례 다이어그램 http://java.sun.com/mailers/newsletters/fundamentals/img/usecase.png

단순함에 주목하세요.하나의 행위자, 하나의 시스템, 5개의 사용 사례.다른 것은 없습니다.

또한 다음과 같이 @에릭 피 제안된 예시 이미지에서 알 수 있듯이 사용 사례의 제목은 "[동사] [객체]" 구조로 지정해야 합니다.즉."회원이 책을 빌립니다."는 "책 대출"이 됩니다.유스 케이스 문장의 누락된 주제("멤버")는 유스 케이스 다이어그램에 유스 케이스와 연관된 행위자로 인코딩됩니다.

직원은 시스템을 사용하는 사람입니다.회원이 여전히 배우로 속해 있습니까?

이에 대한 답변은 주관적일 것 같습니다.어떤 사람들은 시스템이 직원에 의해서만 사용되기 때문에 직원이 유일한 행위자라고 아니라고 말할 것입니다.나는 개인적으로 동의하지 않습니다.

왜?우선, 사용 사례는 요구 사항 수집 단계의 일부입니다.시스템의 최종 기능을 구성하는 데 도움이 됩니다.하지만 부정하기에는 Member 단순히 당신의 현재 믿음이 기술이 다른 기업에 의해 사용되지 않을 것이라는 믿음 때문에 배우가 됩니다. Member 그 단계에서 자신을 제한하는 것입니다.

최종 시스템이 어떻게 될까요? ~이다 자동화됨, 즉 Member 책을 확인하러 터미널에 직접 가시나요?요구사항 수집 중에 가정을 한 경우 중요한 기능을 놓칠 수 있습니다.

편집하다: 행동 순서는 어떻게 설명됩니까?나는 당신이 재발하는 어떤 종류의 일상에 대한 방법 호출과 같은 사용 협회를 볼 수 있다고 들었습니까?이게 옳은 거니?확장 된 방법은 어떻게 사용됩니까?

사용 사례 다이어그램은 높은 수준입니다..각 사용 사례의 형태로 높은 수준의 기능과 이를 활용하는 액터만 표시해야 합니다.확장 및 포함으로 사용 사례 다이어그램을 어지럽히지 마십시오.이는 드물고 특별한 경우에만 발생해야 합니다.당신이 저지를 수 있는 가장 큰 초보 실수는 유스케이스 다이어그램 내에서 코드를 모듈화하려고 시도하는 것입니다.예, 나도 알아요. 가치 있는 프로그래머라면 누구나 가장 먼저 시도하는 일이지만 유스 케이스 다이어그램은 이를 위한 장소가 아닙니다.

일련의 작업에 관하여:일반적인 UML 다이어그램 모음에서 각 사용 사례는 하나 이상의 연결되어 있습니다. 활동 다이어그램.이는 대략 흐름도와 유사하며 대부분의 소프트웨어 엔지니어링 교과서에서 권장하는 일반적인 사용 사례 설명 구조를 그래픽으로 표현한 역할을 합니다.

어쨌든, 이것이 도움이 되기를 바랍니다.다른 질문이 있으시면 언제든지 문의해 주세요!

Answer 2

유스 케이스 다이어그램에 대한 모든 사람의 접근 방식이 약간 다르다고 배웠기 때문에 이것이 귀하에게 적용되는지는 모르겠지만 액터는 일반적으로 시스템과 직접 접촉하는 사람들입니다.따라서 회원은 직원을 거쳐야 하기 때문에 자신의 도서관 카드 등을 스캔하지 않는 한 배우가 될 수 없습니다.

사용 사례는 모든 것을 포괄해야 하지만 너무 자세하게 설명해서는 안 됩니다.따라서 직원은 멤버십이 있는지 확인하고, 멤버십이 없으면 멤버십 사용 사례를 생성하고, 그렇지 않으면 미결제 수수료가 있는지 확인합니다.회원 자격이 양호한 경우 도서 스캔 등

Answer 3

사용 사례가 무엇인지에 대해 잘 이해하지 못하는 것 같습니다.다음은 올바른 방향으로 나아가는 데 도움이 되는 몇 가지 리소스입니다.

• 사용 사례 - 소개
• UML 사용 사례 다이어그램

Answer 4

행위자는 시스템을 사용하는 사람입니다. 따라서 직원이 시스템을 사용하는 유일한 사람이라면 직원이 행위자여야 합니다.예를 들어 직원과 관리자 모두가 기능을 사용할 수 있는 경우 여러 행위자를 가질 수도 있습니다.

따라서 사용 사례를 "새 회원 추가", "회원 계정 변경" 등과 같이 바꿔 표현하는 것이 좋습니다.

세부 수준에 관해서는 "기술적"이지 않고 최대한 많은 세부 정보를 포함하겠습니다.Brandon의 제안은 꽤 좋습니다.