asatoの技術的な日常日記

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

スポンサーサイト

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

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

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

デザインプロセスの側面

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).
スポンサーサイト

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

少し前から

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

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

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


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

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

更新履歴:

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")の読み直しと、パターン記述にどんな要素があるのかを分析。


設計原則とは何か or 設計原則のメタモデル, パート1

はじめに


ソフトウェア工学の理論と実践では、いくつかの設計原則が知られていると思う。たとえば Parnas の情報隠蔽など。

そもそも、ソフトウェア開発における設計原則とは何だろう? 個々の原則は、どんな要素から成り立っているんだろうか? 原則間にはどんな関係があるんだろう? というようなメタ(オントロジー)な視点から、設計原則を考えていきたい。

原則の定義


まずは、「原則」そのもの定義について考えてみる。

goo の国語辞典で「原則」を調べてみるとこうある。

(1)多くの場合にあてはまる基本的な規則や法則。しばしば原理と区別せずに用いられるが、原理は主として存在や認識に、原則は主として人間の活動に関係する。
「―として五時に下校すること」

(2)〔論〕〔(ドイツ) Grundsatz〕他の諸命題がそこから導き出される基本命題。



マイケル・ジャクソンさんは、「ソフトウェア要求と仕様」という本で、次のように書いている。

原則とは、ソフトウェア開発作業と方法論を律すべきだと私が信じる事柄である。



ソフトウェア工学・システム工学ハンドブック」という本では、「原則」とは書かれていないけれど、「原理」として次のように書かれている(principleは原則あるいは原則と訳される)。

すべての経験が法則と呼べるようになるものではありません。多くの場合、普遍性が足りなかったり、検証が不十分だったりしています。かなり詳細なレベルのものも多くあります。それでも有用なものについて、本書では「原理(principle)」として参照しています。



設計原則の例


設計原則の例として、まずは Parnas の情報隠蔽を考えてみる。

16.3.2 Design Principle

Our module structure is based on the decomposition criterion known as information hiding [6]. According to this principle, system details that are likely change independently should be the secrets of separate modules; the only assumptions that should appear in the interface between modules are those that considered unlikely to change. Each data structure is used in only one module; it may be directly accessed by one or more programs within the module but not by prigrams outside the module. Any other program that requires information stored in a module's data structures must obtain it by calling access programs belonging to that module.

-----
D. L. Parnas, P. C. Clements, D. M. Weiss, The modular structure of complex systems, Software Fundamentals: Collected Papers by David L. Parnas, p. 321. [PDF オリジナルバージョン?]



(1)情報隠蔽は、モジュール分割のための基準である。
(2)情報隠蔽は、原則である。

二つとも、論文の定義をそのまま利用。ただし、2番目については、principle という言葉をわざわざ定義していないので注意が必要。というのも「ソフトウェア工学・システム工学ハンドブック」では、情報隠蔽を原則ではなく法則として紹介しているから。この本によると、法則とは次のようなものらしい。

... 本書ではきわめて重要な教訓を「法則」と呼んでいます。

... 法則(law)という用語に関連して別の意味がありますが、本書においては「自然の法則」という意味での「法則」です。ウェブスター辞書の定義によれば、自然の法則とは「ある条件の下で一定の現象の順序や関係を提示するもの」です。

... 本書では「法則(Law)」、「仮説(Hypothesis)」、「推測(Conjecture)」を区別しています。ある規則を「法則」として引用することで、それを支援する強力な実証的(エンピリカルな)証拠があること、そして重要な洞察を表していることを意味しています。



原則と法則の区別はともかく、情報隠蔽を例に、設計原則として一般化してみよう。他の設計原則も対象にして一般化するべきだと思うけど、まずは、情報隠蔽だけで考えてみる。

(a)ある設計原則には、名前がある

(b)ある設計原則は、何かについての基準である

aは、受け入れてもいいと思う。bについては、議論が必要。

(A)「何かについての基準」ではない設計原則が存在するかもしれない。

(B)何かについての基準だとしても、基準は一つだけとは限らないと思う。

