asatoの技術的な日常日記

「成長に最大の責任をもつ者は、本人であって組織ではない。自らと組織を成長させるためには何に集中すべきかを、自らに問わなければならない」  非営利組織の経営 - ピーター・ドラッカー

スポンサーサイト

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

Datastoreのデータモデル設計のふりかえり, パート4

はじめに


パート1パート2を読んでいない方は、この節を読んで下さい。

個人的に趣味で、Goole App Engine/Java(実際はScalaを使用)を使い始めて一年ぐらいになります。そこで、このシリーズでは、Datastoreのこれまでに設計したデータモデルについて少しふりかえりながら、
-設計上の失敗点
-データモデルのパターン(デザインパターンと言う意味ではない)
-データモデルの進化のパターン(プロパティの追加や削除など)
などについて考えていきたいと思っています。

基本的には、JDO使用で、一部、Objectifyを使ってます。

事例として作ってるWebサイトはGoodsHomeというもので、もともとは、新刊の定期自動チェックのために作ってました。今は、モノ(商品)を中心としてファンやユーザーがつながれるようなソーシャルなサイトにしようと思ってます。

現状、Kind数(クラス数)は、47でした。このシリーズでは、これらモデルの中から、単純なモデルから順に見ていきたいと思います。

考察


今回のパートで例にするモデルは、タグです。単に商品にタグを付けれる機能です。各商品に対してタグは10つまで付けられる仕様です。JDO使用です。
kind_Tags.png
TagsとTagの二つのKindがあります。Tagsは、ある商品に付けられたタグの一覧を保持するだけのものです。asinはamazonの商品IDを表します。Tagは個々のタグを表します。nameは、タグ名を、userIdは、このタグを付けたユーザーのIDを(ない場合もある)、dateはタグが付けられた日時を表します。

このモデルに対する操作は、以下です。
(a) エンティティの作成
(b) tagsの更新
(c) tagsの読み取り
(d) nameからasinリストの取得
kind_Tags_op.png



特徴は以下です。
(1) エンティティ間の関係がある。
(1.1) 1対n(one to many)の関係である。
(1.2) 双方向の関係である。
(2) トランザクションは必要である。タグ数の制約を満たす必要がある。
-Tags(Parent)
(3) tags以外の(JDO上の)プロパティがない。
(4) 各エンティティは、(特に理由がなければ設計上は)削除されない。
-Tag(Child)
(5) 各プロパティは、読み取り専用である。
(6) 各エンティティは、削除される。
(7) Tags(Parent)への関係をもつ。

下記の図は、上記のようなモデルをより一般的に表したものです。

ds_patten4.png


設計について


今回のモデルに限りませんが、設計する上で考慮の必要性が高いように思える順番は以下です。

(1) トランザクションの必要の有無。

(2) 性能。といっても、性能の測定や試験はほとんどしていません。

(3) クエリのやりやすさ。やりやすくなるようにプロパティを持たせます。

(4) 仕様変更への対応のしやすさ。個人的にはそれほど今のところ考慮して設計していませんが、何度かデータモデルの変更の必要性に出くわしました。変換作業は、結構面倒な印象があります。

(5) データ容量。データの重複をなくすることを優先しません。課金で対応します。たとえば、私の場合、現状、エンティティ数:10,480,242(1000万)、使用容量:12.03 of 15.00 GBytes、課金:$0.06 です。


パート5に続く。


付録:データモデルのパターン


パート1で特定したデータモデルのパターン
kind_patten1.png

パート2で特定したデータモデルのパターン
kind_patten2.png


パート3で特定したデータモデルのパターン
ds_patten3.png

パート4で特定したデータモデルのパターン
ds_patten4.png

スポンサーサイト

Datastoreのデータモデル設計のふりかえり, パート3

はじめに


パート1パート2を読んでいない方は、この節を読んで下さい。

個人的に趣味で、Goole App Engine/Java(実際はScalaを使用)を使い始めて一年ぐらいになります。そこで、このシリーズでは、Datastoreのこれまでに設計したデータモデルについて少しふりかえりながら、
-設計上の失敗点
-データモデルのパターン(デザインパターンと言う意味ではない)
-データモデルの進化のパターン(プロパティの追加や削除など)
などについて考えていきたいと思っています。

基本的には、JDO使用で、一部、Objectifyを使ってます。

事例として作ってるWebサイトはGoodsHomeというもので、もともとは、新刊の定期自動チェックのために作ってました。今は、モノ(商品)を中心としてファンやユーザーがつながれるようなソーシャルなサイトにしようと思ってます。

