프로그래밍을 처음 시작했을 때 플로우 차트 (및 프린터 간격 차트)에 크게 의존했습니다. COBOL 클래스에있는 동안 강사가 플로우 차트를 사인 오프 할 때까지 코드 작성을 시작할 수 없었습니다. 당시에는 모든 것에 대한 순서도를 만들어야했습니다.

25 년이 지난 지금, 저는 두 가지 유형의 흐름도 만 제시합니다. 논리가 까다 롭거나 매우 일반적인 개념 인 매우 구체적인 알고리즘을 사용하여 모든 큰 단계를 올바른 순서로 정의 할 수 있습니다.

내가 간과했던 플로우 차트에 대한 다른 사용 사례가 있습니까?

물론.

이전에 수행하지 않은 무언가를 구현할 때마다 (그리고 알고리즘이 몇 단계 이상이 소요될 때마다) 차트를 작성합니다. 나는 그것이 전체 솔루션을 도표로 작성하지 않은 것보다 더 원자 수준에서 더 철저하게 분석해야한다는 것을 알게되었습니다. 이 연습에는 세 가지 주요 이점이 있습니다.

• 내가 전체 알고리즘을 통해 생각했기 때문에 "오 쓰레기"가 적다.
• 나머지 시스템 전체에서 발생할 수있는 문제에 대한 잠재적 노크를 제거합니다.
• 알고리즘을 통해 다른 사람을 쉽게 걸을 수 있습니다.

실제로 이것을 사용하는 두 가지 경우는 다음과 같습니다.

• 낮은 수준의 알고리즘. 나는 매우 구체적인 문제에 대한 매우 구체적인 해결책을 의미합니다. 나는 일반적으로 구현하기 전에 피어에 의해 이것을 전달할 것입니다.
• 사용자 흐름. 이것을 사용하여 피어를 전달할 수있을뿐만 아니라, 기술 전문가가 아닌 매우 전문적인 방법으로 흐름을 설명하는 데 사용할 것입니다.

모든 것을 말했지만, 나는 매일 순서도를 생성하지 않습니다 (그리고 완료되었을 때조차도 기술 설계 문서를 작성하지 않는 한 일반적으로 화이트 보드 세션입니다).

못

순서도 (특히 25 년 이상 전에 실시한 것처럼)는 훨씬 더 표현적인 다이어그램 기법 (활동 다이어그램, 시퀀스 차트, 상태 차트 등 참조)으로 대체되었습니다.

IBM의 자체 연구에 따르면 플로우 차트 사용은 시스템 설계 또는 구현의 품질에 영향을 미치지 않습니다 (사용자 및 다른 개발자와 의사 소통하는 데 거의 유용하지는 않았 음) [정확한 참조는 쉽게 구할 수 없지만 James Martin의 Diagramming Techniques 에서 인용 됨) 분석가 및 프로그래머 용 ].

나는 1976 년 첫 프로그래밍 수업 이후 고전적인 순서도를 그리지 않았으며, 80 년대 초 이후로 다른 사람이 만든 것을 보지 못했습니다. 순서도는 코드가 어셈블리 언어 일 때 프로그램 논리를 전달하는 데 유용했습니다. 1960 년대 후반, 어셈블리 언어 프로그래머는 의사 코드를 사용하고있었습니다. 최신 OO 언어로 프로그래밍 할 때 순서도 나 의사 코드는 아무 가치가 없습니다. 구현 언어로 고급 코드를 작성할 수도 있습니다.

나는 때때로 디자인 아이디어를 표현하기 위해 주로 종이에 UML 다이어그램을 그립니다. 그러나이 다이어그램은 토론이 끝날 때까지만 존재합니다. 또한 상태 전이 다이어그램을 때때로 그린 다음 구현 언어의 상태 테이블로 변환합니다.

여러 가지 이유로 플로우 차트를 항상 사용합니다.

1. 내 의견으로는 UML 사용 사례 다이어그램보다 낫습니다. 다양한 사용 사례와 상호 작용 방식을 반영 할 수 있으며 전반적으로 사용자 경험과 의사 결정을 종합하여 더 나은 작업을 수행합니다.

