asatoの技術的な日常日記

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

スポンサーサイト

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

設計原則とは何か 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)と呼ぶことにする。その原理は、時間の経過によって曖昧なものになってしまったために、特定の名前が付けられていない。この広く受け入れられてしまっている原理を実現した技術が開発されており、原理と技術の区別が難しくなってきている。ここでは、単純にこれらを同義だと見なすことにする。

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

・抽象

・カプセル化

・情報隠蔽

・モジュール化

・関心の分離

・結合度と凝集度

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

・ポリシーと実装の分離

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



その他参考


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

コメント

コメントの投稿


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

トラックバック

トラックバックURLはこちら
http://asatohan.blog77.fc2.com/tb.php/97-4960e2c0
この記事にトラックバックする(FC2ブログユーザー)

FC2Ad

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