フローチャートはアルゴリズムを表現する手段として広く使われた。今[いつ?]でもその用途で使う者もいる[8]。

しかし、1970年代になると対話型端末と高水準言語が一般化し、ソースコードでもっと簡潔にアルゴリズムを表現できるようになり、フローチャートの人気は減退した。また、フローチャートはgoto文を多用したスパゲティプログラムそのものであるとも言え、アルゴリズムの表現としては、特定のプログラミング言語の詳細に関わらない擬似コードがよく使われるようになった。また、#構造化フローチャートという試みもある。

UMLのアクティビティ図はフローチャートを表記変更および拡張したものとも言える。ただし、アクティビティ図は制御フローだけでなく並行動作やデータフローもある程度表現できる。
フローチャートの部品
例Nの階乗 N! を計算するフローチャート

右図は、階乗の計算方法を示したフローチャートである。

最も重要で注意すべきなのは、階乗を計算するアルゴリズムの本質は、箱の中に補助的に（したがって以下の解説ではロクに触れていないが）書かれている、変数を参照している演算式や、変数の代入といったもので表現されていて、「フローチャート」の箱や矢印は、その順序付けを表現しているに過ぎない、ということである。
部品

各工程（処理）を示す絵図の標準の一つとしては「情報処理用流れ図・プログラム網図・システム資源図記号」[9]があり、またその他に多数の標準や規格や仕様や各社まちまちのローカルルールなどがある。
端子
円、楕円、角が丸められた長方形などで表現され、その中に「開始」または「終了」といった単語か、それに類する文が書かれる。プロセスの開始と終了を示す。
流れ線と矢印
制御の流れを示す。部品間をつなぐように描くことで、制御が部品から部品へと流れることを示す。常に矢印を使う作法もあるが、流れ線を使う場合は上から下に制御が流れることを表し、それ以外の方向の場合に矢印を使う。JISでは別の部品の上辺に到達するよう描くように標準化しているが、そうではない作法もある。破線も使われることがあるが、その意味は様々である。
処理
長方形で表現される。中には具体的な処理を「Xに1を加算」、「識別した部分を置換」、「変更をセーブ」などと記述する。
定義済み処理
長方形の左右の辺を二重線にした形で表す。別のフローチャートで詳細に描かれた工程を参照するのに使う。定義済み処理はサブルーチンなどに相当するが、入口と出口が複数存在する場合もある（コルーチン参照）。その場合、どの入口から参照するかを示す記述が必要となる。
入出力
平行四辺形で表現される。中には例えば「ユーザーがXを入力」、「Xを表示」などと書かれる。
準備
六角形で表現される。後続の「判断」で使用する値を準備する操作が書かれる。
判断
菱形で表現され、一般に「Yes/No」あるいは「真/偽」が答えとなる判断を表す。2つの流れ線または矢印が出て行く点が他の部品とは異なる。出て行く流れ線は、下の頂点と右（または左）の頂点から発するのが一般的で、一方が「Yes」または「真」、もう一方が「No」または「偽」に対応する。そのため常にラベルを添えて意味を示す必要がある。3つ以上の線が出て行く場合もあるが、それは判断が複雑であることを意味し、複数個の「判断」で詳細化することができる。あえてswitch文に相当する書き方をする場合は、下の頂点から発した流れ線を分岐させる形で描くのが一般的である。
合流
一般に黒い点で表し、複数の制御の流れが合流して1つの流れとなることを示す。他の種類の図法で使う、丸「◯」の中に円周に接さない十字記号「+」を入れた記号を流用することもある。合流シンボルには複数の矢印が到達し、1つの矢印が出て行く。JISでは単に流れ線の途中に矢印が接する形で合流を表すと標準化している。一般には「判断」によって別れたものを再び合流するなどに使うのであるが、反復処理をループによって実装したり、何らかの本来ならば別の一連の手続きとして切り出すべきものを、その先頭への流れに合流させて済ませたり、など、スパゲティの元である。そのためかUMLのアクティビティ図は、「判断」によって別れたものの再合流には、専用の「判断」と同じ形状の菱形を使うこととした[注釈 2]。JISでは反復を専用に表現する部品があり、そちらを使うべき（使わなければならない）であろう。また、作図の都合上2つの流れ線が交差することがあるが、その場合は合流ではないことを示すために一方の線を小さな半円状に曲げてもう一方の線をまたがせることがある。
結合子
円の中に識別用ラベルを記した形で表現される。複雑なフローチャートで矢印や流れ線の代わりに用いられる。ページをまたがるような場合、JISではホームベース形の結合子を用いると標準化しているが、特に区別しない方式もある。同じラベルの結合子同士が流れ線でつながっているかのように扱われる。結合の終点となる側は一意なラベルを付与し、起点となる側が終点となる側と同じラベルを付与する。起点側は複数でもよく、その場合は合流シンボルを含意する。
並行性
二重の水平な線で表現され、上に複数の流れ線（矢印）が入り、下から複数の流れ線（矢印）が出る形で表現される。これによって複数の同時並行的に行われる制御フローを表す。入ってくるフローが全て二重線に到達すると、出て行くフローが全て同時に開始される。入力フローが1つの場合を「フォーク」、出力フローが1つの場合を「ジョイン」と呼ぶ。

