시스템의 기능과 역할을 정리하고 분석하는 주요 방법 중 하나는 유스 케이스 다이어그램을 그리는 것입니다. 유스 케이스 다이어그램은 UML 의 4+ 1 뷰 중 하나이며 정확히 "+1" 입니다. 유스 케이스 다이어그램은 전체 OOA/D 를 관통하는 핵심 뷰로, 시스템이 사용자에게 제공하는 기능과 해당 기능을 사용하는 사용자를 설명합니다. 사용자와 기술자 사이의 다리입니다.
유스 케이스 뷰를 사용하여 비즈니스 요구 사항을 분석, 추상화, 정리 및 정련하여 추상 모델을 형성하는 프로세스를 유스 케이스 모델링이라고 합니다. 이 모델은 유스 케이스 모델입니다. 일반적으로 유스 케이스 맵에는 참가자, 사용 사례 및 시스템 경계의 세 가지 요소가 있습니다.
위 그림은 시스템의 중성자 모듈을 평가하는 유스 케이스 다이어그램입니다. 그림의 사용 사례는 시스템이 사용자에게 제공하는 기능입니다. 이것은 단지 함수 목록일 뿐, 프로세스 호출과 같은 관계를 나타내는 것은 아닙니다. 이것은 초보자들이 자주 범하는 실수입니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 예술명언)
이 유스 케이스 다이어그램에서 일반 사용자는 시스템에서 제공하는 "경보 모니터링 단일 질의", "경보 모니터링 요약 질의" 등의 쿼리 작업 및 쿼리 보고서를 수행합니다. 일일 자동 트리거는 세금 징수 시스템과 같은 외부 시스템에서 데이터를 수집하는 자동 평가 기능을 트리거합니다. 그림에서, 평가 관리자와 법 집행관은 완전히 다른 두 가지 역할을 대표하지만, 이 그림에는 이 보고서 더미의 조회라는 특징이 나타나 일반 사용자에게서 물려받은 것으로 그려져 있다. 상속은 참가자 간의 유일한 관계입니다. 즉, 상속인은 상속인의 모든 기능과 권리를 가지고 있습니다. 참가자 외에도 몇 가지 유형의 사용 사례와 사용 사례 간의 직접적인 관계가 있습니다. 나중에 자세히 설명하겠습니다. 유스 케이스 다이어그램을 그릴 때 고려해야 할 세부 사항 중 하나는 분석을 통해 사용 사례를 얻는 방법입니다. 이 문제는 고객 정보 관리 경험이 풍부한 일부 프로젝트에서는 존재하지 않습니다. 고객이 제공한 요구 사항 문서에서 각 기능이 명확하게 구분되어 있기 때문입니다. 이러한 기능은 향후 요구 사항 분석에서 조정될 수 있지만 전체적으로 프로토타입을 형성하여 사용 사례를 분석하고 형성하는 기초가 됩니다. 그러나 정보 관리 경험이 없는 고객들을 대할 때는 상황이 좋지 않다. 이 경우, 일반적으로 고객은 우리에게 관리 목표와 기본 아이디어만 줄 수 있고, 다른 연구 작업은 우리 스스로 해야 한다. 이때, 내가 너에게 건의하는 것은 먼저 조직 구조상 시스템이 어떤 부문과 부문을 포괄하는지 명확하게 정의한 다음, 이를 바탕으로 이들 부서의 인원이 어떤 다른 기능을 발휘하고 어떤 업무 운영을 완성할 수 있는지를 구분하는 것이다. 시스템의 기능, 일반적으로 조직의 한 (또는 여러) 역할이 조직의 한 업무 프로세스에 대해 수행하는 작업으로, 특정 결과 (즉, 출력) 가 있어야 합니다. 이 기능은 우리가 추출해야 할 용례이다. 기능적 역할 분석은 전체 요구 사항 분석 과정에서 이해가 깊어짐에 따라 지속적으로 조정될 수 있지만 분석 프로세스는 일반적으로 이렇게 수행됩니다. 어떤 사람들은 우리가 그린 유스 케이스 맵 고객이 이해할 수 없다고 말합니다. 이렇게 명확한 용례도는 우리가 도형에 대한 묘사를 보완해 주는데, 고객이 어떻게 이해할 수 없을까? 중요한 문제는 유스 케이스 다이어그램의 본질을 이해하지 못했다는 것입니다. 몇 가지 일반적인 문제로 인해 유스 케이스 차트가 불륜입니다. 물론 고객은 이해할 수 없습니다.