処理の流れを図で示そう
ここでは例として、画面Ａで入力した値を、画面Ｂで表示するだけの、単純なアプリケーションを考えてみましょう。
このアプリケーションはとても単純ですが、きちんと設計書を書いておくことにしましょう。
ソフトウェアの仕組みは、図で示すと分かりやすくなります。オブジェクト指向で設計したソフトウェアであれば、やはり、UMLを使うのが良いでしょう。
さて、このアプリケーションでは、初めに画面Ａで値を入力し、その後、画面Ｂで値を表示する、という流れがあります。このように、時間の経過とともに進んでいく処理の流れを示すには、UMLの中でも、シーケンス図を描くと良さそうです。
順序だけのシーケンス図は意味がない
ここで、あなたならばどんなシーケンス図を描くでしょうか？
Ｘさんが描いたシーケンス図は、次のようなものでした。
しかし、このシーケンス図は、あまり意味がありません。
確かに、この図は「初めに画面Ａを表示し、その後、画面Ｂを表示する」という動作を表しています。しかし、画面を見せる順序を示したいだけならば、シーケンス図など使う必要はありません。むしろ、次のようなかんたんな図を描いた方が、分かりやすくて良いでしょう。
では、何故Ｘさんのシーケンス図は、意味のないものになってしまったのでしょうか。それは、シーケンス図を描く目的を誤解してしまったためです。
Ｘさんは、「画面Ａの次に画面Ｂを表示する」という、画面を見せる順序を第一に考えてしまいました。しかし、むしろここで重要なのは、「画面Ａで入力した値が、画面Ｂに受け渡される」という仕組みです。そのためには、画面Ａや画面Ｂだけでなく、受け渡されるデータ自身も、重要な登場人物となります。
画面とデータの連携を示す
そこで、シーケンス図にデータを表すオブジェクトも登場させてみると、次のような図ができました。
２つの画面とデータオブジェクトが、互いに連携している様子が表されています。
さきほどのＸさんの図と違って、このシーケンス図は、意味のある図になっています。それどころか、アプリケーションの動作仕様を示すのに、このシーケンス図は欠かすことができません。
オブジェクトの役割分担と、シーケンス図の存在意義
このシーケンス図には、４つのオブジェクトが登場します。しかし、これらのオブジェクトは、それぞれ役割が限定的に定められています。
| オブジェクト | 知っている範囲 | 知らない範囲 |
|---|---|---|
| 画面Ａ | 入力された値をデータオブジェクトにセットすることまでは知っている。 | セットされた値がどう使われるのかは知らない。 |
| 画面Ｂ | データオブジェクトにセットされた値を表示することは知っている。 | それを誰がセットしたのかは知らない。 |
| 制御部 | 画面Ａの次に画面Ｂを表示することは知っている。 | 画面Ａが値をセットしたり、画面Ｂが値を表示していることは知らない。 |
| データ | 値がセットされたり、参照されることは知っている。 | いつ誰がセットし、いつ誰が参照しているかは知らない。 |
いずれのオブジェクトも、限られた範囲しか知りません。それぞれのオブジェクトの詳しい説明を見ても、「画面Ａで入力した値を、画面Ｂで表示する」というアプリケーションの仕様は書かれていません。それを示すのが、これらのオブジェクトが連携する様子を示した、さきほどのシーケンス図です。だからこそ、このシーケンス図は、描く意味があるのです。
シーケンス図は、時間の経過とともに進んでいく処理の流れを示すものです。しかし、シーケンス図は、単に処理や手続きの順序を示すために描くものではありません。
シーケンス図の本来の目的は、あるシーンに登場するオブジェクトたちの役割分担を明確にすることです。役割が限定されたオブジェクトが、どのように連携して、１つの大きな動作を実現するのか。それを時間の経過とともに示したものがシーケンス図です。
このように考えることで、重要なソフトウェアの仕組みを読者に伝える、意味のあるシーケンス図を描くことができるでしょう。