공학 - 2.1 Use Case Modeling

  COMET 생명주기 모델에서 Requirements Modeling은 곧 'Use Case Modeling'이라 했다.

• Use Case와 Actor의 관점에서 SW 기능적 요구사항들을 정립한다.

  • Use Case와 Actor는 SW가 어떤 기능을 제공해야하는지를 표현한다.
    • 고객의 요구사항을 UML의 Use Case와 Actor라는 표현기법으로 표현하는것이다.

• Usecase Modeling이란,

  • 시스템의 요구사항을 추출하기 위한 방법이다.
  • 시스템과 상호작용하는 사용자/외부 시스템을 식별한다.
  • 시스템과 사용자/외부 시스템이 어떻게 상호작용하는지 그 절차를 기술한다.
  • 시스템 내부 구성 요소가 시스템 개발 목적을 달성하기에 적절하게 식별되었는지 확인할 수 있다.
  • 시스템 개발을 요청한 고객과 Use Case Diagram을 통해 협의할 수 있다.

Use Case Modeling

Use Case

Use Case : 'Actor'와 'System' 사이에서 일어나는 Interaction의 Sequence

Use Case : 개발하고자 하는 시스템과 외부의 사용자가 서로 어떤식으로 상호작용하는지에 대한 흐름을 보여준다.

즉, Actor와 System 간의 상호작용이 바로 Use Case이다.

• Use Case는 Actor가 원하는 시스템의 주요 기능이다. ★★★

• Use Case는 Actor의 시스템 사용 목적, 목표라고 볼 수 있다.

• Use Case는 반드시 Actor에게 가치(Value)를 제공해야한다.

• Use Case를 이용해 실제 Requirement Modeling을 수행하는 것이 'Use Case Modeling'이다.

• include와 extend의 'Use Case Relationship'이 존재한다. (후술)

Use Case 설계 시 가장 중요한 것은 "내부 구현을 숨기고, Actor와 시스템 간의 상호 요청과 가시적인 결과만 기술해야한다."는 것이다. ★★★

Actor

Actor : External entities of System

Actor : 외부에서 시스템을 시작시키거나, 시스템과 정보를 주고받는 그러한 개체들!

즉, 시스템과 상호작용하는 외부 사용자 또는 외부 시스템!

• Actor의 종류

  • 사람, 사용자
  • 외부 I/O 장치
  • 외부 시스템 ex) 서버
  • 타이머 ~> Real-Time 시스템들이 이러한 Timer를 가진다.

• Actor는 System을 통해 Action을 취한다.

  • System을 사용하고, 물리적으로 소통한다.
  • Actor가 Use Case를 행하는 것이다. ★

~> 직사각형이 '개발하고자 하는 시스템'을 의미하고, 그 안의 타원이 바로 Use Case, 즉, Interaction이다. 시스템 외부의 사람모형이 Actor이다.
~> University System에서 Student라는 Actor는 System과 TakeCourse라는 Use Case를 가진다.

~> '도착 센서'라는 External I/O System이 Actor이고, 이 Actor가 엘리베이터 System과 소통하는 Use Case '엘리베이터를 멈춤'이 있는 상황!

• Primary Actor : 시스템에 입력을 넣어 Use Case를 시작하는 Actor

• Secondary Actor : Use Case를 시작하진 않지만, 해당 Use Case에 참여하는 Actor

  • Secondary Actor는 다른 Use Case에서는 Primary Actor일 수 있다.

• Actor는 시스템 사용자를 대변할 수 있다.

  • 실제 사용자는 Actor의 Instance라고 볼 수 있다.
  • 실제 사용자는 여러 Actor 역할을 수행할 수 있다.

~> 자율주행 차량에서 특정 타이머가 만료되면 현재 주행속도를 계산하는 시스템이 있다. 이 시스템에서, '주행속도 계산'이라는 Use Case를 촉발시키는 Primary Actor는 Timer이다. 한편, 속도에 관여하는 운전자 Actor는 Secondary Actor이다.

~> 또 다른 예시. 알람 및 공지의 주체가 로봇이면 로봇이 Primary Actor가 될 것이다.

Association

Association : Actor와 Use Case 사이의 모든 상호작용을 의미한다.

• (여기부터)

Use Case 상세

