순서도 및 메소드 호출

흐름도를 작성 중이며 올바르게 접근하고 있는지 궁금합니다. 본질적으로 여러 메소드 호출이 있으며 각각 개별적으로 플로우 차트합니다. 그러나 이러한 방법 중 일부는 정보를 요청한 다음 계속합니다. 이 예제를보십시오 :

GetQueue ()를 호출하는 3 개의 다른 메소드가 있으며 이것을 올바르게 표현하고 있는지 궁금합니다. AddQueue () 흐름이 시각적으로 끊어진 것처럼 보입니다.

참고 : 플로우 차트에서 변경된 사항 :

메소드 호출에 서브 루틴 기호 사용 (사전 정의 된 프로세스)

나는 최근 몇 가지 순서도를 수행했으며 요즘 호출 할 수있는 것과 같은 문제, 서브 루틴 호출을 표시하는 방법 또는 메소드 및 함수 호출과 관련하여 어려움을 겪었습니다.

서브 루틴 호출과 서브 루틴 참조를 분리하는 규칙을 설정했습니다. 전자의 경우 프로그램 실행의 시점에서 유효한 변수를 사용하여 인수가있는 호출을 보여주는 일반 사각형을 사용합니다.

이중 기능 "사전 정의 된 프로세스"사각형을 해당 함수 나 하위 루틴의 정의를 포함하는 다른 플로우 차트에 대한 참조로 간단히 사용합니다. 서브 루틴 사각형은 서브 루틴의 인수를 보여줄 필요는 없습니다. 서브 루틴의 인수는 문제가되는 서브 루틴의 정의 순서도의 일부이기 때문입니다. 호출에 사용 된 실제 인수의 의미를 참조하십시오.

이것은 사각형의 수를 증가 시키지만 호출 된 함수 중 일부의 정의를 찾기 위해 다른 플로우 차트가 존재하는 것이 더 명확합니다. 종종 함수가 단순하면 별도의 다이어그램을 만들지 않고 구두로 문서화합니다.

또한 "문서"기호를 사용하여 코드 목록에서 세부 사항을 찾아야한다고 말합니다.

순서도의 요점은 프로그램을 만드는 것이 아니라 다른 사람들이 프로그램을 이해하기 쉽게 만드는 것입니다. 나는 조감도로서의 도움과 그 목적을 명심해야한다고 생각합니다. 그들은 프로그램의 모든 세부 사항을 시각적으로 설명하기위한 것이 아니며 필요한 경우 코드에서 세부 정보를 볼 수 있습니다. 순서도는 높은 수준의 관점에서 프로그램의 한 그림 일뿐입니다.

플로우 차트를 높은 레벨로 유지하면 코드가 수정 될 때 플로우 차트를 최신 상태로 유지할 필요가 줄어 듭니다.

그들은 사진입니다. 좋은 스토리 소프트웨어 문서와 마찬가지로 코드에 대한 대안 적 관점을 제공하는 그림도 있어야합니다.