Software Engineering 5 - Use case Relationship & Domain Model

 Use-case는 System의 functionally(FR)를 나타내며 각 actor의 tangible benefit (goal)을 나타낸다. 일반적으로 타원 내에 이름을 적는 것으로 표기한다.

- Actor : interact with system(person/system), system을 사용하거나, system이 사용할 functionality를 제공하는 역할(role). 따라서 사용자는 상황에 따라 필요한 role을 선택하여 system과 원하는 interaction을 하게 된다. (사용자가 여러 개의 role을 동시에 가질 수도 있다) 그렇지만 Actor는 system에 속해 있지 않고 system boundary 바깥에 존재한다. (구현 대상은 아니지만, 유저 데이터(이름, 정보) 등은 명시함-interface만 사용) 일반적으로 사람 형상 아래에 이름을 적는 것으로 표기한다.
use case는 하나이상의 actor와, actor는 하나 이상의 use case와 연결이 존재해야 한다.


Relationship between Use-cases
- <<include>> (연달아 꺽쇠 = 귀메이, streotype)
use-case 사이의 relationship. use-case들이 동일한 behavior를 가지는 경우 반복을 방지하기 위해 반복되는 부분을 따로 떼어 여러 use-case와 연결하는 것. (모듈화) 따라서 여러 개의 base가 동일한 included를 가리킬 수도 있다.
base use case -----<<include>>----> included use case
실제 실행은 control이 base에서 included로 넘어갔다가, 중복된 부분의 실행을 완료하면 다시 base로 넘어가는 형식으로 구현된다.(sub routine과 동일하게 진행) 또한 만약 actor가 included use case와 연결되었다면 해당 use case만 독립적으로 호출할 수도 있다.

- <<extend>>
주어진 base의 extension point에서 확장하여 어떤 기능을 구현하는 경우. 위와 다른 점은 해당 부분이 반드시 필요하지 않다는 것이다. 해당 부분을 사용할 수도 있고, 사용하지 않을 수도 있을 때는 included가 아니라 extended로 나타낸다. 따라서 일반적으로 included를 없애버리면 base의 behavior에 문제가 생기지만, (dependency가 있다) extend는 제거해도 아무런 문제가 발생하지 않는다. (dependency가 없다)
이 때 위의 include와는 화살표 방향이 반대임을 유의해야 한다. 다만 작업의 흐름은 base에서 included/extend로 넘어갔다가 다시 돌아오는 것으로 동일하다. 또한 actor와 연결되어있을 경우, 위와 동일하게 독립적으로 시행될 수도 있다.
base use case <------<<extend>>--------- extending use case
화살표의 방향은 앞서 클래스 다이어그램에서 확인했던 것 처럼, 상대 instance의 정보를 알고 있는가에 따라 달라진다. (dependency!= 호출방향) 이 경우에는 base는 extend의 정보를 모르고, extend가 base의 정보를 알고 있기 때문에 이렇게 나타낸다. 대신 base는 extension point를 정의해 interrupt 되고 extended로 넘어갈 수 있는 지점을 정의하여 정보를 몰라도 넘어갈 수 있게 한다. 반면에 included의 경우 base가 included의 정보를 가지고 있다.



- Generalization (상속)
앞서 클래스 다이어그램과 동일하게 빈 화살표로 나타내며 sub이 상속하는 대상 base를 가리키는 형식으로 구성된다. abstract도 동일하게 작동한다.

Relationship between Actors
- Generalization (상속)
위와 동일한 형식으로 작동한다. (abstract & 화살표)

