소프트웨어 분석 및 설계 (6) 유스케이스 모델2

- 지난주: 유스케이스 모델1

다른 UML에 비해 중요한 비중을 차지.

 

지금까지 개발자 관점으로 진행, 코딩 구현과 설계에 비중.

취업을 하면 회사에서 어느정도 교육을 해줌 - Associate Architect.

분석에 관한 이야기를 하면서 가장 강조하는게 바로 '유스케이스'.

 

왜 중요한가?

코딩하는 부분에선 큰 문제가 없다고 가정하면 개발자로서 겪는 큰 어려움은 코딩의 문제가 아니다.

Project의 성공의 가장 중요한 부분: 사용자, 발주자, 이해관계자들이 무엇을 요구하는가.

 

needs <-> requirements

왜 분리하는가. 개념을 구분할 필요 있다.

1) needs: 이 사람들이 가지고 있는 문제, 서비스의 니즈. 니즈를 정확하게 찾아내는 것 중요.

니즈의 식별 -> 명세 -> 확인.

2) 시스템 서비스(솔루션)의 영역으로 들어가면 개발자들이 계획해야 한다.

개발해야 할 시스템의 서비스: requirements.

 

유스케이스는 원칙적으로 둘 다 표현 가능하다.

하지만 통상적으로는 분석의 초창기에서 일어나는 것들 - 니즈에서 활용되는 편이다.

시스템 레벨에서 유스케이스를 다시 한 번 그린다.

 

 

 

- 시나리오

키오스크가 올바르게 작동되려면: 디자인한 사람들이 이렇게 작동되리란 시나리오를 가지고 있어야 한다.

시스템과 엑터간의 대화 = 시나리오. 여러 이야기들이 시나리오를 통해 진행.

 

시나리오는 왜 존재해야 하는가?

분석가가 정해둔 스텝들로 진행되면 사용자는 원하는 결과값을 얻을 수 있는가?

 

나중에 Testing을 하게 되는데 그중 기능 테스팅이 있다. 정해진 시나리오대로 실행하여 결과가 나오는지를 확인한다.

 

 

- 시나리오 찾기를 하는 이유: 목적(Goal).

이 사람들은 왜 키오스크 앞에 섰는가.

롤 플레잉. 내가 구매자라면, 키오스크 앞에 선 '목적'을 완수해야 한다.

 

위의 스텝을 통해 유스케이스를 구체화하는 과정을 거친다.

 

 

 

01. 유스케이스의 파악

1) 분석가는 사용자들이 새로운 시스템을 통해 얻고자 하는 목적을 잘 설명할 수 있는 질문을 해야 한다.

2) 유스케이스 파악을 위한 질문들

- 액터는 어떤 용도로 시스템을 사용하려고 하는가?

- 액터는 시스템에 자료 입력 및 저장/변경/제거/참조를 하는가?

- 액터는 외부 이벤트/변화를 시스템에 알려주는가?

- 시스템은 액터에게 어떤 특정한 변화를 알려주는가?

 

3) 유스케이스가 되기 위해서는: '그것이 범위 안에 있는가?'의 질문을 통과해야 한다.

 

직접적인 관련이 없을 것 같으면 - 유스케이스 대상에서 배제한다.

 

4) 기본 흐름의 파악을 위한 질문들

- 어떤 이벤트가 유스케이스를 시작시키는가?

- 유스케이스는 어떻게 끝나는가?

- 어떻게 유스케이스는 특정 행위를 반복하는가?

 

5) 대안 흐름의 파악을 위한 질문들

대안 흐름: 서비스들은 정상적인 상황 뿐만 아니라 비정상적인 상황도 따라가줘야 한다.

- 유스케이스에는 선택적인 상황이 존재하는가?

- 특별한 케이스가 발생할 수 있는가?

- 유스케이스에 변화는 가능한가?

- 잘못될 수 있는 경우는 있는가?

- 잘 발생되지 않는 경우(예외 상황)는 무엇인가?

 

 

