Embedded World 2021への道：第4回

編集部注：来たるEmbedded World 2021まで続く5回連載シリーズの最初のブログ（第1回）では、Embedded Worldの概要が示されました。第2回では、ランドールがCプログラミング言語の知識を整理してくれました。第3回では、オブジェクト指向プログラミングの活用によって複雑さをどのように軽減できるかに焦点を当てました。この第4回では、優れた設計の基本的尺度が、要件の変更に応じて、構成ブロックを再実装することなく再構成できる能力であることを説明します。　最後のブログ（第5回）では、Embedded World 2021におけるランドールの基調講演に先立って、オペレーティングシステムが必要とする容量の継続的な拡大について議論し、システム分割についても言及します。

これまで、ソフトウェアが現在のオブジェクト指向に進化するまでの経緯を説明してきました。また、オブジェクト指向がエレクトロニクスとどのように類似しているかも説明しました。 オブジェクト指向で考えることにより、実世界の物（すなわちオブジェクト）の代用モデルを作成することができます。オブジェクト指向プログラミング（OOP）の属性やそのようなモデルの品質評価方法についても話しましたが、それらのモデルを構築する方法についてはまだ話していません。これは、システムを便利なモジュールや構成ブロックへと分割する方法と関係があります。これは1970年代前半に論じられた設計方法論の分野ですが、その教訓の一部が現在再び注目されています。

システムを分割するための最も一般的な方法は、機能ごとの分割です。これには、システムで必要とされるすべての機能を構成ブロックとして項目化し、開発者を割り当ててそれらのブロックを実装することが含まれます。これはシステムを設計する最善の方法ではないことが分かりました。この方法には柔軟性がなく、開発者に余分な手間をかけさせる多くの落とし穴があります。機能分割によって設計されたシステムは機能しますが、さらに優れた方法があります。この別の方法は、始めるのがより難しく、理解しにくいのが事実です。最初に多くの時間がかかりますが、その後は開発がより円滑に進み、変化に対してより簡単に対応できるシステムとなります。

デイビッド・L・パーナス、出典：Wikipedia（https://en.wikipedia.org/wiki/David_Parnas）

カーネギーメロン大学のデイビッド・パーナス氏は、1971年にシステム設計とモジュール性についていくつかの論文を書きました。これらの論文は、私がこれまでのブログで言及してきた結合や凝集という概念を確立するのに役立ちました。これらの論文の1つは、1971年2月に書かれた「設計方法論における情報流通の側面」と題するものです。これは短い論文ですが、設計方法論とは何かがしっかりと説明されています。彼は、「設計における進歩は、システム構造の一部の可能性を排除する決定により特徴付けられる」と書いています。つまり、可能性を排除することで、それに続く決定の理由が確立されると述べているのです。そして、彼は自らの主張を裏付ける例を示しています。これらの方法論は、それぞれ解決策へと収束していきます。

彼は以下3つのアプローチを特定しました。

1.「優れた」外的考慮事項を取得すること

2.プロジェクトの開始と終了の間の時間間隔を短縮すること

3.簡単に変更可能なシステムを取得すること

アプローチ1は、「トップダウン」アプローチと関連しています。アプローチ2は、モジュール化に関して下される選択につながります。これには、必ずしも製品の最終的な使いやすさへの影響が十分に考慮されるわけではありませんが、開発者による開発が加速化されます。アプローチ3では、変化する可能性が最も低い要素を特定し、最も一般的な情報が最初に使用されるようにします。

彼は、トップダウンアプローチは後で変更するのが困難なシステムにつながるものであると論じています。これは単に、決定基準は変化に影響する要因よりも外的要素を好むためです。 彼は、これらのアプローチで下される決定の順序に一貫性がないため、それらすべてを同時に満たすことは不可能であると述べて、論文のこのセクションを締めくくっています。 この見解は次に紹介する彼の論文でも取り上げられていますが、まずこの最初の論文について締めくくりたいと思います。

私は、優れたプログラマに関する彼の説明が興味深いと思います。彼は、「優れたプログラマは自分に与えられた使用可能な情報を活用するものだ」と述べています。そして、優れたプログラマは賢く行動し、文書化されていない情報を使用すると続けています。これを実行することは、あるブロックの変化によって他のブロックでも変化が必要になることを意味しています。これは、前回の投稿で言及したコナーセンス（connascence）の考え方であり、アプローチ3とは一貫性がありません。この最初の論文の結論は、情報隠蔽が好ましいということです。これは、パーナス氏によると、システム設計者は「関係者以外極秘」で設計情報を共有する必要があるという意味です。

