スケッチ、設計図、プログラミング言語UMLの利用法を再確認する（第11回）

ソフトウェア工学が誕生してから、40年が過ぎようとしている。今回からは、ソフトウェア工学が要求仕様にどのようにアプローチしてきたのかを、3回にわたって紹介していく。

「工学」とは何か。定義はいくつかあるが、いずれもややこしい。筆者流に分かりやすく言えば、工学とは「それに従って作業をすれば、同じ性能と品質が得られるような手順を研究する学問」となる。つまり、要求仕様の作成に対する工学的アプローチとは、「ユーザーの要求を正しくとらえ、システム仕様として表現する手順や技法を見出そうとする取り組み」のことである。工学的アプローチと要求仕様は、いかに離合集散を繰り返したのだろうか。以下で簡単に見ていこう。

要求仕様への工学的アプローチは、「あいまいさ」との格闘を繰り返してきた。

ソフトウェア開発手法が活発に研究されるようになったのは、1960年代のこと。これ以降、構造化設計技術やDOA（Data Oriented Architecture：データ中心開発手法）が提唱された。これらが発展して、オブジェクト指向という考え方に至ったのは、みなさんもご存じの通りである。

その一方で1970年代後半には、要求仕様があいまいであるために開発コストが増加するという問題が多発するようになった。この問題を解決するため、あいまいさを排除した厳密な要求仕様言語であるRSLが開発された。RSLとはRequirement Specification Languageを略したものである。「要求仕様言語」とでも訳せようか。

ところが、できあがったRSLはその厳密さゆえに実用に適さなかった。このため、実用的になるようあいまいさを許容するよう仕様に変更を加えていったところ、最後には自然言語と何ら変わらぬものになってしまった。

その後、1990年代に入ると多くの技術者がそれぞれ独自のオブジェクト指向技術について提案し、システムの設計図であるドキュメントの表記法を提唱。「OMT法」や「Booch法」「OOSE/Obectory法」「シュレイヤー／メラー法」といった表記法が乱立した。1994年になり、これらの表記法を統一しようという動きが生まれた。

こうした動きのなかで登場したのが、UMLである。UMLは、オブジェクト指向によるシステムの構造を図（ダイヤグラム）としてモデル化するときの表記法をまとめたもの。1997年、UMLはOMG（Object Management Group:オブジェクト指向技術の標準化団体）によって標準技法として認められた（図1）。OMGは、オブジェクト指向開発の表記法としてはUMLを、開発プロセスとしてはUP（Unified Process：統一プロセス）を利用するという統一方針を打ち出した。それ以来、今日に至るまでUMLはオブジェクト指向開発における表記法のスタンダードとして使われ続けている。

図1　様々なドキュメント表記法が統一され、UMLが生まれた（図をクリックで拡大）

ちなみに、UPとは「Use Case Driven」「Architecture Centric」「Iterative& Incremental」の3つを特徴とする開発プロセスのこと。具体的には、各成果物をユースケース図を元にUMLによって作成し、システムの統一的なアーキテクチャを確立したうえで、開発範囲を反復的に拡張していく手法である。

13種類の図を利用

図2　言葉で説明するより、図にしたほうが理解しやすい場合は多い

現在、UMLによるモデリングでは、13種類の図を用いる。なぜ、図を使うのだろうか。

人間は、目と耳を持っている。言葉を聞いて理解する耳と、ものを見て理解する目だ。目では、山や空といった風景や花瓶といったものを見るだけでなく、紙に書かれた文字を見ることによっても「言葉」という情報を理解できる。

我々は何かを表現するとき、主に文章を使っている。意思伝達の多くを文章に頼っているとも言える。しかし、時と場合によっては、図を使って表現したほうがより理解しやすい場合がある。「百聞は一見にしかず」ということわざがある通り、一度に得られる情報量では、目で見て理解できる情報のほうが圧倒的に多いからである。

地図がよい例だ。どんなに厳密な言葉を用いて目的地への行き方を記述しても、地図の分かりやすさにはかなわない（図2）。例えば、初めて上京した友人が、有楽町駅に到着したとする。この友人に、銀座での待ち合わせ場所を案内する場合を考えてみよう。これを携帯電話のメールで説明しようとすると、かなり苦労する。電話を使って話し言葉で伝えるにしても、結構な時間がかかる。

しかし、事前に有楽町駅と銀座近辺の地図を友人に渡してあったらどうだろう。ちょっとした目印を伝えるだけで、友人は迷うことなく待ち合わせ場所にたどりつけるだろう。これは、文章を目から入力して頭の中で地図の内容を解析し理解するよりも、図として直接脳へ取り込んだ方が早いからである。