現状、Kind数(クラス数)は、47でした。このシリーズでは、これらモデルの中から、単純なモデルから順に見ていきたいと思います。

考察


今回のモデルは、商品のブックマークを表すモデルです。各ユーザーは、商品IDをもとに、その商品をブックマークできます。このモデルは、Datastoreに慣れていない初期に作ったモデルです。
kind_Bookmarks.png
BookmarksとBookmarkの二つのKindを定義しました(JDOを使用)。Bookmarkは、各商品を対象としたブックマークを表します。asinは、amazonの商品IDです。userIdは、ブックマークしたユーザのIDを表します。Bookmarksは、単にuserIdごとに、Bookmarkの一覧を保持するだけのものです。

なお、JDOを使用しているので上記のようにモデルを表していますが、実際には、Datastore上では、以下のようにデータが保存されますので注意してください(詳しくはGAEのドキュメントを参照)。
ds_ss1.png
ds_ss2.png



このモデルに対する操作は、三つです。
(a) エンティティの作成
(b) bookmarksの更新
(c) bookmarksの読み取り

特徴は以下です。
(1) エンティティ間の関係がある。1対nの関係。
(2) トランザクションは必要である。
-Bookmarks(Parent)
(3) bookmarks以外の(JDO上の)プロパティがない。
(4) 各エンティティは、(特に理由がなければ設計上は)削除されない。
-Bookmark(Child)
(5) 各プロパティは、読み取り専用である。
(6) 各エンティティは、削除される。


下記の図は、上記のようなモデルをより一般的に表したものです。
ds_patten3.png


設計上の悩み


設計上失敗していると感じるのは、Bookmarksがなぜ必要なのか、という点です。不要な理由はあります。
-性能上の欠点: ブックマークの追加や削除が行われるとindexのプロパティ値の更新が発生する

そもそも、なぜ現状のようなモデル設計になっているかというと、不慣れだったこともありますが、ユーザーIDをもとにブックマークの一覧どのように保持・取得するかという観点から、現状のモデルを思いついた(それ以外は思いつけなかった)ということがあります。

実は、現状のモデルはバージョン2で、バージョン1では、BookmarkはuserIdを保持していませんでした。変更した理由は、性能上の理由と言うよりは、クエリの行いやすさの理由だった気がします。あるユーザーがその商品をブックマークしているかどうかを
userId == '%s' && asin == '%s'
のようにクエリできるようにしたかったからです。
kind_Bookmarks_v1_2.png

ちなみに次のバージョンでは、Bookmarksを削除する予定です。それと、ブックマークした日時を保存するプロパティの追加も検討しています。
kind_Bookmarks_v_2_3_4.png



パート4に続く。


付録:データモデルのパターン


パート1で特定したデータモデルのパターン
kind_patten1.png

パート2で特定したデータモデルのパターン
kind_patten2.png


パート3で特定したデータモデルのパターン
ds_patten3.png

Datastoreのデータモデル設計のふりかえり, パート2

はじめに


パート1を読んでいない人は、この節を読んで下さい。

個人的に趣味で、Goole App Engine/Java(実際はScalaを使用)を使い始めて一年ぐらいになります。そこで、このシリーズでは、Datastoreのこれまでに設計したデータモデルについて少しふりかえりながら、
-設計上の失敗点
-データモデルのパターン(デザインパターンと言う意味ではない)
-データモデルの進化のパターン(プロパティの追加や削除など)
などについて考えていきたいと思っています。

基本的には、JDO使用で、一部、Objectifyを使ってます。

事例として作ってるWebサイトはGoodsHomeというもので、もともとは、新刊の定期自動チェックのために作ってました。今は、モノ(商品)を中心としてファンやユーザーがつながれるようなソーシャルなサイトにしようと思ってます。

現状、Kind数(クラス数)は、47でした。この中の単純なモデルから順に見ていきたいと思います。

考察


パート2では、WishTagというデータモデルを事例にして考えていきたいと思います。このモデルは、ある商品を欲しいと思ったユーザー数(正確には思った回数)を表すものです。facebookの「イイネ!」ボタンと同じような機能です。ユーザーが「欲しい!」ボタンをクリックすると、カウントが一つ増えます。

kind_WishTag.png

プライマリキーは、asin(amazonの商品ID)です。countはクリック数を表します。ちなみに、現状、1,800程度のエンティティがあります。

このモデルに対する操作は、三つです。
(a) エンティティの作成
(b) countの更新
(c) countの読み取り

