목차
📁 유스케이스
유스케이스(use case)란 시스템이 액터(actor)에게 관찰 가능한 가치의 결과를 생산하기 위해 수행하는 일련의 행동 및 그 변형들의 집합을 말한다.
유스케이스는 완전한 기능을 명세해야하고, 이때 기능이란 시스템의 경계를 정의한다.
유스케이스는 프로세스를 묘사하는데, 이때 프로세스란 조직이나 액터에게 가치있는 것을 생산하기 위해 필요한 사건(events), 행동(actions) 및 거래(transactions)의 연속을 말한다.
예를 들면 계좌에서 현금을 인출하는것, 제품을 주문하는 것, 강좌를 등록하는 것이 있다.
시나리오 vs 유스케이스
시나리오는 특정한 목표를 달성하기 위해 수행되는 일련의 행동임에 반해,
유스케이스는 주어진 기능에 대해 가능한 모든 시나리오의 집합을 정의한다.
즉 시나리오는 유스케이스의 한 예가 된다.
유스케이스의 목적
- 시스템의 기능 요구사항을 결정하고 기술한다.
고객과 소프트웨어 개발자 간의 합의로 귀결된다.
- 시스템이 무엇을 해야 하는지에 대해 명확하고 일관된 설명을 제공한다.
개발 프로세스 전반에 걸쳐 이러한 요구사항을 모든 개발자에게 전달하기 위해 사용될 것이다.
- 시스템을 검증하기 위한 시스템 테스트를 수행할 수 있는 근거를 제공한다.
- 기능 요구사항에서 시스템의 실제 클래스 및 오퍼레이션으로 추적할 수 있는 기능을 제공한다.
- 유스케이스 모델을 변경하여 시스템의 변경 및 확장을 단순화한다.
🌱 유스케이스 다이어그램 (Use-Case Diagram)
외부 actor와 시스템이 제공하는 유스케이스와의 연결성을 보여준다.
사용자 관점에서의 시스템 동작만 설명하고, 유스케이스에 대한 설명은 일반 텍스트로 기술한다.
시스템, 액터, 유스케이스와 같은 모델 요소를 포함한다.
🌱 유스케이스 모델링 절차
1. 시스템 정의(defining the system)
시스템(System)이란 개발될 시스템의 경계.
소프트웨어 시스템, 비즈니스 또느 ㄴ기계.
시스템의 경계와 전반적인 책임을 정의하는 것이 항상 쉬운 것은 아니다.
기본 기능 식별하기.
2. 액터 찾기(finding actors)
액터(Actors)란 시스템과 상호작용할 때 외부 에이전트가 수행하는 역할을 말한다.
외부 에이전트는 사람, 하드웨어 장치 또는 다른 자동화된 시스템일수도 있다.
예를 들어 은행 시스템의 경우, 사람은 대출 담당자의 역할을 수행할 수 있고, 동일한 사람이 또한 그곳에 계좌를 가지고 있다면 고객 역할을 할 수도 있다.
액터는 유스케이스를 수행한다.
이때 주 액터(primary actors)와 부 액터(secondary actors)가 있다.
유스케이스는 시스템에 메시지를 보내는 역할을 수행하는 하나의 initiating actor (stimulus)를 갖는다.
여러개의 participating actors가 있을 수도 있다.
• 액터 찾기 (Finding Actors) – 누가 시스템의 주요 기능을 사용할 것인가 (주 액터)? – 누가 그들의 일상 업무를 수행하기 위해 시스템의 지원을 필요로 하 는가? – 누가 시스템을 유지, 관리 및 시스템의 작동을 지속해야 하는가 (부 액터)? – 시스템에서 처리해야 할 하드웨어 장치는? – 시스템이 상호 작용해야 하는 다른 시스템은? – 누가 시스템이 생성하는 결과에 관심이 있는가?
UML에서의 액터 클래스는 속성과 행위를 둘 다 가질 수 있다.
액터 간의 일반화
3. 유스케이스 찾기 (finding use cases)
유스케이스의 특징은 다음과 같다.
- 항상 액터에 의해 개시된다.
- 액터에게 가치를 제공한다.
- 완전한 설명이어야한다.
유스케이스를 너무 작은 유스케이스로 나누지 않아야하고, 최종 값이 생성될 때까지 유스케이스는 완전한 것이 아니다.
유스케이스 찾기는 이전에 정의한 액터로부터 시작해야한다.
• 액터가 시스템에 요구하는 기능은 무엇인가? 그 액터는 무엇을 해야 하 는가? • 액터는 시스템의 어떤 종류의 정보를 읽거나, 만들거나, 파괴하거나, 수 정하거나, 저장하는가? • 시스템에서 발생하는 이벤트에 대해 액터에게 알려야 하는가, 아니면 액 터가 시스템에 알려야 하는 것이 있는가? 이러한 이벤트는 기능 면에서 무엇을 나타내는가?
– 현재의 액터와 관련되지 않는 기타 질문 • 시스템에 필요한 입/출력은 무엇인가? 이런 입출력은 어디에서 오거나 어디로 가는가? • 현재 이 시스템의 구현에서 가장 큰 문제점은 무엇인가?
UML에서의 유스케이스
4. 유스케이스 기술 (describing the use cases)
– 유스케이스의 목적 • 궁극적인 목표 – 유스케이스의 시작 방법/시기 • 액터 • 상황들 – 액터와 유스케이스 사이의 전형적인 메시지 흐름 – 유스케이스의 대체 흐름 • 그것들은 너무 자세히 설명하지 않아야 함 – 액터에게 가치를 부여하여 유스케이스를 완료하는 방법/시점 – 참여 액터와의 상호작용 시점
– 텍스트 • 고객이 이해하고 검증할 수 있도록 명확하고 일관성이 있어야 함 • 복잡한 문장을 피해야 함 – 액티비티 다이어그램 (activity diagram) • sequence of activities, ordering, and optional decisions
유스케이스 템플릿
예시는 다음과 같다.
5. 유스케이스 간의 관계 정의 (defining the relationship between use cases)
1. 일반화(Generalization)
- 자식 유스케이스는 부모의 행위(행동 순서)를 계승한다.
- 자식 유스케이스는 부모 행위의 일부를 우선할 수 있고, 행위 추가도 가능하다.
- 부모 유스케이스가 예상되는 곳이라면 어디든 자식 유스케이스를 사용할 수 있다.
2. 포함관계(Include relationship)
- 다수의 유스케이스가 공통적인 행동을 수행하는 경우, 이러한 행동은 단일 유스케이스로 모델링 될 수 있으며 이 유스케이스는 다른 유스케이스에 포함된다.
- 유스케이스는 특정 위치에서 다른 유스케이스를 포함할 수 있다.
여러 유스케이스에 걸쳐 동일한 이벤트 흐름의 작성을 피하기 위해 사용한다.
포함되는 유스케이스가 그 자체로 완전할 경우, 일반적인 유스케이스와 마찬가지로 즉시 사용 가능하다.
불완전한 경우는 인스턴스화할 수 없는 유스케이스를 말한다.
<<include>> : 함수 호출(function call)과 유사하다. included use case로 제어를 이동시키고, included use case를 수행한 후 제어가 복귀한다.
3. 확장 관계(Extend relationship)
- 한 유스케이스의 확장 지점(extension point)에 액션을 추가하여 다른 유스케이스로 확장한다.
- 기본적으로 확장 관계는 일반화 관계와 유사하다.
- 유스케이스는 기반 유스케이스의 지정된 위치에서 추가 행위를 합병하여 기반 유스케이스를 확장할 수 있다.
기반 유스케이스는 독립된 유스케이스로 작용할 수 있다.
기반 유스케이스는 확장 지점이라고 불리는 특정 지점에서만 확장할 수 있다.
예외에 따라 실행되는 별도의 흐름을 모델링하는데도 사용된다.
조건 확장(conditional extension). 조건은 boolean 수식이며, 이 수식이 참일때만 확장이 이루어진다.
6. 유스케이스 모델 검증 (validating the model)
검증(verification) : 시스템이 올바르게 개발되었는가, 또는 만들어진 명세에 따라 개발되었는가 구현을 테스트한다.
확인(validation) : 시스템이 고객 또는 최종 사용자의 요구를 충족시키는가를 확인한다. 개발 프로세스 초기, 유스케이스 모델링 후 수행한다.
- 유스케이스 워크쓰루 (walking the use cases)
역할극 : 액터 그룹, 시스템 그룹
역할극에 참여하지 않은 개발자는 메모를 하고 유스케이스에서 결함을 찾으려고 노력한다.
몇가지 대안을 찾을 수 있다.
🌱 유스케이스 실현(Realizing Use Cases)
유스케이스는 collaboration으로 실현된다.
유스케이스 내의 단계와 행동을 클래스, 오퍼레이션 및 이들간의 관계로 변환하여 각 단계의 책임을 collaboration에 참여하는 클래스에 할당한다.
