[Software Design] Behavioral Modeling

이젠 OOSAD Analysis의 마지막 단계로 Behavioral(Dynamic) Modeling을 할 차례이다.(iterative가 기본이니 마지막이라고 하긴 좀 그렇긴 함)

Behavioral model은 Structural Modeling과 마찬가지로 시스템을 내부에서 바라본다.

마찬가지로 Requirements, Use-Case, 이전 Model들(요구사항, use-case diagram, class diagram)을 기반으로 한다. 특정 기능이 어떻게 이루어지는지 보여준다.

주의할 것이 있는데, 절대 구현을 생각해선 안된다. 구현은 아직 뒤뒤 단계이다. 구현을 생각하는 순간 분석/디자인에 영향을 끼칠 수 밖에 없고, 그러면 우리가 고생해서 한 분석의 재사용이 어려워진다.

 

analysts는 Problem을 "object들이 상호작용하며 기능하는 use cases들의 집합"으로 본다.

이런 관점을 Behavioral Model을 통해 구체화할 수 있다.

 

 

마찬가지로 다른 model들과 iterative하게 서로 상호작용하여 수정/보완하며 만들어진다.

크게 두가지 모델 타입이 있다.

 

1. Interaction diagrams

: Sequence와 Communication 두가지 방법이 있다.(수업에선 Sequence만 다룸)

object들이 어떻게 상호작용하여 use case의 기능들을 구현하는지 표현한다.

 

2. State Machines

: 특정 Data(Object)의 상태 변화를 중심으로 표현한다.

 

 

1. Sequence diagrams

Object간의 Message sequence를 강조한다. 하나의 Use-Case를 대상으로 작성한다.(usecase D와 class D를 기반으로 작성됨/물론 다른 모델도 참고해야한다면 다 참고할 수 있다. 모든 모델간에 일관성이 있어야한다.)

실제 시간 흐름을 표현해서 복잡한 use-case를 이해하는데 도움을 준다.

 

아래와 같이 두가지로 나올 수 있는데,

1) Generic Diagram : 해당 Use-Case의 모든 시나리오를 표현

2) Instance Diagram : 해당 Use-Case의 특정 시나리오를 표현

(Use-case는 시스템을 이해하는게 중요하므로 instance diagram 하듯이 분리해서 그리면 안되고 어떻게든 한 박스 안에 다 집어넣어야 한다.)

 

activity diagrams과 마찬가지로 한 use-case를 대상으로 내부 기능을 표현하므로, activity diagrams을 참고해서 sequence diagrams을 그릴 수 있다.(둘 사이 일관성도 있어야할듯)

 

즉, system의 (외부) 기능적인 측면만 보고서 그렸던 activity diagram을, system의 구조 측면에서 그려본다고 생각해도 되겠다. usecase-activity / class-sequence 이렇게 짝으로 각각 대응된다고 보면 될듯. 전자는 기능 측면, 후자는 기능을 좀 더 상세하게 구조 측면에서 설명

 

그리는 자세한 방법 및 예시는 강의 ppt 7페이지부터 보면 된다.

주의할 점이 있는데, message를 전달할때(특정 object의 멤버함수를 호출할때), 호출하는 함수는 화살표가 가리키는 object의 멤버함수여야한다.

Actor도 주의해야한다. 특정 class의 object만 표현되는게아니라 해당 Use-Cae를 사용하는 Actor도 sequence diagram에서 표현할 수 있다.

Sequence Diagram에서 메시지를 보낼 수 있는 경우는 Class Diagram에서 직접 association이 있는 경우 뿐이다. 아무렇게나 막 메시지를 호출해선 안된다. 한가지 예외가 있는데, 어떤 두 class 사이에 끼인 class가 association class라면 양쪽 class는 직접 연결이 안돼있어도 message를 주고 받을 수 있다.

 

