中学校技術/プログラムによる計測・制御

コンピュータの処理の手順をプログラムという。 プログラムを記述するための言語をプログラミング言語という。

コンピュータは、特に指示がない限りは、前から順番通りに実行する。これを順次という。
コンピュータは、条件によって(あるいは条件によらず)実行する順序を変えることができる。これを分岐という。
コンピュータは、同じ処理を繰り返すこともできる。これを反復という。
分岐と反復を組み合わせて、条件が満たされている間だけ処理を反復するような手順も、プログラムで指示できる。
プログラミング言語には様々な種類があるが、多くのプログラミング言語は、分岐や反復や順次処理などを利用している。
プログラムでの、順次や分岐や反復の組み合わせ方を、人間が理解しやすいように図示したものとしてフローチャートが有る。 横長のひし形(図では◇の横長のもの)で、条件分岐を表し、ひし形の中に、条件の内容を記述している。
順次処理は、横長の長方形で書かれる。処理内容は、四角の中に書かれる。
順番は、原則として、プログラムの最初が、フローチャートの一番上にあり、一番下が、最後の処理である。

プログラミング言語には多くの種類があるが、1960年代ごろからある古典的な言語では、BASIC(ベーシック)とC言語(シーげんご)とFORTRAN(フォートラン)やCOBOL(コボル)がある。


外界からの情報を信号として出力する装置をセンサという。 以下、コンピュータに取り付けられるセンサについて記述する。
センサとは別に、コンピュータなどからの信号に基づき外界の物体を動かす装置をアクチュエータという。
センサとアクチュエータをコンピュータに取り付ければ、センサで外界の状況を確認できるので、外界の状況が変わっても、センサで外界を確認しなおして、プログラムの判断基準(プログラムの条件分岐の機能を、アクチュエータの判断基準に応用できる。)に従い、アクチュエータで外界の物体をプログラム通りに動かせる。 このように、コンピュータ制御のアクチュエータを、センサと連動させることで、外界の環境変化に対応するアクチュエータを作ることができる。
一般に、パソコンの単体には、センサやアクチュエータは付属していないので、もしセンサやアクチュエータが必要な場合は、パソコン用のセンサやアクチュエータを購入などで入手してから、それらをパソコンに取り付けることになる。

コンピュータの分岐機能での条件判定では、次のような判定が出来ます。
センサーなどを用いてアクチュエータ制御の条件判定を行う場合は、センサーの信号を数値に置き換えて行います。
また、複数の条件判定を組み合わせた条件判定もあります。次に示す、論理積や論理和などです。
たとえば、条件Xと条件Yの両方が満たされている時にのみ、ある行動を実行する条件判定をAND(アンド)という。このANDとは英語の接続詞の 「and」 のことである。式では、
などと書く。
仮に条件が満たされていない場合を数字の0として、条件が満たされている場合を1とすると、andの性質が、掛け算に似ているので、そのことからAND演算を論理積(ろんりせき)ともいう。 ある条件Xが満たされていることを真(しん)と言う。ある条件が満たされていない場合を偽(ぎ)と言う。 条件が真の時、これを数値の1で表すことができる。条件が偽のとき、数値の0で表すことができる。なお、このように、条件の数値を数値の1と0に置き換えて計算する代数学をブール代数(ブールだいすう)という。

条件Xと条件Yの少なくとも、どちらか片方が満たされている時に、ある行動を実行する条件判定をOR(オア)という。このORとは英語の接続詞の 「or」 のことである。式では、
などと書く。OR演算のことを論理和(ろんりわ)ともいう。

