소프트웨어 공학 - [제10강] 유스케이스 다이어그램 및 명세

소프트웨어 공학 - [제10강] 유스케이스 다이어그램 및 명세

주요용어

유스케이스: 사용자 입장에서 시스템의 동작을 기술한 시나리오. 시스템의 유사 기능을 나타내는 모든 시나리오들을 구조적으로 표현함.

유스케이스 다이어그램: UML 다이어그램의 하나로 시스템 외부의 액터와 시스템이 제공하는 기능을 표현하는 유스케이스를 추상화하여 표현한 그림

요구사항: 문제 해결이나 목적 달성을 위해 사용자가 필요로 하는 조건이나 능력

요구사항 분석: 자연어로 작성된 요구사항이 정확하고 완전하며 일관성이 있는지 검토하여 수정하는 작업

유스케이스 분석: 자연어로 작성된 요구사항을 유스케이스를 사용하여 구조화한 후 이것을 보다 정형화하고 구체화하는 작업

유스케이스 분석의 개요

유스케이스

사용자가 본 시스템 동작에 관한 시나리오

액터와 시스템간의 상호작용을 이벤트 흐름으로 기술

사용자 관점에서 시스템을 모델링하기 위한 도구

완성될 목표 시스템의 겉모습을 설명하는 것

시스템 외부의 관점으로 시스템의 내부 구조나 구현 방법을 기술하는 것이 아님

사용자 요구사항을 구조화하여 표현한 것

사용자 요구사항은 일반적으로 자연어로 기술됨

유스케이스 분석은 구조적이지 않은 방법으로 확보된 사용자 요구사항을 재정리하는 과정

UML

UML은 객체지향 분석과 설계를 위한 표준 표기법

1990년대 객체지향 방법론/표기법/도구의 난립

프로세스는 환경과 상황에 따라 바뀌므로 표준의 제정이 어려움

표기법은 표준이 존재할 수 있으며 공통의 의사소통 수단이 됨

UML은 방법론이 아닌 표기법, 즉 모델링 언어임

OMG는 1997년에 UML 1.0을 발표하였고 2015년에 2.5를 발표함

4+1 뷰

UML 모델들을 관점이 따라 분해하는 방법

다양한 관점을 표현하는 여러 다이어그램이 존재함

논리 뷰

기능 관점에서 시스템의 구성과 구성요소들 간의 상호작용을 추상화하여 표현하는것으로

클래스 다이어그램, 시퀀스  다이어그램, 상호작용 다이어그램

프로세스 뷰

시스템의 실행에 초점을 맞추어 내부의 작업을 시각적으로 표현하는 것으로 액티비티 다이어그램, 상태 머신 다이어그램,

개발 뷰

프로그래머 관점에서 시스템의 아키텍쳐를 이루는 각 계층에서 시스템의 모듈들과컴포넌트들의 구성을 표현하는 것으로 

패키지 다이어그램, 컴포넌트 다이어그램

물리 뷰

앞의 세 관점에서 표현된 시스템 설계 결과가 실세계 개체들로 어떻게 연결되는지 표현하는 것이며 최종적 시스템의 배치를 보여주는 

배치 다이어그램

유스케이스 뷰

외부에서 본 시스템의 기능을 표현하는 것으로 다른 네 가지 뷰의 기초가 됨

유스케이스 분석의 필요성

프로젝트 초기 단계에서 목표 시스템을 정확히 이해하고 세부 기능을 파악해야 함

사용자와의 의견 차이를 좁히고 변경의 여지를 줄이는 과정

유스케이스 분석의 결과는 유스케이스 다이어그램과 유스케이스 명세로 표현

장점

작업을 유스케이스로 구분하여 팀에 할당함

시스템의 기능에 관한 시나리오를 이해하면 관리에 도움을 줌

테스트 케이스 작성을 위한 기준을 제시

요구사항 분석

유스케이스 분석 전에 자연어로 된 사용자 요구사항을 분석하는 일

구조화보다는 정확성, 완전성, 일관성 등을 검토

유스케이스 분석의 첫 번째 단계는 목표 시스템과 상호 작용하는 개체를 찾는 일

액터는 요구사항에서 명사로 표현됨

액터

표기법

스테레오 타입은 요소의 의미를 명확히 하기 위해 사용되는 UML 확장법으로 키워드를《...》로 감싸 표현함