特徴は以下です。
(1) 他のエンティティへの関係を持たない(Key経由でも持たない)。
(2) プロパティは、更新/読み取りされる。
(3) 各エンティティは、(特に理由がなければ設計上は)削除されない。
(4) トランザクションは必要である。

下記の図は、上記のようなモデルをより一般的に表したものです。
kind_patten2.png

設計上の悩み



設計上の悩みは、どのユーザー(ユーザー登録している者としていない者)がいつクリックしたのかを示す情報がないことです。つまりこのような情報を保存するような仕様への変更が出た時、データモデルをどう変更するのか? を考える必要があります。新たなKindを定義することなく、単にプロパティを追加するような変更では対応できないと考えます。


パート3に続く。


付録:データモデルのパターン


パート1で特定したデータモデルのパターン
kind_patten1.png

パート2で特定したデータモデルのパターン
kind_patten2.png

ASE 2007

FOSE に参加したりしてたので ASE が同じ時期に開催されてたのを忘れてた。

ASE の論文はあんまり読まないんだけど、今年の気になる論文は次のだった。

・Keyword Programming in Java

・An Aspect-oriented Weaving Mechanism Based on Component and ConnectorArchitecture

・Inferring Structural Patterns for Concern Traceability in Evolving Software

鵜林先生 のアスペクトの論文が気になる。


本会議はさておき、ワークショップが気になる。特に、Workshop on Living with Uncertainties (IWLU) が気になる。

ソフトウェアの美と品質

初トラックバック。変なこと書いてたらすいません。

ひらさんが「ソフトウェアにおける美とは何か」について書いてるので、反応してみよう。

面白い問いだと思うけど、色々と疑問はある。この記事ではどんな疑問があるのかを考えたい。ひらさんの意図していた議論とは少しずれているかもしれないけど。


まず、ソフトウェア開発者は、美という性質を追及する必要があるのか? について。いい例えかどうか分からないけど、数学者は、"役に立つ" 数学を追求する必要があるのだろうか?

Bertrand Meyer さんは「Object-Oriented Software Construction」という本の最初でこう書いている。

Engineering seeks quality. software engineering is the production of quality software. [...]


そして、ソフトウェア品質についてこう書いている。

[...] Software quality is best described as a combination of several factors.


そして次のような特性(ファクター)について議論している。
・Correctness
・Robustness
・Extendibility
・Resusability
・Compatibility
・Efficiency
・Portability
・Ease of use
・Functionality
・Timeliness

もちろん、他の品質特性もあると思うけど、これらの特性の中には、「美」に直接関係するものは無いように思える。では、それらの特性と「美」との関係はなんだろうか?

たとえば、より美しいソフトウェアを追い求めることは、これら品質が高いソフトウェアを追い求めることなんだろうか?


「美」だけがひらさんの議論の中心ではないと思うので、上記の議論は少しずれているかもしれない。というのも、ひらさんは、次のように「感動」という言葉を強調していると思うので。

僕は、ソフトウェアに美が存在しなければ、多くの人に認められそして感動されるような美が存在しなければ、ソフトウェア開発者は永遠に不幸であるような気がする。

~途中省略~

美しさとは感覚に依存するものだろう。であるなら、ヒトの感覚に訴えるソフトウェアを作れるなら、そこに美が宿る。ソフトウェアに感動する。




ここで、「美」というのを、ソフトウェア開発者が追い求めるべきソフトウェア品質の一つだと仮定しよう。

ソフトウェア開発者は、高品質のソフトウェアを開発することが目標なので、開発しているソフトウェアの品質の確認は重要な行為だと思う。たとえば「このソフトウェアは再利用性が高いだろうか? このソフトウェアの性能は十分だろうか? このソフトウェアは使いやすいだろうか?」といった疑問をなげかけ、もし十分な品質が得られていなければ、改善するかどうかを検討する。

もし「美」が品質の一つなら、同じように問いかけることは役立つだろうか? 「このソフトウェアは、十分に美しいだろうか? このソフトウェは、感動させられるだろうか?」

ここでは、誰が「美」や「感動」を感じる対象であるのかを明確にしておく必要がある気がする。大きく分けて二つ考えられる。
(1)開発者:開発者は、恐らく、ソフトウェアの内部構造に関する「美」や「感動」に関心がある。

(2)ユーザ:ユーザは、ソフトウェアの内部構造には関心は無い。ソフトウェアが提供する機能に関わる「美」や「感動」に関心がある。

もし、ひらさんの議論が二番目のユーザにあるなら、僕はこの記事ではこれ以上議論しない。