- 유스케이스 사례: ECP

 

1. 요구 추출 (enduser, 발주자로부터)

2. 요구의 충돌, 중복, 누각 발생.

ex. 관리부서와 판매부서의 요구가 서로 충돌한다면?

1) 충돌 - 판매부서(마케팅부서)는 공격적으로 마케팅해야 하기 때문에 신규 회원들에게 마일리지 보너스를 권장.

관리부서는 그렇게 하면 재정이 바닥난다면서 반대.

2) 중복 - A, B, C로부터 받은 요구가 중복됨.

3) 누락 - 그 사람들이 사용해야 하는 기능 자체가 사라짐.

 

Inventory는 checkout할때 개입. 재고가 그만큼 없다면 거절.

3개의 엑터와 7개의 유스케이스를 식별.

 

Shopkeeper - 제품 관리.

Administrator - 로그와 유저를 관리한다.

Dispatcher - 발송 부서 사람들은 주문이 끝났다면 시스템에서 완전히 내린다. 

 

 

1. 액터의 일반화

- 사용시점: 두 액터가 공통된 행위를 통해 커뮤니케이션 할 경우.

- 의미: 자식 액터는 부모 액터가 갖는 유스케이스와의 관계와 역할을 그대로 상속받는다.

 

즉, 상속.

SalesAgent는 옆에 있는 것만 사용할 수 있지만 - 특정 상황에선 Purchaser가 할 수 있는 일도 할 수 있다.

혼란을 빚을 수 있을때 상속을 통해 표현한다.

잘 사용하지는 않는다.

 

 

 

02. 유스케이스 다이어그램의 확장

1) 유스케이스 일반화: 더 일반적인 유스케이스와 더 특정한 유스케이스의 일반화 관계를 표현할때 사용.

2) 유스케이스의 포함 <<include>>: 다른 유스케이스의 행위를 자신의 유스케이스에 포함하고자 할 때 사용.

3) 유스케이스의 확장 <<extend>>: 다른 유스케이스의 특정 부분을 자신의 유스케이스에 확장하고자 할 때 사용.

 

 

1. 유스케이스의 일반화

: 자식 유스케이스는 부모 유스케이스의 모든 특징을 상속받는다.

더하여 필요 부분을 추가할 수 있으나 재정의는 제한적으로 허용된다.

 

1) 부모 클래스는 추상적인 부분에서 서술된다 - 모든 행동이 완성적일 필요는 없다.

2) 자식 클래스에서 모든 것이 구체적/완성적으로 서술되어야 한다.

 

다이어그램을 간략하게 표현할때 사용.

일반적인 경우와 특수한 경우를 구분해서 사용해야 할 때 사용.

 

CD를 검색하던, Book을 검색하던 - FindProduct로 확장될 수 있다는 뜻.

 

 

2. 유스케이스 포함 <<include>>

: 재사용의 개념. 반복되어 서술되는 유스케이스가 있는 경우, 간결한 서술을 하기 위해 사용.

포함을 사용하는 유스케이스는 클라이언트, 포함을 제공하는 유스케이스는 제공자 역할. 

 

- 코딩할때: #include< >

의미: < >에 있는 라이브러리를 가져와서 재사용하려고 할때.

 

* 유스케이스는 방향성이 없다.

그렇다면 방향성의 의미는 무엇인가? 시나리오를 보면 데이터가 나간다 - 들어간다를 의미한다.

<<include>>를 한다고 포인팅을 해주는 것이 점선 화살표.

 

 

3. 유스케이스 확장 <<extend>>

: 기존의 유스케이스의 행위를 확장/추가시키는 용도로 사용한다.

기존의 유스케이스는 확장 유스케이스가 포함될 지점을 의미하는 확장점을 제공한다.

 

대출기간을 넘긴 사람이기 때문에 벌금을 내야 할때의 유스케이스.

<<extend>>로 확장.

점선 화살표가 include와 반대방향.

