AUTOSAR CountdownAdvent Calendar 2022

算譜(program)が計画(plan),設計(design)である３つの理由, coding(33) 図(27)

Last updated at 2024-11-02Posted at 2018-02-23

算譜(program)を書いていて、時々、計画(plan)や設計(design)を、別に書けという人がいます。

「はい、これが計画(program)です」と答えるようにしています。あるいは、
「ごめんなさい、これが設計(design)なんです」と答えます。

算譜(program)に変換できない文書は作らないようにしています。

<この項は書きかけです。順次追記します。>

理由1 算譜(program)は計画(plan)

算譜(program)は、計画(plan)するという意味です。

program:a plan of action to accomplish a specified end(特定の目的を達成するための行動計画)
http://www.dictionary.com/browse/programme

計算機の算譜(program)は、計算機の動作の設計です。

振り返って考えて見ましょう。計算機で変換できない言語で書いたものは、例えば会議録などは、人間の行動に対する方針です。それで計算機の行動は計画できません。

算譜(program)が計算機の計画・設計です。例えば、C言語で見かける部分を見てみましょう。

int main(int argc,char * argv[]){

int:OSに整数型で戻り値を返す関数です。16bitコンパイラでは16bit整数, 32bit コンパイラでは32bit整数です。
main(): OSから直接コマンド等で呼ぶことができる関数です。
():引数列です。
int argc: 整数の引数の個数(argument counter)をOSから受け取る変数argcを宣言します。
char * argv:引数の文字列の配列(argument vector)の変数argvを宣言します。最初の文字列は関数名そのものです。
{}:main関数の定義の範囲を示します。

いかに、計画しているかわかりますね。

OSを前提としている。
OSに値を返す意思がある。
OSを前提としなかったり、OSに値を返す意思がないときはintではなくvoidと書く。
引数を使う。
ここが設計の基本仕様です。
さらに詳細な設計は関数定義の中に記述します。

大事なのは、上記の意味を、どの文書に基づいているかを付記しているかです。

return argc;
}

最後に返すのに良いものがないときは、argcを返すようにしています。
これは、プログラムが外部から受け取った引数を途中で破壊しなかったかを確かめる試験プログラムを書くことができるからです。
そんな馬鹿なという方がお見えになるかもしれません。暴走しかけのプログラムでは、これでも効果があることがあることがあることが、、、。

1.1 利用したコンパイラの手引き(manual)を記載する。

大事なのは、コンパイラの版が特定できるかどうか。手引きの発行年、手引きの版なども記載するとよい。

1.2 利用したコンパイラとその版を記載する。

手引きではなく、コンパイラの版だけを記載してもよい。

1.3 利用可能なC言語規格を記載する。

利用可能なコンパイラが多くあれば、適用可能なC言語規格を記載してもよい。

記載例：
https://researchmap.jp/jovqfzcc8-1797580/#_1797580

理由2 変換可能性

最初は、図で書こうが、日本語で書こうが実は構わないのです。その書いたものを、計算機が処理できる言語に変換できればいいだけです。何で書こうが、その書いたものが算譜(program)です。

逆に、計算機が処理できない言語で書いたものと、計算機が処理できるものを別々に書くのは、無駄であるだけでなく、誤解を招いたり、保守の間違いを誘引する可能性があり、とても危険です。

だれか、「こういう設計書を書け」と言われたら、「その設計書を計算機が処理できる変換器を書いていただけますよね？」と答えよう。
あるいは、自分で変換可能器を作れるような文章だけ書けばよい。できれば、変換器もついでに作ってみよう。

状態遷移図などは計算機が処理可能な言語に変換する道具が普及しています。文字で書くと伝わりにくいことは、図で書いたり、図だけだと抜け漏れが生じる可能性があるので表に算譜で変換できる道具があります。

ところで、書いた算譜が必要な仕様に適合しているかを確かめる算譜もあります。モデル検査言語、仕様記述言語、検証言語と呼ばれているものです。これらの算譜は直接最終的な製品に含まれませんが、書いたものが妥当かどうかを計算機で確かめるために用います。計画類（仕様類）の一部と理解しておくといいかもしれません。

また、時間的に間に合うかどうかを試験する道具類も記述しましょう。

算譜には、理由１で書いたのとは別の切り口でも、道具類とその利用可能な版を列記するか、仕様・規格を列記しましょう。

図を使って分析・設計すればこんなに簡単。安全(11), 図(11) https://qiita.com/kaizen_nagoya/items/6347eb55b2812d745549

設計図(12) 表はいつ(when)書く、何を(what)書く、どうやって(how)書く。仮説(71) https://qiita.com/kaizen_nagoya/items/7fddfa5d8bfb5a947db8

反省点1

書いていて、linkerの版を記載するのを忘れていたことに気が付いた。
linkerによっては、結合できるライブラリの範囲が異なることがある。
また、macosではlinkerの機能がgccと異なるらしい。

反省点2

ライブラリの版を記載するのを忘れていたことがある。
ライブラリの種類は、コンパイラを呼び出すときの記述(script)にライブラリ指定で名前がわかる。ただし、-lpcapのように、libpcapを導入して、指定するときはlibを省略するという作法などについても記載が必要な場合がある。