자주 사용되는 스테레오 타입을 아이콘으로 표시하거나 액터의 경우 막대 인간(아이콘)으로 표현

액터 찾기

액터의 의미

구현 대상은 아니며 외부에서 시스템과 상호 작용하는 개체로 시스템을 사용하는 사람이나 외부 시스템

액터찾기

시스템과 상호작용하나 그 자체에 대한 분석이 필요없는 개체

사용자 외에도 관리자, 유지보수자, 시스템과 관련 있는 모든 사람이나 시스템이 고려 대상임

액터의 관계

액터들 간에는 일반화(또는 상속) 관계가 존재할 수 있음

공통의 요구사항을 가지는 여러 액터들을 일반화시켜 모델을 단순화하기 위한 것

속이 빈 삼각형을 가진 실선으로 일반화 관계를 표현함

유스케이스

표기법 과 유스케이스의 의미

대개 타원으로 표현함

유스케이스의 의미

시스템 사용에 관한 시나리오를 나타내는 것

시나리오는 일련의 사건의 흐름으로 표현됨

성공적 유스케이스만을 의미하는 것은 아님

유스케이스는 유사 기능을 표현하는 모든 시나리오를 포함하여 일반화하고 구조화시켜 표현한 것

사용자 관점에서 명세되었을 때 요구사항을 검증할 수 있는 기준이 됨

유스케이스의 이름은 타원의 안에 두며 동사로 시작함

유스케이스와 액터와의 관계

액터와 유스케이스를 선으로 연결

유스케이스를 시작시키는 액터로부터 유스케이스로 화살표가 향함

결과를 제공하는 유스케이스로부터 제공받는 액터로 화살표가 향함

왼쪽에 유스케이스를 시작시킨 액터를, 오른쪽에 결과를 받는 액터를 둠

양방향의 경우는 화살표를 생략함

유스케이스  간의 관계

《include》

두 유스케이스에서 중복되는 기능이 있는 경우 중복된 부분을 별도의 유스케이스로 분리

점선의 화살표를 사용하며 소스 유스케이스에서 공통 유스케이스로 향함

분리된 유스케이스로 만들면 유지보수성과 재사용성이 증가함

《extend》

특정 조건에서 선택적으로 사용되는 시나리오를 분리

점선의 화살표를 사용하며 확장 유스케이스로부터 기본 유스케이스로 화살표가 향함

《include》 관계의 경우와 화살표 방향이 반대임

《generalize》

전체적인 흐름은 동일하나 일부에서 구체적인 방법이나 내용이 틀린 경우

자식 유스케이스는 부모 유스케이스에서 사용되는 흐름과 일치함

예로 사용자 인증 유스케이스가 부모가 되며 아이디/암호, 지문 인식, 홍채 인식을 사용한 인증을 자식 유스케이스로 둠

시스템 경계

시스템 경계의 표시

시스템 내부에 존재하는 유스케이스 집합을 사각형 안에 위치시키며 분석과 설계를 통한 개

발이 필요한 부분을 나타냄

액터들을 사각형 외부에 위치시킴

사각형 상단에 시스템의 이름을 표시

유스케이스 명세

유스케이스 다이어그램과 명세

유스케이스 다이어그램

액터와 유스케이스 및 이들 간의 관계를 요약적으로 표현

요구사항을 구조화하고 고객과의 원활한 의사소통을 위한 수단

유스케이스 명세

유스케이스 다이어그램만으로는 구체적이지 못하므로 상세한 설명을 추가하기 위해 유스케이스 명세를 작성함

시나리오의 구체적 사건 흐름을 텍스트 형식으로 기술한 것

유스케이스 명세의 구성

유스케이스 이름, 참여 액터들, 요약 설명, 선행 조건, 기본 흐름, 대체 흐름, 종료 조건, 특수 요구사항

기본 흐름

원하는 목적을 달성하는 성공적 시나리오로 번호와 제목을 달아 구조적으로 작성

        대체 흐름

기본 흐름과 벗어나는 다양한 상황을 기술하는 것으로 기본 흐름의 번호를 이용하여 다른 상황을 기술하거나, 제목을 사용하여 요약된 시나리오로 기술함

특수 요구사항

시간, 성능, 품질 등과 관련된 비기능 요구사항을 기술한 것으로 도메인 요구사항이나 UI 들에 관한 요구사항을 자유롭게 기술