これらについては、今後具体的な他の(設計)原則を例として調査していきたい。たとえば、「ソフトウェアアーキテクチャ」という本で紹介されている原理が参考になるかもしれない。


 いくつかの基礎となる原理に基づいて、ソフトウェア構築は行われる。その基礎となる原理を「根底技術」(enabling techniques)と呼ぶことにする。その原理は、時間の経過によって曖昧なものになってしまったために、特定の名前が付けられていない。この広く受け入れられてしまっている原理を実現した技術が開発されており、原理と技術の区別が難しくなってきている。ここでは、単純にこれらを同義だと見なすことにする。

...ソフトウェアアーキテクチャのためのパターンはこれらの原理に基づいており、パターンの大部分はこの原理のどれか一つに焦点をあてている。本節では、ソフトウェアアーキテクチャのための「根底技術」のうち最も重要なものをまとめておく。

・抽象

・カプセル化

・情報隠蔽

・モジュール化

・関心の分離

・結合度と凝集度

・充足性、完全性、プリミティブ性

・ポリシーと実装の分離

・インタフェースと実装の分離



その他参考


ソフトウェアに限らず、原則自体について僕が調べたのがあるので、参考に。
-原則の原則
-原則の特徴

デザイン:設計順序の原則

更新履歴:
2008.02.27 - 読みやすいように&議論を少し修正。

 疑問:実現すべき機能要求の集合が与えられたとして、どの順番でそれらの機能を設計・実装していくのが適切なのか?

疑問


少し前に気づいて疑問に思ったことだけど、実現すべき機能要求の集合が与えられたとして、

 (1)どんな順番で機能を設計・実装していくのがいいんだろうか?

 (2)順番は最終的な設計・実装結果に影響を与えないのだろうか?

ここでは、簡単のために機能的な要求だけを考えてる。非機能要求の考慮は保留。

議論


さて、自分自身に問い合わせてみたところ、少なくとも一つの原則に従って(従おうとして)設計・実装していることに気づいた。それは、抽象がなるべくできあがるような順番で機能を設計・実装しようとしている、ということ。

もっと具体的に言えば、ある機能AとBを設計・実装することで、抽象的なモジュール(たとえば抽象クラスやインタフェース)が出来るような順番。

たとえば、ゲームを作っているとし、次のような機能要求集合が与えられたとする。

 (1)キーボードによる操作ができること
 (2)マウスによる操作ができること
 (3)ゲームコンフィグができること。
 (4)ゲームデータがセーブできること
 (5)ゲームデータがロードできること

とすると、順番としては、たとえば次のようなものを選ぼうとする傾向があった。

 (A) (1)->(2)
 (B) (2)->(1)

これは、1と2がどちらも操作に関わる機能であるため、モジュール(クラス)として実現したときに共通の特性を持つ抽象(抽象クラスや interface)ができる可能性がある、という理由から。つまり、

 (a) コードの重複や共通のインタフェースができるだろうということ。

 (b) そして、操作に関わる機能を実現したモジュールを使うモジュールは、抽象を通して依存すべき、という原則の点から。

AとBのどっちを優先するかは機能の優先順位によるけれど、どちらもある一定の期間中に実現できればいいとするなら、AとBの順番は気にしない。

もちろん、個々の要求が独立しているとは限らないので[2]、実現の順序がほとんど決まってしまう場合もある。たとえば、機能Aを実現する前に機能Bができていなければならないなら、B->Aの順番で実現するのが普通だと思う。ただし、AとBの間にインタフェースI(もしくはデザインルール[3])を導入するなら、AとBは独立に実現できる可能性もある。


今まで考えたことがなかったので、読み逃しているかもしれないけど、僕が知る限り、機能の設計・実装の順序について議論している本はないように思える。

