1. ソフトウェアアーキテクトとは
  2. トレードオフについて
  3. モジュール性について
  4. モジュール性の評価
  5. # 機能的凝集度
  6. # シーケンシャル凝集度
  7. # コミュニケーションの結束
  8. # 手続き上の結束
  9. # 時間的凝集度
  10. # 論理的凝集度
  11. # 偶然の結束
## ソフトウェアアーキテクトとは
開発者の初期のキャリアは、経験と専門知識を構築するために、ピラミッドの上部を拡張することに焦点を当てています。 しかし、アーキテクトにとって**幅は深さよりも重要**です。 アーキテクトは機能を技術的な制約に一致させる決定を下す必要があるため、さまざまなソリューションを幅広く理解することが重要です。 したがって、アーキテクトにとって賢明な行動は、**苦労して得た専門知識を犠牲にし、その時間を使用してポートフォリオを拡大することです。**
## トレードオフについて
マーク(著者の1人)を引用すると > 「アーキテクトはあなたがグーグル検索できないものです。」 **アーキテクチャのすべてはトレードオフです。** そのため、宇宙のすべてのアーキテクチャの質問に対する有名な答えは「場合による」です。 ニール(あなたの作者のもう一人)を引用するには: > アーキテクチャには正しい答えも間違った答えもありません。トレードオフだけです。 Clojureプログラミング言語の作成者であるRichHickeyを引用すると、次のようになります。 > プログラマーは、すべての利点と何もないことのトレードオフを知っています。アーキテクトは両方を理解する必要があります。
## モジュール性について
プログラミング言語などではしばしばモジュールを使用、作成します。 これは、オブジェクト指向言語のクラスのグループ、または構造化言語または関数型言語の関数の場合があります。 モジュールの評価の一つに**凝集性** があります。 これは、モジュールの各部分が同じモジュール内にどの程度含まれるべきかを示します。 言い換えれば、それはパーツが互いにどの程度関連しているかの尺度です。 理想的には、まとまりのあるモジュールは、すべてのパーツを一緒にパッケージ化する必要があるモジュールです。これは、パーツを細かく分割するには、モジュール間の呼び出しを介してパーツを結合し、有用な結果を得る必要があるためです。 モジュールの評価
## モジュール性の評価
### 機能的凝集度
モジュールのすべての部分は他の部分に関連しており、モジュールには機能に不可欠なすべてのものが含まれています。
### シーケンシャル凝集度
2つのモジュールが相互作用し、一方が他方の入力となるデータを出力します。
### コミュニケーションの結束
2つのモジュールが通信チェーンを形成し、それぞれが情報を操作したり、何らかの出力に貢献したりします。たとえば、データベースにレコードを追加し、その情報に基づいて電子メールを生成します。
### 手続き上の結束
2つのモジュールは、特定の順序でコードを実行する必要があります。
### 時間的凝集度
モジュールは、タイミングの依存関係に基づいて関連付けられています。たとえば、多くのシステムには、システムの起動時に初期化する必要がある、一見無関係に見えるもののリストがあります。これらのさまざまなタスクは**時間的にまとまり**があります。
### 論理的凝集度
モジュール内のデータは論理的に関連していますが、機能的には関連していません。 たとえば、テキスト、シリアル化されたオブジェクト、またはストリームから情報を変換するモジュールについて考えてみます。 操作は関連していますが、機能はまったく異なります。このタイプの凝集度の一般的な例は、事実上すべてのJavaプロジェクトにStringUtilsパッケージの形式で存在します。これは、Stringを操作するが、それ以外は無関係な静的メソッドのグループです。
### 偶然の結束
モジュール内の要素は、同じソースファイル内にある以外は関連していません。これは、最も否定的な形の凝集度を表しています。