2. 이해하기 쉽고 직관적입니다. 당신의 마음은 처음부터 끝까지 미로처럼 화살표를 따라갑니다. 플로우 차트를 사용하여 다른 사용자 스토리에 대한 다른 플로우 차트를 종료하고 참조 할 수 있습니다. 일반적으로 페이지 번호가 매겨진 책으로 인쇄하고 페이지를 빠르게 넘겨 다음 순서도로 이동할 수 있습니다.

3. 그들은 보편적입니다. 사용자 및 비즈니스 분석가가 플로우 차트 다이어그램을 훨씬 더 잘 인식 할 수있는 소프트웨어 엔지니어링 외부의 사람들이 UML 다이어그램을 알고 이해하는 사람은 거의 없습니다. 나는 복잡한 유스 케이스를 고객에게 전달하려고 시도하고 때로는 이해하기가 힘들고, 플로우 차트를 그려서, 왜 생각보다 복잡하게 만드는 모든 뉘앙스를 마침내 이해하는지 이해합니다.

순서도는 작업이 특정 순서로 수행되어야 할 때 유용합니다. 그들이 실제로 내 마음에 비추는 곳은 결정이 내려진 곳을 보여주고 가능한 각 결정에 길이 있는지 확인하는 것입니다. 이렇게하면 mamager 승인이 필요한 프로그램을 만들 수 없지만 관리자 (98 %의 시간을 승인 한 관리자)가 아니라면 처리 할 방법이 없습니다. 그들은 우리에게 가장 일반적인 길은 유일한 길이 아니라는 것을 상기시켜줍니다. 사용자에게 가장 일반적인 경로 만 알려주기 때문에 요구 사항에 대해 사용자와 대화 할 때 유용합니다.

순서도는 매우 잘못 구조화 된 코드의 리버스 엔지니어링에 유용 할 수 있습니다. 특히 고토가 있다면. 고맙게도 최근에 많은 코드를 보지 못했습니다.

다른 사람들이 최종 사용자와의 의사 소통을 위해 언급했듯이. 순서대로 문서화 된 TV 송신기의 시작을 정렬합니다. 하드웨어 및 소프트웨어 사용자는 공통 사양을 가지고있었습니다.

UML 활동 다이어그램 및 순서도는 프로세스 또는 알고리즘의 중간 정도의 복잡성을 보여주는 데 유용합니다.

비즈니스 규칙과 관련하여 비즈니스 사용자와 통신 할 때 매우 유용합니다.

비즈니스 프로세스 모델링에 매우 유용한 BPMN 2.0 형식의 변형이 있습니다.

일부 BPMN 도구는 차트에서 실행중인 웹 응용 프로그램을 생성 할 수 있습니다.

예, 흐름도는 여전히 자리가 있지만 현명하게 사용해야합니다.

나는 프로그래머가 아니다. 저는 하드웨어 엔지니어링 기술입니다.

적어도 사용할 논리 블록을 설명하는 주석으로 시작하는 것이 좋습니다. 그런 다음 실제 코드로 프로그램 스켈레톤을 수정하십시오. 스토리 보드로 영화 스크립트를 시작한 다음 액션 세부 정보 및 대화 상자를 채우는 것과 비슷합니다.

가치있는 노력을 신중하게 계획해서는 안됩니까? 하드웨어 영역에서 고객 요구 사항 문서로 시작한 다음 하드웨어 사양 문서를 작성한 다음 회로도를 작성하고 보드 레이아웃을 그린 다음 어셈블리 문서를 작성합니다. 우리는 최종 제품을 만들기위한 아이디어를 도출 할 때 부품을 잡고 함께 납땜하기 시작하지 않습니다.

실제 코딩을 시작하기 전에 많은 준비 작업없이 15KB 또는 15MB 프로그램으로 얼마나 효율적인 코드를 작성할 수 있는지 알 수 없습니다.