Embedded World 2021への道:第3回
編集部注:来たるEmbedded World 2021まで続く5回連載ブログシリーズの第1回では、Embedded Worldの概要を紹介しました。第2回では、ランドールが忘れてしまったC言語に磨きをかける過程を紹介しました。この第3回では、オブジェクト指向プログラミングの考え方を応用することで複雑さをどのように減らせるかに焦点を当てます。第4回では、優れた設計の基本的尺度とは、構成ブロックを再実装することなく、要件の変化に応じて再構成できる能力であることを説きます。最終回となる第5回では、Embedded World 2021でのランドールの基調講演に先立ち、オペレーティングシステムに必要なスペースの拡大傾向に疑問を投げかけ、システム分割について触れます。
先月に続いて複雑さに焦点を当てる理由は、この業界がそれを軽減する必要があると考えているからです。ここで言う複雑さとは、電気的なデバイスを使用するのに必要な複雑さのことです(なお、私が電気的と言う場合、主に電子的なものを指しています)。デバイス内の複雑さは今後も増していくと思われます。この複雑さをどのように整理するかが、次回のテーマとなります。
第1回で述べたように、電気工学(EE)分野の人数は他の国学分野の後塵を拝しています。にもかかわらず、今より多くの電気デバイスが将来導入されると私は確信しています。また、これらのデバイスは、現在よりも幅広い用途に対応できると考えています。その証拠として、「メイカームーブメント」を挙げることができます。
電気デバイスには大きな関心が向けられており、製品の種類には限りがないように思われます。電気工学をこれまで学んだことのない人々の間で、関心が高まっているのです。2020年の第46週の時点で、maker.io、MikroE、Adafruit、Seeed、SparkFun、その他(下の図1を参照)などのウェブサイトは、総計で毎月数百万人ものユニークビジター(重複なしの一意のビジター)を引き付けています。これは、エレクトロニクスに対する関心の高さを示しています。
図1:エレクトロニクスに関心を持つ人々向けのウェブサイトの月間ユニークビジター数
実際、電気デバイス市場は、電気工学の専門家が単独で対応できるよりも大きな市場があると考えています。電気工学を専攻した技師たちは最高レベルの複雑さに対処するための訓練を受けています(少なくともアプローチ方法は知っている)が、私たちにとってのチャンスとは、あまり訓練を受けていない人々が電気デバイスを開発できるようにすることだと思います。つまり、電気工学関係者が電子デバイスやサブシステムをより簡単に使えるようにすることができれば、市場をさらに拡大できると考えています。
前回の投稿は、オブジェクト指向プログラミング(OOP)に触れたところで終わりました。より多くの概念を習得する必要があるという点で、OOPは複雑さを増大させると論じられることがあります。そのような概念については後ほど扱いますが、機能を再利用するための複雑さをOOPがどれほど軽減するかをまだ指摘してきませんでしたので、例を挙げて説明したいと思います。
私の義理の息子は経営学の学位を持っていますが、今は情報技術の大学院プログラムを受講しています。彼は、最近の課題の1つを私に見せてくれました。彼は自分が作成した3Dビデオアクションゲームを実装する必要がありました。
3Dグラフィックスやリアルタイムプログラミングの教育や経験が皆無であるにもかかわらず、彼はうまくやり遂げました。担当教授のアドバイスに従い、Unityプラットフォームを使用して自分のゲームを実装したのです。というわけで、複雑さについての話でしたが、ここから先は再利用関連のトピックについて話そうと思います。
私のお気に入りの本は、M.ペイジ=ジョーンズ著の「Fundamentals of Object Oriented Design in UML(UMLにおけるオブジェクト指向設計の基礎)」です。私がこの本を購入したのはOOPをかなり実践した後でしたが、自分がうまくできていないことを知っていました。腕を上げたいと思ったのです。
出典:Amazon(https://www.amazon.com/gp/product/020169946X/ref=dbs a def rwt bibl vppi i0)
うれしいことに、ペイジ=ジョーンズはOOPの概念を集積回路の例で説明していました。彼は、ブラッド・コックスが1986年に書いた「Object-Oriented Programming: An Evolutionary Approach(オブジェクト指向のプログラミング)」という本からこの発想を得たと述べています。ペイジ=ジョーンズは、「Introduction to Radar Systems(レーダーシステム入門)」を書いたメリル・スコルニクの言葉も引用しています。彼はこの本の中で、「電子工学は、(1)コンポーネント、(2)技術、(3)システムによって分類できる」と指摘しました。さらにスコルニクは、「コンポーネントとは、適切な技術を使用してシステムを生み出すために組み合わされた基本的構成ブロックである」と説明しています。ペイジ=ジョーンズは、「電子」を「ソフトウェア」に、「コンポーネント」を「クラス」に置き換えれば、ソフトウェアシステムに関する有益な視点が得られると主張しました。
さらに彼は、電気システムに含めるべき価値あるコンポーネントの選択が、有益な抽象的概念を特定する電気技師の能力に依存していると説明しました。彼は、最初の集積回路が製造される前に、電子システムが必要とする有用なパターンを技術者が見つけるのに数十年もかかったと主張しています。彼はこの点を利用して、OOP開発者が「健全、堅牢、便利」なクラスを特定する必要があることを学ぶように手助けしています。彼は、プリント回路基板(スコルニクの例の場合)を使ってこれらのコンポーネントを接続しなければ、スコルニクが言及した手法は役立たないと述べています。
そこで私は、集積回路とオブジェクト指向プログラミングは、本質的に同じ概念の異なる実装であることを指摘したいと思います。ソフトウェア工学はハードウェア工学よりもずっと自由なことを認めたいと思います。今では、誰でもソフトウェアを実装することができます。ただし、ソフトウェアを簡単に「結合」できるというのは真実ではありません。
MyHDLの生みの親であるジャン・デカルウェは、ブログ投稿の中で、ハードウェア記述言語(HDL)を使用したデジタル設計においてVerilogやVHDLで算術を記述することは決して簡単ではなく、むしろ複雑で分かりにくいものであると述べています。プログラマブルロジックにしろ、ソフトウェアシステムにしろ、より大きな市場を目指すならソフトウェア設計をもっと上手に行わなくてはなりません
それでは、今月の投稿の締めくくりとして、「優れた」OOP設計に必要な概念に注意を向けたいと思います。最も一般的な概念は、凝集度と結合度です。凝集度とは、ソフトウェアクラス、デジタルモジュール、または集積回路であれ、カプセル化されたユニットのパーツの関連性です。高い凝集度は、システムの理解、テスト、維持が容易になるため、低い凝集度よりも優れています。結合度とは、1つのソフトウェアまたはハードウェア要素が持つ、別の要素に対する接続性または依存性のことです。低い結合度は、他の要素への影響を最小限に抑えながら1つの要素を変更できるため、高い結合度よりも優れています。
ペイジ=ジョーンズは、結合度の危険を説明するために「コナーセンス(connascence)」という新しい言葉を作りました。彼によると、コナーセンスは「一緒に生まれた」を意味するラテン語に由来します。彼は、これは「人生において絡み合った運命」を持つことを意味すると付け加えています。コナーセンスの正式な定義を以下に示します。
2つのソフトウェア(またはハードウェア)要素AおよびBの間のコナーセンスとは、
- Aにいくらかの変更を要求することにより、全体的な正確性を保つためにBも変更(または少なくとも慎重に確認)する必要が生じること、または
- いくらかの変更を要求することにより、全体的な正確性を保つためにAとBの両方を一緒に変更する必要が生じることを意味します。
上記の定義にある括弧内の言葉は私自身によるものであることに注意してください。次に、彼は10種類以上のコナーセンスについて説明しています。コナーセンスの1つの形態は、関数呼び出しにおける引数の順序に応じています。順序が変更されると、依存するすべての関数も変更する必要が生じます。彼が、違いを維持することが重要だとするコントラナセンス(contranascence)の概念も説明していることに注意してください。コントラナセンスは、オブジェクトが同じタイプのインスタンスでありながら、互いに異なっていなければならないOOP継承の場合に特に当てはまります。
凝集度、結合度、およびコナーセンスに加えて、優れたOOP設計とは何かを理解するのに役立つ他の概念もあります。参考までに、下に列挙しておきます。
- カプセル化
- 情報/実装隠蔽
- 状態保持
- オブジェクトID
- メッセージ
- クラス
- 継承
- ポリモーフィズム
- 総称性
これらのトピックは、前述したペイジ=ジョーンズの著書や他のOOP教科書本の中で扱われています。
複雑さのトピックだったため、話が複雑になってしまいました。考慮すべき側面はたくさんありますが、最も根本的な目標は、新しい電気デバイスを作成するために誰でも使用できる便利なブラックボックスを開発することです。ブラックボックスである理由は、内部にあるものを公開する意志または必要性がないからです。それらのインターフェースを可能な限りシンプルにし、内部の複雑さを気にしないで済むようにしたいと考えています。
求めるものの良し悪しを評価する方法についてある程度わかったかもしれませんが、実際にシステムやサブシステムを再利用可能なコンポーネントやモジュールに分割する方法についてはまだ説明していませんでした。それが、次回の投稿トピックになります。
Have questions or comments? Continue the conversation on TechForum, Digi-Key's online community and technical resource.
Visit TechForum