7-2. Usecase Modeling Advanced

지금 우리가 하고 있는 것은 모델링, 모델링이라는 것은 말로 하는 것보다 다이어그램을 그리면 서로 이해하기가 쉽고 복잡성도 간소화시킬 수 있고 코드로 자동화할 수도 있고 추적하기도 쉬워서 좋다 모델링 언어 중에 UML이라는 언어를 사용하고 이걸로 다이어그램을 만들 수 있는데 가장 중요한 게 클래스다이어그램(구조), 시퀀스 다이어그램(갹체 간의 상호작용), 엑티비티(흐름), 사용자의 요구사항을 찾아서 그리는 유스케이스 다이어그램, 유스케이스만 보이기에 명세서 작성을 각각 해야 한다. 가장 중요한 것은 사용자가 시스템에게 요청하고 시스템이 응답하고 왔다갔다 할 수 있게 도메인 입장에서 도메인 용어로 시나리오 흐름을 잘 써야 한다. 기본 흐름은 매우 정상적인 케이스이기에 대안 흐름을 잘 찾는게 중요

구조화하고 조직화해서 좀 더 어드벤스하게 그려보자!!

유스케이스 모델의 구조화 개요

유스케이스 모델의 구조화

• 구조화 이전의 유스케이스 모델

사서라는 엑터가 도서관리 기능을 할 것, 학생은 단행본 대출과 정기간행물, 도서반납을 하고 교수도 세개 다함

액터의 일반화

• 시스템과 비슷한 방식으로 상호작용을 하는 유사한 액터를 일반화하여 부모 액터를 정의

학생과 교수 둘 다 도서관리시스템 입장에서는 대출자이기에 셋 다 연관관계가 있지만 각각 그으면 복잡하니까 엑터 간의 일반화가 가능

→ 대출자의 Role을 하니까 학생과 교수가 대출자라는 상위 엑터로 해주면 선이 줄어들어 복잡도가 줄어든다

유스케이스의 일반화

• 유사한 기능을 제공하는 유스케이스들을 일반화하여 부모 유스케이스를 정의

엑터들 사이에 isa 관계가 만족하는 거처럼 유스케이스 사이에도 일반화가 가능하다

단행본, 정기간행물 모두 도서대출이니까 얘를 기본흐름으로 하고 얘를 상속받아서 유스케이스 간에도 상속이 되지만 사실 거의 쓰면 안된다.

개념은 알아야 하지만 헷갈리니까 쓰지 말것

유스케이스의 포함

• 여러 유스케이스에 공통적인 시나리오를 별도의 유스케이스로 정의한다

유스케이스들 사이에 포함관계(include)도 있음. 도서관리와 도서대출에서 반드시 항상 도서검색의 기능을 해야 한다. 이 때의 도서검색의 단위가 클 경우 검색이라는 기능을 따로 뽑아서 포함하게 해야 한다. 유스케이스 사이의 관계는 상속, 포함((include)이나 확장(extend)관계밖에 없음

도서관리가 도서검색을 포함, dependency, 의존(방향 조심)

유스케이스의 확장

• 기본 기능에 부가적인 기능을 별도의 유스케이스로 정의

Extend는 확장, 대출자는 도서반납도 할 수 있는데 사용자가 반납할 책을 선택한다라는 기본흐름이 있는데 그 흐름 외에 가끔 예외적으로 반납할 도서가 연체될 경우가 있음, 즉 확장될 수 있기에 연체료부과가 도서반납을. 확장한다

이것도 유스케이스 사이의 dependency이지만 확장한다 써줘야 한다

포함 vs 확장

차이는 포함은 항상 해야 한다 즉 항상 도서검색을 꼭 해야하는 거지만 확장은 도서반납할때 원래는 없지만 예외적으로 한다 이게 되는 것

유스케이스를 이렇게 구조화가 가능하다

이렇게 바뀌면 더 생기기도 하기에 명세서를 따로 만들어줘야 한다

모든 유스케이스에 대해서 명세서가 있어야 한다!!

기본개념

액터 일반화

• 두개 이상의 유사한 액터를 일반화하여 부모 액터를 정의한다

도서대출 반납을 둘다 할 수 있다면 대출자의 역할을 하므로 얘를 만들어서 상속할 수 있다

→ 액터 일반화를 사용하여 유사한 액터와 많은 유스케이스 간의 연관관계의 복잡도를 감소시킬 수 있다

M개의 엑터 n개의 엑터를 m개의 엑터를 하나로 합치면 n의 복잡도만 가지게 된다

유스케이스 포함

유스케이스 포함은 시나리오를 잘 쓰다보면 c1,c2,c3가 공통적인 기능이 되고 어느 정도의 기능이 된다면 이걸 뽑아낸다. 클래스로 구현되거나 컴포넌트로 구현될 것인데 클래스 x,Y로 나누면 쓸대없이 중복되므로 하나로 만드는게 유지보수에 좋다-> 그래서 포함을 만든다

• 포함 유스케이스는 두개이상의 유스케이스의 부분적인 공통 시나리오를 표현

출금과 이체기능에 항상 카드 판독과 암호확인을 해야 하니까 두개의 기능으로 뽑아내서 include한다.

둘 다 이동하는 기능이 있으므로 뽑아서 include해야 한다.

출금 유스케이스 기본흐름을 보면 이체 123과정도 동일하고 6,7,89도 똑같기에 따로 유스케이스로 뽑아내서 include한다.

• 함수호출과 동일함. 기초 유스케이스를 시행하다가 include된 유스케이스로 갔다가 리턴되어 돌아온다. 여러개의 유스케이스에서 공통적인 단위가 있다면 뽑아내서 include한다

• 포함 유스케이스는 유스케이스 간의 모듈화를 통해서 재사용성을 높이는데 기여한다.

클래스나 컴포넌트가 나오게 되는게 한번만 나오게 해서 재사용하게 한다

• Include는 공통적으로 들어가는 부분! 함수같은 것

유스케이스 확장

확장은 기본적인 흐름이 아니라 예외적인 경우, 만약 연체된 도서일 경우 연체료를 계싼하고 대출자에게 부과됨을 기록, 연체된 도서일 때만 한다 이럴 때 단위가 크다면 기능으로 뽑아내서 extend한다

• 확장 유스케이스는 기존 유스케이스에 대한 확장 기능을 표현한다

연체되었을 때만 연체한다. 방향을 잘 봐야 한다

연체료부과가 도서반납을 확장한다

Ex) 도서관리 유스케이스에 관리 중에 등록기능 시 대출 가능 통보를 하는 것, 등록 중에 대기 중인 대출가능이 있다면 하는 것

