思考のサルベージ
各工程で心がけたい思想を掘り起こしてみる
今日のテーマは、「機能設計」 一例として、以下のようなケースで考えてみましょう。
システム
メモリアクセスのシステム。目的は、大きく二つ。
- 目的１：メモリに「書く」
- 目的２：メモリから「読む」
基本思想は
「読む」は「書く」より優先される。
「書け」と命令されて「書く」を動かしてる最中に
「読め」の命令が来れば「書く」を中断して「読む」を動かす。
追加する機能
- 目的1のカテゴリに
機能A：特定条件下で「めちゃくちゃ速く書く」 - 目的２のカテゴリに
機能B：特定条件下で「めちゃくちゃ速く読む」
ここで、大事なのが「機能Aの特定条件」と「機能Bの特定条件」のすみ分け。この二つの条件は競合するのかしないのか？はい、競合しないなんて夢みたいな話は、ほとんどないですね。つまり「機能A」と「機能B」は同時に動作しうるという結論に至り「競合時の動作」が重要な設計ポイントとして挙がります。
システムの基本思想に寄り添ってみる
基本思想に従えば、「機能B」は「機能A」より優先させてやればいいですね。何もめんどうなことはないです。 * 「機能B」のもつステートは、<起動><終了> * 「機能A」のもつステートは「機能B」の動向を意識するので、<起動><中断><再開><終了>。
「機能A」のほうが面倒臭そうにみえますが、<中断><再開>は、そもそもの基本思想に従い従来の設計・実装としては織り込み済みなのでそこに乗っかってしまえばよいでしょう。設計ポイント一つ解決。
の、はずなんですけどな。
超目玉機能「機能A」 VS 目玉機能「機能B」
まさかのランク付け。どうやら「機能A」のほうが期待度が高いらしいです。となると「機能B」が「機能A」の邪魔するような設計はいやらしいですね。とはいえ、基本思想からは大きくはずした設計もいかがなものか。そこで、ユースケースを含め、「機能B」が「機能A」の邪魔をする発生頻度・その際のシステムへのインパクトを考慮した設計が必要になりました。
まぁ、どちらも新機能です、たいていは「実際に動かしてみなきゃわからないよね」という結論にいたります。
明確な要求じゃないし、割り切りますか
「ひとまず、基本思想重視(あるいは期待度重視)の設計で行きましょう。」と設計段階で割り切らないことは重要ですね。最終的にソフトはどちらかに割り切った動作になりますが、不明確な要素があるので、「機能B」の設計は基本思想重視と期待度重視の「動作切り替え」が可能なものをひねり出しましょう。
試験工程で様々なテストが始まればあるべき姿がきっと見えてくるでしょう。
何か掘り起こせた？
- 「他の機能の動作を考慮して、機能同士の交差点があれば交通整理をする」
- 「そも、あるべき姿が不明瞭な場合は、複数動作に対し対応可能な柔軟な設計にする(どうとでも解釈できる、という意味ではない)」
といったところかな。当たり前の話なんですけどね。単純な機能設計が続くと、思想から飛ぶことがあるんですよ。
おしまい
「費用対効果」という伝家の宝刀が睨みをきかせてる世界です。一刀両断にされることもあります。それでも、ズバッと断ち切られたとしても、確固たる思想は持ち続けたいですね。