actor가 한명 이상이라면 해당 actor type에 대한 actor object로 각각 표시한다. 즉, class diagram의 class들만 object가 돼서 나타나는게 아니란 말이다. 예를들어 ppt p.11에 `:Student`라고 돼있는 actor는 student라는 usecase의 actor의 구체적인 오브젝트 중 하나인 것이다. 이렇게 만들어진 actor 오브젝트와 class diagram에 있는 해당 actor의 정보같은걸 저장하는 class의 object는 다른 놈이니 혼동하지말자. 즉 class의 object와는 아예 다른 개념이다, 그냥 actor를 use-case에선 제너럴 하게 표현했는데, 여기선 여러 엑터가 참여할 수도 있으니 object로 만들어서 표현하는 것이다. 또 ppt p.11의 "Registar's Database도 actor"이다.
근데 만약 actor의 object라면 왜 message를 주고 받는지 궁금할 수도 있다. message도 미안한데 class에만 있는건 아니다.. 대부분 class의 멤버함수가 message에 해당해서 오해하는거지 object끼리 정보전달하면 그게 message이다.

 

return value는 화살표를 따로 그리지 않고, 메시지를 전달할때 한번에 명시할 수 있다. 메시지 전달하는 화살표 위에 "message()"만 작성하지말고, "ret_val := message()" 식으로 작성하면 된다.

 

다 그리고 나서 use-case 기능을 제대로 구현하는지 따라가보며 검증해본다.

 

객체 사이 관계 분석 도구로 CRUDE analysis라는 방법이 있다. CRUDE는 각각 아래의 약자이다.
C : Create
R : Read or Reference
U : Update
D : Delete
E : Execute

우선 특정 use-case에 관여하는 object들을 모두 표의 1행과 1열에 똑같이 작성한다.
이후 어떤 object가 어떤 object에 어떻게 관여하는지 CRUDE 중 하나로 표에 기입하여 두 object가 서로 어떻게 연관되는지 파악한다.
(자세한 예시는 강의 ppt p.20)

 

 

 

2. State Machines

교수님께서 Automata 수업에서 배운 머신의 일반화 버전이라고 생각하면 거의 맞다고 하셨다.

특정 Object를 기준으로 그 Object의 state(상태)가 변화하는 양상을 표현한다. (class D를 기반으로 작성됨/물론 다른 모델도 참고해야한다면 다 참고할 수 있다. 모든 모델간에 일관성이 있어야한다.)

예를들어 1학년, 2학년, 3학년, 4학년 이라는 class가 따로 있다고 해보자. 이는 적절치 않은 표현이다. 예를들어 박지환 이라는 object는 입학할때 1학년으로 생성됐다가, 2학년이되면 삭제되고 다시 생성돼야한다.

이럴땐 State Machines으로 표현하는게 알맞다.

주로 복잡한 Objects 혹은 주요 Objects를 분석할때 사용한다.

 

작성 방법은 아래와 같다.

1. 우선 해당 Object(Data)의 가능한 "모든 State"를 파악한다.

2. "어떤 event"가 발생했을때 한 event에서 다른 event로 transitions(전이)될 수 있는지 파악한다.

들어가면 나올 수 없는 state가 있다던가 하는 경우를 조심해야한다.

(자세한 작성 방법 밑 예시는 강의 ppt p.23부터)

 

이를 통해 주요 Object의 행위를 낱낱히 파악하고, 제한을 둘 수 있다. 나중에 구현할때 이런 가이드라인이 명확한 것이 더 수월하다.

마찬가지로 다 작성한 후에는 당연히 직접 따라가며 검증을 해봐야한다.

 

 

 

 

ㅡㅡㅡ

이렇게 Behavioral model까지 작성한 후엔 지금까지의 각종 model들을 상호 대조하여 서로 일치하는지 확인한다.

예를들어 actor가 어떤 모델에선 A인데 또 어떤 모델에선 B이고 하는 일관성이 없는 경우가 있는지 파악하여 보완한다.