유스케이스 모델링(Usecase Modeling)
l 개요 및 목적
유스케이스 다이어그램은 시스템 요구사항을 유스케이스 용어로 설명하는 모형이다.
유스케이스 다이어그램은 다음과 같은 목적을 가진다.
· 시스템의 의도된 기능 및 환경 모형으로 고객과 개발자 사이의 합의 및 시스템 개발 전반에 걸쳐 줄거리를 통합하는데 도움을 준다.
· 고객 또는 최종 사용자에게 시스템 행위를 전달한다. 결론적으로 이해하기 쉬워야 한다.
· 사용자 및 시스템과 교류하는 타시스템은 액터이다. 그들은 시스템 사용자를 대표하기 때문에 액터는 시스템의 범위를 정하는데 도움을 주고 예정된 일에 대한 명확한 상황을 제공한다. 유스케이스는 액터의 요구를 기반으로 개발된다. 이것은 사용자가 기대하는 시스템이 될 수 있도록 한다.
l 예시
l 구성 요소
n 유스케이스
유스케이스는 액터에게 의미 있는 결과를 제공해야 하며 시스템이 수행하는 일련의 작업 또는 트랜잭션 단위를 나타낸다. 반드시 액터를 통해서 시작되며 사용자와 시스템의 상호작용에 대한 추상화 된 표현이다.
유스케이스는 타원으로 표시하고 타원의 내부 중앙에 유스케이스명을 기입한다.
n 액터
액터는 시스템과 상호작용하는 사용자, 역할, 타 시스템을 표현하며 대체로 시스템을 사용하는 사용자의 역할을 나타낸다. 액터는 시스템에 능동적이나 수동적으로 정보를 교환한다.
액터는 클래스 사각형에 스테레오 유형으로 “actor”라고 표시할 수 있으나, 일반적으로 사람모형으로 표시하고 하단에 액터명을 기재한다.
액터 |
n 관계
유스케이스 간, 유스케이스와 액터 간, 액터와 액터 간의 관계에는 몇 가지 표준 관계가 존재한다.
l 포함(Include) 관계
포함 관계는 기본 유스케이스에서 포함 유스케이스로 향하는 관계이다. 이것은 기본 유스케이스가 도출된 후 해당 유스케이스의 역할에 관련 있는 공통적인 일의 흐름을 따로 묶어서 명시할 때 사용한다. 따라서 포함 관계로 도출된 유스케이스는 다른 유스케이스에서도 재사용 될 가능성이 높다.
«include»
l 확장(Extends) 관계
확장 관계는 확장 유스케이스에서 기본 유스케이스로 향하는 관계이다. 이것은 기본 유스케이스가 도출된 후 해당 유스케이스의 역할에 관련 있는 추가적인 역할을 명시할 때 사용한다.
l 유스케이스 일반화(Usecase-Generalization) 관계
유스케이스 일반화는 자식 유스케이스에서 부모 유스케이스로 향하는 관계이다. 이것은 자식 유스케이스가 부모 유스케이스에서 설명된 모든 행위 및 특성을 특수화하는 방법을 설명한다.
l 액터 일반화(Actor-Generalization)
자손 액터 유형으로부터 선조 액터 유형으로의 액터 일반화는 자손이 선조가 유스케이스에서 수행하는 역할을 상속 받는다는 것을 나타낸다
l 통신(Communicates) 연관
통신 연관은 액터가 유스케이스와 교류하는 것을 모형화 한다.
n 유스케이스 패키지
유스케이스 패키지는 유스케이스, 액터, 관계, 다이어그램 및 다른 패키지의 집합이다. 유스케이스 모형을 좀더 작은 부분으로 나누어 구조화하기 위해 사용된다.
n 유스케이스 다이어그램
유스케이스 다이어그램은 액터, 유스케이스, 유스케이스 패키지 및 그들 간의 관계를 보여준다.
l 지침 및 고려사항
n 유스케이스 모델링
액터와 유스케이스는 고객과 잠재적인 사용자의 요구사항 수집을 통하여 중요한 정보로서 도출된다. 도출된 액터와 유스케이스에 대한 간단한 설명을 기술한다. 유스케이스가 상세히 기술되기 전에 유스케이스 다이어그램은 모든 유스케이스와 액터가 도출되었는가 그리고 고객이 원하는 것을 제공하는가를 검증하기 위해 고객에 의해 검토되어야 한다.
반복적 개발 환경에서 각 반복에서 상세화되어질 유스케이스의 부분 집합을 선정한다.
액터와 유스케이스가 도출되면 각 유스케이스의 사건흐름이 상세하게 설명된다. 이 설명은 시스템이 액터와 교류하는 방법 및 시스템이 각 개별 사례에서 해야 할 일을 보여준다.
마지막으로 완성된 유스케이스 모델링(유스케이스 설명 포함)은 검토되어지고 개발자와 고객은 유스케이스 모델링을 이용하여 시스템이 해야 할 일에 대한 합의를 한다
n 기능적 분해를 피하는 방법
유스케이스 모델링이 시스템의 기능분해 형태로 만들어지는 것은 일반적이지 않다. 이를 피하기 위해 다음 증상을 살펴본다.
· 작은 유스케이스, 사건 흐름의 설명이 단지 하나 또는 몇 개의 문장을 의미한다.
· 큰 유스케이스, 많은 유스케이스가 수십 이상 수백 문장을 의미한다
· “특정 데이터에 대해 이 연산을 수행한다” 또는 “특정 데이터를 가지고 이 기능을 수행한다” 처럼 구성된 유스케이스 이름, 예를 들어, “ATM 기계에서 PIN(Personal Identification Number)을 입력한다”는 ATM 기계에 대한 분리된 유스케이스로서 모델링되어서는 안 된다. 왜냐하면 어느 누구도 꼭 이러한 방식으로 시스템을 사용하지 않기 때문이다. 유스케이스는 액터에게 가치 있는 어떤 것을 산출하는 완전한 사건흐름이다.
기능 분해를 피하기 위해 유스케이스 모델링이 다음과 같은 질문에 답할 수 있도록 지원하는지 확인해야 한다
· 시스템의 배경은 무엇인가?
· 시스템이 왜 구축되는가?
· 시스템을 사용하여 사용자가 달성하고자 하는 것은 무엇인가?
· 시스템이 사용자에게 부가하는 가치는 무엇인가?
n 비기능적 요구사항
유스케이스는 시스템에 관한 기능적 요구사항을 수집하기 위한 가장 좋은 방법이다. 그러나 비기능적 요구사항은 어떠한가? 그것들은 무엇이며 어디에서 수집되는가?
비기능적 요구사항은 보통 사용성, 신뢰성, 성능, 대치가능성 요구사항으로 분류된다. 그것들은 보통 어떠한 법률 및 규정 요구사항을 준수해야 할 필요성을 기술하는 요구사항이다. 그것들은 또한 사용되는 운영시스템에 기인한 설계 제약사항, 플랫폼 환경 호환성 이슈 또는 적용해야 할 응용 표준이 될 수 있다. 일반적으로 하나 이상의 설계 선택사항을 허용하지 않은 요구사항은 설계 제약사항으로 간주되어져야 한다고 말할 수 있다.
개별 유스케이스에 적용되는 많은 비기능적 요구사항은 그 유스케이스의 프로퍼티(property) 내에 수집된다. 그러한 경우, 비기능적 요구사항은 유스케이스의 사건 흐름 내에 또는 유스케이스의 특별 요구사항으로 수집된다
보통 비기능적 요구사항은 전체 시스템에 적용한다. 그러한 요구사항은 부속 사양서에 수집된다
n What 대 How 딜레마
아주 어려운 것 중 하나는 유스케이스가 어느 정도의 상세수준으로 시작하고 끝나야 하는지를 결정하는 방법을 배우는 것이다. 시스템 특성의 정의는 어디에서 시작하고 유스케이스는 어디에서 시작하여 어디에서 끝나며 설계는 어디에서 시작하는가? 흔히 유스케이스 또는 소프트웨어 요구사항은 시스템의 수행방식(how)이 아니라 시스템이 해야하는 일(what)을 기술해야 한다.
유스케이스 작성자가 자신의 경험에 따라 다른 배경을 사용하여 “what”이라고 생각되는 것과 “how”라고 생각되는 것을 결정하게 될 것이다. 이것은 어떠한 상세사항을 유스케이스 모델링에서 빼야 할지 아닐지를 결정할 수 있는 고려사항이 주어져야만 한다.
n 구체 유스케이스(concrete usecase) 및 추상 유스케이스(abstraction usecase)
구체 유스케이스와 추상 유스케이스 간에 차이가 있다. 구체 유스케이스는 액터에 의해 초기화되고 완전한 사건 흐름을 구성한다. 여기에서 “완전한”의 의미는 유스케이스가 액터에 의해 요청된 전체 연산을 수행한다는 것을 의미한다.
추상 유스케이스는 자체적으로 초기화되지 않는다. 추상 유스케이스는 다른 유스케이스에 포함되거나 다른 유스케이스를 확장하거나 또는 다른 유스케이스를 일반화한다. 구체 유스케이스가 초기화될 때 하나의 유스케이스가 생성되고, 이는 그와 연관된 추상 유스케이스에 의해 기술된 행위를 드러낸다. 액터가 보게 되고 시스템에서 초기화시키는 것이 구체 유스케이스이기 때문에 추상 유스케이스와 구체 유스케이스 사이의 구별은 매우 중요하다.
n 유스케이스 모델 구조화
유스케이스 모델을 구조화하는 이유는 다음과 같다.
· 유스케이스를 좀더 쉽게 이해하기 위해
· 많은 유스케이스 내에 설명된 공통된 행위를 분해하기 위해
· 유스케이스 모델의 유지보수를 좀 더 쉽게 하기 위해
그러나 구조화는 해야 할 첫번째 작업이 아니다. 한 문장의 간단한 설명 이상으로 행위에 대해 좀 더 많이 알 때까지 유스케이스를 구조화하지 않는다. 행위에 대한 정확하고 충분한 이해를 기반으로 결정을 내릴 수 있도록 하기 위해 적어도 유스케이스의 사건 흐름에 대한 단계별 개요를 설정해야 한다.
유스케이스를 구조화하기 위해 3종류의 관계(포함, 확장, 일반화)를 사용한다. 이들 관계는 다른 유스케이스에서 재사용되거나 그 유스케이스의 특수화 또는 유스케이스 조각으로 분해하기 위해 사용한다. 변경을 의미하는 유스케이스는 추가 유스케이스로 불리우고, 변경되어지는 유스케이스는 기본 유스케이스로 불리운다.
· 만약 결과를 산출하기 위해 사용된 메소드가 아니라 단지 결과에만 의존하는 유스케이스의 기능을 나타내는 유스케이스의 한 부분이 있다면, 그 부분을 추가 유스케이스로 분해할 수 있다. 이 추가 유스케이스는 포함-관계를 이용하여 명시적으로 기본 유스케이스에 포함된다.
· 만약, 기본 유스케이스의 일부분이 선택적이라면, 또는 유스케이스의 주요 목적을 이해하는데 필수적이 아니라면,기본 유스케이스의 구조를 단순화하기 위해 그 부분을 추가 유스케이스로 분해할 수 있다. 이 추가 유스케이스는 확장 관계를 이용하여 묵시적으로 기본 유스케이스에 포함된다.
· 만약 행위와 구조에 공통성을 가지고 유사한 목적을 가지는 유스케이스가 있다면 공통 부분은 추가 유스케이스(자식)가 상속을 받는 기본 유스케이스(부모)로 분해될 수 있다. 자식 유스케이스는 부모 유스케이스로부터 상속받은 구조의 기존 행위를 변경하고 새로운 행위를 추가할 수 있다.
액터가 다른 액터를 특수화하는 방법을 보여주기 위해 액터 일반화를 사용할
수 있다.
좀더 낳은 이해를 위해 유스케이스 모델을 조직화하는 또 다른 측면은 유스케이스를 패키지로 그룹화하는 것이다.유스케이스 모델은 계층화된 액터 또는 유스케이스가 있는 “잎(leaf)”을 포함한 유스케이스 패키지로 조직화 될 수 있다.
<< 유스케이스 모델 계층구조 >>
n 유스케이스와 액터 관계
유스케이스의 실행은 하나 이상의 액터와의 통신을 포함한다. 하나의 유스케이스는 항상 시스템에게 무언가를 요청하는 액터에 의해 시작된다. 이것은 모든 유스케이스가 액터와의 통신 연관을 가져야만 한다는 것을 의미한다. 이러한 규칙의 사용은 시스템이 사용자가 필요로 하는 기능성만을 제공하고 다른 어떤 것도 제공하지 않도록 한다. 누구도 요청하지 않은 유스케이스를 가지고 있다는 것은 유스케이스 모델 또는 요구사항에 무언가 잘못되어 있다는 것을 나타낸다.
그러나 이러한 규칙에 대한 몇 가지 예외가 있다.
· 만약 유스케이스가 추상 유스케이스라면 그 행위는 어는 액터와도 교류를 포함하지 않을 것이다. 그러한 경우에는 추상 유스케이스에서 액터로의 어떠한 통신 연관도 없다
· 일반화 관계에 있는 자식 유스케이스는 그의 부모 유스케이스가 모든 액터와의 통신을 설명하고 있다면 자신과 연관된 액터를 가질 필요가 없다.
· 포함 관계에 있는 기본 유스케이스는 포함 유스케이스가 모든 액터와의 통신을 설명하고 있다면 자신과 연관된 액터를 가질 필요가 없다.
· 유스케이스는 일정(예, 일주일 한번 또는 일일에 한번)에 따라 초기화 될 수 있다. 이것은 시스템 시간이 개시자(initiator)라는 것을 의미한다. 시스템 시간은 시스템 내부에 있기 때문에 유스케이스는 액터에 의해 초기화 되지 않고 내부 시스템에 의해 초기화된다. 만약 다른 어떤 액터 교류도 유스케이스에서 일어나지 않는다면 액터와의 어떤 관계도 갖지 않을 것이다. 그러나 명확하게 하기 위해 유스케이스 다이어그램에 유스케이스가 초기화되는 방법을 보여주는 가공의 액터 “시간”을 사용할 수 있다
n 유스케이스 모델 구조화
유스케이스 모델의 개요 설명은 다음 내용을 포함해야 한다.
· 시스템의 주요 유스케이스가 어느 것인지를 기술한다.(시스템 구축 이유)
· 시스템에 대한 중요한 기술적 사실을 요약한다.
· 시스템의 범위를 나타낸다. – 시스템이 하기로 되어 있지 않은 것
· 시스템의 환경을 요약한다. 예를 들어, 목표 플랫폼 및 기존 소프트웨어
· 시스템에서 정상적으로 수행되는 유스케이스를 순서적으로 설명한다.
· 유스케이스 모델에 의해 다루어지지 않은 기능성을 상술한다.
출처 : http://blog.naver.com/hyounge05?Redirect=Log&logNo=110109517317
[출처] 유스케이스 모델링(Usecase Modeling)|작성자 hyounge05