순서도
더보기
유스 케이스 다이어그램(Use Case Diagram)은 액터(Actor), 유스 케이스(Use Case)로 구성된 시스템 기능과 이들 간의 관계를 설명하는 데 사용되는 뷰로, 액터라는 외부 사용자가 관찰할 수 있는 시스템 기능 모델 다이어그램입니다. 사용 사례 다이어그램은 요구 사항 분석 단계에서 자주 사용됩니다.
시스템을 개발하기 전에 가장 중요한 작업은 사용자 요구사항을 파악하는 것이며, 사용자 요구사항 중 가장 중요한 것은 사용자가 제안하는 시스템의 기능적 요구사항입니다. 사용자 요구사항을 시각적으로 표현하기 위해 유스케이스 다이어그램을 사용할 수 있습니다.
시각적 사용 사례 다이어그램
유스 케이스 다이어그램의 주요 요소에는 액터, 유스 케이스 및 요소 간의 관계가 포함됩니다. 이 외에도 사용 사례 다이어그램에는 주석과 제약 조건이 포함될 수도 있습니다.
1. 참가자의 개념
행위자는 기본 시스템과 상호 작용하는 외부 개체입니다. 참가자는 시스템 외부의 사람, 하위 시스템, 기타 시스템 등일 수 있습니다.
각 액터는 실제로 역할 세트입니다. UML에서는 행위자가 사람 모양을 사용하여 그래픽으로 표현되고 이름이 지정됩니다. 아래 그림과 같이 '독자'는 도서관 대출 시스템의 참여자입니다.
사용 사례 다이어그램 액터
액터는 시스템의 일부가 아닌 시스템 경계 외부에 있어야 합니다.
2. 참가자 식별 방법
유스 케이스 모델링을 수행할 때 행위자를 식별하는 것이 유스 케이스 다이어그램 모델링의 첫 번째 단계입니다. 그렇다면 시스템 참가자를 어떻게 결정합니까 ? 우리는 다음과 같은 생각으로 그것에 대해 생각해 볼 수 있습니다:
(1) 도서관 대출 시스템의 독자와 같은 시스템의 서비스 개체;
(2) 작업 완료를 지원하는 사람 - 도서관 대출 시스템의 도서관 직원과 같이 독자가 도서 대출, 도서 반납 및 알림을 완료할 수 있도록 시스템을 사용해야 하는 사람.
(3) 시스템 유지관리자: 시스템의 설치, 유지, 관리를 담당하는 사람. 이 경우 시스템은 해당 인력이 설치, 유지, 관리 작업을 완료할 수 있도록 관련 기능을 제공해야 합니다.
(4) 외부 장치: 카드 리더기와 같은 외부 장치와 정보를 전송하거나 외부 장치로부터 정보를 읽어야 합니다.
(5) 기타 시스템 또는 하위 시스템: 대출 시스템의 금융 시스템과 같은 금융 시스템은 대출 시스템의 기능이 아니지만 대출 시스템은 연체된 벌금 작업을 완료하기 위해 정보를 전송해야 합니다.
(6) 시간: 예정된 순간에 자동 백업, 정기 알림 등과 같은 특정 이벤트가 자동으로 발생합니다.
(7) 특정 이벤트: 예를 들어 테이크아웃 시스템의 자동 주문 접수는 주문 생성 이벤트에 의해 구동됩니다.
참가자를 식별할 때 다음 사항에 유의하세요.
(1) 참가자는 시스템의 일부가 아닌 시스템 외부에 있습니다.
(2) 참가자는 시스템 경계를 통해 시스템과 상호 작용합니다.
(3) 참가자의 아이콘은 사람 모양의 아이콘으로 표현되지만, 참가자가 반드시 사람일 필요는 없으며, 다른 하위 시스템, 다른 시스템, 시간, 온도 및 기타 요소일 수도 있습니다.
3. 참가자 간의 관계
참가자 간의 주요 관계는 일반화입니다. 일반화는 보다 일반적인 참가자를 가리키고 "특정" 참가자 끝에서 끝나는 실선 개방형 삼각형 화살표로 표시됩니다. 일반화 관계는 일반과 특수(구체적) 사이의 관계입니다. 일반화 관계에서는 참가자에 대한 추상적인 설명을 하나 이상의 구체적인 참가자가 공유할 수 있습니다. 다음 그림은 도서관 대출 시스템 참가자 간의 일반화된 관계를 보여줍니다.
도서관 대출 시스템 참여자 간의 일반화 관계
독자 아래의 교직원, 학생, 퇴직 교원 등은 '특정' 참여자이다. 참가자 일반화는 다음과 같이 이해될 수 있습니다. "특정" 참가자는 일종의 독자인 교수진과 같은 "일반" 참가자입니다. 액터 일반화에서 "일반" 액터가 실행 가능한 사용 사례는 "구체적인"("특수") 액터가 실행 가능한 것으로 표시됩니다.
1. 유스케이스의 개념
유스케이스는 참가자가 경험할 수 있는 시스템 서비스 또는 기능 단위입니다. 시스템이 달성해야 할 목표를 정의합니다. 유스케이스는 시스템의 동작만 정의할 뿐 시스템의 내부 구조를 드러내지는 않습니다.
유스 케이스의 가장 큰 장점은 사용자 관점에서 시스템 기능을 설명한다는 것입니다. 그래픽적으로 유스 케이스는 타원 내부 또는 아래에 유스 케이스 이름이 있는 단색 타원으로 표시됩니다.
도서 대출 활용 사례
2. 사용 사례 식별
사용 사례는 다음 사항을 통해 확인할 수 있습니다.
(1) 참가자가 자신의 작업을 지원하기 위해 시스템에서 어떤 기능을 필요로 합니까?
(2) 참가자는 시스템에서 일부 정보를 쿼리해야 합니까?
(3) 참가자가 작업 생성, 수정, 삭제 등 시스템의 일부 정보를 변경해야 합니까?
(4) 특정 이벤트나 시스템 상태 변경을 참가자에게 알려야 합니까?
(5) 시스템의 어떤 외부 이벤트로 인해 시스템이 이에 대응하여 관련 기능을 수행하게 됩니까?
(6) 시스템은 유지보수 담당자가 시스템을 유지하는 데 도움이 되는 관련 기능을 제공합니까?
3. 유스케이스 식별의 핵심 포인트
(1) 식별된 사용 사례는 시스템의 목표, 즉 "어떻게 해야 하는지"가 아닌 "무엇을 해야 하는지"를 반영해야 합니다. 즉, 사용 사례는 시스템 구현의 세부 사항이 아닙니다.
(2) 시스템 관점이 아닌 참여자(사용자) 관점에서 유스케이스를 정의한다.
(3) 사용 사례는 일련의 작업이 아닌 참여자에게 가치 있는 결과를 제공해야 합니다.
(4) 기능적 분해와 단계적 분해를 피한다.
(5) 각 참여자는 실행 가능한 유스케이스를 가지고 있어야 하며, 각 유스케이스는 적어도 한 명의 참여자와 연관되어야 합니다.
4. 사용 사례 명명
시스템의 사용 사례를 결정한 후에는 각 사용 사례의 이름을 지정해야 합니다. 사용 사례의 이름은 사용자 관점에서 참가자가 달성한 목표를 설명해야 합니다. 다음과 같은 이름 지정 방법을 사용할 수 있습니다.
동사 + 목적어
즉, 유스케이스의 이름은 동사-목적어구 형태이어야 한다. 강좌선택, 도서대출, 물품주문, 신용카드 결제 등이 있습니다.
5. 사용 사례 세분성
유스 케이스 세분화는 유스 케이스가 시스템 기능을 개선하거나 통합하는 정도를 의미하며 유스 케이스에 포함된 시스템 서비스 또는 기능 단위의 수라고도 할 수 있습니다. 유스 케이스 세분성이 너무 거칠거나 너무 크면 유스 케이스에 더 많은 시스템 기능이 포함되며 그 반대도 마찬가지입니다. 유스 케이스의 입도가 너무 촘촘하면 시스템을 이해하기 어려울 수 있으며, 유스 케이스 모델이 너무 커지면 설계가 어려워집니다. 사용 사례가 너무 세분화된 경우 다음과 같이 기능적으로 분해될 수 있습니다.
사용 사례 세분성 초기
실제로 시스템 내의 많은 업무에는 추가, 삭제, 수정, 확인 등의 작업이 포함되어 있습니다. 그렇게 하면 사용자에게 의미 있는 목표를 제공할 수 없으며 사용자의 실제 목적을 무시하게 됩니다.
위의 "추가, 삭제, 수정 및 확인"은 참여자의 실제 목적인 사용자 관리에 지나지 않습니다. 위의 사용 사례를 다음과 같은 방식으로 처리하는 것이 더 나을 수도 있습니다.
사용 사례 세분성 감소
사용자 관리 사용 사례는 시스템 관리자의 목표 또는 작업을 나타냅니다. 추가, 삭제, 수정, 질의 등을 추가해야 하는 경우에는 다음과 같이 표현하는 것이 좋습니다.
사용 사례 세분성 최적화 후
유스 케이스 모델링에서 흔히 저지르는 또 다른 실수는 단계를 유스 케이스로 취급하는 것입니다. 예를 들어, 다음은 완벽해 보이지만 작업 단계가 유스케이스로 간주되는 것이 분명합니다.
사용 사례 오류 예로서의 작업 단계
위의 단계는 참가자로서 사용자의 목표인 등록을 완료하는 것에 지나지 않습니다. 따라서 다음과 같이 변경되어야 합니다.
사용 사례 최적화 후
유스 케이스 모델링에서 세 번째로 흔한 실수는 시스템 활동을 유스 케이스로 취급하는 것입니다. 아래 사용 사례 다이어그램에서 연결 개체 설정, 명령 개체 생성 및 SQL 문 실행은 사용자가 인식할 수 없는 시스템 내 활동입니다. 이는 사용자의 목적이 아니며 사용자는 신경 쓰지 않습니다. 따라서 이 사용 사례 다이어그램은 정확하지 않습니다.
시스템 활동 사용 사례 오류 예
유스 케이스 모델링에서 흔히 발생하는 네 번째 실수는 시스템 관점을 사용하여 유스 케이스의 이름을 지정하는 것입니다.
시스템 관점을 사용하여 사용 사례 오류 예 이름 지정
위의 두 가지 사용 사례 다이어그램 중 어느 것이 더 좋나요? 당연히 오른쪽 유스케이스는 왼쪽 유스케이스보다 낫습니다. 왜냐하면 오른쪽 유스케이스는 사용자 관점에서 명명된 반면, 왼쪽 유스케이스는 시스템 관점에서 명명되었기 때문입니다. 그것을 본다.
6. 사용 사례 사양
유스케이스 다이어그램은 일반적으로 사용자의 기능적 요구사항(시스템이 제공하는 기능이나 서비스)을 기술하지만, 유스케이스가 구체적으로 무엇을 해야하는지 사람들이 알 수 있도록 각 유스케이스를 자세히 설명해야 합니다. 이것이 유스케이스 명세입니다. 즉, 유스케이스 모델은 기본적으로 유스케이스 다이어그램과 각 유스케이스에 대한 자세한 설명(유스케이스 사양)으로 구성됩니다.
사용 사례 사양에는 다음 내용이 포함되어야 합니다.
(1) 사용 사례의 식별 및 이름
(2) 사용 사례에 관련된 참가자;
(3) 사용 사례에 대한 간략한 설명
(4) 기타 관련 사용 사례;
(5) 유스케이스 실행을 위한 전제조건
(6) 기본 이벤트 흐름;
(7) 대체 이벤트 흐름;
(8) 유스 케이스 실행을 위한 사후 조건;
(9) 비기능적 요구사항, 설계 제약사항, 사용 사례 검토 상태, 작성자, 수정 기록 등과 같은 기타 정보
유스 케이스 간의 관계에는 주로 일반화, 포함 및 확장의 세 가지 유형이 포함됩니다.
여러 사용 사례에 유사한 속성이나 동작이 있는 경우 해당 공통성을 상위 사용 사례로 추상화하고 다른 사용 사례를 일반화 관계의 하위 사용 사례로 추상화할 수 있습니다. 하위 사용 사례는 상위 사용 사례의 속성과 동작을 상속합니다. 사용 사례의 일반화 관계는 동일한 비즈니스 목적에 대한 서로 다른 구현 경로로 이해될 수 있습니다.
일반화 관계는 하위 사용 사례에서 상위 사용 사례를 가리키는 속이 빈 삼각형 화살표가 있는 구현으로 그래픽으로 표현됩니다.
사용 사례 다이어그램 일반화 관계
위 예시에서 '결제 수단 1 '과 '결제 수단 2 '는 '결제'의 하위 활용 사례입니다. 상위 유스 케이스 "결제"는 특정 결제 방법을 제공하지 않고 결제에 필요한 속성과 인터페이스만 제공하며 하위 유스 케이스에서는 특정 결제 기능을 구현합니다.
시스템 모델링 프로세스 중에 일부 기능은 다양한 비즈니스 시나리오에서 반복적으로 사용해야 합니다. 이렇게 반복적으로 사용되는 기능을 분리하여 별도의 Use Case를 구성할 수 있으며, 관련 기능을 실행할 때 분리된 공용 기능을 메인 프로세스에 포함시킬 수 있습니다. 사용 사례의 포함 관계는 이러한 상황을 설명할 수 있습니다. 또한 기본 사용 사례에 기능이 너무 많으면 여러 개의 작은 사용 사례로 나눌 수도 있습니다. 포함된 사용 사례를 공급자 사용 사례라고 하며, 다른 사용 사례를 포함하는 사용 사례를 클라이언트 사용 사례라고 합니다.
UML에서 포함 관계는 <<include>> 스테레오타입이 있는 점선 화살표로 표시됩니다. 화살표는 기본 사용 사례(사용 사례/고객 사용 사례 포함)에서 포함된 사용 사례(공급자 사용 사례)를 가리킵니다.
사용 사례 다이어그램에는 관계가 포함되어 있습니다.
다음은 구체적인 예입니다. 이 예에서 독자는 책을 미리 빌리기 전에 질의서 사용 사례를 실행해야 합니다. 따라서 질의서 사용 사례가 포함됩니다. 사전 대출 도서 사용 사례 동시에, 독자는 도서를 사전 대출할 때 시스템에 로그인해야 하며 시스템은 사전 대출 작업을 수행하기 전에 로그인 상태를 저장해야 합니다. 신원 확인 사용 사례는 대출 전 도서 사용 사례에도 포함됩니다. 책을 조회하는 것은 독자에게 필요한 기본 기능일 뿐만 아니라, 다른 기능을 위해 꼭 필요한 작업 과정이기도 합니다. 신원 확인은 도서를 사전 대출할 때뿐만 아니라 대출 기록 조회, 벌금 납부 등의 기능을 수행할 때에도 사용 사례를 구성하기 위해 별도로 신원 확인을 제안하는 것이 더 적절합니다.
독자 대출 도서 포함 관계
기본 사용 사례는 새로운 동작을 추가할 수 있는 확장 지점을 제공합니다. 확장 사용 사례는 기본 사용 사례의 확장 지점에 삽입할 수 있는 삽입 조각 집합을 제공합니다.
· 기본 유스케이스는 확장 유스케이스의 세부 사항을 알지 못한 채 확장 포인트만 제공합니다.
· 기본 유스케이스는 포함 관계와 달리 확장 유스케이스 없이도 완전합니다.
· 사용 사례는 여러 확장 지점을 제공할 수 있으며 각 확장 지점은 여러 번 나타날 수 있습니다.
· 일반적인 상황에서 기본 유스 케이스의 실행에는 확장 유스 케이스가 포함되지 않습니다. 확장 유스 케이스의 기능은 특정 조건이나 이벤트가 발생할 때만 실행됩니다.
UML에서 확장 관계는 <<extend>> 스테레오타입이 있는 점선 화살표로 표시됩니다. 화살표는 확장 사용 사례에서 기본 사용 사례를 가리킵니다.
사용 사례 다이어그램 확장 관계
다음 예는 도서관 대출 시스템의 사용 사례 다이어그램 조각입니다.
독자는 관계 확장을 위해 벌금을 지불합니다
이 예에서 벌금을 지불하는 것은 독자의 기본 사용 사례이자 책 반환을 위한 확장된 사용 사례입니다. "과태료 납부"는 "장부 반환"의 확장된 사용 사례로서 다음 조건에서만 실행됩니다.
(1) 독자의 도서가 기타 이유로 인해 연체되었거나 기록이 양호하고 전액 지불되지 않은 경우
(2) 독자는 책을 반납한 후 벌금을 동시에 납부하기로 선택합니다.
위 내용은 UML 유스 케이스 다이어그램에 대한 관련 내용입니다. 위 유스 케이스 다이어그램 케이스는 모두 ProcessOn을 사용하여 작성되었습니다.
무료 온라인 협업 마인드 맵 및 순서도 무료 사용 
