第5回 Webサイトの詳細設計


樫山友一
2002/5/28


 第4回でアーキテクチャの設計が終わりました。今回は、アーキテクチャを利用した詳細設計に入っていきます。前回までに作成したプラットフォームに依存しないモデルがいかにプラットフォームに依存したモデルとなっていくかが分かります。具体的には、システムのEntityモデルをどのように実装に落としていくかに焦点を置いて解説します。

 まず、前回作成したプラットフォームに依存しないモデルをもう一度見てみましょう。

図1 プラットフォームに依存しないモデル

 ここでは、開発チームが理解しやすく、モデルが分かりやすいように日本語でモデルを記述しています。しかし、今回からはJ2EEを前提としたモデルを作成するためにJavaを利用することを前提にモデルを作成します。よって、モデルはJavaの言語仕様に沿った形で記述することになります。今回は以下のような手順で開発を進めましょう。

  1. モデルをJava言語に依存した形にする
    プラットフォームに依存しないモデルをJavaの言語仕様に添った形に変更する

  2. クラス図を作成する
    各クラスがJ2EEのどの技術を利用しているかが明確となっているモデルを作成する

  3. システムの動的な動作を記述する
    シーケンス図、状態図などでシステムの動的な動作を記述する
 

 モデルをJava言語に依存した形にする

 開発言語がJavaなので、まずパッケージを決める必要があります。パッケージの分類は、Javaでなくても行っておくべきです。パッケージの分け方もいくつかの方法があります。

  • 機能ごとにパッケージを分類する
  • 利用する技術によって分類する

 機能ごとにパッケージ化を行うと再利用するような場合にとても有利になります。ただし、パッケージへのインターフェイスを設計時にしっかりと設計しておく必要があります。

 利用技術により分類する場合は、EJBをすべて1つのパッケージに入れたり、JSPから利用するクラスを1つのパッケージにまとめたりします。

Javaのパッケージは、階層化することができますので、機能ごとに分類した後にその下の階層にEJB、Servletといったパッケージを配置することも可能です(図2)

図2 パッケージの作成例

 開発チームの体制とリンクしてパッケージを作成することも効率的です。パッケージごとに責任範囲を明確にすることが可能だからです。また、パッケージ間の依存関係をできるだけシンプルにしておくことも重要です。パッケージ間の関係が複雑になっていると修正に苦労したり、再利用性が悪くなります。パッケージが相互利用されないような設計を心掛けましょう。図3のように相互参照をするようなパッケージができてしまった場合は、パッケージを2つに分割することを考えてください(図4)

図3 相互依存しているパッケージ

図4 相互依存を解消したパッケージ関係

 パッケージの構成方法が分かったところで、例題のプロジェクトをパッケージに分類してみましょう。方針としては、機能ごとに分類して、その下の層にJ2EEの技術に相当するパッケージを作って分類します。まず、図1から、機能ごとにどのようなパッケージがあるかを考えてみます。

 図5にパッケージ図を示します。ここから、Javaの言語仕様に沿った形でパッケージやクラス名などを決めていくことにします(実際には、Javaではクラス名などに日本語が利用可能ですが、慣習としてすべて英語名にしていきます)。

図5 例題のパッケージ

 図1から分かるように、このモデルは大きく3つに分類可能です。顧客を表すcustomerパッケージ、注文や請求書などの販売に関するものがorderパッケージ、商品に関するものがproductsパッケージ、オペレータの管理の機能が入っているのがoperatorパッケージです。実際のJavaのコードでは、以下のようになります。com.izeまでが会社のドメイン、reidaiのところはプロジェクト名や製品名、次が例題の分類です。これは、最も一般的に行われているパッケージの分類ですが、パッケージ名はユーザーが任意に決めることがあります。ただし、プロジェクト内で同じパッケージ名が出てくると混乱するためプロジェクトのチーム内で勝手にパッケージ名を決めることは避けた方がよいでしょう。

com.ize.reidai.order
com.ize.reidai.customer
com.ize.reidai.products

 いよいよ次にJ2EEへのマッピングの作業です。第4回の解説で、例題のプロジェクトではJSPとEJB、フレームワークとしてstrutsを利用することが決定しています。まず、図1のクラス図を各部分に落とし込んでいきましょう。

 

 クラス図を作成する

 どこから詳細な設計をしていくかがとても難しいのですが、これは何から入るのが正しいという方法はありません。開発者によりやりやすい方法があります。筆者は、Entityから詳細な設計に入る方がなじみがあるためにEntityの設計から入ります。まず、customerパッケージの詳細設計から行いましょう。

