dev 2.2 유스케이스다이어그램

1. 개요(Overview)

시스템의 기능적, 비기능적 요구사항 중에서 시스템의 기능적 요구사항을 정의 한다. 유스케이스는 사용자 입장에서 시스템을 보았을 때, 시스템이 제공해야 할 기능(functionality)을 분석하기 위한 방안이다. 즉, 외부에서 보여지는 요구사항을 분석하기 위한 방안이다. 시스템 영역내의 유스케이스와 액터, 그리고 그들간의 관계를 유스케이스 다이어그램으로 도식화한다.

1. 작성기준
   1. 미작성시 영향

• 개발 시스템에서 반드시 구현되어야 할 기능적 요구사항들이 누락될 수 있다.
• 시스템과 연관이 있는 액터의 도출이 누락될 수 있다.
• 액터와 유스케이스간의 상호작용을 파악하기 어렵다.
• 프로젝트 내외부의 의사소통이 원활하지 못할 수 있다.

1. 1. 작성이 불필요한 경우

유스케이스다이어그램은 반드시 작성하도록 한다.

1. 1. 제출시 고려사항

N/A

1. 작성항목
   1. 시스템명/업무명

• 프로젝트에서 분류한 시스템명과 업무명을 기술한다.

1. 1. 작성자/작성일

• 다이어그램의 작성내용이 명확하지 않은 경우 작성자에게 작성내용의 의미를 확인하고, 작성내용에 대한 작성일을 확인하기 위한 목적으로 작성자와 작성일을 기재한다. 프로젝트의 상황에 따라 작성자와 작성일의 기록을 다이어그램별로 하지 않고 업무단위별로 할 수도 있다.

1. 1. 개요

• 유스케이스 다이어그램을 간략하게 설명할 수 있는 내역을 기술한다.

1. 1. 유스케이스 다이어그램
2. Actor

• 사람 심볼(Stick Man)로 표기하고 Actor명을 기재한다.
• Actor명은 물리적인 사람이나 조직명 보다는 역할 중심으로 추상화하여 Actor 이름을 정의한다.
• Actor는 사람이 아닌 시스템과 정보를 교환하는 시스템도 포함될 수 있다.
• 사용자가 하는 역할(Role)을 표현한다. 즉, Actor명은 물리적인 사람이나 조직명보다는 역할 중심으로 추상화하여 Actor 이름을 정의한다.
• 시스템과 직접 상호 작용(Interact)하는 것을 표현한다.
• 사람 이외에, 다른 시스템이 될 수 있으며, 현 개발할 시스템의 일부가 아니다.
• 표현 예

2) Use Case

• Actor와 시스템간의 전형적인 대화(Dialog)이다.
• 완벽(Use Case간의 교집합이 없다)하고 의미 있는 이벤트(Event)의 흐름이다.
• 시스템내의 기능 군을 호출하기 위해 Actor에 의해 초기화 된다.
• Use Case 이름은 "목적어+서술형 종결어미" 형태로 정의하며 다이어그램 안에서 식별 가능하도록 부여한다.
• Use Case는 여러 Actor들과 교류(Interact)할 수 있다.
• 한 Actor는 여러 Use Case와 교류할 수 있다.
• 각 Use Case는 일련의 교류(Sequence of Interaction)이다.
• 표현 예

3) System Boundary

• 시스템의 경계와 시스템을 위한 유즈 케이스를 포함하며, 액터들은 시스템 경계 외부에 위치한다.
• 표현 예

1. Communicates, Association

• 상호작용하는 액터와 유스케이스간의 관계를 표현한다.
• 액터는 하나 이상의 유즈 케이스와 연관될 수 있으며, 유즈 케이스 또한 하나 이상의 액터와 연관될 수 있다.
• 표현 예

5) Extend (선택) - 유스케이스 모델링시 Extend의 사용은 최대한 지양한다.

• 하나의 유즈 케이스가 다른 유즈 케이스의 행동을 추가함을 나타내는 두 유즈 케이스 간의 관계을 나타낸다
• 수행 순서는 화살표 반대 방향으로 발생하며 하나의 유스케이스가 다른 유스케이스를 경우에 따라 수행할 수도 있고 안할수도 있는 Optional하게 수행되는 경우에 사용된다.
• 확장 유형에 따라 Extend Points를 가질 수 있다.
• 표현 예

6) Include(선택) - 유스케이스 모델링시 include의 사용은 최대한 지양한다.

