アーキテクチャー

アーキテクチャの品質観点

①更新性

設計は変更が簡単であることが好ましい

変更によって受ける影響の違い

直接的
→変更に合わせて責任範囲が変わる

・直接的影響を受けるソフトウェアユニットを最少にする
→変更が見込まれるユニットをまとめる

間接的
→責任範囲が変わらないが、実装を見直す必要がある

• 間接的影響を受けるソフトウェアユニットを最少にする
→依存性を最少化する

②性能

処理スピードや容量などシステムの性能属性を評価する

評価対象

応答時間

1件の要求への応答にかかる時間

スループット

ある単位時間にいくつの要求に応答できる数

負荷

応答時間やスループットを低下させずに対応できる負荷(e.g.ユーザーの数)

③セキュリティー

悪いアーキテクチャーだとセキュリティが悪くなり、あとでセキュリティをあげようと思ってもなかなかあげれない

耐性:攻撃を阻止する能力

・セキュリティー上の対策をすべて設計に含める
• 悪用できる弱点を最少にする

回復力:攻撃から素早く簡単に回復する能力

• 機能を断片化して攻撃の広がりを阻止する
• 機能を素早く回復できる考慮

④信頼性

要求された機能を、想定される条件下で、正確に果たすこと

信頼性を失う物

誤り

人のエラーで起きる(実装ミス、アーキテクチャー設計ミス、バグ検出で見つけられなかった)

障害

要求された機能から外れること

誤り検知

受動的誤り検知

実行時に誤りが起きるのを監視する

能動的誤り検知

定期的に過りの兆候を探したり予期する

 

障害回復

トランザクション取り消し

• 途中で障害が起きても安全に取り消せる単位で処理をまとめて(トランザクション)管理する

ロールバック

• 現在の状態をチェックポイントとして保存し、その後にシステムで問題が起きたら、そのポイントまでシステムの状態を戻す(ロールバック)

バックアップ

• 障害のあるユニットをシステムが自動的にバックアップと置き換える

制限付きサービス

• 障害発生前の状態に戻り、障害に影響されない範囲のサービスを提供する

クレジットカードが使えなくても現金支払いはできるようにアーキテクチャーを設計する

修正・継続

• 問題を検知し、症状を治して継続する

報告

• 障害発生前の状態に戻り、障害が起きたことを例外処理ユニットに報告する

⑤堅牢性

不正な入力(悪意がないものを含む)や予期しない条件の中でも正確に動作する

環境や他のユニットに問題が発生しても、正確に動作を続ける

他のユニット障害が起きていることを想定する

回復手段

– トランザクションの中止
– チェックポイントへのロールバック – バックアックの起動
– 制限付きサービスの提供
– 自己治癒
– 例外の発生を報告

⑥ユーザービリティー

ユーザーによるシステム操作がどれだけ簡単かを表す

–  ユーザインタフェースは、他の機能等とは分離して、 独立したソフトウェアユニットに割り当てるべき

–  ユーザが起点となるコマンドの中には、アーキテク チャーの配慮が必要なものもある:例)undo

–  システムが起点となる活動の中には、環境のモデル を必要とするものがある:例)時間指定の処理

⑦ビジネス価値

システムが発揮しなければならないビジネス上の特性
開発コストの最小化、開発工期の短縮

開発vs購入

– 開発工期、費用の節約
– 信頼性の確保
– 既存コンポーネントを利用した場合の制約

初期開発費用vs管理コスト

– 更新性の高いシステムにして費用を削減
– 複雑なシステムは納期が遅れる:競合他社に顧客を奪われる

最新技術vs枯れた(安定した)技術

新しい技術はコスト高い&納期が遅れる
新しい技術を学ぶor新しい人材を雇う
新しい技術を獲得することで会社などに知見がたまる

ソフトウェア開発おすすめ本