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

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

はじめに


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

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

事例


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

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

まずは、NewItemというモデルです。これは、商品が新たに見つかった時の情報を表すモデルです。新たな商品データがあるかどうかは、タスクを使って定期チェックされます。

kind_NewItem.png

図のPKは、プライマリキーのことです。PKの値はasinで、これは、amazonの商品IDです。categoryは、商品のカテゴリ(書籍やおもちゃなど)を表しています。dateは、見つかった日時を表します。ちなみに、152,000のエンティティがあります。

モデルに対する操作は、二つです。
(a) エンティティの作成
(b) カテゴリごとに新着順にエンティティの読み取り(select from NewItem where category == '%s' order by date desc)。

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

上記の図と同じですが、下記の図では、プロパティが読み取り専用という点を強調してみました。
kind_NewItem2.png

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

kind_patten1.png


さて、何らかの設計ミスを感じているかどうかですが、それは、他のモデルの紹介時にまた考えたいと思います。


次回に続く。


Webページ変化のモデリングとパターン化, パート1

この連載は、Webページの変化の整理を目的とする。

整理は、以下の二点から行う予定である。

(a) Webページ変化の種類の特定
(b) Webページの変化に伴う品質の変化の特定

web_page_change.png

このような整理により、Webページを変化させる開発者の意思決定を支援できると考えられる。現状のWebページを出発点とし、期待する品質を備える到達点のWebページが予測できるためである。


第一段階として、Webページの変化には、二種類が考えられるとした。
(1) レイアウト変化
(2) 情報変化
page_change.png


layout_change.png

info_change.png

もちろん、この分類には、問題点がいくつかある。たとえば、フォントの色の変化は、どちらに分類できるのか。

他にも、Webページ自体のモデルorメタモデルを定義する必要がある。

また、今後は、Webサイト、あるいは、Webシステム内での変化を対象としてスコープを広げることも必要かもしれない。


次回に続く。

テーマ:プログラミング - ジャンル:コンピュータ

ソフトウェアデザインの理論:組織構造と意思決定プロセス

この記事では、ソフトウェア開発における組織の構造が、ソフトウェアデザインにおける意思決定プロセスに与える影響を考察します。

デザインプロセスの側面

John Gero さんによれば、工学におけるデザインのプロセスには、以下の側面があります[1]。

goal-oriented, constrained, decision-making, exploration and learning activity which operates within a context, which depends on the designer's perception of the context.
 (1) ゴール指向
 (2) 制約がある
 (3) 意思決定
 (4) 探索
 (5) 学習


この記事では、ソフトウェアデザインでの意思決定の側面に着目します。

ソフトウェアデザインにおける意思決定

ソフトウェアデザインでの意思決定とは、ここでは、以下のようなプログラム構造に影響を与えるような決定であるとします。

 (1) 抽象度の高いレベルであれば、アーキテクチャスタイル(もしくはパターン)の選択に関わる決定など。

 (2) 低いレベルであれば、プログラムの変数の名前付けに関わる決定など。

ここまで、どのような状況で意思決定を行うのかについては触れてきませんでした。状況の一つは、意思決定者の数です。

 (a) 一人の開発者が意思決定を行う。

 (b)二人以上の開発者が意思決定を行う。

通常、ソフトウェア開発ではbの状況ですので、この記事ではbの場合を考察します。


次の状況は、意思決定者の間の関係です。

 (i) ある意思決定者の決定は、他の意思決定者の影響を受けない。

 (ii) ある意思決定者の決定は、他の意思決定者の影響を受ける。

iで言いたいは、ある決定されたことAとBとが依存していないというわけでなく、意思決定が必要なことについて、意思決定者XとYが共同して最終的な決定を行わない、ということです。

ソフトウェア開発における組織構造

ここでは、組織構造とは、意思決定者とその間の関係からなる構造です。関係は、意思決定の権限がどちらが強いのか、ということに着目します。意思決定の権限の強さは、開発チームでの上司・部下の関係で決まると仮定します。

org_design.png

