Software FactoriesコミュのFeature Localization

書籍の2章で"Feature Localization/Delocalization"という言葉が出てきます。言っていることはだいたいわかるんですが、これにピタッとあてはまる良い日本語が思いつきません。

皆さんはどう訳されていますか？

コメント(2)

最初
全て
最新の40件

わたなべさん、こんにちわ。
現在、拡散と局所化という訳語を当てています。
フィーチャーの訳はまだ決定していないのですが、「特性」が最有力候補です。
もっとよい訳、あるいは好きな訳がありましたら、ご指摘いただければ幸いです。

以下のような感じです：
フィーチャーの拡散
Coplien［Cop99］が指摘するように、初期のオブジェクト指向の手法の誤りは、問題における個々のオブジェクトがソリューションにおいて1つのオブジェクトによって表現されるだろうと想定したことにあります。つまり、問題におけるフィーチャーは、ソリューションにおけるフィーチャーに対して、直接マッピングできると想定されていたのです。しかし実際には、複数の問題フィーチャーが複数のソリューションフィーチャーのいたるところに散在し、混ざり合っています。
たとえば、図2-1の「製品」と「注文」と「顧客」の実装は、Webサーバーページと分散コンポーネントとデータベース接続のアセンブリに散在し、混ざり合っています。製品の実装を変更するために、3つ全部のアセンブリの変更が必要になることもあり、注文と顧客の実装にも影響が及びます。フィーチャーの「拡散」（delocalization）と呼ばれるこの現象は、偶発的な複雑性の主な原因の1つです。この現象が起きるのは、この図の例では、Webサーバーページや分散コンポーネントやデータベース接続といった複数のソリューションフィーチャーが、製品のような単一の問題フィーチャーを実装するときであったり、また逆に、単一のソリューションフィーチャーであるWebサーバーページが、製品や注文や顧客など複数の問題フィーチャーを実装するときです。
これらの問題フィーチャーが要求によって定義されるのに対して、ソリューションフィーチャーは実装によって定義されることに注目すると、さらにいくつかのことに気付きます（後ほど、この章で要求と実装を正確に定義します）。
■ 要求において、問題フィーチャーは最も局所化（localized）され、ソリューションフィーチャーは最も拡散（delocalized）される。たとえば、注文は単一の分析クラスによって定義されるが、Webサーバーページは、セキュリティや分散コンポーネントやデータベース接続と共に、複数の分析クラスに含
まれる。
■ 実装において、ソリューションフィーチャーは最も局所化され、問題フィーチャーは最も拡散される。たとえば、Webサーバーページは単一のアセンブリによって定義されるが、注文は顧客や製造と共に、複数のアセンブリのいたるところに散在する。

[2] mixiユーザー 09月20日 23:16

＞とらばさん
回答ありがとうございます。

Localization=局所化、Delocalization=拡散ですね。Localization=局所化、というのは思いついたのですが、対になる概念は訳語もできるだけ対になっていたほうがいいと考え、Delocalizationを「○○化」という方向でなんとかできないものかといろいろ悩んでいました。

Problem Features/Solution Featuresも「問題フィーチャー」に対して「ソリューションフィーチャー」だとちょっと収まりが良くない気がします。「解法フィーチャー」だと直訳っぽすぎるでしょうか。

ログインすると、みんなのコメントがもっと見れるよ