達人に学ぶソフトウェアの構造と設計 29,30章

Transcript

1. クリーンアーキテクチャ 達人に学ぶソフトウェアの構造と設計 29,30章 kazuki ijima
2. 29,30章 クリーン組込みアーキテクチャ データベースは詳細
3. 29章 クリーン組込みアーキテクチャ
4. ソフトウェアは消耗しないが、ファームウェアやハードウェアは時代遅れになる。 その結果、ソフトウェアの変更が必要になる。 ソフトウェアは消耗しないが、管理できていないファームウェアやハードウェアの依存関 係により、ソフトウェアが内部から破壊される可能性がある。
5. • ファームウェアは、ハードウェアの変化に対して、どれだけ依存しているかで変化し にくさが決まる • 依存の強いコードを書く = ファームウェアを書いているようなもの
6. 適性テスト • ソフトウェアを構築する活動 ◦ 動作させる ◦ 正しくする(リファクタ、変更しやすく、理解しやすく ) ◦ パフォーマンスを高速化する • 適性テスト ◦ アプリを動作させること ◦ アプリを動作させることだけに関心を持つプログラマは、 プロダクトに不利益を与えている Apptitude Aptitude
7. ターゲットハードウェアのボトルネック • HWは、SWやFWと同時に開発されることが多い ◦ 開発中はHWに欠陥があることが多い ◦ SWの開発は通常よりも遅くなる
8. ターゲットハードウェアのボトルネック • クリーン組込みアーキテクチャ = テスト可能な組込みアーキテクチャ • レイヤー ◦ 図29-1 ▪ HWは変化していく ◦ 全てのコードからHWの知識の汚染を取り除くものが存在しない ◦ SWとFWを混ぜるのはアンチパターン • ハードウェアは詳細 ◦ 図29-3 ◦ SW - FWの境界は、HW - コードの境界ほど明確ではない ◦ HAL(Hardware Abstraction Layer)
9. ハードウェアの詳細はHALのユーザに明らかにしない • クリーン組込みアーキテクチャのSWは、 ターゲットHWをオフにしたテストが可能 • プロセッサは詳細 ◦ 全てのSWはプロセッサに依存しないようにすべき。 FWにはそれができない ◦ 例 • OSは詳細 ◦ 寿命を延ばすために OSの依存関係から身を守る ◦ 図29-5 ◦ OSAL(OS抽象化レイヤー)
10. インターフェイスに対するプログラミングと代替可能性 • 主なレイヤーにHALやOSALを追加するだけでなく、これまでの原則を適用するべ き • このタイミングで説明する内容??
11. DRYな条件付きコンパイル命令 • 代用可能性 ◦ 組込みのC/C++のプログラムが複数のターゲットや OSを扱う方法 • HALを使うといい
12. 30章 データベースは詳細
13. • データベースはエンティティではなく、詳細 ◦ データベースはデータモデルではない ▪ データベースはソフトウェアに過ぎない ▪ データアクセス機能を持つ道具に過ぎない
14. リレーショナルデータベース • 普及した ◦ 素晴らしいもの • ただし、アーキテクチャの円の外側 ◦ 単なるテクノロジーの一つに過ぎない ◦ あくまで詳細
15. なぜデータベースシステムが普及しているのか? • 素晴らしい点 ◦ ディスクの進化 ▪ 小ささ ▪ 容量 ◦ 欠点である、ディスクの遅さを軽減する方法がある ▪ ファイルシステム ▪ リレーショナルデータベース
16. もしもディスクがなかったら? • ディスクはRAMに取って代わられつつある ◦ ? • ディスクが絶滅した場合 ◦ ? ◦ 次の節に繋がる
17. 詳細 • データベースは、ディスクとRAM間でデータを移動しているに過ぎない
18. だけど、パフォーマンスはどうなの? • 気になるけど、下位レベルの関心ごと
19. 小話