次に、パーナス氏は1971年8月に後続の論文「システムのモジュール分割で使用される基準について」を書きました。この論文の評判はかなり悪かったものの、今は再評価されつつあります。彼が変化の可能性に基づくシステムの設計（すなわち前回の論文のアプローチ3）を主張したのは、この論文でした。

彼の目的は、開発の合計時間を短縮しつつ、システムの柔軟性と包含性を改善することであり、例を使って成功を示しました。情報隠蔽に基づいてコードをモジュール化することにより、変更管理に基づいてシステムをモジュール化できます。変更点はより少ないモジュールへ分離されます。これは、要件の変更時に、システムを変更および再構成することがより簡単になることを意味します。機能的な分割または変化の分割のどちらが使用されるかに関わらずシステムは機能しますが、情報を隠蔽したまま高い凝集度を確保することで、システムはより柔軟かつ包括的になり、より迅速に開発できます。

特定の構造のよく知られたアイテムがメモリに保存されている場合を考えてみましょう。システムが機能的に分割される場合は、一部またはすべてのモジュールがその上で動作します。構造が変更されると、それにアクセスするモジュールもすべて変更する必要があります。ただし、その構造がアクセスの提供を担当するモジュールによって管理されている場合は、構造にアクセスする必要のあるすべてのモジュールを変更せずに、構造を変化させることができます。ポイントは、この方法論では変化する可能性の高いものを設計者が初めから特定することです。各方法論は同じ機能を生み出しますが、モジュール性が異なります。パーナス氏は、変化に基づくモジュール性は機能に基づくモジュール性よりも設計上の決定をより明確にするため、システムがもっと容易に理解できるようになると信じています。

情報隠蔽に基づくモジュール化には危険がないわけではありません。パーナス氏は、この方法で設計されたシステムは非効率的になる可能性があると指摘していますが、システムの成長に伴い、情報を隠蔽することがますます重要になると論じています。来月の最後の投稿では、危険について説明します。

最も根本的なこととして、機能の再使用を促進するために、その機能へのインターフェースが開示する情報を最小限に抑える必要があります。アインシュタインが述べたように、「ものごとはできるかぎりシンプルにすべきですが、シンプルすぎてもいけません。」私たちの場合は、「ものごと」を「インターフェース」に置き換える必要があります。このタスクは、組み込み技術者に好適です。組み込み技術者は多くの技術に熟練しており、未熟練者と比較して、設計のどのレベルでも作業を行う能力があります。最大数のユーザー（すなわち顧客）によって使用されるものである場合、その技術者の設計はできるだけシンプルに使用できる必要があります。

出典：https://rightingsoftware.org/

前述したように、パーナス氏の論文は再び評価されるようになっています。さらに詳細を知りたい方には、パーナス氏の論文とジュヴァル・ローウィー著の「Righting Software」と題する本を読むようにお勧めします。

ローウィー氏は、潜在的変化の不安定さを考慮して分割によりシステムを設計し、構成ブロック内にそれらの潜在的変化をカプセル化するというパーナス氏のアプローチを支持しています。システムに必要な動作は、それらの構成ブロック間のインタラクションとして実装されます。成功を収める設計は、すべてのユースケースを満たす構成ブロックの最小セットを備えています。これを言うのは簡単です。

ローウィー氏は、コアのユースケースを知ることにより、このセットを作成するように勧めています。彼は、これらのセットはあまり多くなく、1～3個程度であると付け加えています。その結果として生じるコンポーネントは、一般的に12個未満です。12個の要素の組成やインタラクションの数は膨大です。私は、楽器の12の音階で作曲できる曲の多様性を思い出します。音階の配列やタイミングがあるため、彼の意見は正しいと思います。

彼は続けて、20万年前の人間が現代の私たちと異なるユースケースを持っていたわけではないと述べています。そのユースケースとは生き残ることであり、狩猟や収集によってこれを可能にしたアーキテクチャは、現代のソフトウェア技術者が生計を立てることを可能にするアーキテクチャと同じです（すなわち、同じコンポーネントを使用しています）。彼は、象とネズミのアーキテクチャは同じであり、異なるのは詳細な設計であると論じています。これは、説得力のある意見です。

したがって、優れた設計の基本的尺度とは、要件の変更に応じて、構成ブロックを再実装することなく再構成できる能力です。成功する分割は、過去、未来、既知、未知というすべての要件を満たします。これは重みのある内容であり、研究に値します。

最後の投稿では、前述のとおり、開発した機能をより多くの人々が使用できるようにしたことで生じた問題について説明し、それがより広範な市場のために費やしたコストであることを論じる予定です。