유스 케이스 다이어그램(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. 사용 사례 세분성
유스 케이스 세분화는 유스 케이스가 시스템 기능을 개선하거나 통합하는 정도를 의미하며 유스 케이스에 포함된 시스템 서비스 또는 기능 단위의 수라고도 할 수 있습니다. 유스 케이스 세분성이 너무 거칠거나 너무 크면 유스 케이스에 더 많은 시스템 기능이 포함되며 그 반대도 마찬가지입니다. 유스 케이스의 입도가 너무 촘촘하면 시스템을 이해하기 어려울 수 있으며, 유스 케이스 모델이 너무 커지면 설계가 어려워집니다. 사용 사례가 너무 세분화된 경우 다음과 같이 기능적으로 분해될 수 있습니다.
사용 사례 세분성 초기
실제로 시스템 내의 많은 업무에는 추가, 삭제, 수정, 확인 등의 작업이 포함되어 있습니다. 그렇게 하면 사용자에게 의미 있는 목표를 제공할 수 없으며 사용자의 실제 목적을 무시하게 됩니다.
위의 "추가, 삭제, 수정 및 확인"은 참여자의 실제 목적인 사용자 관리에 지나지 않습니다. 위의 사용 사례를 다음과 같은 방식으로 처리하는 것이 더 나을 수도 있습니다.
사용 사례 세분성 감소
사용자 관리 사용 사례는 시스템 관리자의 목표 또는 작업을 나타냅니다. 추가, 삭제, 수정, 질의 등을 추가해야 하는 경우에는 다음과 같이 표현하는 것이 좋습니다.
사용 사례 세분성 최적화 후
유스 케이스 모델링에서 흔히 저지르는 또 다른 실수는 단계를 유스 케이스로 취급하는 것입니다. 예를 들어, 다음은 완벽해 보이지만 작업 단계가 유스케이스로 간주되는 것이 분명합니다.
로그인
무료 온라인 협업 마인드맵 흐름도