Macintosh対応「基礎からわかるTCP/IP　アナライザ作成とパケット解析　Linux/FreeBSD対応」小高知宏　オーム社
https://qiita.com/kaizen_nagoya/items/517411b42fc5ceabd581

理由3 抽象度

論理回路記述言語(verilog HDL)では、言語で書いた文字列が設計書で、回路図が実装です。
配線などは抽象化されていて、回路図でも、まだ実装ではないと言うこともできます。配線の指定まであって、初めて実装。

C言語で言えば、C言語が設計書で、コンパイラがコンパイルした機械語が実装です。機械語でも、まだ実装ではないと言うこともできます。linker, locatorで、どのような順番で機械語を配置するか、メモリのどこに配置するかなど、実装までの道のりは、論理記述と同様長いのです。

いつも同じlinker, locatorを使っているから、Cの記述が決まれば実装が決まるのだというのは、制約条件次第だと言っているのと等価です。linkしたものを、メモリのどの領域に配置するかで、動作が変わる場合があります。ところで、locaatorはloaderとも言います。送り込む側の視点か受け取る側の視点の名前の違いかも。

リンカ・ローダ実践開発テクニック―実行ファイルを作成するために必須の技術
,坂井弘亮,CQ出版,2010
https://www.amazon.co.jp/dp/4789838072/ref=asap_bc?ie=UTF8

参考文献

【クソ食らえ】CocoaPodsとApple Mach-O Linker Errorとlinker command failed with exit code 1でどハマり
https://qiita.com/sutchan/items/0a78042261ca3f0a7d91

RTL設計スタイルガイドVerilogHDL版が電子書籍として復活
http://www.eda-express.com/2016/08/rtlveriloghdl.html

SEI CERT C Coding Standard AA. Bibliography
https://wiki.sei.cmu.edu/confluence/display/c/AA.+Bibliography

The latest publically available version of the C11 standard
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

自己参照

self-reproduction方式によるBasicプログラムジェネレータの作成, 小川清, 電気関係学会東海支部連合大会, 1987年10月
https://qiita.com/kaizen_nagoya/items/117c7a1b6dad97470ae9

OBJ の試用経験,小川清,二木厚吉,ソフトウェア技術者協会シンポジウム,1992 年 6 月
https://qiita.com/kaizen_nagoya/items/acb2f1740740d5e57892

C++ Support(0)　
https://qiita.com/kaizen_nagoya/items/8720d26f762369a80514

Coding Rules(0) C Secure , MISRA and so on
https://qiita.com/kaizen_nagoya/items/400725644a8a0e90fbb0

[C][C++]の国際規格案の例題をコンパイルするときの課題７つ。
https://qiita.com/kaizen_nagoya/items/5f4b155030259497c4de

C Puzzle Bookの有り難み5つ、C言語規格及びCコンパイラの特性を認識
https://qiita.com/kaizen_nagoya/items/d89a48c1536a02ecdec9

The C++ Standard Library: clang++とg++でコンパイルしてみた(まとめ):14件
https://qiita.com/kaizen_nagoya/items/9bdfaa392443d13e5759

C++17 - The Complete Guide clang++とg++でコンパイルしてみた(まとめ):4件
https://qiita.com/kaizen_nagoya/items/c000f307e642990781e1

C++N3242, 2011, ISO/IEC 14882, C++ standard(1) Example code compile list
https://qiita.com/kaizen_nagoya/items/685b5c1a2c17c1bf1318

C++N4606 Working Draft 2016, ISO/IEC 14882, C++ standard(1) Example code compile list
https://qiita.com/kaizen_nagoya/items/df5d62c35bd6ed1c3d43/

C++N4741, 2018 Standard Working Draft on ISO/IEC 14882 sample code compile list
https://qiita.com/kaizen_nagoya/items/3294c014044550896010

C++N4910:2022 Standard Working Draft on ISO/IEC 14882(0) sample code compile list
https://qiita.com/kaizen_nagoya/items/fc957ddddd402004bb91

Autosar Guidelines C++14 example code compile list(1-169)
https://qiita.com/kaizen_nagoya/items/8ccbf6675c3494d57a76

coding (101) 一覧を作成し始めた。omake:最近のQiitaで表示しない5つの事象
https://qiita.com/kaizen_nagoya/items/20667f09f19598aedb68

OSEK OS設計の基礎　OSEK(100)
https://qiita.com/kaizen_nagoya/items/7528a22a14242d2d58a3

Error一覧 error(0)
https://qiita.com/kaizen_nagoya/items/48b6cbc8d68eae2c42b8

算譜(program)が計画(plan),設計(design)である３つの理由, coding(33) 図(27)

理由1 算譜(program)は計画(plan)

1.1 利用したコンパイラの手引き(manual)を記載する。

1.2 利用したコンパイラとその版を記載する。

1.3 利用可能なC言語規格を記載する。

理由2 変換可能性

反省点1

反省点2

理由3 抽象度

参考文献

自己参照

関連資料

自己記事一覧

文書履歴(document history)

最後までおよみいただきありがとうございました。

Thank you very much for reading to the last sentence.