요구사항 명세 팁

유스케이스 분석은 유스케이스 다이어그램을 보완하는 추가적 설명을 텍스트로 제공함

유스케이스 상세화 과정에서 초기에 발견하지 못했던 액터나 시나리오들을 발견할 수 있음

고객과 반복적으로 의사소통함으로써 이전 작업의 수정을 통해 유스케이스 모델에 정확성을 가하게 됨

01
다음 중 UML에 관한 설명으로 잘못된 것은?
1 객체지향 시스템 개발을 위한 표준 방법론이다.
2 비영리 컨소시엄인 OMG에서 관리한다.
3 사실상 표준의 통합 모델링 언어이다.
4 다른 사람과 소통할 수 있는 메커니즘을 제공한다.
정답 | 1
해설 | 방법론은 환경과 상황에 맞춰 적용되므로 표준을 제정하기 어렵다. OMG는 객체지
향 기술에 관한 표준을 연구하고 제정하는 단체로 UML 표준을 관리한다. UML의 현재 버
전은 2.4이다.
02
다음 UML 다이어그램 가운데 요구 분석 단계에서 사용하는 것으로 보기 힘든 것
은 무엇인가?
1 클래스 다이어그램
2 유스케이스 다이어그램
3 컴포넌트 다이어그램 4 시퀀스 다이어그램
정답 | 3
해설 | 컴포넌트 다이어그램은 프로그래머 관점에서 소프트웨어 내부의 물리적 구성을 보
여준다. 컴포넌트의 대표적 예는 자바의 jar 파일이나 닷넷 환경에서 dll파일이다.
03
유스케이스에 관한 설명으로 잘못된 것은?
1 사용자 요구사항을 찾고 기록하기 위한 것이다.
2 목적 달성을 위해 시스템을 사용하는 시나리오이다.
3 시스템의 기능성과 환경을 표현한다.
4 소프트웨어에 필요한 객체와 속성을 나타낸다.
정답 | 4
해설 | 속성과 오퍼레이션으로 동일한 부류의 객체들을 추상화한 것은 클래스이다. 클래스
들과 그들 간의 관계는 클래스 다이어그램으로 표현된다.
04
‘OpenAccount’와 ’OpenChildAccount’라는 유스케이스가 있다고 할 때, 이 둘의
관계로 적당하지 않은 것은?
1 포함 관계 2 상속 관계
3 확장 관계 4 일반화 관계정답 | 1
해설 | 여러 유스케이스들에서 사용되는 공통의 기능을 분리할 때, 소스 유스케이스는 공통
유스케이스를 포함한다고 한다. ‘OpenChildAccount’는 성년이 아닌 미성년자의 계좌를 개
설하는 특수한 경우이며 이것을 재사용될 수 있는 공통의 기능으로 보기 어렵다.
05
유스케이스 다이어그램에서 표현되는 것이 아닌 것은?
1 유스케이스 2 액터
3 시스템 범위 4 클래스들 간의 관계
정답 | 4
해설 | 유스케이스 다이어그램에서는 액터나 유스케이스들 간의 관계가 표현될 수 있다.
06
UML 스테레오 타입에 관한 설명이 아닌 것은?
1 UML 요소의 의미를 바꾸거나 명확하게 하기 위한 방법이다.
2 《parallel》와 같이 키워드를 《
》로 감싸 표현한다.
3 스테레오 타입 대신에 특별한 아이콘을 사용하여 표현할 때도 있다.
4 몇 개의 특별한 UML 요소들에만 적용할 수 있다.
정답 | 4
해설 | 거의 모든 UML 요소에 스테레오 타입을 적용할 수 있다.
정리하기
01
UML의 4+1 뷰에서 가장 기초가 되는 것은 무엇인가?
유스케이스 뷰는 사용자가 요구하는 기능을 표현하기 위한 것으로 나머지 네 가지 뷰는 유
스케이스 뷰에 종속적이다. ‘4+1’이라 표현하는 이유도 그러하다.
02
유스케이스 다이어그램에서 액터의 의미를 설명하라.
액터는 시스템과 상호 작용하는 사람이나 외부의 시스템이다. 시스템을 시작시커나 시스템
의 기능을 활용하여 혜택을 받는 개체이다.
03
유스케이스는 재사용될 수 있다. 유스케이스를 구성하는 하나의 진행 과정에서 다
른 유스케이스를 사용하는 것을 의미하는 유스케이스 간의 관계는 무엇인가?
중복성을 제거하고 유스케이스의 재사용을 위해 공통 유스케이스를 소스 유스케이스로부터
분리한다. 포함 관계는 점선 화살표로 표시되며 화살표 위에 《include》
라는 표시를 한다.
04
자연어로 사용자 요구사항을 표현하는 것과 비교하여 유스케이스 다이어그램과 유
스케이스 명세를 사용하는 방법의 장점은 무엇인가?
유스케이스 다이어그램을 작성하면 전체 시스템을 추상화하여 파악할 수 있고 액터와 유스
케이스 간의 관계를 통해 개발해야 하는 시스템의 범위를 명확히 할 수 있다. 유스케이스
명세는 사용자 요구사항을 구조화한 것으로 보다 정형적인 분석을 가능하게 하고 고객과의
원활한 의사소통을 위한 수단을 제공한다.
05
유스케이스 명세를 작성할 때 포함하는 항목들은 무엇인가?
시나리오의 사건 흐름을 표현하는 방식은 다양할 수 있으나 일반적으로 유스케이스의 이름,
참여 액터, 요약 설명, 선행 조건, 종료 조건, 기본 흐름, 대체 흐름, 특수 요구사항 등으로
구성된다.

