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

*  relation 과 attributes는 무슨 차이가 있는가.

 

속성는 보관되어야 하는 정보이다.

속성은 클래스 자체의 특징이기도 하다. 이름, ID, 부서, 업무내용, 소속부서 등의 기본적인 정보가 된다.

이때 Employee의 Department(부서정보)는 따로 클래스로 정의할 수 있다.

 

이 둘은 어떤 관련이 있을까? 어떻게 정의하는게 좋을까.

Employee assorted to Department(속성 취급) 와 Employee -- Department(관계 형성) 중에서 무엇을 선택해야 하는가.

 

관계도 어떤 관점에서는 Attribute(정보)이며, 양쪽 클래스를 모두 거치는 정보이다.

결국 Attribute는 고유한 정보이고, 관계는 양쪽에 걸친 정보이다.

후자는 속성으로 정의할 것이 아니고 관계로 정의해야 한다.

 

 

 

01. 속성과 연관의 구분

어떤 정보가 한 클래스와 다른 클래스와의 관련을 나타내는 경우, 클래스 속성 대신 두 클래스 간의 연관으로 표현하는 것이 바람직하다.

 

즉, 두 클래스의 공통적인 특성을 설명하는 부분이 있다면, 속성에서 지워버리고 관계를 설정한다.

 

 

개별적인 클래스들의 집단으로 봤지만 연결관계가 형성되어 있는 경우이다.

relation이라는 것은 class간 meaning이다.

 

 

1. 단방향 연관의 표현

한 사람의 영업담당자는 여러명의 고객을 관리한다. 

방향성이 설정되었다는 것은?

영업담장자의 속성을 보면 private으로 고객의 객체를 가지고 있으며, 계약설명을 할 때 고객의 정보를 습득하고 활용한다.

= 고객의 정보를 attribute로 가지고 있다는 것.

 

아까의 관계연결을 보면, 보유하고 있던 속성이 사라지면서 관계가 연결된것을 볼 수 있다.

그것의 연장선으로, 호출하는 쪽에서 책임을 가진다.

 

 

* 모델은 문제 영역에서 일어나는 비즈니스 활동을 굉장히 비슷하게 반영하고 있어야 한다.

각각의 클래스의 활용은 그대로 비즈니스 환경을 재현해야 한다.

비즈니스 활동은 시스템 시뮬레이션으로 구현되어야 한다.

이것을 모델링이라는 활동으로 표현한다.

 

문제가 무엇인지를 이해하면 모델링으로 표현한다. 맞다면 프로그래밍 언어로 구현한다.

 

클래스 쪽을 이런 관점으로 바라봐야 한다.

구현 때까지 이 관계는 계속 업그레이드 된다.

모델링 설계(디자인)은 알고리즘, DB, 다이어그램 등으로.

 

 

! 방향이 변했을떄는?

 

고객은 영업담당자로부터 보험금액, 보험료 등을 받아야 한다고 하자.

이 방향으로 보자면 영업담당자가 고객에게 할 일이 없다.

 

=> 함부로 표현할 게 아니구나?

즉, 분석은 굉장히 신중하게 진행해야 한다.

실제로 현업에서 분석팀에 들어가면 화살표 방향조차 의미가 있다는 것을 미싱해서는 안 된다.

모델과 코딩은 연결되어 있다!

 

 

 

02. Use case와 UML

좋은 모델링 기법은 방대하고 복잡한 정보를 효과적으로 다루는 사고수단을 제공한다.

 

* UML을 공부하다 보면 드는 생각: 이거 몰라도 다 잘했는데 진짜 이거 해야 하나? 회사에서 이 정도로 활용하나?

회사마다 다르다. UML을 분석부터 쓰기도, 설계부터 쓰기도, 아예 쓰지 않기도 한다. 하지만 대기업은 전부 UML을 사용한다고 봐도 이해에 부족함이 없다.

 

- UML을 만든 세 사람.

미국에서 활동하던 컨설턴트들. 자신들만의 메소드를 보유하고 있었다.

부치 메소드, OMT, OOSE - 세가지를 합친게 UML.

 

 

- Actor 배우 - Scenario 시나리오에서 유래한다.

 

- 초창기에는 Use case에 거의 관심을 가지고 있지 않았다. 클래스부터 쓰고 코딩에 들어간 시대에 더 부적합 - 객체지향 방법론과 연결되어 있지도 않았다.

그러나 지금에 와서는 거꾸로 시작할때 Use case부터 쓰고 들어간다.

 

- 특이한 발상의 전환인 모델링이다. 왜?

모델링에는 크게 세 가지의 부류가 있다.

 

- 구조 모델 Structure Model

속성으로 구성된 데이터들에는 무엇이 있나. (데이터=클래스) 그들은 관계를 통해서 특정한 meaning을 가진다.

(우리가 지금까지 진행한 것)

- 행위 모델 Behavior Model

따로 모델을 만든다. 누가, 언제, 무엇을 하는지.

(위에서 설명된 것)