ここで、意思決定の権限の強さは、技術的な能力で決まるのではないと仮定していることに注意してください。意志結果が得られる過程には次がありえます。

(1) 部下にとって技術的に適切だと思われる意思決定が、上司に受け入れられる。

(2) 部下にとって技術的に適切だと思われる意思決定が、上司に受け入れられない。

ただし、ここでは、デザインは、個人的な経験や知識によって行われるため、「技術的に適切」というのが実際に「技術的に適切」かどうかの判断は難しいとします。

また、意思決定は、「技術的に適切」かどうかだけでなく、スケジュールやコストといった開発状況の考慮も必要です。そのため、そのような考慮が欠けている部下の意思決定を、上司が受け入れないというのは現実的です。

まとめ

ソフトウェア開発での組織構造が意思決定に影響を与えるとするなら、ソフトウェア開発での最終的な成果物であるコードorプログラム構造を技術的に適切な観点からアウトプットするのは難しいということを議論しました。

今後調査したいと思っているのは、オープンソースソフトウェア開発の組織構造での意思決定プロセスとの比較です。

参考文献
[1]
J. S. Gero, Design prototypes: a knowledge representation schema for design, AI Magazine, 11(4): 26-36, (1990).

[コード進化パターン][Scala] Scala におけるコード進化パターン

Scala のバージョン 2.7.2 から、Java と Scala のコードを共存できるようになったので、昔作った Java プログラムを Scala に徐々に変換しようとしてます。

で、そのJavaからScalaの変換過程を

 「Scala におけるコード進化パターン

としてドキュメント化しようとも思ってます。

デザイン:デザインパターンの内部構造

少し前から

 デザインパターンの内部構造

というドキュメントを書き始めました。

概要は今のところ、(論文っぽく少し難しめの言葉を使っていますが)次のようにしています。
個々のデザインパターンを細かな粒度の構成要素に分解し、要素間の関係付けを行うことで、それらデザインパターンの内部構造を明らかにする。明らかになった個々のパターンの内部構造に基づき、個々のパターンの不変部分・可変部分を特定する。また、関連しあうパターン間を、各パターンの内部構造の観点から関係付けを行う。そのような特定と関連付けにより、個々のパターンおよびパターン間での構造的な洗練・修正が可能となることを目指す。


ですが、内容は一般の方でも分かるように書いていく予定です。デザインパターンの適用だけでなく、デザインパターン自体の理解に興味ある方向けです。

デザイン:デザインパターンにおける設計問題と設計解の変化過程

更新履歴:

2008.04.25:誤字・脱字を修正。


昨日の 自分のTwitter で垂れ流した内容を(オリジナルに近いのは こちら)自分でさらに考察してみる。


スタートポイントとなったのは、とある論文にあったこんな記述。

[...] Evidence in support of first-person knowledge is provided by the fact that different designers are likely to produce different designs for the same set of requirements. And the same designer is likely to produce different designs at different points in time even though the same requirements are presented. This is a result of the designer acquiring new knowledge while interacting with their environment.


Gero, JS and Kannengiesser, U (2008) A Function-Behaviour-Structure ontology of processes, AIEDAM (to appear).

気になったのは次の点。

 (1)同じ要求が与えられたとしても、設計者が異なれば、異なるデザインを出力する。
design_output1.png


 (2)同じ要求が与えられ、同じ設計者であっても、設計する時期が異なれば、異なるデザインを出力する。
design_output2.png


僕は最近は デザインパターンの研究 をしているので、このことをデザインパターンの観点から考えてみた。

このことをデザインパターンの観点から考えてみると、複数の設計者のその時の設計知識を基にして抽象化・一般化して記述されたのがパターンといってもいい気がする。したがって、オリジナルの筆者に加えて他の人がパターンの執筆に加わっていたとしたら、パターンの記述内容は変化する可能性がある。さらには、オリジナルの執筆者が後にパターン記述を見直したとき、記述内容は変化する可能性がある。



上に書いたことを考え直してみると、いくつか間違いとか疑問とかがある。

 (間違の点)設計知識というよりは設計経験といったほうが適切だった。

 (疑問の点)抽象化・一般化の定義が曖昧なので、この点はちゃんと考える必要がある。

