Functional Model

1. 들어가면서

 

시스템의 요구사항은 크게 functional requirements와 non-functional requirments로 구분할 수 있다고 말씀드렸습니다. 이번 글에서 기술할 functional model은 요구사항중 functional requirements를 분석하여 이를 모델링한 결과를 표현하는 모델입니다. software system의 관점에서는 가장 기본적이고 필수적인 요구사항이라고 할 수 있습니다.

 

그런데 기능이란 무엇일까요? 시스템이 수행할 일이라고 바꾸어 이야기할 수 있을 것 같습니다. 따라서 시스템이 수행하는 일들이 무엇이고 이 일의 단위와 구조를 어떻게 잘 표현할 것인가가 functional model의 품질을 좌우한다고 할 수 있습니다. UML에서는 이러한 일의 단위를 use-case라고 하는 용어를 사용합니다. 따라서 functional model은 아래와 같이 use-case들의 집합이라고 할 수 있습니다. 

 

use-case 집합으로서의 functional model

2. use-case

 

use-case를 좀더 시스템 관점에서 정의하자면 "시스템  외부에서 발생한 자극에 반응하는 시스템의 행위"라고 정의할 수 있습니다. open system은 외부와의 상호작용을 하기 때문에 외부로 부터 어떠한 자극을 받고 이 자극에 반응하는 유기체이고, 이러한 자극에 대해 반응을 하는 행위를 use-case라고 할 수 있습니다.

시스템의 상호작용

시스템을 분석한다는 의미중에 가장 중요한 것이 바로 이 use-case를 어떻게 식별하고 use-case를 수행하는 행위가 무엇인가를 파악하는 것이라고 할 수 있습니다. 이러한 use-case를 분석하는 방법을 이해하기 위해 도움을 줄 수 있는 개념이 event입니다.

 

3. event

 

우리말로 번역하면 사건이라고 하는데, 사건이라고 하면 마치 법적인 문제 같습니다. event는 시스템의 외부와 내부에서 발생할 수 있습니다.  시스템 외부에서 발생하는 event를 external event라고 하고 외부라는 것은 시스템 관점에서는 context model에서 정의된 actor를 의미합니다.

 

external & internal event

internal event는 시스템의 내부에서 발생하는데 보통은 어떤 시점이 되면 자동적으로 발생하는 event라고 하여 temporal event라고도 합니다.

 

external event는 event가 발생하면 actor가 자극(stimulus)을 시스템에 주게되고 이 자극을 받은 시스템은 이에 반응(response)하기 위해 일련의 일을 수행하게됩니다. 이렇게 자극에 대해 일련의 일을 수행하는 것이 use-case라고 할 수 있습니다. 따라서 use-case를 식별한다는 것은 이런 event를 식별하고 event의 자극에 대한 반응을 분석하는 것과 같다고 할 수 있습니다. 정보처리시스템에서는 이를 transaction이라고 부르기도 합니다. 

 

use-case는 반드시 일을 처리하고 그 결과(반응)을 출력합니다. 이러한 반응은 2가지로 구분될 수 있습니다. 하나는 시스템 외부에 존재하는 actor에게 어떤 결과를 출력하는 것이고, 또 하나는 시스템 내부의 상태를 변경하는 것입니다. 시스템의 상태를 변경한다는 것은 시스템이 존재하기 위해 유지해야 하는 데이타의 집합이라고 할 수 있습니다. 

 

4. use-case event diagram

 

UML에서는 functional model을 use-case diagram을 활용하여 모델링합니다. use-case diagram은 information 처리 관점에서 기능의 입출력을 표현하지 않기 때문에 use-case가 actor와 시스템 상태와의 관계를 분석하고 표현하는데 한계를 갖고 있습니다. 따라서 SSDM에서는 기존의 use-case diagram을 확장하여 functional model을 use-case event diagram이라는 것으로 모델링합니다. 이러한 use-case event diagram은 전통적인 분석방법인 structured analysis에서의 data flow diagram의 개념을 적용한 것입니다.

 

use-case event diagram은 use-case의 자극과 반응을 UML의 information flow을 사용하여 use-case diagram을 확장한 diagram입니다. 또한 use-case event diagram은 시스템에서 관리하는 data들을 모델링하는 data model에 정의된 data entity들을 data store라는 객체로 모델링합니다.

 

use-case event diagram의 예

 

위의 그림은 CMS라는 체계의 한 예를 보여주고 있습니다. 예를 들면  "survellance radar"라는 외부 actor에서 "track detect"라는 event가 발생하여 그 결과로 "SR Track Info."라는 자극이 시스템으로 입력된다는 것을 의미하며, 이 자극을  "Managing SR Track"이라는 use-case가 입력 받아 "SR-track"이라는 data store 객체를 갱신한다는 것을 의미합니다. 기존의 use-case diagram에서 처럼 actor와 use-case간의 association관계 만을 표현하는 것이 아니라 use-case의 입출력관계를 information flow와 data entity를 이용하여 모델링합니다.

 

5. use-case granularity

 

use-case를 분석하고 모델링하다 보면 어느 정도의 규모로 use-case를 모델링할 것인가라는 문제를 만나게 됩니다. 가장 일반적이고 직관적인 방법은 use-case scenario를 한 페이지 내로 작성할 수 있는 수준으로 최하위 use-case로 모델링하는 것입니다.  use-case를 use-case event diagram으로 모델링하게 되면 입출력관계를 명확히 기술하기 때문에 개략적으로 use-case의 행위를 이해할 수 있지만 시스템의 기능을 모델링을 완료한다는 것은 use-case scenario 작성을 통해 시스템에 존재하는 busienss rule을 명확히 정의하는 것이라 할 수 있습니다. 

 

