프로젝트 계획(7) - 사용 사례(Use case) [소프트웨어공학]

 

 

 

 

도메인 분석은 문제의 배경을 알고자 하는 것이다. 

또한 도메인은 시스템을 모델링하기 위한 개념적 프레임워크를 제공한다고 했다. 

 

다시 말해서 도메인 분석 자체는 모델을 만드는 것은 아니다.

모델링을 위한 개념 이해화 정보 추출 작업일 뿐이었다. 

 

우리는 모델링 하기 전 단계인 사용사례와 액터를 알아봐야 한다.

 

 

 

---

 

사용 사례란 시스템이 수행할 것으로 기대되는 기능을 말한다. 

시스템 사용자에게 서비스를 제공하기 위한 상호작용의 단위로도 쓰인다.

 

다시 말해서

사용자 또는 외부 시스템이나 기타 요소들이 시스템과 상호작용 하는 다이얼로그를 모델링 한 것이다.

ex) 현금인출기의 현금 인출 시스템과 주고 받는 이벤트의 기록 == 사용사례

 

 

사용사례는 사용자와 시스템 설계자/테스트 프로그래머들이 의사 교환하는데 유용하게 쓰인다.

 

사용자들은 필요한 기능을 설계하였는지를 사용 사례를 통해 확인할 수 있고

개발자들은 사용 사례를 이용하여 필요한 클래스를 고안할 수도 있다

시스템이 구현되었을 때 테스트를 위해 쓰이기도 하고 완성 후에도 쓰인다.

 

결국 모든 단계에서 쓰인다고 말할 수 있다.

 
또한  소프트웨어 개발자와 이해 당사자 간의 계약이라고 할 수 있다.

시스템이 사용 사례에 기술된 대로 동작되어야 한다는 것을 약속한 것이며 이를 만족시킨다면 시스템의 개발은 완료되었다고 본다.

 

 

 

++

사용사례 구축 시 주의 사항

1. 시스템 내부를 모델링 하는 것이 아님

요구를 만족시키기 위해서는 내부도 모델링 되어야 하지만 사용 사례를 작성하는 단계는 외부 관점에서만 본다.

2. 비기능적 요구를 찾아내는 데 효과적인 방법이 아님

시스템의 기능적인 요구에 초점이 맞춰져있다는 것을 명심하자

 

3. 시스템의 흐름도가 아님

제어 흐름을 표시하지 않기 때문에 선후관계를 알 수 없다.

4. 단계적 분할이 아님

구조적 분석에 사용하는 단계적 분할 방법이 아님, 시스템의 의미 있는 목표를 성취하기 위한 동작의 단위임

5. ‘어떻게’가 아니라 ‘무엇을’ 시스템이 하는가

요구 분석을 위한 도구이지 설계를 위한 도구는 아니다.

 

 

 

** 사용 사례를 발견하기 위해서는 요구의 리스트와 도메인 개념을 잘 살펴봐야 한다.

 

 

 

+++ 사용 사례 작성 작업 

 

액터 찾기 >>> 사용 사례 찾기 >>> 사용 사례 사이의 관계 찾기

위 과정으로 만들어진다. 

결과물은 사용 사례 다이어그램과 각 사용 사례의 명세가 나온다.

(용어는 뒤에서 더 자세히 설명하겠다)

 

 

---

그럼 사용 사례 다이어그램부터 알아보자

 

사용 사례 다이어그램은 시스템의 기능을 나타내기 위해 사용자의 요구를 추출하고 분석하는데 사용한다.

 

이전과 같이 이 다이어그램 또한 외부에서 보는 시스템의 동작에 초점을 두고 있다.

 

사용 사례 다이어그램은 사용 사례와 액터(actor)로 구성된다.

 

여기서 사용 사례란 액터에게 보이는 시스템의 기능이다.

 

액터는 시스템과 상호 작용하는 것 사용자나 다른 시스템 또는 환경을 뜻한다.

 

 

 

다시 말해서 액터와 사용 사례를 정하는 것은 결국 시스템의 범위를 정하는 것이다. 

 

어떤 식으로 되냐면??

시스템에 의하여 수행되는 일과 시스템 밖의 환경에 의하여 수행되는 일을 구별하는 것이다.

 

 

**자꾸 범위를 정하는 것이 나오는데, 범위를 정하지 않으면 구분할 수 없고 두루뭉술해진다.

 

 

액터 : Clerk, Manager  사용사례: ren, return, add

 

액터를 더욱 자세히 말하자면 시스템과 상호 작용하는 외부 엔티티이다. 

사용자가 맡은 일 또는 다른 시스템이 액터가 될 수 있다.

 

**액터는 구별되는 이름과 설명이 필요하다. 

 

사용사례는 액터가 볼 수 있는 결과를 내는 이벤트의 집합 또한 다른 사용 사례를 가동시킬 수 있는 것을 말한다.

 

** 액터와 사용 사례가 정보를 교환할 때 "통신"한다고함

 

---

