샘플 UML 활동 다이어그램

Question

다음 다이어그램을 그렸고 그게 정확한지 알고 싶습니까?

이것은 명령을 수신하고 명령 정의 파일 (해당 파서)에 올바른지 확인한 다음 실행하고 다른 명령은 오류를 사용자에게 던지는 샘플 CLI 프로그램입니다. 실행 과정에서 실행을 종료시키는 일이 발생하면 사용자에게 오류로보고됩니다. 이러한 모든 이벤트도 기록되어야합니다.

Answer 1

귀하의 설명에 따라 활동도를 그립니다. 액티비티는 실행을 시작한 후 "Command Received"이벤트를 기다립니다. 커맨드를 받았을 때 "in definition file"조건이 참이면 실행될 수 있습니다. 그렇지 않으면 예외가 발생합니다. 예외는 명령 개체입니다. (이 예에서는 변경할 수 있지만 변경할 수 있음). 명령이 실행되거나 오류가 기록 된 후 활동은 다음 명령을 기다립니다. 둘 이상의 명령을 동시에 수신해야하는 경우 "명령 수신"이벤트로의 흐름을 제거하면됩니다. 아래

참조 다이어그램 :

Answer 2

먼저 내가 그림은 매우 명확하지 않다 생각 : 나의 관심사는 수평 바 (병합 포크라고도 함)입니다. 당신은 당신의 요소에 대한 묘사에 더욱 표현되어 있어야합니다. 예를 들면 : "명령"은 무엇을 의미합니까? 나는 맥락에서 "명령받은"것을 의미한다고 생각한다.

나에게 불투명 한 또 다른 사실은 처음에는 신호를 의미하는 것입니다. 먼저 "명령"신호를 수신 한 다음 불명확 한 결정을 내린 다음 결정이 한 방향으로 진행되면 신호 " 실패한". 명령이 실행되지 않기 때문에 나는이 경로에서 유효하지 않다고 생각합니다. 귀하의 결정을 말씀하십시오. (당신은 당신의 가지들 [유효한 명령]과 [잘못된 명령]에 태그를 달 수 있습니다).

병합 막대의 경우이 방법으로 사용해서는 안되는 주석에 동의합니다. 그러나 내 favorite source은 행동에 화살표를 직접 가리 키지 말아야한다고 말합니다. (하지만 실제적으로는 종종 그렇게합니다 :)). 대신 의사 결정과 마찬가지로 다이아몬드를 사용해야하지만 여러개의 화살표와 하나의 나가는 화살표가 있어야합니다.

약간의 의견 : 나는 UML이 종종 산만해질 수 있다는 것을 알았다. 나는 하나 이상의 회의에 참석하여 소프트웨어 설계에 대해 논의하고 UML에 대해 논의해야했습니다. 중요한 부분은 UML이 모든 노치와 트 위치가 표준에 따른 것이 아니라 효과적으로 의사 소통하는 데 도움이된다는 것입니다. 물론 코드/생성물을 생성하려는 경우는 제외합니다.