Ex) 로그인 할 때 기본적인 흐름이 있지만 그거 외에 메일이 도착했다면 메일 도착했다고 통보도 해준다. 예외적인 경우에 통보

• 확장 유스케이스의 시나리오는 기초 유스케이스의 한 부분으로서 수행된다

언제 확장을 하는지 확장시점을 나타내주기도 한다 : extension point

연체 반납일 경우에는 연체료 부과 유스케이스를 실행하는데 반납이 지체되었을 때 확장점을 써준다

밑에 써준다 연체반납이 될 경우에만 연체료를 부과한다

연체반납이 되었을 때만 확장 유스케이스로 갔다 돌아온다

유스케이스 포함(include)과 확장(extend)의 비교

Include와의 차이점은 얘는 항상 실행하지만 얘는 어떤 예외적인 경우에만 실행

= > 포함은 공통적인 기능, 항상하는 것을 말하는 것이고 확장은 예외적인 부분만 한다. Extend는 연체료 부과가 의존하는 것이고 기초 유스케이스가 의존하는 것 방향 유의!

기본원칙

액터 일반화

• 모든 자식 액터는 부모 액터와 동일한 상호작용을 한다

교수와 학생이 도서대출 반납을 하는데 대출자로 일반화해서 상위엑터를 만듦-> 도서반납한다면 자식인 학생과 교수는 이두가지 기능을 함

근데 시스템사용자로 일반화할 경우 모든 기능을 교수와 학생이 하게 되는데 학생도 성적등록을 하고 교수도 수강신청을 하게 되므로 이렇게 하면 안되고 뒤의 다이어그램처럼 해야 한다. 학생은 세가지 기능, 교수도 두가지 기능 + 성적등록 세가지 기능을 한다

유스케이스 포함

• 유스케이스 포함은 개발자 관점에서의 상세한 기능적 분할을 표현하지 않는다

포함이나 확장을 하게 되면 포함하다 보면 함수하고 공통적인 걸 하게 되면 구현것도 포함하게 되는데 개발자 관점의 상세한 거는 하면 안됨

유스케이스 확장

• 기초 유스케이스의 확장점은 확장이 필요한 시점만을 언급하며 구체적인 확장 기능을 정의하지 않는다.

Extension point는 언제 확장되는지 그 시점을 쓰는 거임, 기능을 쓰는 게 아니라 시점을 쓰는 것임! 언제 확장이 되는지 써야 하는데 통보라고 기능을 써주면 안된다!