何かを表現するとき、あるいは何かを理解するときに、言葉や文字は非常に役に立つ。しかし、時と場合によっては図を使って表現したり理解したりすることも必要である。上に挙げた地図の例のほかにも、天気図や鉄道路線図などを想像してみれば、納得いくだろう。

建築業界に学ぶ

システム開発との類似性を指摘されることが多い建築・設計業務では、図を効果的に利用する方法を確立している。ここでは、注文住宅を設計するケースを想定してそのあらましを説明する。

まず最初に、施主は建築士に対して自分がどんな家がほしいかを説明する。次に、建築士は施主の要望を基に諸条件を勘案しながら建物を計画し、図面を作成する。作成する図面には「設計図」のほか建物の自重や台風、雪、地震などに対する強度を考慮した「構造図」、電気設備や機械設備を配置した「設備図」などがある。建築士は、施主に対して言葉だけでなくこれらの図を見せながら説明する。

各種図面を見ながら建築士の説明を聞くことによって、施主は建築後の建物のイメージを想像し、それが自分の理想の建物かどうかを判断できる。もし、想像と理想像が異なっていれば、施主は具体的に変更の指示を出すことができる。

このように建築業界は、施主と建築士の考えを共有するために様々な図を活用する技法をとうの昔に確立している。ひるがえってシステム開発を見ると、そうした技法をまだ模索している段階と言わざるを得ない。建築技法は、人間の歴史とともに成長してきた。一方、システム開発の歴史はまだ半世紀ほどだ。建築技法にくらべてシステム構築技法が未発達であるのも、無理のないことかもしれない。

道具としてのUML

図3　UMLの使い方には、大きく3種類ある

先に述べたように、システム開発の世界でも建築業界が活用しているような統一的技法を実現しようという取り組みはもちろんある。そのなかで最も普及が期待されているのが、UMLである。

UMLには、大きく3つの使い方がある。「スケッチとしてのUML」「設計図としてのUML」「プログラミング言語としてのUML」である（図3）。

（1）スケッチとしてのUML

スケッチとは、風景や事物を大まかに写しとることである。これと同様に、UMLによってシステムの外観を呈示できる。スケッチとしてのUMLは、フォワードエンジニアリングやリバースエンジニアリングの方針を示す材料として使える。フォワードエンジニアリングでは、UMLをコードを書く前に描く。リバースエンジニアリングでは、既存のコードからUMLを作成し、コードを理解しやすくする。

スケッチとしてのUMLは、これから作ろうとしているシステムについてのアイデアや選択肢を話し合うのに役立つ。例えば、様々な開発作業を事前に取捨選択できる。 あるいは、実装を予定しているコードを大雑把に列挙して、その妥当性についてチームで話し合うことができる。

（2）設計図としてのUML

UMLは、システムの設計図として用いられることも多い。設計図としてのUMLには、特に完璧を期さなければならない。作成したUMLが完璧であれば、プログラマーはそれに忠実に従ってコードを書けばよい。UMLに不備があると、開発ミスによる手戻りが発生する危険が増す。

（3）プログラミング言語としてのUML

UMLを熟知し十分な開発経験があれば 、UMLをプログラミング言語として扱うことができる。JudeやEclipseといったツールを使えば、UML図から実行可能なコードを生成できる。

難解さが課題

先に、建築では設計図や構造図、設備図といった各種の図を、表現したい目的に応じて使い分けていると述べた。UMLによるモデリングでもこれと同様に、目的に応じて13種類の図を使い分ける。図4に、要求定義・分析・設計・実装という4つの開発工程でそれぞれ用いられるUML図をまとめた。当然ながら、要求モデリングを基にして分析モデリングを行い、分析モデリングを基にして設計モデリングを行う。このように工程の段階が進むごとにUMLモデリングの内容も進化する。要求仕様を作成する際には、主に「クラス図」「ユースケース図」「シーケンス図」の3つを使用する（図5）。

図5　要求仕様を作成する際によく用いる3つのUMLモデル

クラス図は、クラスの構造と複数のクラス間の関係を定義するモデル図だ。ユースケース図では、利用者の視点でシステムの機能（＝システム要件）をまとめる。シーケンス図は、時系列に着目して、オブジェクト間のやり取り（＝相互作用）を表現する。

UMLには問題点もある。モデル図の種類が多いうえに、1つひとつが難解で習熟に時間がかかることだ。「ユーザー部門の担当者との打ち合わせで、システム担当者がクラス図を持ち出したら、途端に話が行き詰まってしまっ」たといった話を聞くことは珍しくない。システム開発への工学的アプローチは、まだ敷居が高いらしい。

次回は、具体的な事例を設定してUMLモデル図を作成してみる。題材は、広告誌の業務を効率化することを目的にした新システムである。自社の営業や編集担当者が顧客と原稿をやりとりし、編集作業を進めて記事を作成し入稿するまでの過程をユースケース図やクラス図などを使って表現する。