部品の論理的順序を保つことが重要である。あらゆるプロセスは上から下、左から右に流れるべきである。
データフロー的拡張

制御フローではなくデータフローを表現するデータフロー図を描くための部品の規格化が行われてきた。そのような部品は制御フローを表すフローチャートでも特に平行四辺形の「入出力」部品を詳細化するのに使われている。

なお、そもそもコントロールのフローとデータフローは違うものであるため「（フローチャートの）データフロー的拡張」として両者を混用すると、フローチャートの「代入などの操作を表現する箱」と、データフロー図の「データを保持したり加工する実体を表現する箱」が混在することになり、同様に「順次的な手続きの流れ」を表現する矢印と「データの流れ」を表現する矢印が混在することになる。

長方形の下辺を波形にした図形で、「書類」を表す。

上辺が左から右に斜めに上がっている四角形で、「手操作入力」を表す。例えば、帳票へ書き込むことを表す。

上底の方が長い台形で、「手作業」を表す。人間が自ら行うしかない作業や調整を表す。

円柱形で「データファイル」を表す。

様々なフローチャート

Sterneckert (2003) によれば、フローチャートは様々なユーザーグループ（管理者、システムアナリスト、事務員など）の異なる観点からモデル化でき、それらは次の4種類に分類できる[10]。

文書フローチャート - システム内の文書の流れについての制御を示す図

データフローチャート - システム内のデータの流れについての制御を示す図

システムフローチャート - 物理レベルまたは資源レベルの制御を示す図

プログラムフローチャート - システム内のプログラムにおける制御を示す図

どのフローチャートも流れ自身ではなく、ある種の制御に着目したものであることに注意が必要である[10]。自動車の運転をフローチャートでモデル化したもの

他にもいくつかの分類がある。例えば、Andrew Veronis (1978) は、システムフローチャート、概要フローチャート、詳細フローチャートという3つに分類した[11]。また同年、Marilyn Bohl (1978) では「実際、ソリューションプランニングにおいてはシステムフローチャートとプログラムフローチャートの2種類のフローチャートが使われる」と記している[12]。さらに最近の Mark A. Fryman (2001) ではさらに様々な種類があるとし「意思決定フローチャート、論理フローチャート、システムフローチャート、製品フローチャート、プロセスフローチャートは、ビジネスや政府で使われている様々なフローチャートのほんの一部である」と記している[13]。

さらに、フローチャートとよく似たダイアグラム技法を異なる名前で呼んでいる場合もあり、例えば、UMLのアクティビティ図がある。
株式公開・内部統制向けフローチャート

JISで標準化された図法は、工業・情報処理でどうしてもフローチャートで書かなければならない場合に用いられることが多い。一方、株式公開や内部統制のフローを描く場合には、以下のような形式のフローチャートを用いることがある。
NOMA方式
日本経営協会 (NOMA) の理事であった、三枝鐘介によって作られたもの。使用する記号を抑えて、シンプルに記述するのが特徴。
日能式
日本能率協会によって作られたもの。思想はNOMA方式に近い。
産能大式
学校法人産業能率大学によって作られたもの。NOMA方式に比べ、「FAX」「コピー」等の具体的な記号を用いているのが特徴。