UMLの9種類の図は，システム開発の要求分析，設計，開発，配置の各工程で使うことができる。どの工程でどの図を使うかは明確に決まっていないので，自由に使ってほしい。多くの場合，システム開発の最初の段階でユース・ケース図を作成し，次いでクラス図を作成する。クラスは要求仕様の中に登場する名詞が候補となるが，その中からクラスとして適当かどうかを判断し，適切な名詞のみをクラスとする。その際，クラスの属性や操作を具体的に考えると判断しやすい。
情報システムの設計に有用なモデリング言語「UML＊」を，初心者向けに解説するセミナーの第3回である。今回と次回の2回に分けて，実際のシステム開発でUMLを活用する方法を解説する。
何事にも言えることだが，基礎の習得は大事である。基礎を知らないまま何となく実践していると，いずれ壁にぶつかり挫折してしまう。様々な応用テクニックだけを先に知ってしまうと，何をすれば良いのかが分からなくなり，自らのアイデアを具現化できないということも多々ある。それは，UMLにも当てはまる。今回はUMLの活用方法を解説するが，UMLをうまく活用するにはUMLの各図とUMLのベースとなるオブジェクト指向＊の習得が欠かせない。
そこで，最初に簡単にオブジェクト指向の基礎と，UMLの9種類の図（表1[拡大表示]）との対応を再確認し，基礎知識の整理をしておこう。これまでの連載をお読みいただいた皆さんなら，すんなり理解できるはずだ。その後で，具体的な例を基にUMLの各図を作りながら，システム開発におけるUMLの使い方を解説する。
基本はクラス，動きはメッセージで表す
オブジェクト指向では，クラスとオブジェクトを区別する。クラスは，オブジェクトの定義（クラス名，属性，操作を示したもの）である。オブジェクトは，クラスが実体を持ったものである。このように区別する理由は，1つのクラスから複数のオブジェクトが作られることがあるからだ。例えば，「従業員クラス」は定義であり，「鈴木君」，「佐藤君」，「田中君」は，従業員クラスの実体（オブジェクト）である。UMLでは，クラスを「クラス図」で表し，オブジェクトを「オブジェクト図」で表す（図1[拡大表示]）。
オブジェクト指向では，オブジェクトのメッセージ・パッシングと状態の変化（または遷移）でシステムの動きを表す。メッセージ・パッシングとは，他のオブジェクトが持つ操作（プログラム的には関数）を呼び出すことである。オブジェクトの状態の変化とは，オブジェクトが持つ属性（プログラム的には変数）の値が変化することだ。UMLではメッセージ・パッシングを「シーケンス図」または「コラボレーション図」で表し，状態の変化を「ステート・チャート図」または「アクティビティ図」で表す（図2[拡大表示]）。
オブジェクトのメッセージ・パッシングや状態変化を考える単位となるのが「ユース・ケース」であり，ユーザー（アクター）とユース・ケース（システムの使われ方）の関係を示すのが「ユース・ケース図」である。
もうこれでUMLの9種類の図のうち，7つが説明できた。これら7つは論理的な図だが，実際の開発においては物理的な図も必要となる。物理的な図には「コンポーネント図」と「デプロイメント図」があり，ファイルの構成や，コンピュータへの配置方法を表す。
以上でUMLの図はすべてだ。改めて整理してみると，何とも簡単なものだと感じただろう。
システムの開発手順とUML
次に，システム開発のどの工程で，UMLのどの図を使うかを説明しよう。システム開発の手順には大きく分けて「ウオーターフォール・モデル」と「スパイラル・モデル」の2つのスタイルがあるので，まずは2つのスタイルを簡単に説明する。
ウオーターフォール・モデルとは，「要求分析」，「外部設計」，「内部設計」，「プログラム設計」，「プログラミング」，「テスト」，「配置」という手順を厳守して，それぞれの工程のレビュー（評価）を行ってから次の工程に進むという開発スタイルである（図3左[拡大表示]）。ウオーターフォール（waterfall＝滝）という言葉が示す通り，後戻りせずに全体の整合性を維持しながら開発することを目的としている。その通り実践できるかどうかは別として，昔からシステム開発手順の規範となっている開発手順である。
一方のスパイラル・モデルとは，システム開発の工程を大きく「要求分析」，「設計」，「開発」，「配置」に分け，それぞれの工程を小さな単位で繰り返しながら徐々にシステムとしてまとめ上げていく開発スタイルである（同右）。スパイラル（spiral＝らせん）という言葉が示す通り開発を繰り返すことが特徴であり，部分的にシステムを運用しながら機能を追加していくこともできる。システムの一部を短期間に提供したい場合に適し，ウオーターフォール・モデルと比べると仕様の変更に強い開発手順だと言える。
UMLのベースとなっているオブジェクト指向開発では，スパイラル・モデルが適していると言われる。オブジェクトの単位で，スパイラルを実現できるからだ。ただし，ウオーターフォール・モデルでオブジェクト指向開発ができないというわけではない。開発手法とシステム開発手順は独立した関係にあり，オブジェクト指向開発だからといってスパイラル・モデルでなければならないわけではない。とは言うものの，最近のシステム開発は大規模かつ短期開発が求められているので，スパイラル・モデルが注目されている。以下の説明もスパイラル・モデルを基に行う。
設計，開発工程とUMLの各図の関係
スパイラル・モデルの4つの工程で，どのようにUMLが使われるかを説明しよう。あらかじめお断りしておくが，どの工程でどの図を使うのかは開発者に任されており，必ずこうやって使わなければならないというものは無い。これから説明するのは，あくまでも目安である。
(1)要求分析，(2)設計，(3)開発（プログラミング），(4)配置——の各工程と，UMLの各図の関係を図4[拡大表示]に記した。(1)要求分析の工程では，ユーザーの要望をヒアリングする。ユーザーは，システムの内部構造などおかまいなしに，システムをどのように使いたいかを話すだろう。これを図示するには，「ユース・ケース図」がピッタリだ。ヒアリング内容をユース・ケース図で示せば，それをユーザーにレビューすることもできる。ユース・ケース図は，コンピュータの知識の少ないユーザーでも理解できるものである。
要求分析の工程では，ユース・ケース図だけでなくシステムの要求仕様を文書でも表すはずだ。この文書の中に登場する名詞が，システムを構成するクラスやオブジェクトの候補となる。なぜなら，名詞は物（オブジェクト）を表す言葉だからである。クラスを洗い出して「クラス図」を作成する。クラスの属性や操作は後から決めるものなので，最初はクラス名だけを決めればよい。クラス名が決まったら，個々のクラスの属性と操作を洗い出し，クラス間の関連を考えてクラス図を徐々に完成させていく。
後は，必要に応じて「オブジェクト図」，「ステート・チャート図」，「シーケンス図」，「コラボレーション図」などを作成する。これらの図が，システムの要求分析に使われる。
(2)設計の工程では，要求分析の結果を基にして，システムを具現化する方法を考える。ここで作成されるのは，「アクティビティ図」，「コンポーネント図」，「デプロイメント図」などだ。要求分析と設計の工程は，明確に線引きして区別できるものではない。要求分析で作成された図を，設計工程において修正，詳細化，拡張することもある。
(3)開発（プログラミング）の工程では，前工程で作成した各種の図を参照しながら，プログラムのソース・コードを記述する。UMLはプログラムのアルゴリズムやデータベースの構造を表すものではないので，必要に応じてフローチャート＊など他の図を作成する。
(4)配置の工程では，デプロイメント図を参照し，ユーザーの環境にシステムをインストールする。ソース・コードのドキュメントやシステムの運用マニュアルも作成することになるが，その書式はUMLでは規定されていないので自由に作成すればよい。
UMLの各種の図は，必ず特定の工程だけで使われるというものではない。例えば，要求分析の工程でコンポーネント図やデプロイメント図を書いても構わない。9種類のすべての図を必ず作成しなければならないわけでもない。ある工程で概要図であったものが，他の工程で詳細図に拡張されながら，必要に応じて何度でも利用される。複数の図を組み合せて使ってもよい。とにかく自由にUMLを使ってほしい。
|
矢沢 久雄（やざわ ひさお） グレープシティ（旧文化オリエント）アドバイザリースタッフ |
