井上 研一 オブジェクト指向分析・設計の第3回です。
今回は、第2回で取り上げた3つの側面（責務・静的・動的）のうち、責務側面と静的側面で、ブログシステム（例えばWordPressのようなもの）を分析してみましょう。
ブログシステムの責務側面
WordPressなどでブログを作ったことのある人なら分かると思いますが（ブログを作ったことはなく、読んだことしかない人でもある程度想像できるでしょう）、ブログではこんなことが出来るでしょう。
- 記事を書く（その際、カテゴリを付けることが出来るでしょう）
- 記事を読む
- コメントを書く
それぞれ、誰がやるのかを考えると・・・
- 投稿者
-
- 記事を書く、カテゴリを付ける
- コメントを書く
- 読者
-
- 記事を読む
- コメントを書く
といった具合になると思います。
注意深い人なら、投稿者だって記事を読むことがあるじゃないかと思うことでしょう。それは正解です。
ただ、例えばこの（あなたが今、読んでいる）ブログを書いているのは私ですから、私は投稿者ですが、私がだだ記事を読んでいるときは、私は読者です。つまり、私という一人の人間が、投稿者という役割を演じることもあるし、読者という役割を演じることもあるのです。
「誰がやるのか」の「誰」とは、個別具体的な人というより、「人の演じる役割」と考えた方が良いでしょう。
また、「コメントを書く」ことについては、投稿者と読者の双方に入れてあります。
多くのブログシステムでは、コメントを書く際に名前とメールアドレス等の入力を求めます。その際、投稿者がコメントを書く場合は入力を求めません。投稿者はブログシステムに登録され、ログインしているので、コメントを書いているのが投稿者自身であることが分かるのです。
UMLのユースケース図として書くと上図のようになります。
人型のアイコンは「アクター」と言います。まさに役割を演じる俳優といった感じですね。（またの名前をスティックマンと言います。棒で出来てますからね・・・）
楕円形で文字を囲んでありますが、これを「ユースケース」と言います。
また、このユースケース図では、「管理者」というアクターが登場し、「投稿を承認する」というユースケースが増えています。
どうやら、このブログシステムは1つのブログに複数の投稿者が存在するブログマガジンのような体裁をとり、管理者が投稿を承認して初めて公開されるといったことを想定しているようです。
アクターとユースケースの間に線が引かれ、5つのユースケースが長方形で囲まれています。この長方形を「システム境界」と言います。
第1回の記事で、オブジェクト指向ではシステムを箱庭のように捉えると書きましたが、このシステム境界は箱庭と人間（ユーザ）の間にある壁のようなものです。
壁の中にあるユースケースはシステムの責務であり、壁の外にいる人間（アクター）はユースケースとの間に引かれている線とシステム境界の交点に開いている窓を通してしか、壁の中を覗く（システムを使う）ことは出来ません。
ブログシステムの静的側面
次に静的側面の分析をやってみましょう。
静的側面の分析とは、第1回に書いたようにクラスの分析ですから、ユースケース図からクラスになりそうなものを導出してみましょう。
クラスの導出では、ユースケース図（あるいはユースケース記述：アクターとシステムの相互作用が記述された文書。ユーザマニュアルのようなもの）から名詞を抜き出す品詞技法を用いることが多いようです。
ざっと名詞を抜き出してみました。
これだけでは散漫なので、関連のあるものに線を引いて、整理してみましょう。
記事には投稿者、カテゴリ、コメント、承認、アクセスログが関連付いています。アクセスログはユースケース図に存在しない名詞ですが、読者と記事を関連付けるものとして、追加してみました。
このように、分析を進める中で、抜けているクラスを追加したり、不要と思われるクラスを削除したりして、洗練させていくのです。
投稿者と管理者は、ユーザというクラスを継承するサブクラスとして整理しました。
コメント投稿者と読者はユーザのサブクラスにはしていません。図中のコメントにあるように、ログインしないと閲覧できない会員制ブログなら、読者やコメント投稿者もユーザのサブクラスにしなければならないでしょう。（会員制ブログでなくても、コメントを投稿するには会員登録とログインが必要なケースもあります。その場合は、コメント投稿者はユーザのサブクラスとなります。この辺は、ケースバイケースであり、システムデザインの妙味です。）
さらに、属性（クラスの持つデータ項目）を加えてみました。
抜き出した名詞をクラスにするのか、クラスの属性にするのか迷うかもしれません。クラス設計の要点の一つと言っても良いことです。とりあえずは、その名詞が表す概念にタイトルを付けたくなったらクラスにするくらいの考え方で行きましょう。
例えば、記事やコメントにはタイトルがあります。コメント投稿者という概念のタイトルはコメント投稿者の名前でしょう。一方、「投稿日時」という概念にタイトルを付けるのは難しいでしょう。「記事の投稿日時」なのですから、記事クラスの属性にするのが良さそうです。
また、投稿者とコメントの関連が抜けていたので追加しました。読者とアクセスログは、システム化対象外（会員制ブログではないので、一人一人の読者をオブジェクトとして認識できない）という判断の下、削除しました。
このように、クラス図はさらに洗練が進んでいくわけです。
まとめ
今回はブログシステムを題材として責務側面の分析をユースケース図で、静的側面の分析をクラス図で表現してみました。
このような分析は、ソフトウェアを開発するというよりも、作りたいサービス、システムをどのように理解、認識しているかを明らかにすることと言った方が良いのではないかと思います。私は、オブジェクト指向分析は、ソフトウェア開発の領域を超えて、価値のあるものだと考えています。
とはいっても、この講座はソフトウェア開発で使うオブジェクト指向を説明していますから、次回はロバストネス分析の話に進んで、粛々とプログラムに近づいていきましょう。