システム設計で使う表現と設計原則
要点と定義
システム設計では、要件をハードウェア、ソフトウェア、サービス、手作業などに割り振り、構成や処理方式を決める。ソフトウェア設計では、要件を基にソフトウェアの構造や要素を設計し、要素をユニットに分けて機能と相互の処理・関係を明確にする。設計の表現や手法は、整理する対象に応じて使い分ける。
CRUDマトリクスは、機能とデータ上のエンティティの対応を整理し、機能がエンティティを生成、参照、更新、削除する関係を示す。決定表は、条件の組合せとそれぞれに対応する動作を表形式で整理する。DFDは、機能やプロセスと入出力データの流れを表す。E-R図は、実体、関連、属性によってデータと実体間の関係をモデル化する。
モジュール結合度は、モジュール間の依存の強さを表す尺度であり、低いほど独立性が高い。必要なデータ項目だけを引数で受け渡すデータ結合は、共有領域やデータ構造全体への依存を避ける。オブジェクト指向設計では、サブクラスがスーパークラスから操作を継承し、その操作を再定義することができる。
適用条件と例
機能とデータの対応を確認するときは、CRUDマトリクスで各機能による生成・参照・更新・削除を整理する。条件の組合せに応じた動作を整理する場合は決定表を用い、複数条件が同時に成立するなら、その条件ごとの動作を合わせて扱う。形状や線種など独立して変化する種類を拡張する設計では、別々の継承階層に分けて関連付ける。モジュール間の受渡しでは必要なデータ項目を引数で渡すと、共有データや制御情報への依存を抑えられる。業務機能やそれを支えるIT機能をサービスとして組み合わせる構成は、システムのアーキテクチャを検討する際の選択肢となる。
設計時に機能とエンティティの対応を整理する表現として、CRUDマトリクスは各機能がエンティティに対して行う生成、参照、更新、削除を対応付ける。条件と動作の組合せを整理する決定表や、データの流れを示すDFDとは用途が異なる。
拡張しやすくするため、独立して変化する要素は別々の継承階層に分け、関連によって組み合わせられる。形状の種類と線種を独立に追加できる構造にすれば、それらの組合せごとにクラスを増やす必要を抑えられる。
システムの信頼性を検討する際、FTAは障害を頂上事象として、その中間原因や基本原因へ段階的に展開し、原因間の論理関係をゲートで示す樹形図を用いる。これは設計上のリスクや信頼性を分析する適用例である。
モジュール結合度が低いほどモジュールの独立性は高い。必要なデータ項目だけを引数として渡すデータ結合は、共有領域、構造体全体、外部形式などへの依存を避けるため、示された結合方式の中で依存が最も小さい。
SOAは、業務プロセスの機能やそれを支援するIT機能をサービスとして提供し、組み合わせてシステムを構成するアーキテクチャである。システム処理方式や構成を検討する際の選択肢として位置付けられる。
この節の続き
- 誤りやすい点
ここまでが冒頭部分です。ログインすると、無料でも1日2節まで全文をお読みいただけます。
アプリでこの節を読む