僕がここで1つ意識してたのは、各パターンの解(クラス図とかの構造)だけでなく、パターンの記述内容も考えの対象にしている点。つまり、そのパターンがどんな設計問題を解決しようとしているのかとか、どんなフォースがあるのかとか、パターン解以外にどんな代替案があるのかとか、そういうのも含めてる。

「したがって~」からの後半の部分は、最初に引用した論文の内容を基に考えると、あってる気がする。


続いて僕はこう書いてみた。

とここまで書いた思ったのだけど、もしかするとパターンの品質とか妥当性の評価は、元々の記述内容が '変化しない度合い' によって測ることができるのか? 元々のアレクサンザーのパターンの定義はここでは置いておくとして。


ここで、いきなりパターンの品質とか妥当性の評価の話になってるのは、僕がいまこのテーマを研究しているため。

で、上で書いたときの感覚をうまく伝えるのは難しいけど、感じたのは、パターンの記述内容が変化しないということは、パターンの記述内容が適切だった、といえるんではないかということ。特に、パターン解が変化しないということは、それこそがパターンの本質なんではないか、ということ。

なぜこの点がひっかかるかというと、ソフトウェアにおけるデザインパターンの場合、パターン解はプログラミング言語に依存するから。たとえば、アスペクト指向言語のひとつである AspectJ でパターンを再実装してみた、というような研究がある。この観点からいうと、従来のオブジェクト指向におけるパターン解と、他の言語でのパターン解は、プログラム構造(クラスだけでなくアスペクトも構造要素として用いられている)の点で異なる。

アレクサンザーの話を最後にいってるのは、この点が気になったから。つまり、元々の建築におけるアレクサンザーのパターンは、ソフトウェアと同じように解の構造が変化するのかわからなかったため。この点に関しては、パタンランゲージ本などを読み直す必要があると感じてる。


続いてこう書いた。

各パターンが解決の対象とする設計問題があるとして、パターンはその問題への解を与える。一方で、その解は、問題を解決する解候補の1つにすぎないともいえる。

パターン解と代替案の違いの1つの側面は、解の安定性にあるのかもしれない。つまり、問題の状況が変化するとして、パターン解から代替案への変換の度合いと、代替案からパターン解の変改の度合いには違いがあるはず。 別の言葉で言えば、代替案からパターン解へのリファクタリングを行う度合いと、代替案からパターン解へのリファクタリングの度合いは異なるといえるきがする。



「解の安定性」というのは、ここでは厳密に定義はしていないけれど、図で僕のイメージを伝えるとこんな感じ。
design_transformation.png


問題空間とは何か?とか解空間とは何か? とかの疑問はとりあえず置いておくことにする。

この図の例では解として、パターン解、代替案A~Cの4つあると考えてる。

それぞれの解が、問題を解決する(かもしれない)とする。この部分についても今後考える必要があるけど、とりあえずは、そういうことにする。

「解の安定性」という言葉でいいたかったのは、ある解から他の解への変換がどれだけ行われるのか、という度合い。

図の例で言うと、こうなる。

 ・パターン解から他の代替案への変換数は、0
 ・代替案Aから他の解への変換数は、2
 ・代替案Bから他の解への変換数は、3
 ・代替案Cから他の解への変換数は、1

この場合、パターン解が一番小さな数字なので、一番安定した解であるといえる、というのが僕がイメージしたこと。

ただ、上のTwitterでの発言では書いていないけど、気になることがある。それは、解が安定しているからといって優れているとは必ずしもいえないのではないか、という点。たとえば、解がそこで留まってしまっている、つまり、この解から他の解への変換数が少ない理由は、他の解への変換自体が難しいからかもしれない。特に、アーキテクチャレベルで考えると、イメージしやすいと思う。あるアーキテクチャから他のアーキテクチャの変換が難しいのは、変換自体が困難であるためとも考えられる。もちろん、この点についても検証する必要がある。


続いての発言。

