[Software Design] Business Process and Functional Modeling

OOAD랑 뭐랑 뭐 자꾸 헷갈리는데 다시 정리하고가자면,
SDLC는 일단 4단계로 나뉜다. 그 단계의 배치가 어떻게 되냐에 따라 방법론이 나뉘기도 하지만,
data/process 어디에 집중할지에 따라 방법론이 나뉘기도한다.
즉 두 부류의 방법론들은 서로 덮어씌우지는(?)거다. OOAD이면서 agile일 수도 있고, parallel일 수도 있는 것이고..
지금은 그냥 SDLC 각 단계들을 OOAD 특성을 살려 배워 나가는 것 같다.
(use case, 반복/점증, functional/structural/behavioral 이라는 특성들을 각 단계에서 적소에 써가며...)
(마지막에 다 하고나야 좀 제대로 감이 잡힐 것 같긴하다. 이거도 맞는지모르겠네. 이론만 배우니 뜬구름 잡는 것 같음)

 

이전까지 requirements를 어떻게 찾아내고, 분석하고, 정리하는지 알아봤다.

이번 chapter에선 그 요구사항을 바탕으로 어떻게 Functional model(기능적 모델)을 만드는지 알아본다.

 

requirements -> functional models로 만드는 방법 :

1. requirements를 통해 use-cases를 만든다.

2. use-cases를 통해 activity diagram을 만든다.

 

Use Cases란? (사용례)

user의 관점에서 user가 어떻게 system을 사용할지 설명한 것으로 system의 기초 기능을 설명한다.

사용자는 use cases를 거쳐 원하는 작업을 완료한다.

각 use case는 1가지 기능만 기술해야한다.

 

이를 이용해 use case diagram을 그릴 수 있는데, 이것은 개발자만을 위한 것은 아니고 user와 소통을 위한 것이기도하다. user의 요구사항을 제대로 이해해서 system이 설계됐는지 user에게 보여주며 서로 소통하기 쉽도록 하는 장치이다.

UML을 통해 use case diagram을 그릴 수 있다.

(그리는 법 등 세부사항은 ppt ch4 참고)

 

use-case는 대략적으로 그려진다.

특히 (1)nonfunctional requirements나 (2)flow 같은 정보는 포함하지 않는다.

이를 보완하는 측면에서 각 Use-Case를 더 자세히 기술하는 Activity Diagram과 Use case Description에 대해 알아보자.

 

Activity Diagram

이렇게 그려진 use case diagram은 "what"에 초점이 맞춰져있다. 즉, 딱히 순서는 기술되지 않는다.

각 Use Case 별로 어떻게 수행될지 자세히 (그 안을 파고들어) 기술하는 것이 activity diagaram이다.

activity diagram은 특정 use case를 어떻게 수행할지, 그 use case와 관련된 generalization, inclusion, extension 등과 해당 use case를 수행하기위한 activities로 작성된다. 여기엔 순서가 반영된다.

 

swimlane이란, 누가, 즉 use-case에서의 actor에 중점을 둔 activity diagram이다. 주로 fork/join 등으로 기술되는 것 같다.

 

 

Use case Description

activity D처럼 특정 use-case를 더 자세히 기술하는 것이다.

모든 Use case에 대해 할 필욘 없고, 우선순위가 높거나 이해하기 어려운 use case에 대해 진행한다.

Overview, Relationships, Flow of events, Optional characteristics 에 해당 use case의 "모든" 정보를 나눠서 작성한다.

flow of events는 activity D와 일치해야한다. (usecase description과 activity D 중 뭐 먼저 적을진 본인 마음)

 

자세한 내용 작성법, 가이드라인 등은 ppt 참고.

 

한번에 이걸 작성하긴 쉽지 않으니, "structural/behavioral modeling에 들어가기 전에" verifying/validating 과정을 거쳐야한다. (이건 functional modeling임)

검증 과정도 ppt에 자세하게 나옴.

 

 

 

 

종합하자면,

use-case diagram은 requirements를 분석해 작성되고, 이 use-case diagram의 세부사항은 use-case description이나 activity diagram으로 더 자세하게 작성될 수 있다.

use-case diagram은 system의 scope를 정의하는데도 유용하다.

use-case diagram은 requirements를 만들어내고 검증하는데 사용된다.(고객과 의사소통 시에도 사용)

test cases를 정의하는데 기초가 된다.

 

즉, 향후 설계의 기초가 되는 requirements를 좀 더 정형화해서 다이어그램(use-case/activity diagram)과 문서(use-case description)로 작성하는 것이 Functional Modeling인 것이다.

이런 모델을 통해 requirements를 좀 더 잘 파악하고 다듬을수 있다.(물론 OOSAD 특성상 반복/점증이 있으니 한번에 완성되진 않는다. 다른 단계를 진행하다가 빠진 부분을 찾게 되면 보완하고 하는 것이다.)