一番目にあるなら、もうすこし議論する。

そのどちらでもないなら、僕が間違った議論をしているので、ここで終了。


具体的な例で考えてみよう。最近読んだ、APIデザイン を例にしてみる。

あることをするためのライブラリ(API)が二つあるとする。APIを使う側の開発者からすると、これらのAPIをどんな観点から比較・評価するだろう? ありそうな問いは「どちらのほうが使いやすいだろうか?」や「どちらのほうが、理解しやすいだろうか?」といったものだと思う。しかし「どちらのほうが、美しくて感動できるだろうか?」という問いを行うだろうか?

APIユーザの追及する品質が「使いやすさ」であったり「理解しやすさ」であるなら、開発者はこれらの品質が高いAPIを設計しなければならない。API設計時に「このAPIは美しいだろうか?」と問いながら考えれば、「使いやすく」「理解しやすい」APIが生まれるのだろうか?


二番目の例。ソフトウェア内部構造の「美」とは何だろう? 我々は、たとえば、よりモジュラー(モジュール性が高い)なソフトウェア構造を見ると、より「美しい」と感じるのだろうか? 感じるかもしれない。しかし、単に「感じる」だけかもしれない。

オブジェクト指向が提供する技術では、十分なモジュール性を得られないことが知られている。たとえば、アスペクト指向プログラミングやフィーチャ指向プログラミングなどは、オブジェクト指向よりもさらに高いモジュール性を提供するための技術であると考えられる。

これら新しいモジュール化の技術は、「美」の追求の結果として現れたのだろうか? 通常論文で書かれる品質は「モジュール性」「再利用性」「理解容易性」「保守性」などであり、「美」ではない。


以上のことから、僕は、ソフトウェア開発者が考慮すべき品質特性として「美」を考えることはそれほど役に立たない気がする。理由は以下の点。

(1)「美」よりも具体的な品質特性がある。

(2)ソフトウェア開発技術の発展は、「美」という特性の直接的な追求の結果ではない。


今回の記事の目的は、「ソフトウェアにおける美」を考えるのは、くだらないということを主張したいのではなく、もし美を考えるなら、いくつかの疑問に答えなければならないとうことでした。以下は、疑問のまとめ。

疑問のまとめ:
(1)ソフトウェア開発者が追求するべきものが、高品質なソフトウェアであるとするなら、ソフトウェアの「美」の追求は重要だろうか?

(2)「美」は品質特性の一つだろうか?

(3)もし、「美」が品質特性の一つなら、開発者が「このソフトウェアは十分に美しく、感動させられるか?」という問いを発することは役立つだろうか?

(4)もし、「美」が品質特性の一つでないとするなら、何か? なぜ開発者は「美」を気にする必要があるのか?

(5)もし、ソフトウェアの美やその美から得られる感動を与えたい対象がソフトウェア使うユーザであるなら、開発者の役割は何か?

Evolution Styles

まだちゃんと読んでないけど、

Olivier Le Goaer and Peter Ebraert

Evolution styles: change patterns for Software Evolution

Proceedings Third International ERCIM Workshop on Software Evolution 2007

http://w3.umh.ac.be/~infofs/preprints/index.php?page=paper_info&ID=199


この論文って、僕のやってる「Java におけるコード進化パターン」のプロジェクトに似てる気がする。

パターン適用の確認

あるデザインパターンをシステムに適用したかどうかを知るにはどうすればいいだろう。

デザインパターンのカタログを読み、そこで書かれているあるパターンは今まで知らなかったものだが、今作っているシステムでそのパターンを適用している ような気がする。しかし、本当にそのパターンを適用したことになっているか確信が持てない。

この状況に対する二つの反応が考えられる。

(1)あるパターンを適用しているかどうかを知ることは重要でない。私は設計上の問題を熟考し、現在の解決策を適用した。その解決策がパターンだったかどうかは関係ない。

一方で、パターンを適用したかどうかを知ることが重要だという主張も考えられる。

(2)あるパターンを適用したかどうかを知るのは重要である。パターンは問題と解決策の関係を表現する。パターンの適用を知ることで、どんな設計上の問題があったのかを理解できる。パターンの記述を読むことで、なぜそのような設計になったのかを理解できる。仕様変化などでパターンが適用された構造を変化させなければならないとき、設計の意図を壊さないように安全に変更することができる。

二番目の主張は仮説を含んでいるが、妥当に思える。


