netail.net
自作フリーソフトや,ゲームに関する雑記を公開してます.
日記はソフトウェア工学の論文ネタが中心です.
最近のお知らせ (古いものはこちら)
2004-04-05 古い日記からの変換データ [長年日記] ▲
_ Profes2004 ▲
Tutorial 2:A Feature-Oriented Method for Product Line Software EngineeringKyo C. KangPohang University of Science and Engineering
続き.
ドメインのスコープだけは,広すぎないようにしないといけなくて,基準としては「変化するものが多すぎるときは,もっと狭める」らしい.また,開発者だけだと,実装の詳細に踏み込みすぎるので気をつけましょう,とも言っていた.ドメインが未成熟なときは terminology の定義も必要.
モデルが複雑になりすぎるのを抑えるために,モデルが複雑になりすぎたときは抽象クラスの作成や,共有されるようなクラスが多いときは逆に違いをはっきりさせるために派生クラスの作成を行ったりもする.また,ドメインからアーキテクチャ上にマップするときに1対多対応になってしまうものは,1対1になるように分解する,といったことによって目的を達成するらしい.
_ Profes2004 ▲
Tutorial 2:A Feature-Oriented Method for Product Line Software EngineeringKyo C. KangPohang University of Science and Engineering
Feature-Oriented Programming と関係あるのかな?ということで聞きにいってみたチュートリアル.チュートリアルの担当者は,SEI でドメイン分析 FODA とかを研究していた人らしい.
特定のドメインに対するソフトウェア群(たとえば「エレベータ制御」--どんな場所に設置されるか,何人乗せられるか,実際に動かす対象などが異なる)をうまく共通のアーキテクチャ,コンポーネント群を使って構築しようというのが基本コンセプト.
ただ,ソフトウェアの変更や継続的なメンテナンスにもドメイン分析は有効である,とは言っていた.一つのシステムが変化していくのを,Product Line の開発として考えれば,確かにその通り.
ハードウェアなら CPU やメモリ容量が仕様に相当するが,ソフトウェアならサービスがそれに当たる.ドメイン上で,必要なサービスや品質特性を分析して,それをアーキテクチャ上のコンポーネントにマッピングしていく.コンポーネントを,さらに実際のソフトウェア部品などに対応させていく.
Capability と Operating Environment を顧客とアナリストがつくり,開発者が,アナリストと一緒に Domain Technology やImplementation Technique を考えていく.Feature の階層構造から,わりと自然に,ドメインに対応するクラスが導出できるものらしい.で,抽出された要素をアーキテクチャ上にマップしていく.