• 하나의 유즈 케이스가 다른 유즈 케이스의 행동을 추가함을 나타내는 두 유즈 케이스 간의 관계을 나타낸다. 여러 Use Case에 걸쳐 공통적으로 사용되는 유즈케이스에 사용한다
• 표현 예

• Extend & Include 표현 예

1. Generalization(선택) - 유스케이스 모델링시 Generalization의 사용은 최대한 지양한다.

• 액터간의 상속관계를 나타내는 두 액터간의 관계
• 추상화된 유스케이스를 상세화하는 유스케이스간의 관계를 표현할 때도 사용되나 현재 Tool에서는 이 관계과 지원되지 않는 관계로 액터간의 관계만을 활용한다.
• 표현 예

1. 작성시 고려사항

• 한 유스케이스의 크기는 액티비티다이어그램(TO-BE)의 액티비티 크기 정도가 적합하다.
• 요구분석 단계에 있어 액터는 현업 조직 구성과 액티비티 다이어그램을 참조하여 도출할 수 있다. 이때 사람이나 직책이 아니라 Role(역할) 중심으로 액터를 도출할 수 있도록 한다. 즉, 역할에 따라 여러 사람이 한가지 Role을 수행하는 액터로 정의될 수 있고, 한 사람이 여러 역할을 수행하여 여러 액터로 정의될 수 있다.
• 분석/설계 과정을 거치며 상세화 하도록 하며, 프로젝트에 따라서는 상세수준의 유스케이스까지 도출할 수도 있다
• 사람이나 직책이 아니라 Role 중심으로 Actor를 정의한다.
• 인터페이스가 발생하는 타 시스템은 Actor로 정의한다.
• 사용자가 이해하기 쉽도록 너무 복잡하지 않고 간결하게 작성한다.
• 유스케이스와 Actor를 정의하는 용어는 용어사전에 정의된, 사용자와 친숙한 용어를 사용한다.
• 유스케이스 간의 업무흐름을 표현하려 하지는 않는다.
• 비즈니스 모델링에 의해 파악된 현업의 업무에 대해 요구사항을 유스케이스로 빠짐없이 정의한다.
• 유스케이스는 규모산정(예:기능점수)과 밀접한 관계가 있다.

Tip
유스케이스의 기준 및 크기는 어떻게 정의하는가?
액터 입장에서 바라봐야 한다. 다시 말하자면, 우리는 타겟 시스템을 우리 스스로 만들어 가면서, 그 시스템이 액터에게 무엇인가를 제대로 서비스 해주기를 바라게 되는데, 바로 그러한 궁극적인 서비스 단위로 유스케이스를 식별하도록 한다. 유스케이스의 종류를 CRUD 관점에서 다음과 같이 구분할 수 있다.
어떤 유스케이스는 참여하는 Domain Entity가 - 실제로는 그렇지 않더라도 - 개념적으로는 하나의 Entity로 간주될 수 있는 것이 있다. 예를 들어, 고객 정보의 경우 실제로는 고객 Entity와 주소 Entity 등이 관계를 갖게 되지만 개념적으로 보면 고객 Entity 하나로 생각해볼 수 있다. 이와 같은 종류의 유스케이스, 즉 개념적으로 하나의 Domain Entity에 대한 작업이 일어나는 유스케이스는 CRUD를 하나로 묶어 하나의 유스케이스로 간주한다. 이에 대한 유스케이스 정의서는 각 CRUD를 Basic Flow로 간주하되 Basic Flow 내의 Sub Flow로 작성한다. 그리고 각 Flow에 목록 조회가 있을 경우 Sub Flow의 Sub Flow로 작성하거나 중복되는 경우에는 별도의 Sub Flow로 작성한다.
또 다른 종류의 유스케이스는 개념상으로도 다양한 종류의 Domain Entity가 유스케이스에 참여하는 경우이다. 이와 같은 경우의 유스케이스는 액터에게 의미있는 서비스 단위로 유스케이스를 식별한다. 예를 들어 입금, 출금, 대출신규, 대출상환, 대출취소 등이 될 수 있다. 이 때 대출취소는 취소 전후에 대출목록을 조회할 수 있는데 대출목록조회가 그 자체만으로 액터에게 의미 있는 서비스인 경우에는 별도의 유스케이스로 도출한다. 그러나 그렇지 않으면 대출취소 유스케이스 내에 포함시키도록 한다.

1. 관련기법(Related Technique)

N/A