표현하고자 하는 바가 벌금이기 때문에.

 

 

 

- 유스케이스 확장 버전.

 

장바구니에 아이템을 추가하기 위해서는 장바구니를 봐야한다.

장바구니를 관리하는 것은 <<extend>>는 Dispaly에서 파생-확장.

 

Flow chart가 되는 것을 방지하기 위해서라도 선을 긋는건 조절해야 한다.

그러한 흐름들은 여기에 표현하지 않는다. 사용자라는 것은 흐름을 가질 필요가 없다.

1) 사용자는 모든 하나하나의 행동을 독립적으로 실행시킬 수 있다.

2) 그러한 흐름을 표현하는건 따로 있다.

3) 그래도 표현할 필요가 있다 -> 회원 자격이 있는 사람만 아래를 할 수 있다고 했을 때: 어떻게 표현해야 할까?

Pre condition, post condition을 설정해준다.

이때 순서 정보는 Pre condition에서 포함하고 있으면 된다.

 

AcceptPaymentByCard에 <<include>>를 통해 Customer도 연결되어 있는 게 맞다.

4개의 엑터가 달려있다.

 

 

 - 또다른 예시

 

 

 

03. 유스케이스 구성의 선행조건/종료조건

 

1) Pre-condition: 유스케이스를 시작할때 충족되어 있어야 하는 조건.

이 조건이 항상 True로 적용되어 있음을 가정된 상태에서 시작한다.

 

2) Post-condition: (1) 원하는 음료, (2) 정확한 잔돈의 조건이 충족되어야 만족스러운 성공.

즉, 맞는 결과인지를 확인하는 조건이다.

 

선조건, 후조건, 기본흐름 - 이러한 명세의 확인과 검증을 사용자, 발주자가 확인해줘야 한다.

 

+ 대안흐름: 사건들을 나열. 시스템은 여기에도 대응해야 한다.

이것 또한 담당자가 알려줘야 한다.

 

 

 

04. 유스케이스의 서술 형식

유스케이스는 논리의 흐름에 따라 다음으로 나뉜다.

- 기본형

- If 분기형

- Alternative 분기형

- For 루프형

- While 루프형

- 혼합형

- 시나리오 분리형

 

1. 유스케이스 형식 - Basic

모든 유스케이스에는 식별번호가 있다.

 

 

2. IF 분기

 

종료 후의 상태) 장바구니가 업데이트 '한 것이' True로 확인되었습니다.

Action이 아니라 Condition.

 

IF문에서 주어가 두개가 등장한다. Customer와 System이 대화한다.

Customer이 무엇을 하는지, System이 다시 무엇을 제공하고 있는지. 둘을 구분하고 서술한다.

 

 

3. Alternative 분기

 

중요! 어떤 때라도 고객은 시스템/장바구니를 빠져나갈 수 있다는 것을 말한다.

 

 

4. For 반복

 

시스템은 반복된다. 제품을 보여주고/디테일을 보여주고/가격을 보여주고.

 

 

5. 대화형

 

시스템 - 고객의 반응(대화)를 알기 쉽게 구분했다.

 

 

 

- 유스케이스 <<include>> 예시

 

Include <- 다른 유스케이스에 있는 덩어리를 인클루드 하라는 의미.

 

 

- 유스케이스 <<extend>> 예시

 

overdueBook

(1) IF 표현을 사용할수도 있고

(2) Extension으로 따로 빼낼수도 있다.

 

- 이 둘은 무슨 차이가 있는가?

벌금을 부과하는 것은 큰 흐름중의 하나이며 빈번하다면, 뛰어넘지 않고 집어넣는다.

벌금 부과라는 업무가 과정에서 생기는 파생적인 별도의 업무 단위라고 판단한다면 - 업무에 독립적인 덩어리로 분리.

 

무엇이 옳은지는 그때그때 다르다.

발주자가 스텝중의 하나라고 생각한다면 전자, 따로 관리되어야 한다고 생각한다면 분리해서 후자.