? 그럼 액터가 사람도 될 수 있고 시스템도 될 수 있다는데 어떻게 찾는걸까?

 

**요구 추출의 첫 단계가 액터를 찾는 것이라 한다.

(그래야 시스템의 범위를 정하고 시스템을 개발하는 정보를 얻음)

 

액터를 찾는 질문이 몇가지 있다 알아보자

 

 

 어떤 사용자 그룹이 작업을 수행하기 위하여 시스템의 지원을 받는가?
 어떤 사용자 그룹이 시스템의 주요기능을 사용하는가?
 어떤 사용자 그룹이 유지 보수와 관리 등의 부수적 기능을 사용하는가?
 시스템이 다른 외부 하드웨어나 소프트웨어 시스템과 동작하는가?

 

액터 찾았다 ㅎㅎ

 

 

---

그러면 사용 사례는 어떻게 찾을까??

 

사용 사례는 컴퓨터 시스템을 사용할 때 사용자가 무엇을 하고 경험하는지를 글로 표현한 것이다.

 

** 사용 사례는 소프트웨어를 사용 할 업무나 조직의 프로세스를 기술하는데 사용될 수 있다.

 

사용 사례는 결국 여러 개별 시나리오를 묶어서 일반화한 것이다. 

즉  정상적인 흐름 + 오류, 예외케이스도 모두 사용 사례가 된다.

(시나리오로부터 사용 사례 형성)

 

 

 

시나리오로부터 사용 사례를 형성하는만큼 시나리오는 중요하다.

 

**시나리오는 요구 추출 과정 이외에도 다른 여러 개발 작업과정에 사용된다. 

 

시나리오는 개발자와 사용자가 함께 작성하며

 처음에는 추상적이지만 몇 개의 질문을 던짐으로써 다듬어지고 향상된다.

 

1.시스템이 어떤 작업을 수행하기를 액터가 원하는가?
2. 액터가 원하는 정보는 무엇인가?
3. 누가 데이터를 생성하는가? 데이터는 조작, 삭제될 수 있는가? 이런 작업이 누구에 의하여 행해지는가?
4. 액터가 시스템에 정보를 알리는데 필요한 것은? 얼마나 자주 또 언제 이런 작업이 일어나는가?
5. 액터가 시스템으로부터 정보를 알아내는데 필요한 이벤트는? 이런 사건의 빈도는?

 

이러한 질문에 답을 내기 위해 

우리는 현재의 응용 도메인에 대하여 기술한 여러 문서를 이용

ex)사용자 지침서, 매뉴얼, 표준규격, 사용자 노트, 인터뷰 등

 

**시나리오 작성시 항상 응용 도메인에서 사용하는 용어를 써야 한다.

 

말만 하면 모르니까 완성된 시나리오를 함 보자

 

여기에 쓰인 용어는 응용 도메인 용어다.

 

 

** 이렇게 시스템의 기능을 정의하려고 사용 사례와 시나리오를 사용하는 것은 개발자와 사용자가 요구 사항을 확인하는 과정이다. ( 개발이 한창 진행중이거나 완성 직전에 기능을 추가시킨다는 것은 매우 힘들다)

 

++ 이러한 과정은 소프트웨어가 완성되었을 때 사용자와 고객을 만족시키기 위한 것이다.

 

 

---

사용 사례도 알아봤다. 그렇다. 사용 사례는 엄청 많아질 수 있다.

그렇지만 중구난방으로 아무렇게 펼쳐져있거나 널부러져 있으면 복잡하고 이해도 안된다. 그래서

우리는 사용 사례 관계를 찾아서 위의 문제를 해결하려고 한다.

 

사용 사례 다이어그램에서 사용 사례는 두 가지 종류, 포함 관계, 확장 관계를 가질 수 있다. 

 

확장 관계를 이용하여 정상적인 이벤트와 예외적인 이벤트를 분리하고

포함 관계를 이용하여 사용 사례의 중복을 줄인다.

 

 사용 사례 사이의 중복을 제거함
 어떤 사용 사례가 다른 사용 사례를 포함하는 관계
 공통된 동작을 떼어 낼 수 있다.

 

 

 

 

사용 사례가 일정한 조건 아래 확장된 동작을 포함한다면 다른 사용 사례를 확장하는 관계에 있다.

 

예를 들어서 사용자 정보 입력 중 미성년자를 위하여 부모 허락을 받는 사용 사례가 확장되는 경우

 

 

 

** 기본 사용 사례에서 예외적인 이벤트를 분리시키면 두 가지 이점이 있다.

1. 기본 사용 사례가 더욱 간단해짐

2. 일반적 경우와 예외적 경우를 나눌 시, 개발자는 설계와 구현이 쉬워짐

 

 

사용 사례를 정할 때 원칙을 가지고 나눈다

1. 예외적이며 선택적이며 거의 발생하지 않는 경우는 확장

2. 두 개 이상의 사용 사례가 공유하는 동작은 포함

 

결국 이런 식으로 짜진다.