Upload
nasim-riddle
View
35
Download
0
Embed Size (px)
DESCRIPTION
Disciplined Software Engineering Lecture #11. Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213 Sponsored by the U.S. Department of Defense. Lecture #11 概要. 個人的ソフトウエアプロセスの拡張 拡張性の原則 ソフトウエアの複雑さの取り扱い 開発戦略 循環的 PSP ソフトウエアインスペクション (現在はPSP2). 拡張性とは何か ?. - PowerPoint PPT Presentation
Citation preview
Copyright © 1994 Carnegie Mellon University1
Disciplined Software Engineering Lecture #11
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213
Sponsored by the U.S. Department of Defense
Copyright © 1994 Carnegie Mellon University2
Lecture #11 概要 個人的ソフトウエアプロセスの拡張
•拡張性の原則•ソフトウエアの複雑さの取り扱い•開発戦略
循環的 PSP
ソフトウエアインスペクション(現在はPSP2)
Copyright © 1994 Carnegie Mellon University3
拡張性とは何か ? 製品開発プロセスは使用される方法と技法が、より大規模なプロジェクトに対しても同様にうまく働く時、拡張可能である。
拡張性は典型的には以下である。•製品規模の狭い範囲を越えて適用される•類似のアプリケーション領域に限定される•先例のないシステムには適用しない•管理が貧弱なプロジェクトには働かない•技術作業に規範がないところで適用される事はありそうにない。
Copyright © 1994 Carnegie Mellon University4
拡張性の原則 拡張性が可能であるためには、より大きなプロジェク
の要素は小さな と同じ様に振る舞う事がト プロジェクト必要である。
したがって製品設計はその をそれぞれ分プロジェクト割開発される要素に分けなければならない。
これは開発 は個人が効率的に開発できるプロセス プロシの (規模)を考慮に入れることを要求ずェクト スケール
る。
Copyright © 1994 Carnegie Mellon University5
拡張性のステージ 我々は を5つの拡張性 に分類されソフトウエアシステム ステージるものとして見る事が出来る。
これらの拡張性 は以下のようになる:ステージ• ステージ 0 - 単純ルーチン• ステージ 1 - プログラム• ステージ 2 - コンポーネント• ステージ 3 - システム• ステージ 4 - 複合システム
Copyright © 1994 Carnegie Mellon University6
拡張性 ステージ 0 ステージ 0 は基本的な構成物レベルである。これはループ、case文、などの構築に関係する。
0 は 入門コースの主要な焦点でステージ プログラミングある。
ステージ 0 では , 各 構成物を意識して設プログラミング計する。
あなたの思考がこれらの詳細に没頭している時には、より大きな構成物を思い浮かべる事は難しい。
Copyright © 1994 Carnegie Mellon University7
拡張性 ステージ 1 1は数百LOCまでの小規模 に関係ステージ プログラムが ある。
0から 1への移行は言語に習熟してくステージ ステージれば自然に起こる。あなたは今や小規模 をプログラムその詳細な構成物を意識的に設計することなしに一つの実体として考える。
あなたが 1で経験を得るのにしたがって、あステージなたが理解し、自信を持って使う事が出来る小規模プログラム機能を表す語嚢を増やしていく。
Copyright © 1994 Carnegie Mellon University8
拡張性 ステージ 2 ステージ 2 は レベルである。ここで、複数のコンポーネント
が結合され高度な機能を提供する。プログラム ステージ2の は典型的には数千コンポーネント LOC である。
1から 2への移行は経験の増加に伴っステージ ステージて起こる。今や一人で多分作成できる よりプログラムも大規模な について考えることが出来る。 プログラム
2ではステージ , システム問題:すなわち品質、性能、使用性、などが出始める。
(図 11.1 参照:知識の自覚)
Copyright © 1994 Carnegie Mellon University9
拡張性 ステージ 3 3のシステムは数百万ステージ LOC くらいの大きさになるかもしれない。ここで、システム問題が目立ってくる。• は協調して働かなければならない。 コンポーネント• 部品はすべて高品質でなければならない。 コンポーネント
2から 3への移行は次のことを含む。ステージ ステージ• の複雑さの取り扱いプログラム•システムとアプリケーション問題を理解すること•チーム環境で働くこと
3では、主要な力点をプログラムの品質に置かねばステージならない。
Copyright © 1994 Carnegie Mellon University10
拡張性 ステージ 4 4の複合システムは数千万ステージ LOC を含むかもしれない。 •複数の半独立システムが協調して働かねばならない
•品質は最高に重要である。
3から 4への移行では集中制御についステージ ステージての問題のみならず大規模かつ分散したシステムの問題が起こる。
4は半自主的な開発グループと自己管理するステージチームを要求する。
Copyright © 1994 Carnegie Mellon University11
拡張性条件 - 1 拡張可能であるためには
• は管理されなければならない。プロセス• は管理されなければならない。プロジェクト•製品は管理されなければならない。
管理された はプロセス•定義されるべきである•その仕事を分離可能な要素に分解するべきである
•これらの要素を最終システムに効果的に統合するべきである。
Copyright © 1994 Carnegie Mellon University12
拡張性条件 - 2 管理された に対してプロジェクト
•仕事は計画されねばならない•仕事はその計画に対して管理されねばならない•要求の変更は制御されねばならない•システム設計とシステムアーキテクチャはプロジェクトを通して一貫して継続しなければならない。
•構成管理が使用されなければならない。
Copyright © 1994 Carnegie Mellon University13
拡張性条件 - 3 管理された製品に対しては
•欠陥は追跡され制御されなければならない•統合とシステムテストを行わねばならない •縮退テストは首尾一貫して使用される
製品品質は高くなければならない•モジュール欠陥は統合とシステムテストの前に除去すべきである
•モジュール品質の目的は統合とシステムテストの前に全ての欠陥を発見することであるべきである。 ( すなわち、百万 LOC あたり100未満の欠陥を見逃す) →1 KLOC あたり0 . 1未満
Copyright © 1994 Carnegie Mellon University14
拡張性の目的 拡張性の目的は大規模製品を小規模製品と同様な品質と生産性で開発することである。
拡張性は小規模 において行われたタスクプロジェクトにだけ適用される。
より大規模な により要求される新しいタプロジェクトスクは追加の作業を要求するので、生産性は一般的にジョブの規模が増加するのに伴って下降する。
Copyright © 1994 Carnegie Mellon University15
拡張性の範囲 - 1
小規模 プロジェクト
中規模プロジェクト
大規模プロジェクト
モジュール C
モジュールB
モジュール A
モジュール F
モジュール E
モジュール D
モジュール I
モジュール H
モジュール G
モジュール L
モジュール K
モジュール J
モジュール O
モジュール N
モジュール M
コンポーネント X コンポーネント Y
製品 Z
Copyright © 1994 Carnegie Mellon University16
拡張性の範囲 - 2 から への拡張においてモジュールレベル コンポーネントレベル
• の作業の品質と生産性の維持を求めモジュールレベルる
• の作業は新しいので拡張が出来なコンポーネントレベルい
製品 への拡張においてレベル• 作業の品質と生産性の維持を求めるコンポーネントレベル•製品 の作業は新しいので拡張が出来ないレベル
Copyright © 1994 Carnegie Mellon University17
複雑さの管理 - 1 規模と複雑さは密接に関係している。
小規模 は程々に複雑であり得るが、極めてプログラム重要な問題は大規模 を扱う事である。プログラム
が大規模になると一般にプログラムは非常プログラムに複雑になる。
Copyright © 1994 Carnegie Mellon University18
複雑さの管理 - 2 ソフトウエア開発は主として個人によって行われる。•個人は小規模プログラムを一人だけで書く。•大規模プログラムは普通複数の小規模プログラムから構成される
以下を実施するための方法に関連した3つの問題がある。•高品質の小規模プログラムを開発する •より大きなそしてより複雑なプログラムを個人が取り扱えるようにする
•これらの個人的に開発されたプログラムをより大きなシステムに組み合わせる
Copyright © 1994 Carnegie Mellon University19
複雑さの管理 - 3 ソフトウェアの複雑さについての主要な問題は人間が次に関してかぎられた能力しかもっていないと言う事である。•詳細を記憶すること•複雑な関係を視覚化すること
したがって我々は次第に複雑になるプログラムを個人が開発するのに役立つ方法を探し求める。•抽象化•アーキテクチャ•再利用
Copyright © 1994 Carnegie Mellon University20
抽象化の力 - 1 人間は概念的なチャンク (塊 ) で考える
•積極的に使えるのは 7+/- 2個のチャンクの範囲である。
•チャンクが豊かであれば我々の思考が強力になる。
このことはアマチュアのチェスプレイヤーにゲーム中のチェスの駒の位置を記憶することを求めることで示された。 •彼等は僅か 5~6駒しか覚えられなかった.•エキスパートは盤全体を記憶することが出来た。•ランダムに置かれた駒に対しては , エキスパートもアマチュアもほとんど同程度の結果になった。
Copyright © 1994 Carnegie Mellon University21
抽象化の力 - 2 以下のことが成り立てば、ソフトウエアの抽象化はこの様なチャンク (塊 ) を形作ることが出来る•抽象化が精密である•我々が完全に理解している•考えたとおりに正しく実行する
いくつかの可能性のある抽象化は以下である•ルーチン•標準手続きと再利用可能なプログラム•完全なサブシステム
Copyright © 1994 Carnegie Mellon University22
抽象化の力 - 3
概念的な複雑さを減らすため , これらの抽象化は次でなければならない
•仕様化されたとおりに精密に実行する•仕様化された以外の相互関連を持っていない•首尾一貫しかつ自己完結的なシステム機能を 概念的に表現する
Copyright © 1994 Carnegie Mellon University23
抽象化の力 - 4 これらのより大きな言葉で考えるとき , 我々のシステムを精密に定義できる。
そうするとそれらから構成される抽象化を構築することが出来る。
これらの抽象化がシステムに結合されるとき、期待されたように働く可能性がより大きくなる。
Copyright © 1994 Carnegie Mellon University24
抽象化の力 - 5 抽象化において主要な制約になることは以下である。•開発者 ( 人間 ) は仕様化において誤りをする •抽象化はしばしば欠陥を含む•多くの抽象化は特殊であり汎用性がない
このことは他人の仕事を活用することが滅多に出来ないことを意味している。
したがって複雑な システムを知覚する我々ソフトウエアの知的能力は、われわれ自身が開発してきた抽象化によって制約される。
Copyright © 1994 Carnegie Mellon University25
アーキテクチャと再利用 - 1 設計は以下の理由から複雑さを減少さシステムアーキテクチャせることが出来る•首尾一貫した構造的な枠組みを与える •概念的に類似な機能を識別する• を明確に分離するサブシステム
よく構造化された は標準設計の利用を促進アーキテクチャする•アプリケーションの固有事項は一番下のレベルまで決定が延ばされる
•可能なところでは、調整可能なパラメータが定義される。
Copyright © 1994 Carnegie Mellon University26
アーキテクチャと再利用 - 2 このことは標準化された の使用を通してコンポーネント再利用可能性を増加させる。
これらの精密に定義された標準 がそのとコンポーネントき概要設計の抽象化として使用できる
もしこれらの が高品質ならコンポーネント , 拡張性が達成できる可能性はより大である。
Copyright © 1994 Carnegie Mellon University27
フィーチャオリエンテッドなドメイン分析 - 1
なドメイン分析はフィーチャオリエンテッド SEI によって開発された。それは の設計手法の1つでアーキテクチャ•概念的に類似な機能を識別する•これらの機能を にカテゴリ分けするクラス•各 に対する共通の抽象化を定義するクラス•可能なところでは ー を使用するパラメ タ• に特有な機能は後に回す アプリケーション• 部品の最大限の共有を可能にするプログラム
Copyright © 1994 Carnegie Mellon University28
フィーチャオリエンテッドなドメイン分析 - 2 なドメイン分析の例はフィーチャオリエンテッド
• 出力機能を定義するシステム•最高 は を作成し送るレベル メッセージ•次に低い は や などを定義するレベル プリンタ ディスプレイ•次の は を取り扱うレベル プリンタフォーマッティング•次の は特定の を するレベル プリンタタイプ サポート
Copyright © 1994 Carnegie Mellon University29
開発戦略 - 1
開発戦略は があまり大きすぎて1つの製品にシステム作り込めない時要求される•その時システムを要素に分割しなければならない
•それからこれらの要素を開発しなければならない
•それから開発された要素は最終 に統合されシステムる
Copyright © 1994 Carnegie Mellon University30
開発戦略 - 2 戦略は
•より小規模な要素を定義する•それらの要素が開発される順序を確立する•要素が統合される方法を確立する
もし戦略が適切で、要素が適切に開発されるならば•開発 は拡張できるであろうプロセス•開発全体は部品の和に 設計及び統合を加えたシステムものである。
Copyright © 1994 Carnegie Mellon University31
いくつかの開発戦略 多くの開発戦略がありうる
目的は の最も早い時点で主要な問題を識別すプロセスるように、その を逐次的に構築していく事であシステムる。
いくつかの戦略例は以下である: •段階的戦略•機能拡張戦略•高速 拡張戦略パス• 戦略ダミー
Copyright © 1994 Carnegie Mellon University32
2nd拡張
1st拡張
1st拡張
1stモジュール
1stモジュール
1stモジュール
段階的戦略
段階的戦略においては , 機能はそれらが実行される順序で開発される。このやり方は比較的単純な で済み、テスト足場や特別な 機能はほとんど要らない。テスト
In
Out
Out
サイクル 1
サイクル 2
サイクル 3
In
In
Out
Copyright © 1994 Carnegie Mellon University33
機能拡張戦略
機能拡張においては、 を最初に構築し、そベースシステムれから拡張しなければならない . が大規模ベースシステムになるとしばしばその開発に対して別の戦略が必要になる .
4th機能拡張
2nd機能拡張
3rd機能拡張
コアシステム
Ist機能拡張
Copyright © 1994 Carnegie Mellon University34
高速パス拡張戦略
高速 拡張ではパス , 高性能ルーフが最初に構築され、゚ デバッグ
され計測される。
その性能が適切であれば機能拡張が行われる。
性能がまだ仕様の範囲内にあることを保証するために各々の拡張を計測する。
1st拡張
2nd拡張
3rd拡張
4th拡張
a
b
c
d
e
h
g
f
Copyright © 1994 Carnegie Mellon University35
ダミー戦略
B C
コアシステム
機能A
ダミー戦略においては , システムの機能の全部または大部分をダミーコードで置き換えたコアシステムが最初に作られる。
これらのダミーは、その後開発が進むのにしたがって完全な機能に次第に置き換えられる。
A B C
コアシステム
機能B
コアシステム
機能A
C
機能C
機能B
コアシステム
機能A
Copyright © 1994 Carnegie Mellon University36
循環的PSP - 1 循環的 PSP は中規模のプログラムを開発するために循環的開発戦略を使用する枠組みを与える。
複数の PSP2.1 のような循環的要素を含むより大規模なプロセスである。
PSP の要求、計画立案、および事後分析ステップはプログラム全体に対し一度実行される。
Copyright © 1994 Carnegie Mellon University37
概要設計
要求 & 計画立案
概要設計レビュー
統合とシステムテスト
事後分析
循環的開発
循環的 PSP フロー仕様
製品
詳細設計 &設計レビュー
サイクルの明確化
テスト開発とレビュー
テスト
コンパイル
実装とコードレビュー
再評価と再循環
Copyright © 1994 Carnegie Mellon University38
循環的PSP - 2 概要設計はプログラムを小規模要素に分解して 開発戦略を確立する。
そのプロセスは統合、システムテストおよびそれに続く事後分析によって終了する。
開発戦略は以下のような循環的ステップを決定する。•要素の選択•テスト戦略•最終統合を不要にするかもしれない。
Copyright © 1994 Carnegie Mellon University39
チームソフトウェアプロセス - 1 プロジェクト規模をさらに大きくするために、典型的にはチーム開発 が要求される。プロセス
これは主要なプロジェクトタスクを識別する。•これらのタスクを相互に関係づける•開始と終了の条件を確立する•チームメンバーの役割を割当てる•チーム尺度を確立する•チームの目標と品質評価基準を確立する
Copyright © 1994 Carnegie Mellon University40
チームソフトウェアプロセス - 2 チームプロセスはまた個々の PSP がチームの中で関係をもつ事が出来る枠組みを与える , それは•チーム --PSP インタフェースを定義する•標準と尺度を確立する•何処で されるべきか規定するインスペクション•計画立案と報告のガイドラインを確立する
たとえ PSP をもっていたとしても , ではインスペクションチームサポートを得るように試みたほうがよい
PSP の欠陥摘出率を改善するために設計のインスペクショを使用する事を最初に考えなさいン .
Copyright © 1994 Carnegie Mellon University41
インスペクション - 1 (現在はPSP2)
インスペクションはソフトウエア品質の改善と開発時間およびコストを減少させるためにもっともコスト効率のよいテクニックとして知られている。
インスペクションは次のことに役立つ•よりよい仕事をするよう動機づける•効果的なチームコミュニケーションを保証する•優れたものへのこだわりを維持する (個人的なベンチマークの設定)
Copyright © 1994 Carnegie Mellon University42
インスペクション - 2 インスペクションの目的は
•出来るだけ早期の時点でエラーを発見すること•全 が仕事に合意している事を保証することパーティー•その仕事が定義された判断基準に適合している事を検証すること
•公式に仕事を完了すること• を提供することデータ
インスペクションは任意の 製品の要素に使用ソフトウエアできる、例えば•要求、仕様、設計、コード• 資料テスト•文書
Copyright © 1994 Carnegie Mellon University43
インスペクションプロセス - 1 インスペクションは公式に構造化された にプロセス従う
と標準がインスペクションの各 に対チェックリスト タイプして開発される。
インスペクションは技術者のために技術者によって運営される。管理者は出席しない。
Copyright © 1994 Carnegie Mellon University44
インスペクションプロセス - 2
計画立案 説明会議 準備 インスペクション会議 フォローアップ
管理者開発者司会者
司会者開発者
者レビュー
者レビュー 司会者記録者開発者
者レビュー
司会者開発者
Copyright © 1994 Carnegie Mellon University45
インスペクションプロセス - 3 者は前もって準備するレビュー .
インスペクション会議は焦点を問題の識別に置き、問題の解決には置かない .
インスペクション を収集して追跡と分析のたデータめにインスペクション に入力するデータベース .
Copyright © 1994 Carnegie Mellon University46
インスペクションにおける役割 - 1
司会者 •インスペクション を するプロセス リード•焦点を問題解決よりもむしろ問題識別に置き続ける
•識別された問題が解決される事を保証する•インスペクション報告書を提出する
開発者(その仕事をした開発者) • 資料を作成する レビュー•質問に答える •識別された問題を解決する
Copyright © 1994 Carnegie Mellon University47
インスペクションにおける役割 - 2
者 レビュー•インスペクション 会議に出席するキックオフ•前もって 資料を するレビュー レビュー•インスペクション会議に出席する•識別された欠陥または他の関心のある事について問題を提起し質問する
記録者 •識別された問題点を文書化しそれらの解決に責任をもつ人を記録する
•全ての関連する を記録するデータ
Copyright © 1994 Carnegie Mellon University48
演習課題 #11 の第11章を読みなさいテキスト
PSP3 を使用して、ある から説明変数が3データセットつの重回帰 と予測区間を計算するためのパラメータ プロ 10グラム A を書きなさい。 t 分布を計算するた
めに 5プログラム A を使用しなさい。 この宿題のために3つの期間が許される。
付録 D にある 仕様と付録プログラム C にある 説プロセス明と報告書仕様を読んでそのとおりやりなさい。
Copyright © 1994 Carnegie Mellon University49
重回帰 - 1 あなたは6 について以下のような をプロジェクト データもつと仮定しよう•要求される開発時間•新規 LOC 、再利用 LOC 、および修正 LOC
あなたが新規 650コード LOC 、再利用コード 3,000LOC 、および修正コード 155LOC をもつだろうと判断した新規 にかかる時間を見積もりたいプロジェクトと仮定しよう。
開発時間と予測区間をどのように見積もるだろうか?
Copyright © 1994 Carnegie Mellon University50
重回帰 - 2 プログラム # 新規 再利用 修正 時間 w x y z
1 1,142 1,060 325 201
2 863 995 98 98
3 1,065 3,205 23 162
4 554 120 0 54
5 983 2,896 120 138
6 256 485 88 61
合計 4,863 8,761 654 714
見積り値 650 3,000 155 ???
Copyright © 1994 Carnegie Mellon University51
重回帰 - 3 重回帰はあなたが各変数に対して別々の効果データを持たない時に多変量の効果を見積もるための 1つの方法を与える。
1. 見積もり値を計算するため次のような
重回帰公式を使用するだろう。
zk 0 wk1 xk 2 yk3
Copyright © 1994 Carnegie Mellon University52
重回帰 - 4 2. 次のような連立 1次方程式を解くことによって あなたは Beta を求めることが出来るパラメータ
0n 1 wii1
n
2 x ii1
n
3 yii1
n
zii1
n
0 wii1
n
1 wi2
i1
n
2 wix ii1
n
3 wiyii1
n
wizii1
n
0 xii1
n
1 wix ii1
n
2 x i2
i1
n
3 xiy ii1
n
x izii1
n
0 yii1
n
1 wiyii1
n
2 x iyii1
n
3 yi2
i1
n
yizii1
n
Copyright © 1994 Carnegie Mellon University53
重回帰 - 5 3. あなたが項の値を計算するとき ,
次のような連立 1次方程式が得られる。
6 4 863 8 761 654 714
4 863 4 521 899 8 519 938 620 707 667 832
8 761 8 519 938 21 022 091 905 925 1 265 493
654 620 707 905 925 137 902 100 583
0 1 2 3
0 1 2 3
0 1 2 3
0 1 2 3
, ,
, , , , , , ,
, , , , , , , ,
, , , ,
Copyright © 1994 Carnegie Mellon University54
重回帰 - 6 4. 次に、 Gauss の方法を使用して対角化する。 この方法は以下の式を与えるために継続的に掛け
算と引き算を行って方程式から 1回に 1 パラメータずつ
消去して行く。 6 4 863 8 761 654 714
0 580 437 5 1 419 148 90 640 89 135
0 0 4 759 809 270 635 5 002 332
0 0 0 37 073 93 9 122 275
0 1 2 3
0 1 2 3
0 1 2 3
0 1 2 3
, ,
, . , , , ,
, , , , .
, . , .
Copyright © 1994 Carnegie Mellon University55
重回帰 - 7 5. このようにしてBeta項が得られる
0
1
2
3
6 7013
0 0784
0 0150
0 2461
.
.
.
.
Copyright © 1994 Carnegie Mellon University56
重回帰 - 8 6. 次のような方程式を解くことによって範囲に対する
予測区間を決定する。
7 - 分散を次のように計算する
Range t / 2, n 4 11
n
wk wavg 2
wi wavg 2
xk xavg 2
xi xavg 2
yk yavg 2
yi yavg 2
2 1
n 4
zi 0 1wi 2xi 3yi
i1
n2
Copyright © 1994 Carnegie Mellon University57
重回帰 - 9 8. 分散は次のように計算する
9. 平方根の中の項は
2 513.058 22.651
Newk Newavg 2 wk wavg 2 650 810.5 2 25,760.25
Reusek Reuseavg 2 xk xavg 2 3,000 1,460.17 2 2,371,076.43
Modifyk Modifyavg 2 yk yavg 2 155 109 2 2,116
Copyright © 1994 Carnegie Mellon University58
重回帰 - 10 10. n=6, p=4 のときの70 %予測区間に対するt分布
の値は , 表A2 における 85% の列で自由度2 の
ところで見つかる。その値は 1.386 である .
11. 平方根はそのとき次のように計算される
Range 1.386 *22.651 1 1 / 6 25,760.25580,437.5
2,371,076.43
8,229,5712,116
66,61638.846
Copyright © 1994 Carnegie Mellon University59
重回帰 - 11 12. 最終見積もり値はそのとき
z = 6.71+0.0784*650+0.0150*3,000+0.2461*155
= 140.902 時間
13. 38.846 時間の予測区間は見積もりが 102.1 から 179.7 時間であることを意味している。
Copyright © 1994 Carnegie Mellon University60
講義 11 で覚えておくべきメッセージ - 1
1. が拡張可能であれば生産性向上とソフトウエアプロセス 計画立案に非常に役立つ。
2. 拡張性のためには が定義され、良く管理さプロセスれ、そして高い品質をもつことが必要である。
Copyright © 1994 Carnegie Mellon University61
講義 11 で覚えておくべきメッセージ - 2
3. 欠陥摘出管理に焦点を当てたPSPは拡張性を達 成するために役に立つ。(→インスペクション)
4. 抽象化、 、および再利用を利用するこアーキテクチャと
はまたプロセスを拡張可能にすることにも役に立
つであろう。