* UML 표준은 한 use-case에 연결된 모든 actor가 있어야 해당 use-case를 실행할 수 있다는 것을 의미한다. (AND) 그러나 산업계 표준의 경우, 하나의 use-case가 여러 개의 Actor와 연결되어 있더라도 어느 것 하나만 있으면 된다고 해석하는 경우가 많다. (OR) 따라서 주어진 그림이 어느 것을 의미하는지 알 필요가 있다.
* Use-case diagram은 workflow / process를 모델링하는 방법이 아니다. 예를 들어 작업은 base->include/extended의 순서로 진행되지 않는다. include/extension point는 base 작업의 중간에 있을 수도 있기 때문이다.
* 같은 objective를 가진 small use case들은 하나로 묶어 표현하는 것이 더 좋다. 예를 들어 CRUD 같은 경우, create, update 등을 따로 use-case로 표현하지 말고 하나로 묶어서 Manage 로 나타내는 것이 더 선호된다. 다만 상황에 따라 작은 작업을 분리해야할 필요도 있기 때문에 알맞게 사용해야 한다.
* functional decomposition을 use-case에 대해서는 하는 것을 추천하지 않는다. 예를 들어 해당 use-case 작업을 위해 필요한 세부 스텝들을 하나하나 나누어 모두 표현하는 것이다. use-case는 requirement를 추출하고 명세하는 작업이므로 이렇게 세세하게 구현 방식까지 결정하고 고려하는 것은 좋지 않다.
하나의 use-case더라도 여러 번의 iteration을 통해 개발될 수도 있다.


Supplementary specification
URPS+를 나타내기 위한 document. 일반적으로 특정 상황/use case가 아니라 전체 시스템(모든 use-case)의 상황에 모두 적용되는 common functionality 와 FR를 제외한 NFR 모두를 명시한다.
이 명시는 inception에서만 일어나는 것은 아니고 elaboration 단계까지 지속적으로 이루어진다. (UP는 iterative & evolutionary) 그러나 초반부터 중요한 high risk, important NFR을 정리하여야 전체 프로젝트를 성공할 확률이 높아진다.

Inception : short(one week only) & non-iterative step. 주로 requirement의 간단한 이름과 actor의 goal을 설정하고, risk가 높은 것들을 정의하는 단계
Elaboration : core/risky architecture를 개발하고 테스트, 거의 대부분의 requirement를 확인하고 안정화, 주요 risk들은 해소가 되어야 함. 그리고 전체 스케쥴과 리소스를 추정하는 단계가 된다.
Domain model, Design model, software architecture document, data model, use-case UI prototype 등등이 iteration의 결과물로 만들어진다.
Use-case ranking : risk(technical complexity, amount of effort), coverage (얼마나 많은 부분을 커버하는지), criticality(클라이언트가 중요하게 생각하는지) 세 가지의 요소를 고려하여 rank를 결정하고, 높은 것 부터 먼저 처리하는 것이 좋다. rank가 높은 것들은 먼저 만들어지고, 시스템에 계속 남아있으므로 지속적으로 테스트를 받아 안정성이 높아진다는 장점도 있다.

Domain model
해당 business domain에서 주목해야 할 중요한 concept/real situation object 들을 시각화한다. 추후의 design에서 object, class를 만드는데 도움을 주며 OOP analysis에서 가장 중요한 classic model이다.
textual form으로 명시된 use-case를 통해 실제 오브젝트와 클래스, 그리고 그들의 관계 등을 class diagram으로 나타낸 것이 되며, 이들은 다시 glossary나 design model을 제작하는데 사용된다.
단, 이 도메인 모델에는 해당 부분을 실제 소프트웨어에서 구현한 software object는 포함하지 않는다. 예를 들어 데이터 저장을 실제 구현하는 DB, 함수(responsibility)까지 구현한 완전한 클래스 등은 design, 설계 단계에서 이루어지며 분석 단계인 도메인 모델에서 다루지 않는다. 따라서 class diagram의 이름과 attribute만 명시하며 operation은 분석 단계가 아닌 설계 단계에서 제작하게 된다. (다만 해당 도메인이 DB, library와 같이 특정 software artifact와 관련된 경우에는 서술해도 된다.)
정리하면, 도메인 모델을 구성하는 것은 domain object/conceptual class, attribute, association이 된다. 또한 software architecture에서 domain layer와 완전히 동일하지 않다.
이런 도메인 모델을 통해 현실을 정의하면, 실제 소프트웨어에서 제작될 오브젝트들 역시 현실과 동떨어져 있지 않게 설계될 수 있다. (lower the representation gap) domain model의 class와 design 단계의 domain layer의 class 들이 서로 차이가 크지 않아 유지보수에 더 편리하다. (현실 세계와의 매핑을 가능하게 함)
쉽게 말해, domain model은 현실을 반영하여 제작하므로 현실에 있는 것, 개념들의 이름과 구조를 가져오게 된다. 이를 기반으로 design을 하면, 해당 결과도 현실의 것들의 이름과 역할을 가지게 되는 것이다. 따라서 이렇게 inspire을 통해 괴리(representation gap)를 줄이는 것이 OOP의 중요한 요소 중 하나이다.

