【階層構造(ヒエラルキー Hierarchy)】《SW設計》
階層とは、ソフトウェアの単位(モジュール)を分割し、木のような構造につなげることを言い、その構造を階層構造と言います。
階層構造は、Windows等のファイル構造にも使用されていて、その目的は、ソフトウェアを物理的側面と論理的側面からみれるようにすることと情報の隠蔽等です。つまり、階層構造の上に行けば上に行くほどモジュールの意味が論理的になり、下に行けば下に行くほどモジュールの意味が物理的になります。例えば、通信を考えた場合、上から、送受信モジュール、TCP/IPモジュール、デバイス制御モジュールの階層構造になります。この場合、下へ行けばデバイスのレジスタなどを具体的に制御しますが、上に行くとプロトコル(伝送制御手順)も物理的なレジスタ等も意識しなくなり、送信データと受信データしか見えなくなります。
同じような意味で、上に行くと具体的なデータが見えなくなります。これが「情報を隠蔽する」と言います。
具体的に階層構造を作る場合、作成されるモジュールの意味を考えて、論理的なモジュールからより物理的なモジュールへ、モジュール分割し、階層化する方法と既存の物理的なモジュールを組み合わせて、より論理的なモジュールを構成する方法の2つの方法があります。どちらを選ぶかまたは組み合わせて行うかは、具体的な開発案件により選択します。
具体的な方法として、有名なのはUMLのドメイン分割などです。
組込み機器が影響を受ける外来ノイズ(外部のノイズ要因)としては、次のようなものがあります。
組込み機器がこれらのノイズの影響により誤動作を起こさないよう、ハードウェア，ソフトウェア両面のノイズ対策が重要です。
タイマクロックや信号の変化をカウントするレジスタで、アップカウンタとダウンカウンタがある。イベントカウンタは周期の短い信号をCPUに負荷をかけることなくカウントできるため、タイマと併用すれば、ロータリーエンコーダの読み込みなども処理能力の低いコントローラで実現することができる。
使用に際しては、オーバフロー、アンダーフロー(カウントが一周)に注意すること。
プリント基板上にあらかじめ設けられた設定変更のための回路パターン。
カットポイントの導体を削って電気的接続を切る、あるいはソルダーポイントの導体上にはんだを落として短絡することにより、異なる動作条件を基板に与えることができる。
ジャンパ線を用いた応急処置と異なり、多機種対応などのあらかじめ想定される事象に対して基板設計時に対応を考慮し、製造ラインにおいて正規の製造工程として利用される。
コード利用者への記述意図の伝わりやすさを示す、ソースコードの特性。
下記例のような手段をコーディングに用い、記述意図の視覚的・言語的な表記を調整し、可読性を作り込むことができる。
【カバレッジ】《テスト》
Coverageという言葉自体は、「どれ位のモノや 範囲をカバーしているか」という程度を表すことに用います。
身近なものとして無線の例をあげますと、携帯電話や業務用無線において1つの無線基地局がカバーする地理的な範囲のことを「カバレッジエリア」と言います。
ソフトウェア開発の世界でカバレッジというと、ソフトウェアコード(パス)に対して「どの程度テストを実施したか」というテストの消化具合を表すために使用します。ここでミソとなるのは「どの程度」をどう定義するのかということです。ソフトウェアテストを実施する為に、どれ位の網を掛けるかと言い換えることもできるでしょう。このため、もし何の定義もせず「100%のカバレッジにてテストを完了した」と言い切ってしまうと、全てのエラーを排除できた。つまり完璧なテストを実施したという全く夢物語のようなことを意味してしまいます。完璧なテストがどうして「夢物語」なのかは以下のカバレッジの説明から理解してください。
では、よく使われる定義から説明していきましょう。
まずは、C0,C1,C2というのがあります。
カバレッジの定義については、1970年代中盤から使われていたようですが、C0,C1と言い出したのはエド・ミラー:Ed Millerさんで、1976年位のことです。この定義はほぼ時を同じくして、ご本人から我が国のエンジニアに伝えられたそうです。
テストの終了判定に用いるという意味においては、テストの設計度合いを示すものと実行度合いを示すカバレッジに分けて考えられます。
パスカバレッジを用いるC0,C1,C2基準は後者に当たります。
では、どれ位テストを実施すればよいかといえば、C0やC1については、単体テスト/ホワイトボックステストレベルで100% 網羅するべきです。しかしながらカバレッジ測定を人間がするとなると大変な手間がかかることは想像に難くありません。
メジャーなプログラミング言語には大抵 無料/有料のカバレッジ測定ツールがあり ますので、いろいろと試してみると良いでしょう。
統合テストやシステムテストといったプラックボックステストにおいて、C0,C1 100%というのは現実的に不可能です。
理由は簡単で、コードの中身を知らずに全ての命令/分岐を通るようなテスト設計することは出来ないからです。
そこでブラックボックステスト手法では、ドメインテストや境界値分析などといったテクニックを用いてテスト設計することにより、要件に対するカバレッジを確保します。
カバレッジ定義には他にもいろいろとあります。以下はそれらの一部です。
いろいろあると、どの定義を使用すべきか悩むかもしれませんが、大切なのは、何のためにテストを実施するのかを見極めた上で、テスト設計することです。C0,C1カバレッジが100%だったとしても、単にプログラムが異常終了しなかったことを証明したに過ぎません。仕様と合致しているかや、エラー処理がきちんと組み込まれているかまでは検証できないことを理解しておきましょう。
<その他のカバレッジ>
Modified Condition/Decision (MC/DC) Coverage
Data Flow Coverage
Loop Coverage etc.
【カプセル化】《OO》 → 隠蔽
【ガーベジコレクション(Garbage Collection)】
プログラムから動的なメモリの確保や解放を繰り返すと、ヒープ上に小さな未使用領域の断片が多く発生する。この断片をガーベジ(garbage)と言い、ガーベジを集めて大きな未使用領域に再編成することをガーベジコレクションと言う。
明示的に領域解放をする命令の無い言語処理系(Java、C#等)ではプログラマは領域の解放を意識する必要はない。ある領域が使用中か使用済みかの判断は処理系側の責任になる。従って、あるタイミングで、使用済みの領域を探索して収集する（自動）ガーベジコレクション処理が、プログラム設計者の想定外のタイミングで、プログラムの処理を中断して走る。
一方、C、C++といった領域解放命令の有る言語処理系でも、不定長の領域の確保解放を繰り返すと未使用領域の断片が多く発生し、この領域を再編成するために、領域の確保、解放のタイミングでガーベジコレクション処理が走る場合がある。
ガーベジコレクションは非常に重い処理で、厳密にリアルタイム性を求められるプログラムでは、思わぬタイミングで処理を中断させられる危険性がある。この場合、自分で簡単な特定目的のヒープを実装するか、ヒープ相当の軽い流通ライブラリを活用するか、ライブラリ側のガーベジコレクションの実行を明示的に制御する必要がある。
参照：ヒープ、ヒープとガーベジ
【擬似SRAM】《HW》 → RAM
【基板】《HW》 → プリント基板
【記法(Notation)】《SW設計》
ソフトウェアを設計するために用いる各種の表現方法。さらには、図面、図の詳細な表記法を指す場合もある。
アルゴリズムやデータ構造、それらの集合論的な関係を簡潔に示すために多数の記法が提案されている。自然言語ではあいまい性が残り厳密な表現に不足するという事実からソフトウェア開発や研究の用途に特化した形で方法論者、研究者が提案したものである。例えばBNF記法は、データの構造を仕様記述するために古くから利用されている。
図の表現においても内容的に同一の問題を異なった記法で示すことができる。組込みソフト開発でよく利用される状態遷移図には、階層型と単層型があり、単層型にはミーリーの記法とムーアの記法がよく知られている。
現状のソフトウェア工学の状況では、記法とその含意が記法の利用者によって異なることが多い。このために、開発プロジェクトの中で記法の選定とそれぞれの記法の用途、含意を開発メンバーで共通認識しておくことが好ましい。
参照：ド キュメントの書き方
計算機システムの動作速度向上を目的として使用される補助的な記憶装置の総称。
一般にキャッシュとして使用される記憶装置はキャッシュ対象である主記憶装置や入出力装置より高速アクセス可能だが高価である。
主記憶装置や入出力機器が配置された計算機システムのアドレス空間には、よくアクセスされる領域と、まれにしかアクセスされない領域が偏在する特性がある。このため、対象とするアドレス空間の容量よりも小さい容量の記憶装置をキャッシュとして実装し、主記憶装置や入出力装置の情報を一部キャッシュ上に保持することで、動作速度と製品コストのトレードオフを解決することができる。
ただし、応答時間の変動が許されない割込み処理やDMA転送によって情報を移動させる場合、あるいはキャッシュ容量を越える大きさの情報を扱う場合など、キャッシュを使用しないほうが良い場合もある。
キャッシュ上に情報が保持されていない領域へのアクセスが行われた場合、キャッシュミスヒットと呼ばれる現象が起こる。逆に情報が保持されている領域にアクセスしたことによって、高速アクセスできた場合をキャッシュがヒットしたという。ミスヒットが起こった場合、キャッシュ上の情報の置換、キャッシュ対象への情報の書き出しなどが発生する。これら置換や書き出しについては、タイミングや置換対象の選択方法などについて異なる方式が存在し動作速度、コストに影響を与える。全アクセス回数に対するキャッシュヒット回数の割合をキャッシュヒット率と呼び、速度性能の指標として使用される。
また、キャッシュは保持する情報の種類によって、命令(インストラクション)キャッシュ、データキャッシュ、ユニファイドキャッシュに分類される。命令キャッシュはフェッチ時に読み込んだ命令を保持する。データキャッシュは命令に従って書き込み／読み込みを行うデータを保持する。ユニファイドキャッシュは命令とデータを区別せずに両方を保持する。
参照：ダイレクトマッピング／Nウェイセットアソシアティブ／フルアソシアティブ
オブジェクト指向ソフトウェアの構造的な中心概念。
同じデータ構造とデータを操作するメソッドを持つソフトウェア実体の抽象のこと。C言語で構造体とそのアクセス関数群を一つにまとめたものは原始的なクラスと言える。
クラスそのものは、C言語の関数と異なってコンパイルしても実行はできない。クラスに対して生成の指示が出されるとクラスから実体(インスタンス)が生み出されて様々なメソッドが実行可能になる。また、その実体が不要になった時には消滅を行うことができる。
こうした性質は、現実の組込みアプリケーションをソフトウェアに映し出すために都合が良い。その一方で動的なメモリ管理がいるなどの問題も存在する。
グランドの類似語には、アース、接地があり、ともに電気的に大地に接続する事を言います。
目的は複数あり、以下の3つが代表的です。
電子回路では、主に、回路動作の基準電位を作る為と、共通の配線(戻り線)として利用されます。
基準電位としてみた場合、電位差を作る為にグランドを利用します。デジタル回路、アナログ回路のいずれの電気機器でも電位差を元に動作することが多く、この電位差は常にグランドを基準にしています。例えば、通信線のデータはシグナルグランドとの電位差で示されます。
また、グランドはその機器内で常に 0V を保てるように設計されており、実際の環境下でも、個々の機器は、常に 0Vに保たれていると仮定して動作します。
ちなみに、接地する事が出来ない機器、例えば車、航空機に使用する機器でも、その機器内、航空機内での基準電位としてグランドは利用されています。例えば車の外装金属部分を大地に見立てた物などがあり、これはフレームアースあるいはシャシアースとも言います。但し、この場合は、大地と比較し電位差が発生してしまう場合もありえます。
戻り線として見た場合、グランドを戻り線として利用することにより、信号線は閉回路になり、電流が流れ、基準との電位差によって信号が伝えられ、目的の回路が動作します。
この戻り線は、通信を行う複数の機器間でも必要で、戻り線が無い場合では、同じ電位にならず、通信できることを保証できません。
あと、複数の機器間でグランドを同じ電位にする為には、航空機のフレームアースや、大地への接地を正しく行なう必要があります。
もし、正しく行われていない(電位差が発生する)場合は、機器の破壊につながる電流が流れることがあります。これを防止する為に行う接地を保安用の接地と言い、個々の機器内のグランドから大地へと、個々アース線でつなぐ事で実現します。
コンパイラが動作するコンピュータとコンパイラが生成したオブジェクトプログラムが動作するコンピュータとが異なる場合(プロセッサやハードウェア構成が違う場合)、そのコンパイラをクロスコンパイラと言います。この場合、前者のコンピュータをホスト、後者をターゲットと 呼びます。これに対して、ホストとターゲットが同じであるコンパイラをセルフコンパイラと言います。
組込み用コンピュータシステムではプロセッサやOSが低機能であり(OSを使用しないことも多い)、また構成も特定用途に特化されていてディスプレイ・キーボード・外部記憶といったコンパイラを動作させるのに必要な装置がないことが多いため、開発の際にクロスコンパイラが多く使用されます。このようなコンパイル(クロスコンパイル)はPCやワークステーションのような高機能なコンピュータで行います。
セルフコンパイラではメモリ管理や入出力等についてのサポート機能が開発環境で豊富に提供されているためプログラマはそれを利用すればよいのですが、クロスコンパイラではこれらの機能がターゲットシステム毎に異なるため、プログラマ自身が以下のものを用意しなければなりません。
クロスコンパイラは、これらの実装をサポートするために言語仕様を拡張したり、様々なオプション及びツールを提供したりしています。たとえば、C言語のプログラム中で入出力デバイス名を記述できたり、ウィザード形式でスタートアップルーチンのテンプレートを作成することができたりします。
デジタルコンピュータのロジック実行の基本的なタイミング信号のこと。
現代のデジタルコンピュータのほとんどは、設計として同期回路設計の手法が用いられている。これは、クロックの立ち上がり、立下りのエッジに同期して論理動作を実行するという方式である。これに対して非同期方式というデータの変化に対して論理動作を実行する方式もあるが、回路の理解が難しくなる為ほとんど用いられていない。
同期式設計においては、基本的なタイミングを取り出すために周期の安定した矩形波が必要になる。このタイミング信号を通常は、クロックと呼ぶ。
最近の組込みプロセッサでは、クロックをLSIに内蔵するものもあり、回路設計上は、内部クロックを用いるか、外部クロックを用いるかの検討が必要である。また、RTOSやドライバソフト開発では、どのようなクロックでハードウェアが動作するのかを良く理解して動作の精度を理解しておく必要がある。
【クロック周波数】《HW》 → クロック
オブジェクト指向設計においてクラスの性質を別のクラスが引き継ぐこと。
組込み開発では、継承関係の実装が困難なためにあまり利用されていない。今後はJavaやC++などの言語が利用可能になることも予想されているので利用者は急速に膨れ上がる可能性がある。
【結合度(Coupling)】《SW設計》 → モジュール分割
【ケーブル】《HW》
→ ツイストペアケーブル
→ 同軸ケーブル
→ フラットケーブル
【言語／ライブラリ／ソフトウェア部品選択】《SW全般》
執筆募集中！
ごく最近にいたるまで、電磁誘導による無線通信が可能な周波数より高い領域を高周波とよび、ロジック回路の動作周波数は、それより低い領域となるのが常識であった。しかし、今日ではロジックの動作周波数が上がって無線周波数領域で動作するデジタルロジックがごく普通になっている。
組込みソフトウェアの開発で高周波は、空間を飛んで予期しない信号擾乱を引き起こすことがあるために発生源や伝播経路を良く理解することが重要である。特に高い周波数で動作するプロセッサや素子からのノイズは、電磁波ノイズと呼ばれて他の機器のソフト、ハード誤作動を引き起すことがあるので、注意が必要である。組込みソフトウェアのアーキテクチャによっては、このノイズレベルを下げるような改良ができる場合もあるので低ノイズソフトウェア設計は今後の考慮点となる。
【構成管理】《品質》
あるプログラムがどのような構成要素から出来上がっているか、を管理することを、構成管理と言います。構成要素には、モジュール、ライブラリの種類やバージョン(版)やOSの種類、開発ライブラリ、言語などがあります。
構成管理の下位概念として、バージョン管理、変更管理があります。バージョン管理とは、ソースコードなどのバージョン(版)をビルド毎に把握し、管理していくことを言います。また、OSや開発言語、パッチなどのバージョンを管理することも含めることもあります。テストフェーズに移行したり、出荷用のビルドを行なう場合には、バグ解析時のソースコードなどの特定のために、しっかりとバージョン管理がされている必要があります。
変更管理とは、バージョンよりも小さい単位であるソースコードなどの「変更」を緻密に管理していく手法で、変更内容を書いた変更書などを用いて、厳密に変更内容を制御します。変更管理を行なうと、変更内容毎のUNDOが可能になるとともに、変更に関するレビューなどが緻密に行なえるようになりますが、一方、変更件数が多いと工数が膨大になる欠点があります。このため、例えば、コードの机上レビューまではバージョン管理のみで管理し、単体テストフェーズ以降は変更管理に切り替えるなどのフェーズに応じた適用がされることが普通です。
また、構成管理では、「変更」を覚えておくこと、揃えることも重要ですが、それとともに、「何を根拠に」「誰が」変更することやそのバージョンを使うことを「決めたのか」、といったマネージメントすることも重要です。
【構造化プログラミング】《SW全般》
フローチャートを使用してプログラムを開発すると、判定と飛び先が入り組んだ複雑な構造のプログラムができあがることがあります。この入り組んだ状態を称して、スパゲティプログラムと呼ばれました。スパゲティプログラムは単にプログラムが読みにくいと言うよりも、読み難さが原因で保守性を損ないます。
そこで、3つの構造(1)逐次(sequence)：命令を順に実行する、(2)選択(selection,if-then-else)：条件を判定して判定結果により処理を分ける、(3)繰り返し(iteration,do-while)：条件が成り立つまで命令を繰り返す、のみを使ったプログラミング手法が提唱されました。これが、構造化プログラミングです。構造化プログラミングでは上から下へ処理が動いていくため、プログラムが理解しやすく、修正なども行ないやすい利点がありますが、一方、厳密にこの3種類しか使わなかった場合、無意味な状態の判定が増える欠点があります。(GOTO文論争を参照)このため、 「1 entry 1 exit」になるなら、GOTO文の使用は最小限許そうという考えが一般的です。
【構造化設計の図法／記法】《SW全般》
執筆募集中！
【ＧＯＴＯ文(論争)】→ GOTO文(論争)《SW全般》
組込み製品を小型に、薄く、軽く作るために、高密度実装半導体の使用に代表される個々の部品の小型化・高密度化・個数の削減と併せて、部品自体の配置の高密度化が重要です。そのため、部品を配置するプリント基板にも高密度化が要求されています。これにはプリント基板の多層化・配線の狭幅／狭ピッチ化を初めとしたさまざまな技術が使用されています。
ところで多くの能動素子を高密度に実装するということは、熱が多く発生し、かつ、それを逃がすことが難しくなるということでもあります。発熱量は消費電力と、消費電力は電源電圧と直接に関係しますから、消費電力を下げかつ発熱量も下げる目的で低電源電圧で回路を駆動することが高密度実装で一般的に行われています。
携帯電話やデジタルカメラで代表されるハンドヘルド商品は、性能・機能の向上，消費電力の低減を図りながらより小形に、薄く、軽くというニーズに対する要請を満たしていかなければならなくなっています。これらの課題を満たすために、より集積度の高いLSIを部品として使用するという流れに加え、LSIそのものの実装体積と質量をいかに小さく(すなわち面積を小さく厚さを薄く)実装するか、そのような要請・性能を満たしたうえでLSIの消費電力をいかに低減していくか、が重要な課題となってきています。
集積度を上げる手法としてSoC(System On Chip),COC(Chip On Chip),SIP(System In Package)といったものがあります。
実装体積と質量を小さくする手法としてCSP(Chip Scale PackageまたはChip Size Package),BGA(Ball Grid Array)といったものがあります。
消費電力を低減する手法のひとつとしてSOI(Silicon On Insulator)があります。
これらの高密度実装半導体を使用することで組込み製品のよりいっそうの小型化が図られていますが、これらに課題が無いわけではありません。
例えば機構的には携帯機器が受ける外力(ストレス)によりLSIが物理的な損傷を受けやすくなる可能性、電気的にはこれらの高集積・高密度実装デバイスがプリント基板に実装された状態でどのように動作確認・品質評価をするか、といった課題がありますが、これらにさまざまな解が提示・実践されてきています。
測定や理論的な計算結果と真の値あるいは期待値との差を誤差と呼ぶ。
誤差を持つデータを演算に使用すると、結果も誤差を含む。このように誤差の影響が継承されていくことを「誤差が伝播する」という。
センサからのデータをはじめとして、組込みシステムで扱うデータの精度は有限である。これらはAD変換の精度(ビット長、直線性)およびマイコンの数値表現能力に依存する。例えばセンサの精度が悪い場合、マイコンのビット長が十分であっても、つまり演算能力としての精度が十分であっても、そのセンサからの入力を用いる演算は大きな誤差を含んだものとなり、あとから精度を上げることはできない。このようにセンサ入力を代表とする測定には誤差はつきものだが、その誤差がシステムにとって許容できる範囲であるかどうかが重要である。
センサ入力とは別に特に留意すべきことは浮動小数点データを用いる場合である。コンピュータの浮動小数点表現には有効桁数があり、有効桁数の最後の桁付近に誤差を持つ近似値でしかない。このため浮動小数点を用いた計算結果をある値(真の値あるいは期待値)と等しいか否かで判定するコードを書いてはいけない。一般的に
A * B / A は B にならないのである。
こういった、計算で誤差が発生・伝播する場合は、等号比較ではなく比較対象のある値との差が一定の許容範囲に入っているかどうかというコードを書く必要がある。
コーディングとは、プログラミング言語を用いてプログラム(コードとも呼ぶ)を書くことを指す。コーディングをするというのはプログラムを作成するということで、通常は実現すべき対象をよく理解し、具体的な実現のため手順を明解にしたあとに、その手順をプログラミング言語の言語仕様に合わせて詳細に書き下すことになる。コーディングに際しては、コーディング規約と呼ぶプログラムの記述スタイルのためのガイドラインを事前に決めておき、それに従ってプログラムを書くことが多い。
【コーディング規約】《SW全般》
コーディング規約とは、コード(プログラム)の記述スタイルのためのガイドラインとなるものです。コーディング規約に従ったコードを作成することで、次の2つの効果を得ることができます。
コーディング規約では、バグの作り込みにくさをコントロールするための施策を盛り込むこともあります。例えば、命名規則や、リスクの高い言語仕様を避けるためのルールを用意し、それに従いコードを記述することで、バグの混入の防止につながります。
コーディング規約は、対象となる言語(例えば、アセンブラ、C言語、など)により大きく変わります。その理由として、各言語の仕様の違いが効いてくるからです。なお、コーディング規約は、コードを作成する前には準備をしておくことが望まれます。コードを作成してから(あるいは、その途中で)コーディング規約が作られますと、規約にあわせて再度コードを作成し直さなくてはならず、余計な時間をかけることになります。
コードとはいろいろの場面で使用される言葉で、その場面によって、ソースプログラム(ソースコード)、アセンブラプログラム(アセンブリコード)、バイナリコード(機械語)等を指す。つまり、対象となるソフトウェアの何を現在議論しているかで、その「コード」で呼び表しているかが変わると言える。ソースコードレビューと言えば、ソースコードやアセンブリコードを、コードにnop命令を埋めて実行すると言えばバイナリコードを通常指す。
【コード品質】《品質》
執筆募集中！
【コードレビューの種類】《品質》
執筆募集中！
コネクタとは、ケーブル同士、ケーブルと基板、基板同士を接続する際に使われる、メス(Receptacle)・オス(Pin)が対となる接続器です。組込み機器に限らず、一般の電子製品では組立を簡便化するために内部でコネクタがよく使用されますし、ネットワークなど外部との接続にもコネクタが使用されます。
コネクタを使用するとハードウェア組立の際に内部での相互接続部をはんだ付けしなくて良くなるので、組立作業性および保守性が向上します。しかしコネクタは接触による導通が基本ですから、経時変化で導体表面が酸化して接触不良が発生する危険性があるなど、トラブルのもとにもなり得ます(ケーブルとコネクタを接続する加工での不良という、初期不良もあり得ます)。また便利だからといって多用しすぎると逆にコストアップになることもあります。つまりコネクタは電子機器にとって諸刃の剣なのです。
ちなみに導通抵抗の面からはコネクタ電極に銀メッキを使用するのが良いのですが、銀は容易に酸化するため通常は金メッキが多用されます。
コネクタにはさまざまな形状・大きさがあり、それぞれに特性があります。コネクタの多くはペアとなる同士で違う向きに接続できないように形状の工夫がありますが、まれにどちら向きにも接続できるコネクタがあります。また、力と技で無理やり違う規格のコネクタ同士を接続してしまう人もいます。システムテストなどの際にこのようなコネクタの接続誤りをしてしまうと無用のハードウェアトラブルを発生させることになりますから、十分な注意が必要です。
【コヒージョン(Cohesion)】《SW設計》 → モジュール分割
コマンドとは、何らかの機能を実行してもらいたいことを先方に伝えるためのいわば指令である。マイクロソフト社WindowsのDOSコマンドやUNIXのシェル・コマンド等は有名である。これらのコマンドをオペレーション・システムに伝えることで、各種情報の設定や読み出し、ファイル操作等が実現できる。また組込み用途では、他のデバイスと通信して処理を実行する場合に、送受信するデータの形式をコマンドとして取り決めておき、コマンドを通信データとして先方に送り、返答を受け取ることを通して所望の機能を実現することが多い。
【コメント(Comment)】《SW全般》 → コメントの量と質
【コメントの量と質】《SW全般》
プログラムのソースコードの中のコンピュータが命令で利用しない部分をコメントと言います。コメントには補足情報を記述します。英語または日本語の自然語で書いたり、日時、氏名、版、コード表、試験のためのデータといった付加情報を含めることがあります。また、空行やソースコードをツールで加工するための情報を、文法上のコメント行として記述する場合もあります。
プログラムの補足情報として挿入するコメントは、命令語の部分と比べて、価値を低く評価する人がいます。しかし、プログラマにとっては、処理の概要を未来の自分や現在の同僚、部下などに伝え、プログラムの理解を助ける上で重要な意味を持っています。
多くの組織ではコーディング規約の中にコメントに対する標準として記入する内容、含有率を定めています。コメントの含有率が、コメントの量に関する指標の一つとなります。
また、組織によっては、詳細設計ドキュメントを作成せずに、プログラムのソースコードの中に必要なコメントを埋め込むことにより、機械的に設計書を作成することもあります。
コメントをつける場合には、単純に命令語を日本語や英語に置き換えるのではなく、「処理の目的」、「命令を行なう意味」、「命令に伴う状態の変化」、「関数や呼出し先の機能や処理概要」、「注意事項」を端的に表現することが大切です。これらの各項目は、コメントの質を向上させるための指標と考えることができます。
【コーリングコンベンション(Calling Convention)】《ツール》
サブルーチンの呼び出しにおいて、呼び出す側のサブルーチンと呼び出される側のサブルーチンとの間の取り決めとして、両者で共通に使用する引数や戻り値等のデータの受渡し方法や、レジスタの退避方法、スタック領域の使用方法等について定めた規約のことを、コーリングコンベンション(呼び出し規約)と言います。
コーリングコンベンションは、サブルーチン定義及びその呼び出しに対するコンパイラのコード生成の仕様であり、コンパイラ毎に異なります。
このため、呼び出す側のサブルーチンと呼び出される側のサブルーチンを同じコンパイラを用いてコンパイルした場合は、特に意識する必要はありません。ところが、C言語で記述された関数(C言語の関数はサブルーチンとして実装されます)からアセンブリ言語で記述されたサブルーチンを呼び出す、あるいはその逆というような場合には、コンパイラのコーリングコンベンションに従ってアセンブリ記述を行なう必要があります。
規定する内容には次のようなものがあります。
【コンセプトモデリング】《SW設計》 → Concept Modeling
電荷を蓄積する素子のこと。
素子に流入した電流を電荷として保持することのできる薄膜構造を持った2端子の電子部品である。ある電圧Vをコンデンサの2端子間に印加したときの電荷量Qは、Q=C×V で示すことができる。ここでCは具体的なコンデンサの特性によって決まる能力で静電容量と呼び、単位はファラッドである。
組込みコンピュータには、様々な用途でコンデンサーが利用されている。ボードコンピュータの上には、5Vや3Vの電源ライン上に乗るノイズを吸収するためのコンデンサが実装される。また、ADCには、アナログ電圧を直列接続のコンデンサに蓄えてその端子電圧を調べてデジタル変換するチャージカップル型のAD変換器がある。
このほかにも、シリアル通信には負の電圧が必要であり、そのために正のDC電圧から負の電圧を作るためのチャージポンプがCPUのボード上に置かれるが、これにもコンデンサが必要である。
コンデンサには、耐電圧、及び印加電圧の方向が規定されているもの(有極性コンデンサ)があるので使用にあたっては注意すること。
CやC++のような人間が理解しやすい高級言語で記述されたプログラムを、コンピュータ上で実行可能な形式(機械語あるいはそれに近いアセンブリ言語のような低レベルの形式)のプログラムに変換することをコンパイル(compile)と言い、その処理を行なうソフトウエア(プログラム)をコンパイラ(compiler)と言います。また、変換前のプログラムをソースプログラム、変換後のプログラムをオブジェクトプログラムと言います。
コンパイラは単純にプログラムを変換するだけでなく、より性能のよい(プログラムサイズが小さい、または実行速度が速い)オブジェクトプログラムを生成するように、さまざまな最適化を行ないます。コンパイラの最適化の性能は、プロセッサ自身の性能とともにオブジェクトプログラムの実行性能を左右します。
コンパイラの構造と処理の概要は次のようになります。
【コンパイラのくせやバグ】《ツール》
プログラミング言語で書かれたプログラムを機械語に一括変換するプログラムをコンパイラと言います。
コンパイラもプログラムですから、一般のアプリケーションよりも信頼性は高いとはいえ、バグを抱え込んでいる場合があります。また、コンパイラプログラムとしての論理の関係である程度の「くせ」を持っていることが多くあります。このため、書いたプログラムの論理的な部分の検証をするだけではなく、コンパイラの生成した実行形式のプログラムの動作を検証する必要があります。
コンパイラのくせやバグは次のような部分に多く現れます。
コンパイラのくせをうまく使うことで、効率の高い実行プログラムを分かりやすいロジックで記述することも可能になるようなこともあります。逆に、短いコードを書いたとしても、コンパイラの癖によって複雑で効率の悪い実行プログラムができあがることもあります。また、場合によっては、コンパイラのバグを回避するようにプログラムを書く必要もあります。このように、コンパイラ自身のくせやバグを知ることは実際にプログラムを組む上で重要です。