「メモ/情報隠蔽」の編集履歴（バックアップ）一覧はこちら

「メモ/情報隠蔽」(2008/03/23 (日) 23:53:42) の最新版変更点

追加された行は緑色になります。

削除された行は赤色になります。

*定義
 We propose instead that one begins with a list of difficult
 design decisions or design decisions which are likely to
 change. Each module is then designed to hide such a decision
 from others.

On the criteria to be used in decomposing systems into modules,[[Software Fundamentals: Collected Papers by David L. Parnas>http://www.amazon.co.jp/Software-Fundamentals-Collected-Papers-Parnas/dp/0201703696/]], p. 154.


  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.

[[Software Fundamentals: Collected Papers by David L. Parnas>http://www.amazon.co.jp/Software-Fundamentals-Collected-Papers-Parnas/dp/0201703696/]], p. 321.

  Applying this principle is not always easy. it is an
 attempt to minimize the expected cost of software and
 requires that the designer estimate the likelihood of
 changes. Such estimates are based on past experience,
 and may require knowledge of the application area, 
 as well as an understanding of hardware and software
 technology. [...]

[[Software Fundamentals: Collected Papers by David L. Parnas>http://www.amazon.co.jp/Software-Fundamentals-Collected-Papers-Parnas/dp/0201703696/]], p. 321.

*記事
-[[Encapsulation is not information hiding>http://www.javaworld.com/javaworld/jw-05-2001/jw-0518-encapsulation.html]]

*定義
 We propose instead that one begins with a list of difficult
 design decisions or design decisions which are likely to
 change. Each module is then designed to hide such a decision
 from others.

On the criteria to be used in decomposing systems into modules,[[Software Fundamentals: Collected Papers by David L. Parnas>http://www.amazon.co.jp/Software-Fundamentals-Collected-Papers-Parnas/dp/0201703696/]], p. 154.


  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 programs 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.

[[Software Fundamentals: Collected Papers by David L. Parnas>http://www.amazon.co.jp/Software-Fundamentals-Collected-Papers-Parnas/dp/0201703696/]], p. 321.

  Applying this principle is not always easy. it is an
 attempt to minimize the expected cost of software and
 requires that the designer estimate the likelihood of
 changes. Such estimates are based on past experience,
 and may require knowledge of the application area, 
 as well as an understanding of hardware and software
 technology. [...]

[[Software Fundamentals: Collected Papers by David L. Parnas>http://www.amazon.co.jp/Software-Fundamentals-Collected-Papers-Parnas/dp/0201703696/]], p. 321.

*記事
-[[Encapsulation is not information hiding>http://www.javaworld.com/javaworld/jw-05-2001/jw-0518-encapsulation.html]]