Identifying

  Use Case는 '개발자가 개발할 시스템' 안에서 외부의 Actor와 의사소통하는 Service/Function이다.
~> Actor로 인해 시작되는 일련의 여러 디테일한 이벤트라고 볼수도 있다.

=> 이러한 것들의 추상화가 Use Case이다.

• Use Case is..
  • Actor와 System 사이에서 수행되는 Function이다.
    • Actor가 수행하는 Function이라고 볼 수 있다.
  • Actor에게 Value를 할당하기도 한다.
  • Actor의 입력으로부터 시작한다.
  • 다양한 Variant Path가 있을 수 있다.
    • 상황에 따라 다른 대처, 또는 Error Handling 등을 위해

~> 하나의 Actor에 대해 Use Case가 3개 있는 예시

~> ATM System 예제 (draw.io 이용)
1) ATM기(System)를 Rectangle로 그린다. (Black Box 상황)
2) Actor를 설정한다. ex) User, Server, Maintenance(유지보수 직원) 등
3) 각 Actor에게 이 System이 어떠한 Service를 제공해야하는가, 그리고 반대로 Actor 입장에서 이 System을 어떤 목적으로 사용하는가 등을 따져 Use Case를 상정

※ Monitor, Keyboard와 같은 Hardware적인 요소들은 Actor로 상정하지 않는 경향이 있다. 즉, 어떠한 SW적인 코드가 필요치 않은 HW적인 요소들은 Actor라고 보지 않는다.

Documenting

  각 Use Case에 대해 아래와 같은 형식으로 문서화를 진행한다.

• Name : Use Case의 이름
• Summary : Use Case를 간단히 설명
• Dependency : 다른 Use Case에 대한 의존성 (include & extend 관계 명시) ★
• Actors : 관련된 Actor들
• Preconditions : Use Case 시작을 위한 조건들
• Description : 기본적인 서비스 Path를 설명
  • Step by Step으로 작성한다. ★
• Alternatives : 특정한 예외적인 대안 Path를 설명
• Postconditions : Use Case가 끝나는 상황들 명시

Ex) Use Case Name: 현금 인출
Summary: 유효한 은행 계좌에서 소비자가 특정 양의 자금을 인출한다.
Actor: ATM 고객
Precondition: ATM이 'Welcome' 메세지를 띄운 상태
Description:
1. 고객이 ATM기 카드 리더기에 카드를 삽입한다.
2. 시스템이 카드를 인식하면, 카드를 읽는다.
3. 시스템이 고객에게 비밀번호 입력을 위한 창을 띄운다.
4. 고객이 비밀번호 PIN Number를 입력한다.
5. 시스템이 카드의 만료 기한과 도난 여부 등을 확인한다.
6. 카드가 유효하면, 서버에 저장된 카드의 비밀번호와 입력된 비밀번호가 일치하는지 확인한다.
7. 비밀번호가 일치하면, 해당 카드가 어떤 계좌에 접근 가능한지 체크한다.
8. 시스템이 화면에 선택 창을 띄운다. : 인출, 입금, 송금
9. 고객이 인출을 누르고, 인출할 양을 입력한다.
10. 시스템이 계좌에 충분한 돈이 있는지 확인하고, 또한 한도 초과는 아닌지 체크한다.
11. 확인이 완료되면, 인출을 허가한다.
12. 현금을 드르르륵 내보낸다.
13. 시스템이 영수증을 출력한다.
14. 시스템이 카드를 제거한다.
15. 시스템이 다시 'Welcome' 메세지를 띄운다.

~> 위와 같은 Use Case Document에 Alternatives를 작성한다면, 다음과 같이 할 수 있다.

Alternatives:
• 6번에서 PIN Number 매치가 안되는 경우, 에러 메세지를 띄우고, 다시 한 번 핀 넘버를 입력하도록 창을 띄운다. 3번 이상 매칭에 실패하면 카드를 제거하고 다시 'Welcome' 메세지를 띄운다.
• 10번에서 돈이 충분치 않다면, 에러 메세지를 띄우고, 인출 양을 다시 입력받는다.
• 10번에서 한도 초과라면, 에러 메세지를 띄우고, 인출 양을 다시 입력받는다.

Use Case Relationship

• Include Relationship : 복수의 Use Case에서 공통된 패턴, 요소를 식별하고, 그 공통 속성을 뽑아내어 'Abstract Use Case'로 만든다.