他にも、条件Xが満たされていない場合に、(その他の条件Yなどについては不問)、ある行動を実行する条件判定をNOT(ノット)と言う。式では、
などと書く。NOT演算のことを否定(ひてい)と言う。
他にも、条件Xと条件Yの少なくとも、どちらか片方のみが満たされている時に、ある行動を実行する条件判定をXOR(エクスクルーシブ/オア)という。式では、
などと書く。XOR演算のことを、排他的論理和(はいたてき ろんりわ)とも言う。
条件判定のANDやORなどを回路図の一部として図示したものとして、論理回路がある。条件が満たされた時を、回路に電流が流せる時と同一している。 たとえば、AND回路では、A and B なら、Aに対応するスイッチとBに対応するスイッチが閉じることで、回路に電流が流せるようになる。 NOT回路では、not Aなら、普段はスイッチが閉じていて、条件Aが満たされた時に対応するスイッチAが開き、電流が流せなくなる。
コンピュータのハードウェア内部では、半導体素子の一種であるトランジスタのスイッチング機能を用いて、論理回路を実現している。このようなハードウェアの仕組みを利用して、コンピュータは論理演算を行っている。なおトランジスタが実用化される前には、パラメトロンや三極真空管を、更に真空管が実用化される前には、継電器(リレー)を用いて、スイッチング機能を実現していた。
(トランジスタのスイッチング機能については工業高校や工学系大学の教育内容になる。)
プログラミング言語の具体的な文法については、ウィキブックス内には、記事プログラミングなどに解説があります。 実習などで用いる言語は、時代によって変わるかもしれません。また、実習の内容によっても変わります。 たとえばウェブページを作る場合のプログラムはHTML(エイチ・ティー。エム・エル)という言語で記述を行う場合が多いです。
また、学校で用意された実習キットなどを用いてプログラミングを行う場合は、そのキット用に開発された独自の教育用のプログラミング言語を用いる場合もあります。
中学の段階なら、BASICか、その派生言語を使うことが、あるかもしれません。

プログラミングでは、とりあえず一応のプログラムを書けたら、今度はそのプログラムを実験的に動作させてみて、本当に安全かつ正常に動くかどうかを確認する必要があります。
人間の入力ミスや、勘違いなどによって、プログラムが異常な動作をしてしまう場合もあります。
なんらかの原因で、プログラムが異常な動作をすることを「バグ」と言います。
プログラムにもしもバグがあったら、つまり、なにか異常な動作、正常でない動作をするなら、これは修正しないといけません。このように、バグを取り除いて、プログラムを正常に直すことをデバッグ(debug)といいます。
前提として、プログラムを作った後は、まず開発企業などが自分たちで、本当にそのプログラムが正常かどうかを実際にプログラムを動作させる実験によって試す必要があります(この工程を「テスト」と言います。)。もちろん、時間の制限などもあって、完全には確認しきれませんが、なるべく時間の許すかぎり、プログラムを確認する必要があります。
また、プログラムのエラーだけを除くのではなく、たとえば画面のあるシステムを作っている場合なら、画面が第三者の利用者にも見やすいかのチェックや、操作が分かりやすいかなどもチェックもデバッグにおいて確認する場合もあります(※ 開隆堂の検定教科書)。