- domain model creation steps
find conceptual class - draw identified classes in UML - add association & attributes.
이 때 주의할 점은, 해당 iteration에서 진행되는 requirement에 한정하여 진행해야 한다는 것이다. (왜냐하면 domain model도 결국 iteration을 통해 계속 확장해나가기 때문)
1. find conceptual class
- Reuse existing models : 출판되고 사용되는 데이터 모델 등을 사용하는 것(최선)
- Using a Category List
자주 등장하는 여러 문제(카테고리)와 해당 분야에서 자주 발생하는 문제/개념 예시를 보며 힌트를 얻어 클래스를 만드는 방법
- Identification of Nouns
주어진 use case의 text를 분석하여 noun phase를 사용해 파악하는 것. use case scenario에 명시된 줄글의 명사들을 class, attribute의 이름으로 사용하는 방식.

* Report Objects
만약 어떤 object가 단순히 기존에 있는 정보들을 운반하고 알리는 역할만 할 경우(예를 들어 판매와 지불 사이를 연결하는 영수증 등) 이를 report object라 하고, 이것의 역할을 이미 존재하는 것들이기 때문에 중복이라고 볼 수 있다. 일반적으로 다른 모델의 정보를 보여주는 역할만 하는 오브젝트는 필요가 없다. 다만 상황에 따라 business rule에서 중요한 요소로 여겨지는 등 필요한 경우가 있기 때문에 배제하거나 사용하는 선택을 해야 한다.
* Attribute or Class
어떤 속성을 나타낼 때 클래스의 속성으로 나타낼 지 혹은 독립된 클래스로 나타낼 지 헷갈리는 경우가 있다. 일반적으로 어떤 x가 실제 세상에서 문자, 숫자로 표현되지 않는다면, 이는 속성이 아니라 conceptual class로 생각하는 것이 옳다.
*Description class
다른 클래스를 묘사하는 정보를 담은 클래스. 어떤 실제 물건과 해당 물건에 대한 정보를 별개로 취급해야 하는 경우에 사용해야 한다.(실제 상품과 해당 상품의 가격, 정보 등. 만약 상품을 팔았을 때 해당 정보까지 모두 없어지면 곤란하다)

Association : some meaningful & connection
Association은 두 클래스/인스턴스 간에 의미적인 연결이 있을 때 이를 연결하여 나타낸다. 일반적으로 일정 시간 이상 유지되는 연결 혹은 common list에 있는 카테고리를 고려하여 모두 나타내야 한다. 대부분의 경우, 이렇게 나타낸 association은 navigation/visibility의 형태로 소프트웨어에 구현된다. 그러나 도메인 모델은 데이터 모델이 아니기 때문에 (순수한 개념적 관점의 존재, 이해에 도움을 주는 것이 목적) 실제 자료구조의 구현에서는 달라질 수 있다는 것을 알아야 한다.
클래스 다이어그램처럼, 클래스 사이에는 여러 개의 association이 있을 수 있다. 또한 반드시 association 뿐 아니라 상속, contain 등 다른 연결도 가능하지만 UP에서는 일반적으로 가장 간단하게 association만 사용하여 나타낸다.

Attribute
어떤 오브젝트의 상태, 값을 담을 수 있는 logical data value. 주로 해당 시나리오를 구현할 때 requirement를 맞추기 위해 우리가 알아야 하고 고려해야 하는 것들에 대한 정보를 담고 있다.
attribute는 Visibility name : type multiplicity = default {property}의 형태로 나타낸다. (+ dateTime : [0 .. 60] = 0 {readOnly}) 이 때 만약 해당 attribute가 다른 attribute들로부터 계산해 도출될 수 있다면, visibility와 이름 사이에 / 기호를 넣어주어야 한다.