この変換の度合いの違いは、恐らく問題空間の問題の変換の度合いの違いに関わってくると思う。

とすると、設計問題A-->Bの変換と、設計問題B-->Aの変換の度合いが異なるのは何故だ?

もっと一般的には、問題の変換のプロセスに、何か特徴があるのか? たとえば、問題の(構造?)は複雑になっていくように変化していく、など。これは、リーマンのソフトウェア進化の法則からなんとなく言ってみただけだけど。

再びソフトウェアの文脈でいいなおしてみると、要求仕様(ソフトウェアの機能・非機能、振る舞い)の変化、もしくは設計問題(ソフトウェアの構造、構造の品質)の変化を観察するとき、何か法則はあるのか?


最初の文は、図で書いたのと矛盾してるかもしれない。図では、問題が変化せずに解だけが変化すると捉えての議論だった。

ここで感じていたのは、解の変換(変化)の度合いが対称でないのと同じように、問題の変換(変化)の度合いも対称でない、ということ。もし、非対称であるとするなら、この非対称性を生み出す原因はなんなのだろう? また、問題は複雑になっていくようには変化するけれど、簡単になっていくようには変化しないのか? もし複雑になっていくとするなら、どのくらいの複雑さに変化していくのだろう?

最後の複雑性の点は重要に思える。つまり、あるデザインパターンの解が優れており、僕が上で単純に定義したように解の安定性が高いとしても、もし問題が複雑になり続けていくなら、その安定性は保てなくなるかもしれない。

デザイン:人工物としてのデザインパターン記述 


意思決定に関する文献のほとんどは、「まず事実を探せ」という。しかし成果をあげる意思決定を行うエグゼクティブは、事実からスタートなどできないことを知っている。だれもが自分の意見からスタートする。しかし意見は、未検証の仮説にすぎず、したがって当然現実に対して検証されなければならない。

[~省略~]

意思決定も、科学と同じように、仮説が唯一の出発点である。われわれは、仮説をどう扱うかを知っている。論ずべきものではなく、検証すべきものである。こうしてわれわれは、どの仮説が有効であって真剣な検討に値し、どの仮説が検証によって排除されるかを知ることができる。


P・F. ドラッカー, 経営者の条件


社会人になってしまったので、まとまった時間を使って記事を書くのは難しそう。ということで、段階的にまともな記事内容にしていくアプローチをとってみる。

次の文は、少し前に思いついたこと感じたことを 僕の twitter で垂れ流したのを少し修正したもの(オリジナルに近いのは こちら)。

デザインパターンのようなパターン記述も人工物の一種だとしたら、そこにも設計プロセスが存在するとしてもいいかもしれない。

John Geroさんが FBS (Function-Behavior-Structure) フレームワークという、一般的に設計プロセスを表現するための枠組みを提案している。これをつかってパターンの形成・構築・記述のプロセスを説明できるかもしれない。



上に書いたようなことを調査するのは面白いかもしれないけど、この調査を行う意義を考えないといけない。以下は僕の意見。

 (1)僕としては、パターンも設計される人工物であるとするなら、それは、パターンの記述自体も進化の対象となるんではないかと思う。パターンの記述が、ある種の設計知識を表現しているとしたら、その設計知識を段階的に進化させていくことは重要であると思う。


いくつか検証する項目がある。
 
 (1) デザインパターンのようなパターン記述は、人工物の一種か?

 (2) パターンを記述することは、設計プロセスとみなせるか?

 (3) FBS でパターンの設計プロセスを説明できるか?

 (3.1) パターン記述における機能、振る舞い、構造の要素は何か?

それよりも気になるのが「パターンとパターン記述は同じものか?」という点。 


確認のやり方の予定。

 項目(1)については、まず人工物とは何か、というのを勉強しなおさないといけない。ということで Simon の『The Sciences of the Artificial』を再読。あと『Design Rules』も読み直す。

 項目(2)と(3)については、FBS の論文(たとえば "Design prototypes: a knowledge representation schema for design")の読み直しと、パターン記述にどんな要素があるのかを分析。


次のページ

FC2Ad

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