クリーンアーキテクチャ 達人に学ぶソフトウェアの構造と設計 29,30章 kazuki ijima

29,30章 クリーン組込みアーキテクチャ データベースは詳細

29章 クリーン組込みアーキテクチャ

ソフトウェアは消耗しないが、ファームウェアやハードウェアは時代遅れになる。 その結果、ソフトウェアの変更が必要になる。 ソフトウェアは消耗しないが、管理できていないファームウェアやハードウェアの依存関 係により、ソフトウェアが内部から破壊される可能性がある。

● ファームウェアは、ハードウェアの変化に対して、どれだけ依存しているかで変化し にくさが決まる ● 依存の強いコードを書く = ファームウェアを書いているようなもの

適性テスト ● ソフトウェアを構築する活動 ○ 動作させる ○ 正しくする(リファクタ、変更しやすく、理解しやすく ) ○ パフォーマンスを高速化する ● 適性テスト ○ アプリを動作させること ○ アプリを動作させることだけに関心を持つプログラマは、 プロダクトに不利益を与えている Apptitude Aptitude

ターゲットハードウェアのボトルネック ● HWは、SWやFWと同時に開発されることが多い ○ 開発中はHWに欠陥があることが多い ○ SWの開発は通常よりも遅くなる

ターゲットハードウェアのボトルネック ● クリーン組込みアーキテクチャ = テスト可能な組込みアーキテクチャ ● レイヤー ○ 図29-1 ■ HWは変化していく ○ 全てのコードからHWの知識の汚染を取り除くものが存在しない ○ SWとFWを混ぜるのはアンチパターン ● ハードウェアは詳細 ○ 図29-3 ○ SW - FWの境界は、HW - コードの境界ほど明確ではない ○ HAL(Hardware Abstraction Layer)

ハードウェアの詳細はHALのユーザに明らかにしない ● クリーン組込みアーキテクチャのSWは、 ターゲットHWをオフにしたテストが可能 ● プロセッサは詳細 ○ 全てのSWはプロセッサに依存しないようにすべき。 FWにはそれができない ○ 例 ● OSは詳細 ○ 寿命を延ばすために OSの依存関係から身を守る ○ 図29-5 ○ OSAL(OS抽象化レイヤー)

インターフェイスに対するプログラミングと代替可能性 ● 主なレイヤーにHALやOSALを追加するだけでなく、これまでの原則を適用するべ き ● このタイミングで説明する内容??

DRYな条件付きコンパイル命令 ● 代用可能性 ○ 組込みのC/C++のプログラムが複数のターゲットや OSを扱う方法 ● HALを使うといい

30章 データベースは詳細

● データベースはエンティティではなく、詳細 ○ データベースはデータモデルではない ■ データベースはソフトウェアに過ぎない ■ データアクセス機能を持つ道具に過ぎない

リレーショナルデータベース ● 普及した ○ 素晴らしいもの ● ただし、アーキテクチャの円の外側 ○ 単なるテクノロジーの一つに過ぎない ○ あくまで詳細

なぜデータベースシステムが普及しているのか? ● 素晴らしい点 ○ ディスクの進化 ■ 小ささ ■ 容量 ○ 欠点である、ディスクの遅さを軽減する方法がある ■ ファイルシステム ■ リレーショナルデータベース

もしもディスクがなかったら? ● ディスクはRAMに取って代わられつつある ○ ? ● ディスクが絶滅した場合 ○ ? ○ 次の節に繋がる

詳細 ● データベースは、ディスクとRAM間でデータを移動しているに過ぎない

だけど、パフォーマンスはどうなの? ● 気になるけど、下位レベルの関心ごと

小話