• 확장 유스케이스는 세부적인 대안 시나리오를 표현하지 않는다
  • Extend가 다 대안흐름이 되게 되는데 아주 작은 시나리오인데도 뽑아내면 안됨. 대안흐름에 있어야하고 extend로 뽑아내면 안된다. 결제 시스템에서 기본 결제는 카드인데 사용자가 현금을 선택하거나 계좌이체 포인트 지불 등등이런거 extend로 하기도 한다. 이거는 대안흐름으로도 할 수 있고 extend로 할 수 있다

실용 지침

액터간의 연관관계

• 액터간의 연관관계는 유스케이스 모델의 이해도를 높일 수 있을 때 사용

유스케이스와 얘를 사용이나 상호작용하는 엑터가 있지만 엑터와 엑터 사이도 있음 얘는 개발할 부분이 아님 의사소통을 위해 사용

은행고객이 창구직원에게 부탁하는 것인데 얘는 이해도를 높이기 위함

사서는 도서관리기능을 하는데 신규관리 하는 시점에 예외적으로 통보하는데 그러면 통보는 실제로 하는 것은 sms 전송시스템이 할 것 -> 얘를 통해서 학생한테 가는 거끼엔 시스템까지 인터페이스까지만 구현!

일반화, 확장, 포함의 사용

• 정확하기 이해 전에는 사용을 자제
• 확장, 포함은 쓰지 않고 엑터의 일반화는 자주 씀

아키텍트가 가이듣를 주면 쓰면 되지만 일반적으로는 쓰지 마라

요약

유스케이스 모델 명세서 쓰고 얘를 구조화해서 수정해야 한다!

유스케이스 모델의 조직화 개요

이런 식으로 유스케이스 다이어그램 유스케이스가 많아지면 패키지로. 관련된 것끼리 묶는다

개발하려는 시스템 안에 엑터와 유스케이스가 있는데 엑터1과 관련된 유스케이스끼리 그룹화가 가능하고 2도 마찬가지 -> 패키지로 만들 수 있다

기본 개념

유스케이스 패키지

• 다수의 모델 요소를 그룹화하는 수단
• 클래스를 묶는 패키지
• 유스케이스 패키지는 다수의 유스케이스를 그룹화하는 수단

유사한 유스케이스 : 기능이 유사한 유스케이스를 패키지로 묶을 수 있다

기본원칙

유사한 유스케이스

• 하나의 유스케이스 패키지의 유스케이스들은 유사한 기능을 나타내야 한다

고객은 개인정보관리와 계좌관리 조회 등등 의 관리는 은행직원은 두개의 유스케이스가 있는데 왼쪽과 오른쪽을 묶을 수 있어서 비슷한 기능끼리 묶을 수 있다

상이한 유스케이스

• 성격이 다른 유스케이스는 다른 패키지에 배치한다

  

• 다른 액터의 유스케이스, 상이한 액터가 이용하는 유스케이스들은 다른 유스케이스 패키지에 배치되는 것이 일반적이다.

보통 엑터에 따라서 쪼개면 되는데 일반 고객이 접근하는 것과 대출관리가 있는데 위의 두개는 고객이 밑은 은행직원이 함. 액터가 다름 그래서 패키지 안에 또 기능을 나눌 수 있다. 엑터가 다르다는 것은 uii가 다르다는 것이기에 그룹화를 해서 나누는 것이 낫다. 많은 유스케이스가 나오고 패키지로 묶어야 하는데 하려는 비지니스의 업무구조와 유사함

실용 지침

• 유스케이스 패키지는 도메인 업무 구조와 유사하다

우리가 하려는 도메인 업무구조와 비슷함

패키지를 만들고 그 안에 유스케이스가 존재 → 프로젝트 관리의 단위가 된다, 패키지 안에 여러 케이스가 존재 각각을 구현하는 팀으로 나누기도 하며 우선순위를 정해 가장 중요한 기능을 먼저 구현

• 유스케이스 패키지 이름은 주로 000관리이다

• 유스케이스 패키지는 프로젝트 관리의 단위가 된다

  

나눠지면 할당을 할 수 있고 우선순위가 높은 애를 먼저 할 수도 있다

요약

유스케이스 다이어그램으로 모델링하면 요구사항을 찾아내서 모델링하려는 건데 그러면 패키지 구조도가 나오고 패키지 안에 유스케이스 다이어그램이 존재

구조도가 있고 그것의 다이어그램이 있으며 전체 패키지 구조도와 머하는 건지 각 패키지에 대한 명세서 엑터 유스케이스 명세 패키지 단위로 작업을 한다.

유스케이스 모델링으로 요구사항을 찾아내는 것이고 uml에서는 유스케이스 다이어그램만 제공하는데 명세서가 없으면 모르기에 보통은 문서, 자연어로 처리된 명세서도 반드시 작성해줘야 한다

보통 요구사항이 나오면 다이어그램과 명세서가 나오게 된다~