그러나 현실적으로는 두가지 관점에서 use-case scenario를 완전하게 정의한다는 것이 매우 어렵고 어떤 경우는 불가능한 경우가 많습니다. 따라서 오해하지 말아야 하는 부분이 functional model을 완성한다는 것이 분석이라고 정의해 놓은 단계에 모두 가능해야 한다는 것을 의미하지 않는 다는 것입니다. 지금까지 설명한 내용이나 앞으로 설명한 모든 내용이 특정 단계에 수행하는 것으로 설명은 하지만 이러한 단계를 정해 놓은 것은 방법론을 설명하기 위한 것입니다. 이러한 방법론을 다양한 development life-cycle model 따라 다양한 시점에서 부분적으로 적용해야 합니다. 예를 들어 agile life-cycle model에서는 몇개의 use-case에 한정하여 완전한 scenario를 작성하여 설계 및 구현을 하거나, RUP와 같은 iteraative life-cycle model에서는 각 phase별로 use-case를 기술하는 추상화 수준을 나누어 기술하는 등 다르게 적용할 수 있을 것입니다.

 

6. functional architecture

 

functional model을 구성할 때 가장 최하위 use-case 만을 기술하는 것은 시스템의 규모가 커지면 한계가 존재합니다. 또한 규모가 큰 경우는 단순히 event를 식별하여 전체 시스템의 use-case를 식별한다는 것이 어려울 수 있습니다. 어떻게 use-case를 식별을 하던 use-case들을 논리적으로 그룹핑하여 기능의 계층구조를 식별하고 이를 모델링하는 것이 필요합니다. 

 

이렇게 use-case들을 그룹핑하여 표현한 것을 use-case package라 하고, 이 package로 구성된 use-case들의 구조를 functional architecture라고 부르기도 합니다. 시스템의 규모가 큰 시스템의 경우는 단위 use-case를 직접 식별하는 것보다 오히려 functional architecture를 top-down으로 분석하여 전개하여 최하위 use-case까지를 식별하는 것이 일반적입니다.

 

따라서 이러한 functional architecture를 구성하는 방법은 크게 top-down과 bottom-up 방법이 존재할 수 있으며 시스템의 규모에 따라서 달리 적용하거나 혼합하여 적용할 수 있을 것입니다. 시스템의 규모가 적은 경우는 event식별을 통해 자극과 반응을 식별하고 바로 use-case를 분석하는 것이 유용할 것입니다. 그러나 시스템의 규모가 어느 이상이 되면 시스템의 기능을 분할하면서 시스템을 분석하고 최종적으로 최하위 use-case를 식별하여 모델링하는 것이 유용할 것입니다.

functional architecture

 

7. use-case scenario

 

 use-case scenario는 use-case의 business logic을 기술하는 것입니다. business logic은 무엇일까요? logic이라고 하면 개발자들은 컴퓨터 알고리즘을 생각합니다. 그러나 business logic은 이러한 기술적인 구현방법을 이야기하는 것이 아니라 분석 대상인 시스템에 존재하는 업무규칙을 의미하며 이 규칙에는 데이타를 구성하는 semantic rule과도 연관이 됩니다. data의 semantic rule에 대해서는 data model에서 다시 언급하고자 합니다. business logic을 좀 더 구체적으로 셜명하면 아래 그림과 같이 이야기 할 수 있습니다.

use-case의 business rule

그림에서 처럼 business logic은 입력과 출력의 변환 관계를 설명하는 것입니다 이러한 출력은 actor에 출력도 있지만 시스템의 상태를 변경하는 것도 포함을 합니다. 따라서 data-store를 어떻게, 언제 생성, 수정, 삭제하는 것인가에 대한 규칙을 정의하는 것도 매우 중요합니다.

 

use-case scenario는 일반적인 자연어를 사용하여 기술합니다. 그러나 가능한 일반적인 자연어보다는 이해도의 증지과 정확도를 위해 몇가지 정해진 규칙에 따라 기술합니다.  

 

use-case scenario의 형식

<description>은 use-case의 개요를 free style로 작성하는 것입니다. use-case의 가장 추상화수준이 높은 설명문이라고 할 수 있습니다.  <triggers>는 actor 또는 시스템 내부에서 전달되는 자극이나 temporal event의 경우는 어떤 특정 시점을 기술합니다. 즉 해당 use-case의 행위를 수행하게하는 발단을 제공하는 자극이라고 할 수 있습니다. <pre-condition>, <post-condition>은 use-case의 수행 전후의 시스템의 상태를 표현하는 것으로 보통은 자극과 반응에 대한 준비와 완료 상태를 기술합니다. 이를 이용하여 test case를 설계할 수 있도록 기술하게 되며 이를 기준으로 use-case의 testability를 검증할 수 있습니다.

 

<main flow>는 business logic을 기술하는 부분으로 use-case의 가장 대표적이며 정상적으로 수행되는 business logic을 기술합니다. 이에 반해 <exception flow>는 use-cse가 비정상적이지 않게 종료될 수 있는 event가 발생하는 경우에 대한 시스템의 business logic을 기술합니다. <alternative flow>는 특정 조건에서 flow가 변경되는 경우의 business logic을 기술합니다.  모든 business logic을 기술할 때는 전체의 구조를 쉽게 이해할 수 있도록 적색으로 기술한 3가지의 키워드를 사용하여 조건과 반복의 구조를 표현할 수 있습니다. 그리고 모든 flow에는 번호를 부여하며, <alternative flow>와 <exception flow>에는 flow의 분기가 어디에서 발생하는지 분기되는 문장의 번호를 기입합니다. 

 

마지막 <other requirments>는 use-case에 해당하는 부가적인 요구사항을 기술합니다. 특히 해당 use-case에 국한된 non-functional requirements를 주로 기술합니다.