気楽なソフト工房

プログラミングについていろいろな記事を書いています。



mykonos2008

Author:mykonos2008
システムエンジニアとして働いている30代の会社員です。
仕事や趣味でプログラムを書いている方の役に立つ記事を書いていきたいと思っています。
ご意見、ご感想はこちらまで
If you are an english speaker,Please visit my english blog.

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
前回の記事で紹介した物品管理システムのエンティティ分析の結果に基づいて、
それに対応するデータクラスを定義してみます。とにかく分からないことだらけで大変でした。。

Google App Engineはデータストアを利用する方法として「JDO」、「JPA」、あと「low level API」の
3つを提供しています。

私はどれに関しても、ほとんど知識が無いので、3つの中では最もドキュメントが充実している「JDO」と
使うことにしました。

JDOについて
「JDOについて」と言っても私にもたくさん語れるほどの知識はありません。必要最低限の内容を少しだけ、書かせて頂きます。

JDOとはウィキペディアによると「Javaオブジェクトの永続性に関する仕様」と書かれています。
少し簡単に言い直すと、JavaのオブジェクトをRDBなどの永続ストレージに保存したり、
そこから復元したりするための仕様ということになると思います。

JDO自体にはインタフェースしか定義されていなくて、その実装は各ベンダーから提供されています。
GAEの場合は、オープンソースの「DataNucleus Access Platform」という実装にGAE用のアダプタを追加したものを使っています。

GAEはJDOを採用することにより、基盤を構成するクラスタ化されたデータベースサーバへの接続を隠蔽しているものと考えられます。

開発者からの視点でみると、GAEにおいてデータを保存するということは、データに対応するクラスのインスタンスを保存することになり、
データクラスを定義することが、データベースのスキーマを定義することになります。

JDOではJavaの「Plain Old Java Objects(POJOs)」、つまり普通のJavaクラスのインスタンスを永続化してくれます。
特別なインターフェースを実装したり、クラスを継承したりする必要はありません。

これは、POJOsにアノテーションを付加し、それをエンハンサにより永続化可能なオブジェクトに変換することで実現されています。
エンハンサとは、付加されたアノテーションに従って、コンパイルされたクラスを永続化可能なクラスに変換する作業を行ってくれるツールです。

Eclipeのプラグインを使用して開発を行う場合は、コンパイルの直後にエンハンサが自動的に実行されるので、
特別な作業の必要はありません。

※アノテーションはJava5から導入された機能で、javacやその他のツールがそれを利用してクラスに対してなんらかの加工処理を施すためのものです。
独自のアノテーションを定義して、それを利用するツールを開発することも出来ます。

エンティティ間の関係
それでは、RDBのテーブルに該当するデータクラスの定義から始めたいと思います。

まず、データクラスの定義に入る前に、エンティティ間の関係を整理して置くことが必要です。
それによって、クラスのフィールドの定義の仕方が変わってくるからです。

最初に整理したいのは、エンティティ間の関係が所有関係かどうかという点です。
所有関係というのは一方のエンティティが、もう一方のエンティティの存在なしには存在し得ない
関係を言います。

例を挙げると、伝票とその伝票の明細の関係は所有関係になります。伝票の存在なしに、明細が
存在することは有りません。一方、所有関係にない関係の例としては、明細と勘定科目の関係があります。
勘定科目は複数の明細で使用されることもあるので、明細の存在が無くても存在しうるものです。

前回、抽出した物品管理システムのエンティティ間の関係について、所有関係を整理してみました。
抽出したエンティティは「台帳」、「台帳ユーザ管理」、「物品」、「物品種別」、「管理場所」の5つでした。

「台帳」エンティティは、通常、1つの家庭と一対一になるものです。ユーザはシステムに物品を登録する前に
我が家専用の台帳を作成し、それに対して物品を登録していく想定です。「物品種別」、「管理場所」に関しても、
台帳に対して登録をしていく仕様を想定しています。

この想定において、「台帳」エンティティが「物品」、「物品種別」、「管理場所」エンティティを所有している
関係になります。「台帳」なしに「物品」だけが存在していることがないからです。

一方、「物品」と「物品種別」、「物品」と「管理場所」の関係を考察してみます。
「物品種別」、「管理場所」は「物品」の属性の1つになります。例えば、「物品」ドライヤーの「物品種別」は
電化製品という感じです。しかし、電化製品というくくりで言うと、テレビや冷蔵庫も電化製品になります。

従って「物品種別」電化製品はドライヤーの存在なしにも存在することが出来ます。
このことから、「物品」と「物品種別」の関係は所有関係ではないと言えます。「物品」と「管理場所」についても
同じです。

このような作業を行って、エンティティ間の関係を整理し、クラス図を更新しました。



次回はこのクラス図に従って実際にデータクラスを作成してみます。

コメント

コメントの投稿

管理者にだけ表示を許可する

トラックバック

http://csfun.blog49.fc2.com/tb.php/52-9b25a478

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。