|
本サイトは移転しました。旧アドレスからのリダイレクトは2025年03月31日(月)まで有効です。
|
🛈 | ✖ |
統一モデリング言語(UML)はオブジェクト指向プログラミング分析や設計のためのモデリング言語。
古代、プログラマはフローチャートを方眼紙に書き、ソースコードを手書きしてパンチカードの束に孔を開け、ASCIIアートのモナリザを壁に貼る大型計算機センターへ赴き、カード束を読み取り装置に通して半日待ったジョブの実行時間は5分にも満たず、ラインプリンタが#を連ねて表紙に大書きしたユーザーIDを頼りに出力を拾い出し、それはコンパイルエラーのみを報告して肝心の計算結果は今回も得られない。以来、フローチャートはプログラミングを視覚表現する最重要ツールの地位を長く占めたが、オブジェクト指向プログラミングがそれをUMLクラス図に変えた。
UMLはプログラミングを記述するグラフィカル言語で13種類のダイアグラムで構成される。サイト作成者が理解するのはクラス図、アクティビティ図、シーケンス図だけだが不足を感じる事は無い。最重要は静的構造を記述するクラス図で多くの教科書がプログラミングを視覚表現する手段として用いる。動的振る舞いを記述するフローチャートはアクティビティ図と名を変えて残るが使用機会は少ない。
手続き型プログラミングをフローチャートで視覚表現するのは当然の成り行きだった。サイト作成者もN-BASIC以前(大学の算法通論)より何十年も親しみ、オブジェクト指向プログラミングでも特に変わらなかった。
しかしGoFデザインパターンが代表するオブジェクト指向分析設計(Object-Oriented Analysis and Design, OOAD)はUMLクラス図を強要する。OOADはアルゴリズムをオブジェクト指向プログラミングの"対象"とする。アプリケーションは一つのオブジェクトで表され、そのオブジェクトは様々なアルゴリズムを表す複数のサブオブジェクトから成り、サブオブジェクトはさらに複数のサブオブジェクトから成るかもしれない。プログラミングはオブジェクトの相互関係で表され、動的振る舞いはオブジェクトの内側に隠蔽される。このように記述されたソースコードを俯瞰するには確かにオブジェクト同士の静的関わり合いが重要なのだろう。
プログラミングは頭の中の"やりたい事"からスタートし、それはコンピュータ上で実行する動的な事象である。仕様書や設計書無しで書き始めるソースコードはダイナミックで騒がしいが、コーディング進行で動的振る舞いはサブオブジェクトへ委譲されて静寂に向かう。コーディング完了時にソースコードは静謐に満ち、しかし個別の処理に責任を負うサブオブジェクトは明白だ。これがサイト作成者が理想とするプログラミングで、サンプルコードはその一例としたつもりであり、UMLクラス図がそれを視覚表現する。
本サイトはUMLクラス図作成にPlantUMLを使用する。PlantUMLはリンクからJavaの圧縮バイトコードファイルであるplantuml.jarをダウンロードして適当なディレクトリ(例えばC:\Users\user\CodeBlocks\bin)に配置する。実行には事前にJavaをインストールしておく。Doxygenで使用するにはDoxyfileに以下のオプションを追加して、Doxygenコマンド\startumlと\endumlの間にPlantUMLコードを記述する。
以下に本サイト使用の凡例を簡単にまとめる。クラステンプレートとその特殊化の表現は恐らく文法に背くが容赦いただきたい。