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

Question

학교 과제를 위해 우리는 Useecase 다이어그램을 만들어야합니다. 그러나 우리가 가지고있는 문서는 그다지 확장되어 있지 않습니다. 단지 유스 케이스가 구성하는 구성 요소와 하나의 예를 설명합니다.
도서관 시스템에 관해 유스 케이스를 만들어야합니다. 우리는 11 개의 유스 케이스를 발견했지만, 나는 그들 모두와 함께 당신을 괴롭히지 않을 것입니다.

IIRC, usecase는 시스템의 일반적인 사용법을 설명합니다. 맞습니까? 그러나 유스 케이스 다이어그램에 어떤 것들이 속해 있으며 어떻게 연결되어 있습니까?

우리는 이제 4 명의 배우 (회원, 직원, 관리자 및 회계사)입니다. 가장 문제가있는 것은 구성원과 직원입니다.
직원은 시스템을 사용하는 직원입니다. 아직 회원이 배우로 여기에 있습니까?

• 회원 라이브러리를 결합 : 우리가

  일부 쓰임새.

• 회원이 그의 기록을 변경합니다.
• 회원이 책을 빌린다.
• 회원 부분은 도서관에 있습니다 (탈퇴).
• 회원 책 기사.
• 회원이 책을 반품합니다.
• 회원은 수수료 및 벌금의 일부 (일부)를 지불합니다.

다이어그램의 사용 사례가됩니다. 그러나 직원이 membernumber를 입력하고, 직원이 booknumber를 입력하는 등의 용도가 더 많으면 (? 사용).

누구든지이 부분을 밝힐 수 있습니까?

편집 : 설명되는 동작의 순서는 무엇입니까? 나는 어떤 종류의 루틴에 대한 메소드 호출과 같은 사용 연관을 볼 수 있다고 들었습니다. 이게 옳은 거니? 그리고 어떻게 확장 사용됩니까?

Answer 1

IIRC하는 유스 케이스 바로 시스템의 전형적인 사용법을 설명? 그러나 무엇이 얇은 [g]가 유스 케이스 다이어그램에 속하며, 그들은 어떻게 서로 연결되어 있습니까?

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

Sample Use Case Diagram http://java.sun.com/mailers/newsletters/fundamentals/img/usecase.png

주 단순성 :

는 여기에 내가 구글을 내려서 예제입니다. 하나의 액터, 하나의 시스템, 5 개의 유스 케이스. 다른 건 없어.

또한 @Eric P으로 제안하고 예제 이미지가 암시 하듯이 "[Verb] [Object]"구조로 사용 사례의 제목을 지정해야합니다. 즉 "회원이 책을 빌리다"는 "대출 도서"가됩니다. 유스 케이스 문장 ("회원")의 누락 된 주제는 유스 케이스에 대한 연관이있는 액터로 유스 케이스 다이어그램에 인코딩됩니다.

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

나는 주관적인 답변입니다. 시스템이 직원에 의해서만 사용되기 때문에 직원이 유일한 배우라고 말하는 사람들도 있습니다. 나는 개인적으로 동의하지 않는다.

왜? 하나의 경우 Use Case는 요구 사항 수집 단계의 일부입니다. 시스템의 최종 기능을 구성하는 데 도움이됩니다. 그러나 Member 배우를 거부하는 것은 단순히 현재의 기술이 Member에 의해 사용되지 않을 것이라는 믿음 때문에 그 단계에서 자신을 제한하는 것입니다.

최종 시스템 이 인 경우, Member은 자동으로 책을 체크 아웃 할 수 있습니까? 요구 사항 수집 중에 가정 사항을 작성하면 중요한 기능을 놓칠 수 있습니다.

편집 : 어떻게 행동 의 시퀀스을 설명? 나는 당신이 과 같은 연관을 사용하는 것을 볼 수 있다고 들었습니다. 어떤 종류의 루틴에 대해서 다시 호출하는 ? 이게 맞습니까? 그리고 확장 된 방법은 입니까?

유스 케이스 다이어그램은 높은 수준의 있습니다. 그들은 (각각의 유스 케이스의 형태로) 당신의 높은 수준의 기능과 그것들을 활용하는 액터 그리고 다른 것을 보여줘야합니다. 확장 및 포함으로 유스 케이스 다이어그램을 정리하지 마십시오. 희귀하고 특별한 경우에만 사용해야합니다. 당신이 만들 수있는 가장 큰 루키 실수는 (그리고 내가 그것을 만들었습니다!) 유스 케이스 다이어그램에서 코드를 모듈화하려고 시도하는 것입니다. 네, 알고 있겠지만, 소금을 사용할 가치가있는 프로그래머라면 누구나 할 수있는 첫 번째 시도입니다.하지만 유스 케이스 다이어그램은 그 자리가 아닙니다.

동작 순서 : 일반적인 UML 다이어그램 집합에서 각 사용 사례는 하나 이상의 Activity Diagrams과 연결되어 있습니다. 이는 대략적으로 플로우 차트와 유사하며 대부분의 소프트웨어 엔지니어링 교과서가 권장하는 일반적인 유스 케이스 내러티브 구조를 그래픽으로 표현한 것입니다.

어쨌든 도움이 되길 바랍니다. 다른 질문이 있으시면 언제든지 물어보십시오!

Answer 2

사례 다이어그램을 사용하는 모든 사람들의 접근 방식은 약간 다르므로이 내용이 적용되는지는 잘 모르겠지만 배우는 일반적으로 시스템과 직접 접촉하는 사람들입니다. 그래서 회원은 자신의 도서관 카드 나 물건을 스캔하지 않으면 배우가되지 않을 것입니다. 왜냐하면 그 직원을 거쳐야하기 때문입니다.

사용 사례는 모든 것을 다루지 만 크게 자세히 설명하지는 않습니다. 따라서 직원이 멤버십을 확인한 다음 멤버쉽 유스 케이스를 만들거나 미결료를 확인하십시오. 회원 자격이 양호한 경우 책 등을 스캔하십시오.

Answer 3

사용 사례가 무엇인지 알 수없는 것처럼 들립니다. 여기에 몇 가지 자원은 당신이 올바른 방향으로 가고 얻을 수 있습니다

• Use Cases - An Introduction
• UML Use Case Diagrams

Answer 4

배우가 시스템을 사용하는 사람입니다 직원이 시스템을 사용하여 하나의 경우 이렇게 , 그들은 배우가되어야합니다. 예를 들어 기능이 직원과 관리자 모두에게 제공되는 경우 여러 가능한 액터를 가질 수도 있습니다.

그래서, 당신은, "새 멤버 추가" "회원 계정을 변경합니다"와 같은 뭔가 세부 수준으로 등

귀하의 사용 사례를 바꿔 할 수 있습니다, 당신이 할 수있는만큼 많은 세부 사항을 포함 할 것 "기술"을 얻지 않고 Brandon의 제안은 꽤 훌륭합니다.