シリーズ記事の目次
システム アーキテクチャ設計の専門スキル · ソフトウェア エンジニアリング (1) [システム アーキテクト]
高度なシステム アーキテクチャ設計スキル · ソフトウェア アーキテクチャの概念、アーキテクチャ スタイル、ABSD、アーキテクチャ再利用、DSSA (1) [システム アーキテクト]
高度なシステム アーキテクチャ設計スキル · システム品質属性およびアーキテクチャ評価 (2) [システムアーキテクト]
システムアーキテクチャ設計の高度なスキル・ソフトウェア信頼性分析および設計 (3) [システムアーキテクト]
システムアーキテクチャ設計専門スキル・ソフトウェアエンジニアリングのシステム解析・設計（２）
6. システム設計
システム設計は、システム分析の延長および拡張です。システム分析フェーズでは「何をするか」という問題を解決し、システム設計フェーズでは「どのように行うか」という問題を解決します。同時に、システム実装の基礎でもあり、システム実装への道を切り開きます。合理的なシステム設計は、システムの品質を確保するだけでなく、開発効率を向上させ、システム導入をスムーズに進めることができます。
システム設計フェーズは、物理設計フェーズとも呼ばれ、情報システム開発プロセスにおいて非常に重要な段階です。そのタスクは、システム仕様で規定されている機能要件に基づいて実際の条件を考慮して、論理モデルを実装するための技術的ソリューションを具体的に設計すること、つまり、新しいシステムの物理モデルを設計して、次のシステムの基礎を築くことです。システム導入の段階。
システム設計の主な内容は、概要設計と詳細設計です。概要設計は、システム全体構造設計とも呼ばれ、システムの機能要件をソフトウェアモジュールに割り当て、各モジュールの機能と呼び出し関係を決定し、システム開発プロセスの重要なステップです。ソフトウェアのはシステム構成図です。システム開発の全体的な作業を多くの基本的な作業と具体的な作業に分解し、それぞれの具体的な作業に対して適切な技術的手段や処理方法を選択する作業を概要設計といいます。詳細設計は、タスクに応じて、ネットワーク設計、コード設計、入出力設計、処理フロー設計、データストレージ設計、ユーザーインターフェース設計、セキュリティ・信頼性設計など、多くの種類に分かれます。
ソフトウェア設計
ソフトウェア設計には、アーキテクチャ設計、インターフェース設計、データ設計、プロセス設計が含まれます。
- 構造設計: ソフトウェアシステムの主要コンポーネント間の関係を定義し、モジュール型のプログラム構造を開発し、モジュール間の制御関係を表現します。
- データ設計: モデルをデータ構造の定義に変換します。高品質のデータ設計により、プログラム構造とモジュール分割が改善され、プロセスの複雑さが軽減されます。
- インターフェース設計（ヒューマン・コンピュータ・インターフェース設計）：ソフトウェア内、ソフトウェアとオペレーティング・システム間、ソフトウェアと人間の間でどのように通信するか。
- プロセス設計: システムの構造コンポーネントをソフトウェアに変換するプロセスの説明。
1. ソフトウェアアーキテクチャの設計
ソフトウェア アーキテクチャ = ソフトウェア アーキテクチャ
アーキテクチャ設計は需要の割り当て、つまり要件を満たす責任をコンポーネントに割り当てることです。
2. ユーザーインターフェース設計・ヒューマンマシンインターフェース設計
上記の 3 つの原則は、有名なユーザー インターフェイス設計の専門家であるテオ マンデル博士によって作成され、人間とコンピューターのインタラクションの「黄金の 3 原則」と呼ばれることがあります。また、ユーザーインターフェースを設計する際には、インターフェースの合理性や独自性、効果的な組み合わせ、美しさや調和性への配慮、ショートカットの適切な提供、リソースの連携などにも配慮する必要があります。
3. 構造設計
構造化設計 (SD)はデータ フロー指向の手法であり、SRS および SA 段階で生成されたデータ フロー図やデータ ディクショナリなどのドキュメントに基づいて、トップダウンで段階的に改良およびモジュール化されます。プロセス。SD手法の基本的な考え方は、ソフトウェアを単一の機能を持つ比較的独立したモジュールから構成される構造に設計することであり、概要設計と詳細設計の2つの段階に分かれています。ソフトウェアシステムの構造を決定し、システム設計を行います モジュール分割は、各モジュールの機能、インターフェース、モジュール間の呼び出し関係などを決定し、各モジュールの実装内容を設計するのが詳細設計の主な仕事です。
概要設計
概要設計は、システムの全体構成設計とも呼ばれ、システムの機能要件をソフトウェアモジュールに割り当て、各モジュールの機能と呼び出し関係を決定する、システム開発プロセスの重要なステップです。モジュールを構成し、ソフトウェアの構造を形成するモジュール構成図、つまりシステム構成図です。
システム構造図 (Structure Chart、SC) は、モジュール構造図とも呼ばれ、ソフトウェア概要設計段階のツールであり、システムの機能実装と、モジュール間の階層構造を含むモジュール間の接続と通信を反映します。つまり、システムの全体的な構造を反映しています。
複雑な問題を解決するときに使用する非常に重要な原則は、問題を複数の小さな問題に分解し、それらを個別に処理することであり、そのプロセスでは、システムの全体的な要件に従ってさまざまなビジネス部門間の関係を調整する必要があります。SDにおける機能分解とは、システムをモジュールに分割することです｡モジュールはシステムを構成する基本単位であり､自由に組み合わせ､分解､変形できることが特徴です｡システム内のあらゆる処理機能を一つのモジュールとみなすことができます｡モジュール。
モジュールの 4 つの要素:
- 入力と出力、モジュールの入力ソースと出力先は両方とも同じ呼び出し元からのものです。つまり、モジュールは呼び出し元から入力を取得し、それを処理して、出力を呼び出し元に返します。
- 処理関数は、入力を出力に変換するためにモジュールによって実行される作業を指します。
- 内部データとは、モジュール自身のみが参照するデータを指します。
- プログラムコードとは、モジュールの機能を実装するために使用されるプログラムを指します。
最初の 2 つの要素はモジュールの外観を反映するモジュールの外部特性であり、最後の 2 つの要素はモジュールの内部特性です。構造化設計ではモジュールの外部特性を主に考慮し、必要な内部特性の理解のみが必要であり、具体的な実装はシステム実装段階で完了します。
SD 方式では、システムは論理的に比較的独立した複数のモジュールで構成されますが、モジュールを分割する際には次の原則に従う必要があります。
モジュールのサイズは適度に保ちます
。呼び出しの深さをできる限り減らし、幅は大きすぎないようにします。ファン
イン/ファンアウト係数は適切で、ファンインが多くなり、ファンアウトが少なくなります。単一入口と出口は1つ
モジュールの範囲はモジュール内にあり、機能は予測可能でなければならない
モジュール独立性の原則（高凝集性、低結合性）
密着型と結合型
4. オブジェクト指向設計
オブジェクト指向設計 OOD は、オブジェクト指向分析 OOA の延長であり、その基本的な考え方には抽象化、カプセル化、スケーラビリティが含まれており、スケーラビリティは主に継承とポリモーフィズムによって実現されます。OODでは、データ構造とそのデータ構造上で定義された演算アルゴリズムがオブジェクト内にカプセル化されます。OOD手法は、現実世界にあるものをオブジェクトの集合から抽象化できるため、より現実世界に近く、より自然なシステム設計手法です。
4.1 クラスの分類
对象问的关系有：组合，聚合，继承等
Use-A依赖关系
IS-A继承关系
IS-PART-OF聚合（组合一种），聚合对应的语义是“is a member of”
設計原則
OOD では、保守可能な再利用は設計原則に基づいています。OOD で一般的に使用される原則には、単一原則、開始および終了原則、リスコフ置換原則、依存関係逆転原則、結合/集約再利用原則、インターフェース分離原則、最小知識原則などが含まれます。これらの設計原則は、まず第一に再利用指向の原則であり、これらの設計原則に従うことで、システムの再利用性を効果的に向上させ、システムの保守性を向上させることができます。
- 単一責任の原則、単一の目的を持つクラスを設計します。
- オープンクローズの原則、拡張にはオープン、変更にはクローズ。つまり、元のコードを変更せずに拡張してみます。
- リスコフ置換原則では、サブクラスは親クラスを置き換えることができます (親クラスはサブクラスで置き換えることができます)。プログラムの動作は変わりません。ソフトウェア エンティティが基本クラス オブジェクトを使用する場合、そのサブクラス オブジェクトにもそれを適用する必要があり、基本クラス オブジェクトとサブクラス オブジェクトの違いは認識できません。
- 依存関係逆転の原則、抽象化は詳細に依存すべきではなく、詳細は特定の実装ではなく抽象化に依存する必要があります。実装ではなくインターフェイスに対してプログラムします。
- 組み合わせ/集約の再利用の原則(組み合わせ/集約の原則としても知られています) は、可能な限り組み合わせ/集約関係を使用し、継承の使用量を減らすことです。
- インターフェイス分離の原則では、単一の全体的なインターフェイスではなく、複数の特殊なインターフェイスが使用されます。
- デメテルの法則としても知られる最小知識の原則は、ソフトウェア エンティティが対話する他のエンティティをできる限り少なくする必要があることを示しています。