前回に引き続き、設計技法の適用ミス、です。今回は、構造に焦点を当ててみます。

よく見かけるのは、Ｃ言語でのスパゲティプログラムとＣ++言語での中央集権プログラムです。

スパゲティプログラムは、関数の呼び出し構造が、ファイル単位やタスク単位で循環している構造です。Ｃ言語は、手続き型言語なので、手続きを関数として実装し、関数の呼び出し構造で「動く」プログラムは出来上がります。但し、関数の呼び出しの規則、すなわち、関数の上下関係、と、ファイル単位の関数の括り方がちぐはぐだと、スパゲティプログラムになってしまいます。特に、タスク単位でファイルを形成している場合に、スパゲティになりやすい傾向があります。ファイル単位の静的な構造設計と、タスク単位の動的な構造設計を切り分けることが一つの解となります。

中央集権プログラムは、ひとつの大きなクラスを取り囲むように、小さなクラスが関係している構造です。クラスの責務分担ができていないため、ひとつのクラスに責務が集中してしまっています。「凝集度」が低いクラスが存在していることになります。これは、要求仕様の名詞句をクラス候補にして、オブジェクト指向設計した場合によく見かけます。組込みシステムは、要求仕様に明示的に出現する用語（口座など）だけではなく、モードや状態、そして、制御シーケンス、という概念を見つけて、クラスにすることが大切です。ひとつのクラスに責務が集中するのではなく、責務分担して、連携して動くクラス群となります。

中央集権プログラムには、構造的な問題も含んでいます。クラスの依存関係、Ｃ言語の場合は実装ファイル(.cファイル)からヘッダファイル（.hファイル）の依存関係（#include “xxx.h”）、が循環している場合です。これは、メソッドの呼び出し関係だけでなく、ヘッダファイルの依存関係で破線が縦横無尽に伸びている設計図となります。スパゲティプログラムに加えて、破線が広がっていて、まるでクモの巣にクラスが引っ掛かっている様な図になるので「クモの巣モデル」と呼んでいます。バグ（虫）も絡み合ってしまいます。

構造化設計とは、単一目的の関数やクラスでモジュール化して、そのモジュールを利用関係で階層化する。そして、全体の配置を意識することで、設計意図を伝えることです。

すなわち、

アーキテクチャ設計＝モジュール＋利用関係＋配置
アーキテクチャ設計＝箱＋線＋意図

という図式になります。

次回は、動的構造の典型的な課題と設計原則を紹介します。