다음 중 UML에 관한 설명으로 잘못된 것은?

• 1 객체지향 시스템 개발을 위한 표준 방법론이다.
• 2 비영리 컨소시엄인 OMG에서 관리한다.
• 3 사실상 표준의 통합 모델링 언어이다.
• 4 다른 사람과 소통할 수 있는 메커니즘을 제공한다.

확인

정답 및 해설

정답입니다.

정답 : 1번

방법론은 환경과 상황에 맞춰 적용되므로 표준을 제정하기 어렵다.
OMG는 객체지향 기술에 관한 표준을 연구하고 제정하는 단체로 UML 표준을 관리한다.
UML의 현재 버전은 2.5이다. 

다음 UML 다이어그램 가운데 요구 분석 단계에서 사용하는 것으로 보기 힘든 것은 무엇인가?

• 1 클래스 다이어그램
• 2 유스케이스 다이어그램
• 3 컴포넌트 다이어그램
• 4 시퀀스 다이어그램

확인

정답 및 해설

정답입니다.

정답 : 3번

컴포넌트 다이어그램은 프로그래머 관점에서 소프트웨어 내부의 물리적 구성을 보여준다.
컴포넌트의 대표적 예는 자바의 jar 파일이나 닷넷 환경에서 dll파일이다. 

유스케이스에 관한 설명으로 잘못된 것은?

• 1 사용자 요구사항을 찾고 기록하기 위한 것이다.
• 2 목적 달성을 위해 시스템을 사용하는 시나리오이다.
• 3 시스템의 기능성과 환경을 표현한다.
• 4 소프트웨어에 필요한 객체와 속성을 나타낸다.

확인

정답 및 해설

정답입니다.

정답 : 4번

속성과 오퍼레이션으로 동일한 부류의 객체들을 추상화한 것은 클래스이다.
클래스들과 그들 간의 관계는 클래스 다이어그램으로 표현된다. 

'OpenAccount'와 'OpenChildAccount'라는 유스케이스가 있다고 할 때, 이 둘의 관계로 적당하지 않은 것은?

• 1 포함 관계
• 2 상속 관계
• 3 확장 관계
• 4 일반화 관계

확인

정답 및 해설

정답입니다.

정답 : 1번

여러 유스케이스들에서 사용되는 공통의 기능을 분리할 때, 소스 유스케이스는 공통 유스케이스를 포함한다고 한다. 'OpenChildAccount'는 성년이 아닌 미성년자의 계좌를 개설하는 특수한 경우이며 이것을 재사용될 수 있는 공통의 기능으로 보기 어렵다. 

유스케이스 다이어그램에서 표현되는 것이 아닌 것은?

• 1 유스케이스
• 2 액터
• 3 시스템 범위
• 4 클래스들 간의 관계

확인

정답 및 해설

정답입니다.

정답 : 4번

유스케이스 다이어그램에서는 액터나 유스케이스들 간의 관계가 표현될 수 있다.