設計の原則はある。たとえば「アジャイルソフトウェア開発の奥義」では、次のようなオブジェクト指向における設計原則を解説している(わざわざ英語で書いてるのは、邦訳を持ってないため。


・The Single Responsibility Principle - A class should have only one reason to change.

・The Open-Closed Principle - Software entities (classes, modulues, functions, etc.) should be open for extension, but closed for modification.

・The Liskov Substitution Principle - Subtype must be substitutable for their base types.

・The Dependency Inversion Principle - Abstraction should be not depend upon details. Details should depend upon abstractions.

・The Interface Segregation Principle - Client should not be forced to depend upon methods that they do not use. Interfaces belong to clients, not to hierarchies.

・The Release-Reuse Equivalenct Principle - The granule of reuse is the granule of release.

・The Common Closure Principle - The classes in a package should be closed together against the same kinds of changes. A change that affects a closed package affects all the classes in that package and no other packages.

・The Common Reuse Principle - The classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all.

・The Acyclic Dependencies Principle -
Allow no cycles in the package dependency graph.

・The Stable Dpendencies Principle - Depend in the directions of stability.

・The Stable Abstractions Principle - A package should be abstract as it is stable.



上記以外の設計原則としては「Refactoring in Large Software Projects 」で紹介されているのがある(上記と被る原則は省略)。

・Don't Repeat Yourself - Do not write the same or similar code more than once.

・Speaking Code Principle -
The code should communicate its purpose. Comments in the code could indicate that the code communicate its purpose insufficiently.

・Tell, Don't Ask -
Don't ask an object about an object, but tell it what to do.




でもこれらの設計原則は、プロダクトとしての設計、つまり具体的にはモジュール、プログラム、コードの構造が備えているべき特性や品質の原則に思える。

もしかすると、プロセスの結果としてのプロダクトに関する原則は、プロセスに関する原則との表と裏の関係かもしれない。

それでも、プロセスとしての設計原則を明示的に表しておくのは、効果的であると思う。

たとえば、一つの具体的なものから抽象的なものを考えるよりも、二つの具体的なものから抽象的なものを考える方が易しい。これを設計プロセスの(仮の)原則として言うなら、こんな感じ:

 抽象が作りやすくなるような順番で、機能を設計・実装せよ。


参考


[1] ロバート・C・マーチン, アジャイルソフトウェア開発の奥義

[2] アラン・M・デービス, 成功する要求仕様 失敗する要求仕様

[3] キム・クラーク,カーリス・ボールドウィン, デザイン・ルール―モジュール化パワー

番外編


今回の記事の内容に直接関わるかどうかは分からないけど、Christopher Alexander の「The Nature of Order」のBook 2では、順番についての次の記述がある。


4. VITAL IMPORTANCE OF THE "RIGHT" SEQUENCE

In architecture, as in other things, the importance of sequence is both simple, and potentially shocking. Even when there are only two steps to be token, the order in which they are done may be all-important. And it may be highly surprising.

Consider for example the process of laying out a house on a lot.

"Common sense" says that you should first place the house, and then place the garden, This is common sense; but it is wrong. To make the environment and the formation of house garden together come out right, you have to reverse the order of these two operations, as follows:
1. First: Locate the garden in the best and most beutiful place.
2. Then: Locate the house so that i helps and supports the garden.

This example is fascinating because it illustrate the enormous significance of sequence. If you place the house first, you are stuck with the leftovers as places for the garden. In all likelihood the garden will not become a pleasant place. Possitive space will amost certainly be violated. So will view, smell, noise. But if you locate the garden first and then place the house volume in a way which supports the wholeness of the garden, the garden will come out better and so will the house.

Of the two available sequence for these two operations, one sequence is wrong, and ohe is right (90% of the time). The sequence which is wrong, is correct according to conventional wisdom, and probably considered obviouse by millions of people. The one which is right (and which gives you insight, makes things more understandable, and gets wholesome results), flies in the face of common sense, and would be rejected by nine out of ten people who first hear it. Yet it is the right answer.

Few examples explain the enormouse power and siginificance of sequences more vividly. And as you can imagine, if the sequence -- the order of steps -- is significant when dealing with only two operations, how much more siginificant it will be when dealing with ten, or twenty, or fifty steps. There the chance of getting the sequence right by accident, is extremely small.



デザイン:Design Research Quarterly

またまた、Nigel Cross さんのページ みてたら発見。オンラインの雑誌かな? よくわからん。

 Design Research Quarterly

デザイン:表現の定義

前回の記事(『デザイン:対象と操作』)に関係することを補足。単なる引用だけど。

Simon によれば、表現を定義するとは次のことらしい。

Defining a representation means (1) specifying one or more data types, and (2) specifying the primitive (i.e., "fast") operations that can be performed on information in those data types.


一部しか引用してないけど、詳細を知りたい方は次の論文を参照。

 On the Forms of Mental Representation

ちなみに、元々この論文の存在を知ったのは、 Vinod Goel さんの「Sketches of Thought」という本の139ページで紹介されてたから。


さて、表現の話がなぜデザイン(設計)と関わるのか? そもそも、何を 表現したいのか? これに関しては、(プロダクトとしての)デザインといえる。正確に言えば、もしデザインという行為が、意思決定のプロセス だとするなら、その出力を表現したい。

という流れ。

デザイン:対象と操作

ソフトウェアは、もちろん成果物。成果物を出力するには、なんらかのプロセスが必要。

基本的には、ソースコードをコンパイルして得られるのがソフトウェアだと思う(スクリプトの話はなしで)。

プログラマーは、コードを編集する。要求仕様を満たすように編集する。

さて、ソースコードを抽象化して考えてみよう。ここでの抽象化とは、コメントや空白などを除くことを意味する。抽象化した対象にたいして、プログラマは編集操作を行う。Java プログラムの一部を具体例として考えてみよう。

抽象化した対象をどう表現するか。ここでは、Eclipse なんかでであるようにGUIで表現できるとする。もしくはもっと簡単に、変数名と値を表示するだけとする。

operator_class.png


これで対象が決まったので、次は対象に対する操作を考えてみる。一番単純なのは、クラス名を変更するといった操作。

operator_class2.png


ここで言いたいのは、対象が決まれば、可能な操作が決まるということ。もちろん、可能な操作は勝手には決まらない場合もある。

ソースコードに対する編集操作と、ソースコードを抽象化した表現対象に対する操作は異なる。ソースコードに対する操作には、たとえば、「コメントを追加する」や「空白を追加する」「タブを追加する」「改行する」などの操作が考えられる。しかし、そのような操作は、抽象化した対象に対しては意味を持たなくなる。


次に、操作を抽象化することについて考えてみよう。代表的なのはリファクタリング。たとえば、「スーパークラスの抽出」リファクタリングを考えてみよう。

operator_refactor.png


ここで言いたいのは、抽象化された対象に対する操作のみを使って、より抽象度の高い操作を表しているということ。つまり、「クラスを作成する」などの操作を行ってはいるけどソースコードレベルの操作、たとえば「改行する」などは操作として含まれていないという点。


さて、ここからが今回の話のコアとなる部分。過去の記事で何度か設計という行為は、意思決定の観点から考えられると言ってきた。考えられるとは、つまり、意思決定の観点から抽象化して考えられるとしてきた。

意思決定とは、選択肢からの選択を意味する。つまり、ある操作を表す。そして、操作があるということは操作対象が存在する。

具体例で考えてみよう。状態遷移を実現する必要がある場合、どんな決定を行うだろうか? 選択肢としては、「ifによる分岐」「Stateパターン」「遷移テーブル」などがあると思う [アジャイルソフトウェア開発の奥義]。

ここでは、Stateパターンを選択したとする。

operator_state.png


Stateパターンの基本構造は、こんな感じ。
operator_state2.png



次にStateパターンが適用された構造に対する操作を考えてみよう。二つの観点から考えてみる。

(1)Stateパターンかどうかに関係なくできる操作。たとえば、Stateパターンが適用されていると知らなかったとする。すると、どんな操作が可能か。

(2)Stateパターンが適用されているからできる操作。


まず一つ目だけど、どんな操作でもできる。Stateパターンでなくなるような操作ですら可能。



次に二つ目だけど、たとえば、「ConcreteState」を追加・削除するなんてのは適切な操作の一つ。他にも、request/handleメソッドのペアを追加・削除するなんてのも可能な操作。一方で、request メソッドのみを削除するなんてのは不適切な操作。


まとめ:

対象が決まれば、可能な操作が決まる。

デザイン:design is an attempt at global optimization with finite resources

単なるメモ程度のもの。

Vinod Goel さんの「Sketches of Thought」という本の256ページには、デザインの一つの側面を次のように書いてる。


This is compatible with a widely held view among designers that design is an attempt at global optimization with finite resources.




次のページ

FC2Ad

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