米国強大化の秘密
ソフトウェア再利用技術
世界発展の鍵
2009
松本 正雄
九州産業大学情報科学部
2009
(C)Prof.M.J.Matsumoto
1
何故いまソフトウェア再利用か
• 企業、自治体、病院などエンタプライズに
おけるシステム構築やサービス利用は、
「所有から利用」へ確実に移行している。
• 所有するのは、コストや進化維持が大変。
• 所有しないで、提供元から有用なソフトウェ
アを利用する形態に変えれば、有利。
• クラウドコンピューテイングはその一例。
2009
(C)Prof.M.J.Matsumoto
2
学会設立以来20年論文委員
• IEEE Technical Committee on Software
Reuse
• 国際会議ICSRは 1991年以降1.5年ごとに
開催され、各国から成果が発表された
• 年々競争力の差は開いていった
• 本講義は当事者の証言である。
2009
(C)Prof.M.J.Matsumoto
3
再利用
１．定義
２．何故再利用か？
３．再利用対象
４．再利用方法
５. 再利用の進化
６．領域分析（Domain Analysis）
７． MBSD・CBSD
2009
(C)Prof.M.J.Matsumoto
4
１ はじめに
１．１ 再利用の定義
ソフトウェア再利用(software reuse)とは何を
意味するのか。
この分野に深くかかわっている専門家の定
義を見てみよう。
2009
(C)Prof.M.J.Matsumoto
5
再利用の定義：重点
コード以外も Freeman
再利用を配慮した設計
OTS部品 McIlroy
Tracz
プロジェクトに関連した知識などすべて
ドメイン固有モデルの例化
柔軟な再利用
Basilli
Prieto-Diaz
Frakes
静的再利用と動的再利用の2つある。前者は品質・生
産性向上、後者はﾌﾟﾛﾄﾀｲﾋﾟﾝｸﾞ実現のため
2009
松本正雄
(C)Prof.M.J.Matsumoto
6
McIlroy ・・use of off-the-shelf components as
building blocks in new larger systems
(新たな大規模システムの部材として“棚から
すぐに取り出して利用可能な” コンポネントを
使うこと)
Tracz
・・ reuse of software designed to be reuse
(再利用されるように設計配慮されたソフト
ウェアを再利用すること）
Freeman・・ use of non-executable workproducts for
developing new software
(新たなソフトウェアを開発するために非実行
可能な成果物をも使うこと)
2009
(C)Prof.M.J.Matsumoto
7
Basilli
・・use of everything associated with a
software project including knowledge
(ソフトウェアプロジェクトに関連した知識
その他すべてのものを使うこと)
Prieto-Diaz ・・instantiation of domain-specific
models by composition of reusable
parts
(領域固有モデルから特定システムをインスタ
ンシェートするために、再利用部品を組み合わせること)
2009
(C)Prof.M.J.Matsumoto
8
Frakes ・・ informal reuse of lifecycle object,
primarily code , in an informal and
haphazard way
(ライフサイクルオブジェクト、主にコード
を非形式的にしかも随意に再利用する）
松本の解説・・『作業結果を、 （それが作られた時の想
定コンテクストとは別の）任意の コンテクストのもとで
のシステム作成に際し、構成要素として使用すること。
品質、工期、コストの改善を図ることが目的。 』
2009
(C)Prof.M.J.Matsumoto
9
1.2 再利用の進展
１９６０年代
１９７０年代
１９８０年代
１９９０年代
２０００年代
2009
・サブルーチン
・マクロコード
・初期のドメインモデル
・コマンドのパイプ
・部品によるプログラム自動合成
・上流オブジェクトの再利用
・CASEによる再利用支援
・ラピッドプロトタイピング
・OOクラス
・再利用ライブラリ
・近年のドメインモデリング
・CBSD
・モデルベースの再利用
・SOA
(C)Prof.M.J.Matsumoto
10
１．３ テーマ全貌
再利用技術の全貌は広い。いかなる視点に
立って、どう捉えるかにより、見え方が違う。
◎１．時系列/フェーズ 視点から見ると。。。
(1) 部品作成とライブラリ化を行う段階
(FOR reuse)
(2) 部品を使ってソフトウェアを作成する段階
(WITH reuse)
2009
(C)Prof.M.J.Matsumoto
11
◎ ２．領域視点から見ると。。。
(1)領域固有の再利用(Domain-specific
reuse)
(2)いくつかの領域を横断しての再利用
(Across-domain reuse )
2009
(C)Prof.M.J.Matsumoto
12
ドメイン視点と再利用
S1
S2
あるドメイン
ドメイン固有再利用(水平)
ドメインモデル
あるドメイン
ドメイン固有再利用(垂直)
汎用モデル
他のドメイン
あるドメイン
ドメイン横断再利用
2009
(C)Prof.M.J.Matsumoto
13
◎ ３．技術課題か管理課題か。。。
1)テーマを技術課題として見る (Engineering)
２)テーマを管理課題として見る
（Administration)
2009
(C)Prof.M.J.Matsumoto
14
経営者視点
E1
A1
A2
理論的
B5
D4
D1
D2
D6
D3
C2
C4
A3
C1
C3
B1
D5
B4
B3
技術者視点
A1 : ソフトウェア知的所有権問題
A2 : ソフトウェア再利用コンポネント産業論
A3 : ソフトウェア再利用管理手法
B1 : 再利用方法論
B2 : 再利用ツールと環境（OO等）
B3 : 再利用法コンポネント／文書化要件
B4 : 設計再利用法
B5 : 要求再利用法
C1 : 再利用メトリックス／計測／評価／
効果算定モデル
C2 : 共用ソフトウェアライブラリ相互運用
2009
B2
実際的
C3 : ライブラリインフラストラクチャ整備
C4 : ソフトウェアライブラリ構築・検索
D1 : 言語
D2 : 形式仕様再利用法
D3 : 再利用プロセス
D4 : ドメイン分析、ドメインモデリング、ドメ
インエンジニアリング
D5 : 再利用設計
D6 : 品質認定
E1 : 教育・訓練、コースウェア
(C)Prof.M.J.Matsumoto
15
２．何故、再利用か
◎NASAにおける研究 [SEL87]
２５のプロジェクトチームでの再利用率は
０％から８２％を示している（平均３２％）
◎レイセオン (Laytheon) 社は、
平均６０％程度再利用 [LAN87]
◎銀行及び保険業界向けは
７５％程度の達成率 [JON８４]
2009
(C)Prof.M.J.Matsumoto
16
T.C.ジョーンズ：
○ “新たに” 作成されなければならない
コードは約１５％以下[JON84]
○ 大規模な応用プログラムないしは
システムプログラムは、５０％～８０％まで
再利用可能
2009
(C)Prof.M.J.Matsumoto
17
再利用がどの程度まで全体生産性に
影響を及ぼすか[JON86]
○ ３つの実例
１万ステップのCOBOLコードについて調べ
たところ再利用率は、４分の３(７５％)。
表１のa）参照
○ Love[LOV88]の研究
（２万から３万ステップのObjective-C)
表１のｂ）参照。
2009
(C)Prof.M.J.Matsumoto
18
再利用による利点
平均再利用率
３２％(ＮＡＳＡ)
６０％（Ｒａｙｔｈｅｏｎ）
７５％（金融損保業界）
コード自動生成による生産性(コード作成面) ４０倍
欠陥低減率
計画通りのプロジェクト進捗
2009
20～30％
45～55％
半数のプロジェクト
(C)Prof.M.J.Matsumoto
19
再利用を阻む障壁
投資
■初期投資
■ コンポネント開発費 ２５％増
心理的障壁
■NIH（Not Invented Here ）シン
ドローム取組み不十分
■古い慣習にとらわれたまま
■Edsger Dijkstraの名言
技術
2009
■発展途上
■技術支援不十分
(C)Prof.M.J.Matsumoto
20
これまでソフトウェア再利用が広く
普及しなかった原因は多い：
a）投資面、ｂ）心理面、 ｃ）技術面
投資面
◎イニシャルコストが高い
◎コンポネントの開発が約２５％割高と見
られる
2009
(C)Prof.M.J.Matsumoto
21
心理面
◎ ダイクストラの明言[BUX70]
“私が懸念しているのは「ソフトウェア危機である。
ソフトウェア工学は十分改善されてきている筈だ
と誰もが思い込んでしまっているこ と」である。それ
は大きな見誤りであり、改革されねばならないことが
ある。
それは次の５項：
2009
(C)Prof.M.J.Matsumoto
22
(１)習慣的なものの考え方
(２)プログラム作成ツール
(３)ハードウェア
(４)仕事の仕方
(５)組織編成の在り方
◎Woodfieldほか[WOO87]によれば、
「未熟な開発設計者は、再利用可能なものを
利用する能力に著しく欠ける」
2009
(C)Prof.M.J.Matsumoto
23
３．何を再利用できるか
◎フリーマン(Freeman)の分類：
コードフラグメント、アーキテクチャ、機能仕様
内部仕様、外部仕様、環境仕様
2009
(C)Prof.M.J.Matsumoto
24
環境仕様
外部仕様
内部仕様
技術移転された知識
利用知識
アプリケーション
業務知識
開発知識
システム概要
機能構造
機能集合
論理構造
ソフトウェア
アーキテクチャ
コード
コード
2009
(C)Prof.M.J.Matsumoto
25
コードの種類：粒度
コード断片
意味のある部分
テンプレート
改造のひな型
手続、関数、クラス
モジュール/サービス
部分システム
2009
プログラム構成要素
モジュールの集合
(C)Prof.M.J.Matsumoto
26
◎プログラムコードの分類
ー プログラムの断片
例えば、構文エディタによってプログラムライブラ
リの中から導かれた断片部分か、あるいは初め
からある具体的な条件の元で意味づけられた
コード部分の再利用[WAT８６]
ー ひな形／定型（フレーム）
プログラムまたはその一部を「改造的に作成す
る」際の見本として役立てる
2009
(C)Prof.M.J.Matsumoto
27
ー 手続・関数 (ファンクション)
手続／関数、標準手続／標準関数やマクロとし
て用いるべく収集したアーチファクト
ー モジュール
インターフェースを介して外部と交信し、かつ一
定の設計条件によって決定された
プログラム構成要素[ＬＥＷ８８]
ー 部分システム
論理的に互いに密接な関係を持つモジュールを
まとめて、より大きなシステムコンポネントに構
成したもの。
2009
(C)Prof.M.J.Matsumoto
28
単一のモジュールインタフェースではなく、部
分システムインタフェースを構成し、抽象化レ
ベルを上げる。[LEW88]
2009
(C)Prof.M.J.Matsumoto
29
アーチファクトの呼称
部品
アーチファクト（Archifact）精緻に作成され
たもの
中間成果物
最終成果物
オブジェクト
アセット財産
フレーム
2009
(C)Prof.M.J.Matsumoto
30
◎アーチファクトに関する基本的な課題[BOR88]
いかにアーチファクトを
ー
ー
ー
ー
ー
ー
2009
再利用の候補に挙げ得るか？
コンポネントとして構成するか？
記述するか？
ライブラリ化するか？
見つけ出すか？
詳細にわたって要求条件に適合させるか？
(C)Prof.M.J.Matsumoto
31
◎アーチファクトの具備すべき要件
適合性
定義充足性
転用可能性
検索可能性
高い擬集度
弱い結合度
2009
(C)Prof.M.J.Matsumoto
32
◎アーチファクトが満たすべきいくつかの重要な
条件
ー 適合性
アーチファクトを単純な記述内容に展開し、
構文論、意味論、プラグマティックス等のため
の記法(ノーテンション)に基いて適合させうるこ
と。
ー 定義可能性
アーチファクトで起こり得るすべての状態を予見
し表現可能なこと。
2009
(C)Prof.M.J.Matsumoto
33
ー 転用可能性
アーチファクトが(現在開発している領域
以外の）コンテクストでも利用できること。
この要求条件は上記の適合性とも密接な関連性を持 つ。
ー 検索可能性
アーチファクトをブラウザ機能を使って検索できる
こと。
この要求条件も適合性と密接な関連を持つ。
2009
(C)Prof.M.J.Matsumoto
34
ー 高い擬集度(コヘージョン)
アーチファクトは互いに密接な関係を持つ
要素で構成されていること。
ー 弱い結合度
アーチファクトは広範にわたって互いに依
存し合っていないこと。
2009
(C)Prof.M.J.Matsumoto
35
４．いかに再利用するか
４．１
「再利用のための」および
「再利用による」ソフトウェア作成
◎
「再利用のために (for reuse) 」ソフトウェアを
作成する： いくつかの既存システムを分析
し、それらに共通している機能を抽出し、部品モ
デルを作成する。
◎
「再利用によって （with reuse）」ソフトウェア
を作成する：
部品モデルを活用してソフト
ウエアを作成する。
2009
(C)Prof.M.J.Matsumoto
36
再利用支援方法の理論的分類
帰結法
類別化
モデル化
抽象化・特殊化
2009
(C)Prof.M.J.Matsumoto
37
◎ 支援方法の理論的分類[WEG87]
ー 帰結：
問題Bを問題Aに帰結させるとは、Aを解決
するために開発された技術を、Bを解決する
ためにも導入することである。例えば、文脈
自由な文法のための解析アルゴリズムを
マトリックス乗算法に帰結させることである。
ー 類別化：
問題Aが同類の問題Kに属するとき、Aの解
を得るためK問題の解を利用することが可能
2009
(C)Prof.M.J.Matsumoto
38
ー モデル化：
モデルは、複雑な状態への対処を緩和もしくは
可能にする。例えば、セマンティックモデルは、
プログラムと等価のものとして表すことができる。
ー 抽象化／特殊化：
抽象化は、問題の細目を省略して問題（の共通特
性） を記述すること。例えば、点または線を移動させて線または面を生成
する場面や、下位プログラムに上位プログラムの属性や特質を継承させる場面
において、問題の細目を省略して問題（の 共通特性） を記述することができる。
2009
(C)Prof.M.J.Matsumoto
39
Infra/Component Engineering: What are the best
strategies for preparing reusable components or
building blocks?
Generic
concrete
Abstract
Specific
2009
(C)Prof.M.J.Matsumoto
40
ー インバリアント：
関数のインバリアント （不変式）は、関数の
実現やプログラムの検証を利用もしくは再
利用を通じて行う場合、関係するすべての
プログラムに有効なものとして適用されな
ければならない。
ー サンプルによる識別：
この解決方法は、共通性の発見を容易に
する。
2009
(C)Prof.M.J.Matsumoto
41
ー規則性：
この特性は、例えば、規則的な量を規則的
に表現することにより状態を簡潔に表すこと
ができる。
ー与えられた条件に適合させて（場合によって
は調整し）統合するか？
2009
(C)Prof.M.J.Matsumoto
42
４．２ どのように、再利用を支援できるか
◎“再利用可能ビルディングブロック（基礎単位）”による
再利用
基礎単位とは（比較的）安定した内部構成を持つアーチファクト
◎ “再利用可能パターン”による再利用
パターンは、プログラムまたはその一部であり、作動することに
よってなんらかの機能を発揮するという能動的な性格を持ったも
の
2009
(C)Prof.M.J.Matsumoto
43
再利用支援ツール
（１）支援ツールに望まれる機能
創作
ライブラリ管理
活用
再利用するもの
ドメイン分析
ソフトウェア
アーキテクチャ開発
コンポーネント
（含むジェネレタ）
開発
進 化
調 達
受け入れ
カタログ化
確 認
定量的トラッキング
基礎的支援機能として
データモデリング
ライブラリ
メトリックス
アセットに対する
要求決定
識 別
選 択
テイラリング
アプリケーションと
して他部門と統合
コード
要 求
テスト
プロセス
設 計
分 析
ドメイン知識
各種文書
2009
(C)Prof.M.J.Matsumoto
44
（２）再利用指向ＣＡＳＥの機能例
再利用のためのソフトウェア作成支援機能
コードからのプログラム制御理論支援機能
コードからのフォーム仕様生成
コードからのシステム全体のモジュール関係図生成
コードからの部品切出し支援
領域分析支援
2009
(C)Prof.M.J.Matsumoto
45
再利用によるソフトウェア作成支援機能
要求定義支援機能
検索支援機能
理解／再利用判断支援機能
仕様適合支援機能
差分支援
変更による影響チェック機能
変更による矛盾製チェック機能
プログラム合成機能
仕様のコードへの変換機能
プログラム合成機能
システム統合機能
2009
情報資源管理機能
(C)Prof.M.J.Matsumoto
46
再利用とCASE
大抵
いくつかの領域を複合化
3.情報組織化のメカニズム
1.標準化やコンベンション
（取り決め）整備
(a)情報システム
(a)データ交換フォーマット
(b)標準インターフェース及び標準
ルーチン
(b)分類方式
(c)関連アーチファクトの統合
2.特別調整（カストマイジング）
4.構成のメカニズム
(a)手作業
(b)機械化
(a)パイプ
(b)インターフェイス制御
(c)知的補助
(d)メッセージパッシング
(e)継承
2009
(C)Prof.M.J.Matsumoto
47
7.システム統合
5.メガプログラミング
(a)ジェネレータ
(b)超高級言語（VHLL）
(c)エンド ユーザープログラミング
6.知識に基づくプログラミング
(a)変換システム
(b)生成システム
(c)構築システム
2009
(C)Prof.M.J.Matsumoto
48
◎支援系
○言語をベースとするシステム
○生成システム
○変換システム
2009
(C)Prof.M.J.Matsumoto
49
再利用の方式
アプローチ
構築型
生成型
再利用ｺﾝﾎﾟｰﾈﾝﾄ
ビルディング・ブロック
パターン及び記述子
ｺﾝﾎﾟｰﾈﾝﾄの性質
アトミック的、不変的
ジェネリック、適度に展開的
再利用の方式
コンポジション
生成
重 点
例
ｺﾝﾎﾟｰﾈﾝﾄﾗ 分類とｺﾝﾎﾟｼﾞｼｮﾝ 言語ベース
ｲﾌﾞﾗﾘ
方式
の生成
－ｻﾌﾞﾙｰﾁﾝﾗ オブジェクト指向
ｲﾌﾞﾗﾘ
SEA/Iのｼﾝｾｻｲ
ｻﾞｰﾊｰﾄﾞｳｪｱ部
－SEA/Iの
分のｶﾀﾛｸﾞ
EIB
ドメイン毎のﾗｲﾌﾞﾗﾘ
ｱﾌﾟﾘｹｰｼｮﾝ
ｼﾞｪﾈﾚｰﾀ
ﾄﾗﾝｽ
ﾌｫｰﾒｰ
ｼｮﾝ
－ﾏｸﾛ言語
－SEA/Iの
各ｼﾞｪﾈﾚｰﾀ
GIST
－ﾚﾎﾟｰﾄｼﾞｪﾈ
ﾚｰﾀ
REFINE
（MERIT）
－UIﾌﾟﾛﾄﾀｲ
生成システム
ﾊﾟ
注１．両者の組合せ（例：SEA/I）
2009
２．OS／言語従属からの脱却
(C)Prof.M.J.Matsumoto
50
（３）再利用指向のプロセスモ
デル
ボトムアップ
フレームを使用し、ビルディングブロック式にソフト
ウェアシステムを構築
トップダウン
ニーズに最も近いシステム仕様を検索し、目標のシステム要求条件を
満たすべく必要な修正を行い、生産の出発点とするもので生成系を
当てにしている
ハイブリット
（１）ライブラリの中の要求条件に最も近い仕様を探し
（２）差分法を用いて仕様を修正し
（３）得られた最終仕様を使ってスケルトンコードを生成する。
さらに再利用フレームを利用して実行可能コードを構築する
2009
(C)Prof.M.J.Matsumoto
51
再思考
再思考
提案要求
提案
要求定義のための
ﾌﾚｰﾑ検索と変更
初版ｿﾌﾄｳｪｱ
仕様
再思考
仕様変更
最終ｿﾌﾄｳｪｱ
仕様
コード
変換と合成
エラー
ﾄｯﾌﾟﾀﾞｳﾝｱﾌﾟﾛｰﾁ
←混合ｱﾌﾟﾛｰﾁ→
ﾎﾞﾄﾑｱｯﾌﾟｱﾌﾟﾛｰﾁ
ﾌﾟﾛｸﾞﾗﾑ単位
ﾌﾚｰﾑ
プロセスの流れ
ﾌﾟﾛｾｽ
情報
情報の流れ
ﾁｪｯｸﾎﾟｲﾝﾄと
ﾌｨｰﾄﾞﾊﾞｯｸ
2009
(C)Prof.M.J.Matsumoto
52
（４）再利用指向ＣＡＳＥの評価
◎仕様レベルで再利用
プログラム言語レベルでの再利用よりも利点が多い
◎仕様レベルの再利用が実践的に可能となるための条件
○ライブラリに再利用可能仕様が蓄積されていること
○再利用できるか否かを、決定するための前提事項
に、候補がいかなるものであるかを理解すること、
および要求されていることとの相異点（や類似点）
は何かを認識することなどがある。そのことが容易
に行えること。
2009
(C)Prof.M.J.Matsumoto
53
○(変更を伴う再利用の場合)差分が容易に行えること
○仕様からプログラム言語への自動的な変換メカニズ
ムが用意されていること。
2009
(C)Prof.M.J.Matsumoto
54
（1）機能階層フレームの再利用
（2）入出力設計フレームの再利用
（3）プログラム制御論理フレームの再利用
2009
(C)Prof.M.J.Matsumoto
55
4.3 自動化と再利用との関係
両者の関係は、互いに他の目的や手段となる。
◎ 再利用の立場から自動化を追求すると、
・再利用のためのソフトウェア生産における自動化
[例]部品切り出しのためのコード解析
・再利用によるソフトウェア生産における自動化
[例]確定仕様以降の変換や部品合成による工程自動化
2009
(C)Prof.M.J.Matsumoto
56
◎ 自動化の立場から再利用を追求すると、
・自動化されない工程作業の再利用ベースでの処置
[例]設計を再利用ベースで行う
・自動工程における部品の補充と利用
[例]合成における部品利用
・自動工程への入力の再利用ベースでの準備
2009
(C)Prof.M.J.Matsumoto
57
再利用
●
n2
W4
●
W1
●
W2
●
f1
●
f2
●
●
再利用による
W3
ソフトウェア生産
再利用のための
●
f3
ソフトウェア生産
a1
無再利用
n1
●
m1
●
2009
手動
●
半自動
完全自動化
自動化
m2
●
生産性・品質
f 1 部品洗練
f 2 影響分析
f 3 部品構文チェック
a3
●
m3
●
w1
w2
w3
w4
a 1 変更支援
フレーム理解と使用決定
a 3 仕様コンパイラ
フレーム変更
m 1 危機的
仕様変換
m 2 現状維持
フレームによるプログラム合成
m 3 顧客満足
(C)Prof.M.J.Matsumoto
n 1 低水準
（元来再利用が無理な場
合と再利用が可能である
がしない場合がある）
n 2 ３倍以上良い
58
4.4 モデルベースドソフトウェア開発方法
設計モデル
定義要求のための
ドメインモデル
情報モデル
設計要項
特徴モデル
ﾓｼﾞｭｰﾙ
機能モデル
方針
設計仕様
新規
要求
一覧
absdef
ghijk…
一般設計
absdef
ghijk…
ｶｽﾀﾑ設計
ﾌﾟﾛﾄ
要求分析
特徴
一覧
2009
関連ﾓﾃﾞﾙ
npa ph m
{a b/b ncc(a)}
c
顧客
ﾆｰｽﾞ
再利用
ｱﾌﾟﾘｹｰｼｮﾝ
ｼﾞｪﾈﾚｰﾀｰ ｺﾝﾎﾟｰﾈﾝﾄﾗｲﾌﾞﾗﾘ
ﾀｲﾋﾟﾝｸﾞ
ﾄﾞﾒｲﾝ分析
ｺﾝﾎﾟｰﾈ
ﾝﾄ仕様
構成
指示
ｲﾝﾃｸﾞﾚｰｼｮﾝとﾃｽﾄ
ﾌﾟﾛｾｽﾊﾞｯｸﾄﾗｯｷﾝｸﾞ
(C)Prof.M.J.Matsumoto
ｱﾌﾟﾘ
ｹｰｼｮ
ﾝｿﾌﾄ
ｳｪｱ
ｶｽﾀﾑ製造
59
4.5 For Reuse支援
• Round trip software
engineering
• Pattern
• Class Library
• Framework
• Domain Model
2009
(C)Prof.M.J.Matsumoto
60
５．再利用進化モデルの研究
進化モデル
１
２
３
４
５
初期状態
（なし）
改善計画状態
（認識）
改善実行状態
（試行）
管理状態
（実行）
理想像
（ＰＤＣＡ）
支援ツール
なし
検索ツール
保守ツール
利用状況等
データ統計分析
自動生成
メジャメント
なし
認識
標準化
計画的メジャメント
確立
部品の評価・品質保証・信頼性
個人
制度の必要性の認識
認定・検定制度作成
認定・検定制度運用
確立・実績
法律・契約
認識なし
意識あり
規約作成
規約運用
確立
教育
なし
基礎
テクニカル
ﾃｸﾆｶﾙ＋ﾏﾈｰｼﾞﾒﾝﾄ
全層
再利用ﾍﾞｰｽのｿﾌﾄｳｪｱ開発・収穫
個人
既存部品使用
新部品開発
計画的
標準化
再利用対象
コード
モジュール
＋ﾚﾍﾞﾙ1
パッケージ
＋ﾚﾍﾞﾙ2
設計
要求定義
＋ﾚﾍﾞﾙ4
グループ
プロジェクト
部門
再利用の組織範囲
（支援・部品開発・保守・利用）
2009
個人
(C)Prof.M.J.Matsumoto
＋ﾚﾍﾞﾙ3
会社
61
６．領域分析（ Domain Analysis ）
６．１ 領域分析とは
◎ 領域とは、ここではいくつかのシステムの集合体であり、
を形成するものとする。
ある分野
◎ 領域分析（Domain Analysis,以下DAと略す）とは、システ
ムより上位に位置付けられる領域に対する分析作業を指
す。
2009
(C)Prof.M.J.Matsumoto
62
６．２ 何故重要か
領域分析は、特定目的のソフトウェアでなく、部品やパッケ
ージのような汎用性の高いソフトウェアを開発するための手
法として注目。
2009
(C)Prof.M.J.Matsumoto
63
６．３ システム開発成熟度
無モデル段階
有モデル段階
◎長年、システムの開発はシステ ム分析か
ら行われてきた。
◎ある領域の最初のいくつかのプロジェクト
においては、それで良い。
◎領域モデル化
ある領域の数多くのプロジェクトを経験
するにつれ、性質が掴めてき、その領域
のモデルを描くことができるようになって
くる。
◎特化
その領域内であれば、いかなる開発案
件に対しても、そのモデルを基底にして 、
特殊化を施すことで対処してゆくよう
になる。
2009
◎このようにフィードバックがかかる形態は、
より進んだ段階 と言える。そこでは領域
分析やモデルの洗練化が重要な位置を
占める。
(C)Prof.M.J.Matsumoto
64
システム開発成熟度 第1段階
◎長年、システムの開発はシステム分
析から始まると信じられてきた。
◎それは
システム開発熟成度の第１段階
にいることを物語っている。
2009
(C)Prof.M.J.Matsumoto
65
システム開発成熟度 第2段階
◎数多くのシステム開発を経験するにつれ、
ある領域の性質が掴めてき、モデルを描く
ことができるようになってくる。
◎その領域内であれば、いかなる開発案件
に対してもそのモデルを基底として、特殊
化を施すことで対処していくようになる。
◎このようにフィードバックがかかる形態は、
第２段階 と言える。そこでは領域分析が
2009
重要な役割を担う。
(C)Prof.M.J.Matsumoto
66
6.4 領域分析Domain Analysisとシステム分析Systems
Analysis
領域分析
システム分析
意味
特定の問題領域ないしアプリケーション分野を対
象として、主要概念や要素間の関係を明らかにす
る
システムの主要な要件や制約を
念頭にシステム設計に必要な事を
検討する
分析対象
類似アプリケーションの集合であるドメイン（領域）
とそこに含まれる全てのシステム
注目したある特定のシステム
主な作業
それらシステムの一般化や共通な性質を抽出し
領域固有言語（例BPMN）で記述する
現状分析や情報化システムのモ
デル提案
□その領域に属す既存システムの
・設計諸元
・開発プロセス
・コード
・テスト仕様
□その領域の業務知識
・ＤＡの出力
・システム化要求
□領域モデル
・定義モデル
・概念モデル
・機能モデル
□部品群
・システム基本設計など
主な入力
主な出力
2009
(C)Prof.M.J.Matsumoto
67
表1：ソフトウェア生産性に及ぼす再利用の効果
再 利 用 率 （％）
a）
0%
25%
50%
75%
81.5
45
32
15
8
6
5
4
40.75
22.5
16
7.5
月間就業人員当たりステップ数
165
263
370
833
節約
0%
45％
61％
82％
月間就業総時間
従業員数
１ステップ当たりコスト
出典 ： [JON86]
2009
(C)Prof.M.J.Matsumoto
68
再 利 用 率 （％）
b）
10%
25%
30%
50%
75%
80%
月間就業総時間
9.9
29
37
81.8
208
257
従業員数
8.7
25
31.6
66.7
150
178
１ステップ当たりコスト
7.5
21.2
26.6
53.8
111
127
月間就業人員当たりステップ数
6.4
17.6
22
42.9
81.8
92.3
節約
5.3
14.3
17.6
33.3
60
66.7
出典 ： [END88]
Kwとは、再利用生産コストの再利用しない生産の場合のコストとの相対比で１は両者が同
じ、０．５は再利用した場合コストが半分で済むことを意味する。枠内の数値は再利用しな
い場合と比較した生産性向上率（％）を示す。
再 利 用 率 （％）
c）
0%
10%
30%
50%
80%
月間就業総時間
200
176
131
89
33
従業員数
0%
12%
34%
56%
84%
出典 ： [LOV88]
2009
(C)Prof.M.J.Matsumoto
69
７． 再利用評価
７．１ ROIモデル式
プロジェクト毎ROI
ROI = RCA + ORCA － ADC
ORCA ： 再利用の恩恵を受ける他プロジェクトのRCA
ADC ： 初期プロジェクトにおける開発コスト増
会社毎ROI
R1 － C1
1+k
ROI = －Co +
＋
R2 － C2
＋ ・・・ +
(1 + k) 2
Rn － Cn
(1 + k) n
C ： 再利用開始コスト
Ri ： 年度 i のレビニユ（節減）
Ci ： 〃 コスト
n ： 該当年度数
k ： 割引率
2009
(C)Prof.M.J.Matsumoto
70
７．２ 再利用メトリックス/観測データ
データ
記号
単位
定義
源
１
出荷ソース命令
Shipped Source
Instructions
SSI
LOC
その製品向けに作成したLOCで、RSIは含まない
直接計測
２
変更ソース命令
Changed Source
Instructions
CSI
LOC
その製品のあるリリース向けに追加または改造
したLOCで、RSIは含まない
〃
３
再利用ソース命令
Reused Source
Instructions
RSI
LOC
出荷されるソース命令であるが、自部門で開発も 〃
しくは保守しているものではない。通常ブラック
ボックス的に再利用したもの。
何回もcallしていても１と数える。以前のﾘﾘｰｽの
ﾍﾞｰｽ命令や部門的改造ﾊﾟｰﾂはRSIではない。
４
他部門による再利用
ソース命令
Source Instructions
Reused by Others
SIRBO
LOC
他部門を再利用の面で以下に助けたかを示す。
そうした他部門の数Aだけｶｳﾝﾄする。ﾊﾟｰﾂ毎に：
SIRBO=LOC×A
〃
５
LOC当たりコスト
Cost/LOC
\/LOC
再利用と無関係に開発に要するコスト
履歴ﾃﾞｰﾀ
６
TVUA率
Total Valid Unique
Program Analysis
TVUA/LOC
平均エラー数
〃
７
TVUA当たりコスト
2009
\/TVUA(C)Prof.M.J.Matsumoto
〃71
７．３ 導出可能データ
メトリックス
記号
単位
RSI
１
再利用率
Reuse %
・製品の再利用率
Reuse % for P
・製品リリースの再利用率
Reuse % for P/R
・部門の再利用率
Reuse % for Organization
RSI + SSI
RSI
RSI + CSI
RSI
%
×100
×100
RSI + SSI
２
RCA
３
RVA(Reuse Value Added)
RCA(Reuse Cost Avoidance) + Service Cost Avoidance
=RSI×(1-0.2)×(New Code Cost)+RSI×(TVUA率)
×(TVUA当たりコスト)
( SSI + RSI ) + SIRBO
\
部門の効率指数
SSI
2009
(C)Prof.M.J.Matsumoto
72
８．最近の動向
８．１再利用ライブラリ構築例
ASSET： Asset Source for Software Engineering Technology
○米国の国家的再利用ライブラリ
○RAPID、COSMIC、AMSなどのライブラリシステム
を包括
○1991年8月よりソフトウェアハウスでの開発実務、
教育訓練用途などに使われている。
2009
(C)Prof.M.J.Matsumoto
73
CARDS： Central Archive for Reusable Defense Software
○政府機関におけるシステムの調達や開発委託に
おいて、再利用をいかに組み込む事ができるか調査。
○内容は領域固有で、政府所有且つ政府運用の場合
と、政府所有且つ受請者運用の場合のみに限定。
○ユーザ／サプライアは政府職員か政府受請者（含む
プロスペクト）だけ。
○GOTS (Government off the Shelf )、
COTS( Commercial off the Shelf)、パブリックドメイン
2009
コンポーネント (C)Prof.M.J.Matsumoto
74
米国DoDにおけるライブラリ相互活用
◎各種の再利用ライブラリを相互活用できるように
するため、ネットワークを構築。
◎このネットワークを通じて、円滑なアクセスを図る。
◎異プラットフォーム環境に置かれている再利用
アセットを活用。
2009
(C)Prof.M.J.Matsumoto
75
PAL： Public Ada Library
○Adaソフトウェア、コースウェア、文書
○シェアウェア、フリーウェア、GNU コピーレフトなど
パブリックなどパブリック配布になったものを広く
活用
○Ada教育者間で教材やアイデアを交換
2009
(C)Prof.M.J.Matsumoto
76
Where Are the Libraries?
・Resuse can be increased with increased number of ( different ) libraries
・Successful domain specific libraries are built by remembering ：
1. Know your business objectives
2. Understand reuse principles
3. Do a domain analysis
4. A void leading edge technology areas or those with a high
rate of technical change
5. Control the risks associated with evolving technology
( e.g., language changes)
2009
(C)Prof.M.J.Matsumoto
77
８．２再利用支援・ツール例 AdaReVu
AdaReVuはAda Software Reuse Assesment Tool
(ASRAT)であり、海軍訓練システム( NTS、フロリダ
州オーランド)との契約のもとに、オリジナルなものと
して開発された。
Ａｄａソフトウェア品質と生産性に関するガイドライン
に照らし、ソースコードを評価するツールである。
2009
(C)Prof.M.J.Matsumoto
78
８．３ 重要研究テーマの動向
ソフトウェア再利用に関して国際学会などの場で、
いかなるテーマが検討されているか。
再利用基礎論
○ 再利用プロセスの共通合意モデルが色々な
組織に対応できるか
○ 組織固有要因を一般枠組みの特化拡張によって
モデル化することが可能か
2009
(C)Prof.M.J.Matsumoto
79
(1) 再利用の共通合意プロセスモデル
(CRPM-Consensus Reuse Process Model)や成熟度
モデル(RMM-Resuse Process Model)に関する有用性、
有益性、危険性を検討し明らかにすること。
(2) CRPMやRMMが有用である基準を示すこと。
(3) 現行の再利用プロセスモデルに対する再利用コミュニ
ティからのフィードバックを得ること。
(4) モデル間で共通な側面とそうでない側面とを色分けする
こと。
(5) モデルに関して特定の部門組織に固有な事項と一般に
適用しうる事項とを区別すること。
2009
(C)Prof.M.J.Matsumoto
80
検討されたモデルは以下のものである：
(1) STARSのCFRP (Conceptual Framework for Reuse
Process)．．アセットの創作と利用を区別
(2) HP社の再利用プロセスモデル．．上記(1)のHPの組織に
合わせたインスタンス
(3) ESPRINT Ⅱ REBOOTモデル
(4) Bank of Montreal モデル
(5) Liesbeth Dusink の再利用空間モデル(Reuse Space
Model)
2009
(C)Prof.M.J.Matsumoto
81
(6) SPCの再利用ケーパビリテイモデル
(Reuse Capability Model)
(7) STARSの再利用戦略モデル
Strategies Model)
2009
(C)Prof.M.J.Matsumoto
(Reuse
82
再利用設計
Ａｄａ またはＣ＋＋に適当な再利用ソフトウエアコン
ポーネント
（例：ジェネリックパッケージ、クラステンプレート）を
いかに設計すれば良いか。
以下の点に焦点が当てられている：
(1) 現存のコンポーネントの実践的な再利用度をいかに
測定するか
(2) 言語の持つ再利用性についての設計能力
(例：パラメタ化、継承)をいかに経験的に評価するか
2009
(C)Prof.M.J.Matsumoto
83
(3) さらなる言語の処理系と環境の必要性と有効性
(4) さらなる言語に仕様と設計法の必要性と有効性
(5) 開発をガイドする再利用メトリックスの必要性と有効性
(6) 大規模粒度の再利用を左右するスケーラビリテイ問題
(7) さらに有効な再利用コンポーネントを創作するための設計
者への実践的指針
(8) 離散型コンポーネント (イデオム、パターン、アーキテクチ
ャ、パラダイム)とは直接対応しない設計実体についての
再利用指針
2009
(C)Prof.M.J.Matsumoto
84
課題：
(1) 関数型、論理型、手続型､オブジェクト指向のうち
どのプログラミングパラダイムが、最も再利用設
計に適しているか?
(2) 再利用設計のハンドブックの特質は何か?具体的
にこれらの項目はどうであるべきか?
(3) 再利用設計の考え方は大学や企業で如何に教
えるべきか?
(4) 言語独立ないかなる指針が再利用設計をガイド
しうるか?
2009
(C)Prof.M.J.Matsumoto
85
●プログラミングパラダイムについて
(1 a) 合意：再利用設計を支援するプログラミングパラダイム
として上記以外のものをさらに追加すべきである：
再利用指向プログラミングパラダイム ＝
オブジェクト指向設計
（すなわち、モジュール/クラス/タイプであり
コンポーネントとしての手続/関数ではない）
＋ インプリメントテーション詳細と抽象的ふるまいの
厳密な分離
＋ “local certifiability” を支援する言語要素の使用
法
2009
(C)Prof.M.J.Matsumoto
（コンポーネント毎のふるまいの推論）
86
●ハンドブックについて
(2 a) 合意： 再利用設計ハンドブックはもし集大成的であろう
とすれば、分厚くしかも広範にわたるものとなろう。
高水準設計や仕様や低水準コーディングなどの
課題を網羅しようとすれば。
(2 b) 議論の余地あり：
ハンドブックの構成は｢解探索毎の課題｣であって、
｢課題探索毎の解｣ではないだろう。
2009
(C)Prof.M.J.Matsumoto
87
●教育
(3 a) 合意： 一般論を説明するだけでは不十分である。
再利用設計の指針は操作上の事柄にも言及
すべきである。
(3 b) 合意： 教授内容の中心点はライフサイクルを通して
再利用を行なうことを動機づけることである。
効果的な暗箱コンポーネントの再利用は単に
コーディングの労力節減だけでなく、設計は保守工数
の大きな節減ももたらすことを教えるべきである。
2009
(C)Prof.M.J.Matsumoto
88
MBSD(Model-Based Software
Development)
独立
c
a: Domain models
b: Design patterns
d
c: Architectural styles
ドメイン
d: Frameworks
b
e: Kits
e
e
従属
a
f
g: Domain taxonomy
g
具体化
2009
a
f: Applications
実装
抽象化
(C)Prof.M.J.Matsumoto
89
a: Domain models
MBSDの喩え
オブジェクト再利用技術
c: Architectural styles
d: Frameworks
一般建築キット
独立
b: Design patterns
基本構造設計
c
e: Kits
f: Applications
g: Domain taxonomy
c
d
標準部材
ドメイン
e
別荘キット
b
a
e
従属
a
f
g
具体化
2009
種類別建築モデル
実装
抽象化
(C)Prof.M.J.Matsumoto
90
最新鋭技術
• ソリューション工学で対象をモデル化（革
新）し解を策定し、ソフトウエア工学のDM
を使って実装し実践し改革を繰り返してゆ
く（モデル駆動）。
2009
(C)Prof.M.J.Matsumoto
91
ソリューション工学
ソフトウエア工学
2009
(C)Prof.M.J.Matsumoto
92
最新技術
• サービスコンピューテイング
• SOA
• クラウドコンピューティング
2009
(C)Prof.M.J.Matsumoto
93
健闘を期待する！
• ソリューション工学、ソフトウエア工学、ISプ
ロジェクト管理
2009
(C)Prof.M.J.Matsumoto
94
© Copyright 2024 ExpyDoc