もし二番目の主張が妥当だとしたら、あるパターンを適用したかどうかを知るのは重要だということになる。ここでの課題は、適用したかどうかを確認するのが難しい点にある。よく知られたパターン、たとえば、Singleton パターンなどなら確認は簡単かもしれない。しかし、自分の良く知らないパターンである場合、難しい。

難しくなる要因にはいくつか考えられる。

(1)開発者は、そのパターンを十分に理解できるだけの経験がない。

(2)パターンの適用範囲、もしくはバリエーションの範囲が広い。そのため、パターンの記述でカバーされている範囲外に実際に適用したバリエーションが存在している、と開発者は感じている。

(3)パターンの記述形式は、パターンを適用したかどうかをチェックできるのに適した形式ではない。
pattern.png



要因のひとつには、(3)がある気がする。パターンを学ぶのは難しい。パターンをマスターするために GoF のパターンカタログだけを読むのは不十分だったのは、その後入門書が何冊も出版されたことからも分かる。したがって、パターン記述に則った形式に基づき、異なる観点からパターンを記述できると考えられる。

pattern_desc.png


感じるのは、もうすこしフォーマルな記述があってもいいんではないかという点。


関係しそうな文献:

Neil B. Harrison, Paris Avgeriou, Uwe Zdun, "Using Patterns to Capture Architectural Decisions," IEEE Software, vol. 24, no. 4, pp. 38-45, Jul/Aug, 2007

Frank Buschmann, Kevlin Henney, Douglas C. Schmidt, Pattern-Oriented Software Architecture: On Patterns and Pattern Languages, John Wiley & Sons, 2007

Decision Support Systems

前回の記事に書いたように、設計が意思決定に関わるものだとしたら、設計に関する情報だけでなく、意思決定に関する情報にも注目しておき必要があるのかも。

ってことで「Decision Support Systems」というジャーナルがあるっぽい。

設計のジャーナルは、僕が集めたのをここにまとめてる。

Scala メモ

Scala メモ」を更新。たまに触るぐらいじゃあ、なかなか慣れない。

ソフトウェアは技術

実際の設計-こうして決めた」という本に次のような記述がある(19ページ)。

 個々の技術が存在しているとき、その技術を作ったときの決定の過程の記述は何故必要なのであろうか。それを示したのが図2.1である。できあがった技術をただ単に見ただけではその技術を真に理解し、利用し、更に発展させることはできない。そんなことを可能にするためには、今見えているものを生み出した過程、なかんずく、決定した過程を知らなくてはならない。図2.1(a)に示すように、技術の獲得には今見えているものを生み出した思考の過程を知ることが必要であり、そのことは技術を生み出した者自身がその思考の過程を記述し、他人に伝達可能な形に持ってゆく必要がある。このような記述をしたものは、同図(b)に示すように技術伝達に必要な閾値を越えるので、時間・空間・組織・文化・技術分野を超えて水平展開が可能となるが、そのような記述のないものは閾値に達することがないので消滅してしまう。


ここで上記の文の「技術」を「ソフトウェア」に置き換え、さらに、ソフトウェアの進化・発展を強調してみよう。


 個々のソフトウェアが存在しているとき、そのソフトウェアを作ったときの決定の過程の記述は何故必要なのであろうか。それを示したのが図2.1である。できあがったソフトウェアをただ単に見ただけではそのソフトウェアを真に理解し、利用し、更に発展させることはできない。そんなことを可能にするためには、今見えているものを生み出した過程、なかんずく、決定した過程を知らなくてはならない。図2.1(a)に示すように、ソフトウェアの獲得には今見えているものを生み出した思考の過程を知ることが必要であり、そのことはソフトウェアを生み出した者自身がその思考の過程を記述し、他人に伝達可能な形に持ってゆく必要がある。このような記述をしたものは、同図(b)に示すようにソフトウェア伝達に必要な閾値を越えるので、時間・空間・組織・文化・ソフトウェア分野を超えて水平展開が可能となるが、そのような記述のないものは閾値に達することがないので消滅してしまう


いくつかの疑問が思い浮かぶかもしれない。

・「設計文書がそのような記述に相当するのではないか?」設計文書は、選択肢を明示的に記述しているだろうか? 決定とは、選択肢からの選択である。設計文書は、なぜその選択肢が選ばれたのか問う根拠を記述しているだろうか?

・「ソースコードは、そのような記述に相当するのだろうか?」相当しないと考えられる。ソースコードは、概念的な決定を含まない。たとえば、開発者が想定(決定)したアーキテクチャのスタイルと、ソースコードを分析して抽出された実際のアーキテクチャは一致しているだろうか?
次のページ

FC2Ad

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