+ 두가지 모델이면 충분할 줄 알았는데 중요한 게 미싱되고 있었다.

개발자 위주의 개발을 하면 실패한다고 한다. 왜? 솔루션을 할때는 가장 중요한 '사용자', '발주자'가 있었으니까. 

- 기능 모델 Functional Model

개발자들은 내가 개발한것은 옳고 사용자도 마음에 들 것이란 착각을 하지만 전혀 아니다. 많은 경우 실패하는 이유는 내가 만들고 싶어하는 것을 만들었기 때문에. 이 사람들이 원하는 것이 무엇이지?

-> 사용자들의 요구사항에 대한 문서 필요.

 

 

1. Use cases가 왜 중요한가?

1) 사용자들의 시각에서 시스템을 어떻게 보는지를 캐치하는 모델.

2) 유저들은 시스템이 어떻게 사용되기를 의도되고 만들어졌는지 알기가 어렵다. 이게 진짜 내가 의도했던건가? 내가 바랐던건가? 알 수 없다! 현실적로는 정확히 추측하는게 쉽지 않다.

-> 유스케이스는 아이디어에 사용자들을 초기부터 포함시킨다. 계속해서 피드백을 받아 이게 원하는 것이라는 동의를 얻는 것은 매우 중요한 일이다.

3) 비즈니스 시스템이 어떻게 환경과 상호작용하는지를 알려주는 공식적인 자료이다.

-> 우리는 비즈니스란 말을 할 때는 구현을 완전히 잊어버려야 한다. 실제 협업에서 분석이 진행될때는 객체가 개입될 여지는 없다.

 

 

2. "이해관계자"와 유스케이스

 

- 이해관계자의 범주

(1) 사용자, (2) 발주자, (3) 개발자. 이 셋의 공통점은 전부 사람이다.

그런데 어떤 시스템은 다른 것과 상호작용하면서 작동한다. 이때 그것도 '이해관계자'라고 한다.

단지 사람뿐만이 아니라 (4) 다른 시스템도 이해관계자이고, (5) 다른 장치도 이해당사자이다.

<- 를 'Actor' 이라고 말한다.

 

Q. 네비게이션의 이해관계자를 찾아보도록 하자.

A. (1) 운전자, (2) 지도제공자(지도를 지속적으로 업데이트 받아야 한다), (3) GPS(신호를 받아서 길을 확정)

우리가 하는 키오스크의 이해관계자에도 카드사가 들어가야 한다. 결제를 받을때 필요해지니까.

 

 

1) 이해관계자 관점의 유스케이스

- 이해 관계자 중 일차 액터는 '어떤 목표를 달성하기 위해' 시스템과 상호작용한다.

유스케이스의 단위는 목적(Goal)이다. 정제해야 한다.

- 일차 액터에 대한 시스템의 응답으로 '다양한 조건'하에 있는 시스템을 서술한다.

* 이때 액터는? 극에서 주인공이 메인이고, 그들을 일차 액터라고 말한다. 

키오스크에서 내가 주문하려는 음료가 없는 경우, 카드 결제가 불가능한 경우, 세트로 주문하려는 경우 등.

다양한 환경 존재 - 유스케이스의 서술 대상.

- 시스템 이해관계자 간의 계약을 행위 중심으로 파악한다.

 

2) 시나리오는 이해관계자를 보는 창

: 특별한 요청과 조건에 따라 서로 다른 일련의 행위/시나리오가 전개된다.

시나리오는 특정 시각에서 기능을 바라보는 것이다.

목적을 달성하는 방법을 기능으로 본다.

 

3) 유스케이스는 외부사용자관점에서 시스템을 보는 것이다.

즉, 개발자가 아닌 사용자가 시스템을 보아야 한다. 

 

 

3. 유스케이스의 정의

: 특정 액터가 관찰할 수 있는 시스템의 수행 결과 값들을 생성하는 일련의 엑션을 명세한다.

1) 특정한 액터: 개별 사람, 기계, 소프트웨어 등 - 액션을 유발하는 주체.

2) 관찰할 수 있는 결과값: 가장 중요한 항목 중 하나.

ex. 관리인이 점검버튼을 누른다(액션) -> 무엇을 관찰해야 한다? : '누르면 시스템 버튼의 불이 들어온다.'

 

 

* 커피뽑기 - 시나리오.

주어 "사용자/고객"

0) 시스템은 ready 상태이다.

1) 음료를 결정한다. (시스템과는 무관, 사용자의 머릿속에서 결정) - 빼버린다. 

1) '고객은' 1000원을 투입한다. -> 투입한 행동에 따른 관찰은 아래로

2) '시스템'은 투입금액을 표시한다. 

3) '시스템'은 선택 가능한 음료를 ON시킨다.

4) '고객'은 음료 버튼을 선택한다.

5) '시스템'은 선택한 음료를 배출한다.

6) '시스템'은 잔돈이 있을 경우, 잔돈을 반환한다. 

 

