僕は、ソフトウェアシステムの構造や処理の流れを絵で描くのが大好きです。
つうと、「UML図か」とか思われそうですが、UML図には気力が湧きません。
- 理由1：ナントカ図、カントカ図といっぱいありすぎる。
- 理由2：オブジェクト指向設計の影響が強すぎる。
UMLから派生したSysMLだと、図の種類も少ないし、オブジェクト指向風味も薄まっているようです。それでも僕には面倒な感じです。「フローチャートをめぐる迷信と妄言と愚昧」にも書きましたが、箱と矢印だけくらいの、少数の要素からなる絵がいいのです。
内容：
ロバストネス図
絵にするのは好きだがモノグサである僕にピッタリだと思えるのがロバストネス図です。ロバストネス図の要素は3つしかありません。ユースケース図の要素を入れても5つです。「ロバストネス図の概要」（http://www.ogis-ri.co.jp/otc/swec/process/am-res/am/artifacts/robustnessDiagram.html）から引用します。
元の図のURL: http://www.ogis-ri.co.jp/otc/swec/process/am-res/am/images/models/robustnessDiagramNotation.jpg
ロバストネス図より上流に位置付けられるユースケース図は、実装をどうするかを考える以前の段階で使う図です。ロバスト図はユースケース図と似てますが、バウンダリー（境界）、コントロール（制御）、エンティティ（実体）という3つの要素を導入して、抽象度が高いレベルで実装も考慮します。それぞれの要素の標準的な意味は：
- バウンダリー： 画面などのユーザーインターフェイス
- コントロール： システムにより遂行される処理の単位
- エンティティ： 領域モデル（の一部）に相当するデータプロバイダ
今これ以上はロバストネス図そのものに関する説明はしないので、次のURLなどを参照して下さい。
- UMLを描こう - Vol.5 ICONIXロバストネス図 - アシアルブログ
- http://blog.takeda-soft.jp/blog/show/114
- [Think IT] 第2回：ユースケース図を学ぼう！ (3/3)
- 実践ロバストネス分析 第1回 ロバストネス分析の基礎 | オブジェクトの広場
手書きにサイコー
絵の効果・効能を僕は高く評価します。しかし、コンピュータによる絵の入力は手間がかかるのでやる気になりません（画期的UIが出現すれば別ですが）。入力はテキスト形式（なんらかの人工言語）のほうが手っ取り早いです。既に存在する構造の可視化にはコンピュータ上で動くツールを使うのが便利だとは思いますけどね。
というわけで、自分の考えを整理するときには手書きの絵を使うことになります。ロバストネス図が素晴らしいのは、メチャクチャすばやく手書きできるところです。上に挙げた5つの要素の絵も手書きですよね、これが手早く描けるであろうことは見て分かるでしょう。
まず、基本図形にマルを使っているのが素晴らしい。手書きのとき、四角や三角はメンドクサイのですよ。「Webサービスを設計するための単純明快な方法」から引用：
素早く手書きしたいとき、四角を描くのはけっこう面倒なので、僕はマルを使います； 下の図の右のようです。
データプロバイダを表すために、筒の形（ディスクに由来する）とかも使いますが、これも手書きには向きません。
ロバストネス図では、マルに線を一本足しただけ、カンタン！
処理*1を表すために僕は、歯車を模した形を使ったりしたこともあるのですが、枯れたヒマワリなのか元気なアメーバなのか分からない変な形になってしまいます。描くのも手間。ロバストネス図では矢印付きのマル*2、いいですねー。
バウンダリーとインターフェイス
ロバストネス図の3つの要素のなかで、一番気に入っているのがバウンダリーのアイコンです。T字形の棒が付いたマルですね。マルから出た棒（T字）がインターフェイスと解釈できるのです。
一時期、MicrosoftがCOMの説明のために次のような図を使っていました。
箱から出ている棒はロリポップ（lollipop; 棒付きキャンディー）とかスプーンと呼ばれていました。このロリポップがインターフェイスを表現します。もっと具体的に言うと、オブジェクトが外部に公開しているメソッドやメソッド群が1本のロリポップです。
上の図で、ロリポップ以外に小さな長方形がありますが、これはプロパティ（属性とも言う）です。JavaBeansなどでは、メソッドとプロパティがはっきりと区別されていました。それ以外にイベントまで加えると、次のようなコンポネント図になります。
ウーン、なんか複雑化したな。ロバストネス図のように、マルから棒が出る程度に留めておいたほうがいいみたい。
とか言いながら僕は、ロバストネス図のバウンダリーをほんの少し拡張して使うこともあります*3。T字の棒を複数出してもいいとしているのです。バウンダリーオブジェクトはその名の通り、システム境界に置かれるので、どちら側のサブシステムにどんなインターフェイスを提供しているかを表すのに、複数の棒は便利です。次の図では、バウンダリーBが、サブシステムS1側に2つインターフェイス、サブシステムS2側に1つのインターフェイスを提供しています。インターフェイス1はアクター1に利用され、インターフェイス2はアクター1とアクター2に利用され、そしてインターフェイス3がアクター3に利用されています。
サブシステムS1とS2は、なにかの内部と外部のように考えるの場合が多いですね。そのときは、バウンダリーオブジェクトは外部に公開するAPIと内部向けAPIを提供していると解釈できます。人の形（スティックマン）をしたアクターは、ほんとの人間と解釈する必要はありません。インターフェイスの利用者ならソフトウェアがアクターであってもいいのです。
まとめ
ロバストネス図は、ユースケース図と比べると実装寄りですが、具体的過ぎることはありません。例えば、設計手法やプログラミング言語のパラダイムを前提したりはしません。ロバストネス図で描かれたシステム構造は、どんな手法／言語でも実現できます。
ロバストネス図によりシステムの詳細まで描くことはできませんが、絵が力を発揮するのは、比較的に概念的な大局構造の表現です。そのレベルの構造の記述には、ロバストネス図がとても役立ちます。そしてなにより、極めてすばやく描けます！
