Architect 공부 3일차(1) - UML/Sequence Diagram

Sequence Diagram

동적으로 객체간의 상호작용을 시간 흐름에 따른 메세지 구조로 표현

. 보통 단일 유스케이스 분석에 사용

 

Seqence 읽는법
0) doX로 들어오는 System operation
1) doA,B,C 를 호출/리턴 하고 이에 대한 Body는 Sale에 있다

 

 

구성요소

1) 오브젝트/수명주기

2) 메세지

3가지 메세지 타입 1) Sync : 리턴값을 받을때까지 대기 (쓰레드를 제외한 모든 프로세스) 2) Async : 리턴과 관계없이 진행 (쓰레드) 3) Ack(Response) : Request에 대한 응답 + Found : System operation (시작) + Lost : Output (끝) + Time-consuming : 기본적으로 메세지는 실시간. 시간이 필요한 메세지 표현 Creation(NEW), Destroy도 가능 생성자가 위에있고, 인스턴스가 아래에 있어야한다. 점선으로 표시하고, 인스턴스 정중앙을 향함

 

3) Gaurd (조건문)

4) Fragment (제어문 표현)

Fragment : 미리 정의된 표현방법.(여러시나리오를 한장에 압축해서 표현할때)  alt Fragment : swich-case문과 비슷하며 opt Fragment : else 없는 if문 loop Fragment : 반복문 break Fragment : 조건/반복문에서 탈출

 

Robustness(ECB Pattern) Analysis

유스케이스로부터 3종류의 분석 클래스 추출

1) Boundary class : View에 해당하며, 시스템과 외부 액터의 상호작용

2) Control class : Controller에 해당하며, 비지니스/제어 로직 담당

3) Entity class : Model에 해당하며, 데이터관리를 담당

 

※ 지양되는 케이스

엑터가 뷰를 거치지 않고 컨트롤러나 엔티티 접근
뷰가 뷰를 호출하고, 엔티티 접근하는 케이스 ( 뷰는 in/out만 담당한다. )
모델과 모델간 직접적으로 데이터 변경

 

실습 

웹 사이트 로그인과정을 ECB Pattern 으로 그려보기.

 

ㅁ BP 참고하여 보완할 점.

1) 각 분석 클래스 네이밍 지정

2) Request 메세지에는 요청이라는 표현을 쓸 필요가 없을듯 ( Response 도 마찬가지 )

3) 1.5의 실행결과를 굳이 웹사이트 안거치고 한번에 보내도 이해가 가능할듯 

4) 요구사항에 휴면 계정인 경우 활성화 로직에 대한 내용이 있었으나,

    나는 고객에 활성화 요청을 보냈다. 의도만 파악해서 시스템에서 작업했어야 할 내용

 

 

<BP>