図6 CustomerEJB

 図6にcustomerパッケージに入るCustomerEJBのクラス図を示します。図1より、顧客クラスは、entityであることが分かります。よって、EntityBeanとして実装します。顧客管理の機能は、ほぼEntityBeanのHomeインターフェイスで実装可能なために1つのEJBでカバーすることができました。

EJB( Enterprise Java Beans )
EJBを開発する場合には、ユーザーは以下の3つのクラスを作成する必要があります。

  • Homeインターフェイスクラス
    javax.ejb.EJBHomeを継承して実装します。
  • Remoteインターフェイスクラス
    javax.ejb.EJBObjectを継承して実装します。
  • EJBの実装クラス
    javax.ejb.SessionBean, javax.ejb.EntityBeanをimplementsして実装します。

これらの3つのクラスを作成後、DeploymentDescriptorと呼ばれるEJBの設定事項を格納するXMLファイルを作成し、EJBコンパイラによってアプリケーションサーバで動作させる形式に変換します。

 EntityBeanは、データベースからのロードと書き込みを行います。よって、これに対応するデータベースのテーブルも作成する必要があります。EJB 2.0からは、EJBの起動時にデータベースにテーブルがない場合は、自動的にテーブルを作成する機能もあります。しかし、パフォーマンスを考慮するとデータベースに合った設定と用途を考慮した設定でテーブルを作成することをお勧めします。

 次にorderパッケージの詳細設計をしましょう。図7では、まず図1のクラス図を忠実にJavaに合わせた形で書き直しています。Entityのステレオタイプが付いているのはEntity Beanに、Controlのステレオタイプが付いているものはSession Beanとしています。

図7 orderパッケージのクラス図

 厳密には、EJBでは3つのクラスを作成する必要があるため、Homeインターフェイス、Remoteインターフェイス、EJBクラスの3つをクラス図に記述する必要がありますが、クラス図が複雑になるのでEJBクラス1つで代用することをお勧めします。いくつかのCASEツールでは3つのEJBのクラスを1つとして扱うことができるものがあります。

 全体では、図8のようになります。

図8 EJBへ対応させたクラス図

 図8のクラス図では、まだ実際のJavaのソースコードに対応するほど詳細まで記述していません。CASEツールやIDEを用いると、詳細の情報(引数の型、返り値など)を入力して、ソースコードをクラス図から自動生成することも可能です。このようなツールを利用するとソースコードの変更もクラス図に反映させることも可能です。よって、図8のようなクラス図がソースコードの出発点となります。

 

 システムの動的な動作を記述する

 図8のクラス図をベースに基本的なシーケンスを記述します。

図9 シーケンス図

 図9に請求書のデータを作成して、合計金額を得るシーケンス図を示しました。ここでは、第3回に示したシーケンス図と比較すると分かりますが、Javaのソースコードの呼び出しが実際のメッセージとなっています。また、第3回図8では、印刷の動作がありますが、印刷は、Entityの動作として設計せずに次回の画面遷移の解説で設計をします。

 次に、第3回に示したように請求書の状態図を記述しておきましょう。図10にInvoiceBeanの状態図を示します。実際にこのような状態をInvocieBeanに持たせるためには、InvoiceBeanの属性にstatusを追加する必要があります。このステータスの値を変化させることにより、状態として扱うことができます。そこで、このstatusの値を変化させるためのメソッドをInvoiceBeanに用意する必要があります。このメソッドの呼び出しが図10で示される状態の遷移の矢印に記入されているものです。

図10 InvoiceBeanの状態図

 この結果、InvoiceBeanは図11のようになります。

図11 InvoiceBean

 ここまでで、Entityモデルの設計を終了します。設計のすべての解説ができたわけではありませんが、おおよその流れはご理解いただけたと思います。次回は、このEntityモデルを使って実際のWebページをどのように設計するかを解説します。

プロフィール
樫山友一(かしやま ゆういち)

大手電機メーカー研究所でオブジェクト指向によるシステム開発に従事する。1996年よりJavaへの取り組みをはじめ、J2EEアプリケーションサーバを活用したWebシステム構築のコンサルタントとして多数のプロジェクトを手掛ける。
2001年3月にイーズ・コミュニケーションズ株式会社の設立に参加し、最高技術責任者に就任。
著書に「わかりやすいUML入門」、「Webサイトがわかる本」(いずれもオーム社)がある。


Java Solution全記事一覧



Java Agile フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Java Agile 記事ランキング

本日 月間