~> Withdraw Funds, Query Account, Transfer Funds Use Case는 모두 공통적으로 'Validate PIN' 과정을 필요로 한다.
~~> 이를 Abstract Use Case로 만든다!

• include relationship은 다음과 같이 표시한다.
  • 점선 화살표를 사용한다.
  • 선 옆에는 '< < include >>'라는 표시를 함께 해준다.
  • 화살표는 '뽑아낸 공통 속성'을 향한다. 즉, 포함되는 Use Case를 가리키는 것이다.

이때, '포함하는' Use Case를 Concrete Use Case, '포함되는' Use Case를 Abstract Use Case라고 부른다.

Ex) Use Case Name: PIN 유효 확인
Summary: 시스템이 PIN 넘버의 유효성을 확인한다.
Actor: ATM 고객
Precondition: ATM이 'Welcome' 메세지를 띄운 상태
Description:
1. 고객이 ATM기 카드 리더기에 카드를 삽입한다.
2. 시스템이 카드를 인식하면, 카드를 읽는다.
3. 시스템이 고객에게 비밀번호 입력을 위한 창을 띄운다.
4. 고객이 비밀번호 PIN Number를 입력한다.
5. 시스템이 카드의 만료 기한과 도난 여부 등을 확인한다.
6. 카드가 유효하면, 서버에 저장된 카드의 비밀번호와 입력된 비밀번호가 일치하는지 확인한다.
7. 비밀번호가 일치하면, 해당 카드가 어떤 계좌에 접근 가능한지 체크한다.
8. 시스템이 화면에 선택 창을 띄운다. : 인출, 입금, 송금
Alternatives:
• 만약 시스템이 카드를 인식하지 못하면, 카드를 제거한다.
• 만약 카드 기한이 만료되었다면, 카드를 제거한다.
• 도난 신고가 들어온 카드라면, 카드를 제고하고, 경찰에 신고한다.
• 서버의 비밀번호와 입력받은 PIN이 일치하지 않으면, 에러 메세지를 띄우고, 다시 입력받는다.
• 3번의 입력이 모두 실패하면, 카드를 제거하고, 초기 상태 'Welcome' 메세지로 돌아간다.
• 고객이 'Cancel' 버튼을 누르면, 동작을 멈추고 거래를 취소한 후, 카드를 제거한다.
Postcondition: PIN 넘버의 유효성을 검증받았다.

~> 위에서 뽑아낸 'Validate PIN'이라는 Abstract Use Case에 대한 예시 Document이다.

Ex) Use Case Name: 현금 인출
Summary: 유효한 은행 계좌에서 소비자가 특정 양의 자금을 인출한다.
Actor: ATM 고객
Dependency: Include Validate PIN Abstract Use Case (주목) ★★★
Precondition: ATM이 'Welcome' 메세지를 띄운 상태
Description:
1. Include Validate PIN Abstract Use Case
2. 고객이 인출을 누르고, 인출할 양을 입력한다.
3. 시스템이 계좌에 충분한 돈이 있는지 확인하고, 또한 한도 초과는 아닌지 체크한다.
4. 확인이 완료되면, 인출을 허가한다.
5. 현금을 드르르륵 내보낸다.
6. 시스템이 영수증을 출력한다.
7. 시스템이 카드를 제거한다.
8. 시스템이 다시 'Welcome' 메세지를 띄운다.
Alternatives:
• Description의 각 Step에 대한 대안을 적어두면 된다..
• ...
Postconditions: 고객이 현금 인출에 성공한다.

~> Use Case의 Include 관계를 이용하면 위와 같이 좀 더 간편한 Documenting이 가능해진다.
=> 지금까지의 예시를 Diagram으로 표시하면 아래와 같다.

• Extend Relationship : Include Relationship의 정확히 반대 급부에 해당하는 Use Case Relationship이다.

  • Concrete에서 Abstract로 점선 화살표가 향하는 include와 다르게, Abstract에서 Concrete로 점선 화살표가 향한다.

    • 선 옆에는 < < extend > >라고 적어둔다.

  • extend는 include와 다음이 다르다.

    • include는 Concrete가 반드시 사용해야하는 Use Case이다.

    • extend는 Concrete가 Optional하게 사용하는 Use Case이다.

  차이를 알겠는가?