オブジェクト指向技術を前提とした新しい開発プロセスの紹介
クラスタとは?
- 関連するクラスのグループ
- クラスタ自身は階層となっている
- 5〜40クラスくらい
- 一人の開発者が精通する範囲
クラスタ ��≠ パッケージ
- 本書でいう「スーパーモジュール」とは異なる
- 本書ではスーパーモジュールと、それによるアクセス管理を良しとしない
- フラットな構成が良い
- クラスタ言語構造ではない
クラスタ分けの効果について
- 常識とプロジェクトリーダーの経験によるところが大きい
- 組織の構成によっても最適解が異なる
- クラスタ分けの誤りで致命的になるほどではない
ウォーターフォールモデル
- 関心事の分離、仕事の定義、仕様記述の重要性という意味では効果があった
- 道筋が一つ → 一つの工程の停止が全体の進捗の停止をもたらす
- 他の反復的なモデル → 多くは1つの道筋のモデルが中心
コンカレントエンジニアリング
- ウォーターフォールの規律正しさと非集中化、柔軟さの両立
- クラスタ毎にチームを分け並列に開発する
- 各クラスタではウォーターフォール同様ステップ順に開発を行う
- ステップは戻っても良い
ステップ
- 仕様記述 … クラスの主要な特性と制約を明らかにする
- 設計 … クラスのアーキテクチャとクラスの関係を定義する
- 実現 … 詳細を全て追加し、クラスを仕上げる
- 正当性検証と妥当性検証
- 汎化
他の作業 ｰ 実現可能性調査
- クラスタの分割
- 図28.3 参照
- 各クラスタの困難さなどから開発開始する順番を調整する
統合
- 各クラスタの開発の状態を定期的に調和させる
- 一週間に一度など
- デモがあることを保証する
オブジェクト指向によりコンカレントエンジニアリングが可能になる
- 情報隠蔽機能により、依存するクラスタが完成していなくともクラスタの作業が行うことができる
- 図28.4
- (Cとかでもできる気が…)
- 作ったクラスを再利用可能にする
- 汎化には伝統的なプロセスに対応するものがない
「汎化をプロセスに別だしせずに、ソフトウェアプロセス全体の一部にするべきではないか?」
- 最初から再利用を意識すべき(演繹的見方)
- 演繹的見方と機能的見方は相互補完する関係にある
ソフトウェアが最初から再利用可能になることは通常ない
- そのための十分な時間が通常用意されていない
- また再利用性の約束ができるわけでもない
- 誰かが実際に再利用するまでは
汎化の段階を入れるかどうかは方針の問題
- 再利用性を上げることに公然と反対する人はいない
- ただしリップサービスである可能性はある
- 汎化のために時間を投入する許可が出るかどうか
再利用の文化
- 再利用される前提で、全てのソフトウェアを開発する(演繹)
- 実際に再利用されるまでは、再利用可能だと信じない(帰納)
汎化の役割
- 概念抽象 … クラスの背後にある、純粋な抽象のために、暫定クラスを導入
- 要素抽出 … 無関係な2つのクラスから、汎用的な共通要素を抽出
- 表明の追加
- 例外を処理するための rescue の追加
- ドキュメントの追加
シームレス開発
- 分析、設計、実現、保守のための一つのフレームワークを定義(?)
利点
- 各工程の移行に伴うエラー(インピーダンスミスマッチ)を防げる
- 単一のフレームワークを使うことで逆方向の調整が可能になる
遡行可能性
- 「階段のウィット」
シームレス性と遡行可能性による影響
- 設計者、実現者の垣根を取り除く
- 分析と実現の活動を別物と扱う考えとの決別 オブジェクト技術
- 分析、設計、実装の不要な違いを取り除く
- 実装の仕事の復権ができる
- マシンよりの低レベルな言語による説明よりも、領域の抽象概念に集中する
- プログラミング内の表記をモデリングのツールとしても使えるレベルまで高レベルにする