このブログの更新は Twitterアカウント @m_hiyama で通知されます。
Follow @m_hiyama

メールでのご連絡は hiyama{at}chimaira{dot}org まで。

はじめてのメールはスパムと判定されることがあります。最初は、信頼されているドメインから差し障りのない文面を送っていただけると、スパムと判定されにくいと思います。

［参照用 記事］

フローチャートを復権させよう -- 2020年代のプログラミングへ

雑記／備忘

「悟りやヒラメキがほんとに大キライだ 」という記事を書いた背景には、ユースケースの「主／副シナリオ」、「<<extend>>, <<include>>」とかの概念にウンザリしたことがあります。あれから後も、この件がどうも気にかかっていて、『ユースケースの適用：実践ガイド』（asin:4894711869）という本を恵比寿の有隣堂で見つけてすぐ購入しました。

この本には、僕が疑問に思っていた点が説明してあって、理解に役立ちました。ある程度は理解できた事と、その内容に賛同するかどうかは別問題でして、（理解してもなお）納得のいかない点は多々あります。その話は、まーいずれするかも。

ところで、この『ユースケースの適用：実践ガイド』の第5章「ユースケースを図で表現する」の冒頭に次のような文があります。

これまで、長い時間をかけてユースケースのテキストを書いてきました。しかし、ことわざにもあるとおり、1枚の絵は千の言葉に値します。そこでこの章では、ユースケースを詳細化したり明確にするのに使うことができる2種類の「絵」に目を向けます。

2種類の「絵」のひとつはアクティビティ図です。

アクティビティ図は、この数十年にわたって、さまざまな名前のもとに数々の形式で使われてきました。

アクティビティ図って、フローチャート以外のなにものでもないですよね。各部の名称とかアイコンとかに多少の差異（あるいは揺らぎ）はありますが、基本は4,50年前と変わってません。今日話したいことは、アクティビティ図＝フローチャートのことです。

「この数十年にわたって、さまざまな名前のもとに…」と書いてありますが、実際、フローチャートの別名はやたらにあります。アクティビティ図（activity diagram）もその1つです。もう少し広義だとステートチャート図（statechart diagram）と呼ぶんだそうです。2009年に書いた記事「フローチャートからマゾ・テストまで」のなかで言及した名称には、フローダイアグラム（flow diagram）、フローグラフ（flowgraph）、フローノミアル（flownomial）、ネットワーク（network）などがあります。

そんなに別名を作ってどうすんだよ!? と思いますね*1。

どうしてこんなにたくさんの呼び名があるのでしょうか？ 何度も再発明・再発見されたって事情もあるでしょうが、一時期フローチャートは随分とバッシングされたので、名前を変えて違うモノにみせかけようという意図もあるんじゃないでしょうか。バッシングされたところで、違う名前で同じ概念が延々と（「この数十年にわたって」）再出現しています。

先日テレビ放映されたあの映画のセリフを借りるなら：

フローチャートの構造

フローチャートによるプログラムの表現は、一時期、構造化プログラミングの対極のように扱われました。構造なんてないグチャグチャのスパゲッティだ、と。しかし実際には、フローチャートには整合的で美しい構造があります。構造化プログラミングの黎明期では、そのような構造を認識し解析できる理論も技法も整備されてなかったので、フローチャートの扱いが困難だったのは事実です。

扱うのが困難、だから使うべきではない； と、それは当時は無理もない妥当な判断だったでしょう。しかし、現在ではフローチャートを扱う準備は出来ているといえます。20世紀中盤でもエルゴットやステファネスクのように積極的にフローチャートを研究した人もいますが、基本的な道具であるトレース付きモノイド圏／前モノイド圏（traced monoidal category/premonoidal category）が一般化したのは1990年代から今世紀に入ってからです。

トレース付きモノイド圏に関連することは次の記事と、そこからのリンク先で触れています。

フローチャートと結び目理論

フローチャートは絡んだ糸のような図形です。ですから、それを扱うには結び目（knot）やもつれ（タングル、tangle）の理論がある程度は必要です。しかし、計算現象では（量子計算を除けば）ブレイド（組み紐）は現れなくて置換（対称）で済みます。本質的に結んだりもつれたりはしてなくて、糸が互いにすり抜けてほどける事が多いのです。

ですから、事情はずっと簡単で、本格的に結び目／もつれを扱う必要はないでしょう。でもまー、ブレイドの場合もちょっとは知っておいたほうが楽しい気はします。面白半分もふくめてブレイドやアミダ（置換、対称）を扱った記事は次です。

ブレイドが付いたトレース付きモノイド圏を積極的に使うスタイルの結び目理論は、関手的結び目理論（functorial knot theory）と呼ばれているようです。この関手的結び目理論の方法は、フローチャートを扱う上でも有効そうに思えます。

制御フロー vs. データフロー

しばしば指摘されるフローチャートの欠点は、ワケワカンナクなるということです。実際、制御もデータも勝手気ままに飛び回るスタイルのプログラムはワケワカンナイです。この点ではフローチャートを擁護する気はありません。

しかしこれは、制御フローとデータフローの両方に自由度があり過ぎるのが問題なのです。どちらか一方でも制約をすれば、ずっとわかりやすくなります。かつての構造化プログラミングでは、制御構造を制約して、変数概念とその破壊的代入は許容しました。逆のアプローチもあるのではないでしょうか？ 制御構造の奔放さは開放して、変数概念をなくしてデータは制御と一緒にしか流れない、とするのです。

我々が開発しているCatyScriptも最初は、変数を認めず、制御フローと共にデータを運ぶ方式でした。残念ながらとても使いにくいことが判明してしまいました。結局、変数を認めましたが、単一代入で、破壊的代入は許しません。

変数を制限して、制御の自由度を増やすと、call/returnに拘る必然性は薄くなります。むしろ、行きっぱなしの制御遷移のほうが使いやすく感じます。継続渡しスタイル（CPS)ですね。継続渡しや米田埋め込みの話は次の記事とそこからのリンク先を見てください。

トレース付きモノイド圏などに関する参考文献

このダイアリーのなかで引用したことがある資料をいくつか再掲します。

トレース付きモノイド圏に関しては、この分野のパイオニアである長谷川真人（はせがわ・まさひと）さんによる一連の論文／解説があります。

他に：

以上の論文／論説には絵が描いてありますが、http://www.staff.science.uu.nl/~jeuri101/afp/afp4/ の下からダウンロードできる Paul Hudak "Robots, Arrows and Functional Reactive Programming"（hudak.ppt）の中ほどの Graphical Depiction の箇所に出てくる絵も面白いです（すぐ下に貼り付けてあります）。このスライドに対応する論文は：

アロー（arrow）に関わる資料は「大量のモナド類似物を取り扱う方法：参考文献」にまとめてあります。

フローチャート・リローデッド

1990年代以降、トレース付きモノイド圏／前モノイド圏の計算科学への応用は長足の進歩をしました。いまや、フローチャートは科学として扱えるのです。再びプログラミンミングの有効な道具としてフローチャートがカムバックする準備は出来ています。忌まわしい過去は忘れましょう。

時代は変わったのに、「フローチャートってダメなんだよね」とか根拠もなく盲信しているのって、なんなの？

*1:とか言っておきながら、僕も別名「スパイダーグラフ」を使っていたりします（http://d.hatena.ne.jp/m-hiyama-memo/20111213/1323741530）。言い訳しておくと、もともとある種のシーケント計算である「スパイダー計算」の絵図表現だったからです。