학생의 경우: 일방적인 대화. <-> 교수의 경우: 고객이 이러한 액션을 하면 - 시스템은 어떤 반응을 보이지?

 

Q. 목적을 달성했나요?

A. 달성했습니다.

스텝을 따라가면 당신의 목적이 달성될 수 있습니다.

만약에 5번에서 끝난 경우 잔돈이 나오지 않는 상황이 발생한다. 이 경우, 커피뽑기 목적의 일부분만 달성된다.

또한 천원이 투입되기 전에 하나가 더 관찰되어야 한다. "0번." 

 

- 조건 2개.

1. 선조건 Pre condition - True/False

시스템은 항상 ready 상태여야 진입할 수 있다.

2. 후조건 Past condition

목적을 달생했는가? (1) 원하는 음료, (2) 정확한 잔돈.

 

음료수가 아예 떨어진 경우, 잔돈이 더는 존재하지 않는 경우, 사용자가 음료를 취소한 경우, 자판기 관리자가 관리자 모드에 진입했을 경우, 기타 등등의 상황 존재한다.

 

 

병원의 예약관리 시스템의 액터.

환자, 관리자, 의사.

세개의 액터들과 세개의 큰 덩어리의 유스케이스.

 

 

시나리오 전개.

 

 

- 유스케이스. 

 

박스는 시스템의 영역.

시스템 안의 동그라미들 - 이런이런 기능들이 올라갈 것이라는 의미.

시스템을 구성하는 객체들과 그들의 상호작용은 볼 수 없지만 위로 대략적 이해 가능.

 

 

- 관계

 

03. 분석 활동 관계

- 액터 찾기

- 시나리오 찾기

- 유스케이스 찾기

- 유스케이스 상세화

- 유스케이스 사이의 관계 찾기

 

1. 액터란?

: 시스템과 상호작용하는 사람 혹은 어떤 것.

 

- 엑터의 세가지 종류

1) 사용자: 시스템을 사용하는 사람

2) 다른 시스템/소프트웨어

3) 장치: 다양한 입출력 장치 (제어기, 프린터 등)

 

직관적으로 판단하면 미싱이 발생하며, 잘못 판단하면 액터가 할 기능이 통째로 사라진다.

 

 

2. 액터 파악 및 서술

1) 다음의 질문을 통해 엑터에 대한 필요 정보를 얻는다.

- 누가 시스템을 사용하는가?

- 누가 시스템으로부터 정보를 얻게 되는가?

- 누가 시스템에 정보를 입력하는가?

- 어디에 시스템이 사용되게 되는가?

- 누가 시스템을 지원하거나 유지보수하는가?

- 시스템을 사용하는 다른 어떤 시스템이 존재하는가?

 

2) 액터가 충족시켜야 할 행위의 종류

- 정보가 오가는 두 액터간의 상호작용

- 상대 액터의 이해관계를 보호하기 위한 타당성 확인

-  이해관계 보호나 촉진을 위한 내부 상태변화

 

 

3. 시나리오

- 시스템 사용시 사용자가 무엇을 경험하는가를 글로 표현한다.

- 단일 엑터 관점에서 기능을 서술하며, 비정형적인 서술을 한다.

- 매우 구체적인 사례를 한다.

- 정상적인 경우뿐만 아니라 다양한 대안을 묘사할 수 있어야 한다. 

- '시나리오는 유스케이스의 인스턴스.'

 

유스케이스는 고객은, 시스템은, 하고 디테일한 상황을 전부 하나하나 표현하면 복잡해지기 때문에 일반화한 것.

더 깊은 관찰은 시나리오.

 

 

4. 시나리오의 흐름

 

상황에 따라 데이터에 따라 굉장히 다양한 흐름을 생성하는게 기능의 속성.

분석가들이 캐치해야 한다.

 

 

5. 시나리오의 예시: 창고에 불이 났을 때.

 

 

6. 유스케이스의 작성

- 유스케이스를 시작하는 행위자

- 유스케이스 시작을 위한 선행 조건

- 시나리오 진행 단계

- 유스케이스 종료를 위한 종료조건

- 유스케이스 결과를 받는 행위자

 

 

7. 유스케이스의 예시

- 위의 시나리오의 유스케이스

 

 

- 자판기 유스케이스 다이어그램

 

다른 액터들끼리의 연결도 가능하다.

 

 

- 자판기 유스케이스

 

종료조건은 T/F를 본다.

 

 

- 다른 유스케이스

 

 

- 자동차 사고 보장받기

 

-> 이 과정에서 분기가 발생할 수 있음.

 

 

- 자동차 사고 보상받기 - 대안흐름

 

 

 

- 요약

 

유스케이스는 시나리오의 일반화.

시나리오는 유스케이스의 인스턴스이다.

 

분석가들은 모든 관찰기록을 케이스별로 정리할 수 없기 때문에 일반화시킨다.

필요하다면 시나리오 작성.

 

서로 단어가 교차되어 사용되긴 하지만 개념적으로는 분리.