なお、テストのために動作確認をする前提として、まず、その製品の正常な動作を、決める必要があります。(これをIT業界で「仕様」(しよう)などと言います。)
「〇〇の条件のときに、このプログラムは△△の動作をする」という仕様でしたら、果たして本当にプログラムがそのとおりに動作をできているか、実験をして確認をします。
※ なお、温度を電流に変換するための電子素子としては、PTCサーミスタという素子があります(※ ネットの教科書画像でPTCサーミスタの紹介を確認。教育図書の教科書とのこと)。
バグを見つけて除くデバッグも重要ですが、万が一、バグを見過ごしてしまった場合でも、人が死ぬことや怪我などの取り返しのつかない大被害が出ないように設計することも必要です。
そのように、もしバグや故障などの誤動作などがあっても、システムが安全に稼働するように設計することをフェールセーフ(fail-safe)またはフェールプルーフ(fail-proof)と言います(※ 2022年代の中学技術の検定教科書にフェールセーフが書いてあるらしい)。
「フェイル」fail とは、「失敗する」・「失敗」などの意味の英語です。
たとえば、機械工場で生産システムを管理しているコンピュータの場合、もしシステムが異常を感知したら、そもそも通常起動をしないようにするべきです。
なぜなら、異常のある状態で高圧プレスなどを制御されたら、もしかしたら事故で作業員が死ぬ可能性があります。
かといって、すでに稼働している最中でシステムが級に故障した場合に、果たして急停止するべきかといわれたら、それは場合によっては疑問です。
もしシステムが急停止したことで、逆に人がケガをする事故が起きては困ります。
なので、システム稼働中の事故に対しては、たとえば徐々に減速していく、とかの設計になるでしょうか(職場や製品やシステムによって、適切な設計は変わります)。
ともかく、システムの異常時には、事故防止のため、安全にするための処理が自動的に起動して動作するような感じの設計、または、安全だと認められる処理以外の手作業での入力をシステムが受け付けないように設計するなど、安全措置(あんぜん そち)以外をできないようにする必要があります。
このように、安全側にシステムのモードを移行するための仕組みを組み込むような設計のことが、フェイル・セーフまたはフェイル・プルーフと言われるものです。
なお、仮にプログラムにバグが無くても、部品の故障によってエラーが起きる場合もあります。なので、工場などで使うプログラムでは、フェイル・セーフも必要です。
さて、ある検定教科書では、サーバ・クライアント通信のプログラムを、アクティビティ図を用いて設計する手法を紹介しています。
果たして中学でそこまで必要になるかは不明ですし、そもそも中学レベルの技術力でそういう通信プログラムが書けるのか不明ですが、しかしとりあえず、(※教科書では説明していませんが、)一般的なプログラミングにおける設計技法として、自分の作ろうとしているモノが何なのかを、箇条書き(かじょうがき)などで紙にまとめる必要はあります。
なぜなら、検定教科書では説明されていませんが、
仕事などだと、上司や部下・同僚など他人が読んでもわかるように設計書を書く必要があります。(おそらく、検定教科書が意識してるのはコッチ。)
設計書では、大まかな要件を先に決定していき(ただし、比較的に短期間かつ自力たちで実現できる具体的な目標)、それを元に段階的に、追加の文書により細部を決めていきます。
どちらにせよ、まず、設計目標が何なのかを明確に文書に起こす必要があります。別に文体が美文である必要はありません。
そして、その目標に必要な最低限の技術的に実装すべき対象が何なのかを明確にしていきます。
プログラマーとしては事前にメモ書きのようなものでいいので、紙またはテキストファイルなどに、作りたいプログラムの満たすべき要件をまとめておくなどしておくと、いちいち目標を定期的に思い出す手間が省け、思考力を節約できるので、プログラミングに集中しやすくなります。(検定教科書では紹介されない用語ですが、こういうのを「To doリスト」とか「作業リスト」とか「タスクリスト」とか「やることリスト」などといいます。)
ともかく、プログラミングの入力の前に、まず「自分たちは何を設計したいのか」を具体的に紙または画像データに書き起こすことです。検定教科書ではフローチャートの書き方などを教えていますが、それはあくまで、入力したいものを明確にする手段のひとつです。
そうやって具体的に見て分かるように文章化または印刷化・画像化をしておけば、打ち合わせをするにしても、あるいは忘れないようにするためにメモ代わりにするにしても、どちらにも役立ちます。
要は、「何を入力したいのか?」を読みやすい形式でメモ的に書いておけばいいのです。
並び順を変えることを「ソート」と言います。
ソートには、選択ソートや交換ソートがあります(※開隆堂のサイトで確認)。開隆堂サイトでは、トランプ(カードゲームのほう。カード4枚)の並び替えをしていました。

ゲーム業界の例なのですが、ゲーム業界では「仕様書」(しようしょ)として、ある画面の動作の条件をすべて具体的に書きます。
また、基本的に具体的な画面を使って動作説明すことで、客観的に誰でも分かるように説明しています。
たとえば、ある画面では、
のように具体的に書きます。(※ なお、製図などとは違い、仕様書では日本共通の書き方というのは存在しません。仕様書の規格も存在しません(2023年の時点ではそう)。)
前の画面に戻るためのボタンのように、文脈から分かることでも、上記のように具体的に書きます。
イラストのように、クリックしても何も起こらない場合ですら、何も起こらないことを仕様書では明記します。そうすることで、その仕様書のそのページさえ読めば、これからプログラミングで作るべき動作のゴール地点が分かるようにします。
もちろん、変更ボタンのように、クリックすると変更が起きる場合は、
のように何をどう表示するかも具体的に書きます。
このように、ソフトウェアの設計(デザイン)というのは、先にゴール地点を具体的かつ客観的に決めて、あとから細部をデザインしていきます。一般にゲームも同様、ゴール設定を先に行い、あとから細部を決めていきます。アイデアは、「なんのために」というゴールを達成するための手段です。
ゲームデザインではない単元ですが、教育図書(教科書会社)の検定教科書でも木工などの単元で、目的や条件から逆に(設計の)構想を考えるように指導しています。なお、実用品などの場合は、問題を先に見つけ、その問題を解決するために上記の目的や条件を考えます(※ 教育図書の見解)。
また、設計のための書類で使われれる文章のレベルも、中学卒業したレベルの知識さえあれば、とりあえず内容は分かるような文章で書く必要があります。