論理演算３ 論理演算と記号論理

　前に関数型言語のお話を描きました。＜過去記事＞
　システムの信頼性や品質を保証していく上で、何をしなければならないかを考える必要性は、非常に高くなってきています。しかしながら、アウトソーシングを含め、複数の会社との関わりの中での開発や、派遣技術者を含めた所属部の人員構成、個々の技術者が全体像をつかめないままに進めれれて行く大規模プロジェクトなど、非常に多くの現場での課題が山積している状況があります。こういった、開発環境の中では、「製品開発からテスト評価まで必死になってやりました。だから信用してください」と言われても、結果としては困りますというか、必死になってやったことそのものには、意味はありません。必死になって造ろうと、片手間に造ろうと、出来上がった製品に問題がなければ良いのです。
　かつては、バグゼロの思想が日本は主流だったこともあり、シーケンス制御装置なんかのソフトウェア品質は、かなりのオーバースペックで要求されてきました。現在の世界的な大会社の社長が、バグを仕様と言い切る時代では、製品の性能を優先する場合は、バグを仕様の中に組み込んでしまう覚悟がなければ、製品の性能を上げることができない状況になりつつあります。逆に、ちょっとしたシステムのバグから、大惨事につながることもゼロではなくなってきています。
　”総合的ものづくり”の中でシステム全体をとらえた場合、バグはゼロではないけれど、致命的なバグは無い。これを、どのように保証していくかが、”総合的なものづくり”の中で考えていかなければならない課題となりつつあります。
　原因は主として二つあげられると考えられます。設計者から管理者、使用者といったシステム関わる人それぞれが、システムそのものを上手く把握できていない。仕様書に網羅されるべき内容が、十分に精査されていないため、仕様書の段階で存在するテスト解析が十分に実施されない。
　前者は、構成される社会システムの中で、日本版ＳＯＸ法、安全設計（ISO/IEC Guide.51）や品質管理といった様々なシステムや規定での対応が図られつつあります。後者は、ＣＲＣやＵＭＬといった技法を含め、技術者が保有すべき知識・技能の体系的な提示や、ユーザーやクライアントに提示し守るべき知識・技能といった内容を含めての対応が、徐々に試みられています。
　後者の技術者が保有すべき、知識・技術のベースになっている基礎技術が、記号論理[symbolic logic]の知識・技術となります。

　課題：１から１０までの整数の和を求める
　　　１．暗算する
　　　２．紙の上で筆算する
　　　３．電卓をたたいて演算する
　　　４．Ｃ言語のプログラムで、int sum=1+2+3+4+5+6+7+8+9+10;を求め出力する
　　　５．Ｃ言語のプログラムで、sum=(1+10)*10/2;を求め出力する
　　　６．Ｃ言語のプログラムで、for (i=1; i!=10; i++) 　sum=sum + i;を求め出力する
　１から３は、間違えて出力されるかもしれない。４は、他人が見ても検証しやすいので、判断はしやすいが、短い式でなければ使用しにくい。５や６は、演算式そのものが正しいかどうかについて、確認しなければならない。単純な作業であっても、信頼性や品質を考えた場合は、保証するための作業は論理の膨大な演算処理が必要となる。
　システムは、論理の膨大な塊であり、巨大なシステムになればなるほどに、一人の人間では把握不可能なシステムの”化け物”となります。どこかにバグや歪といった欠陥があれば、システムの安全な稼働は、保障されません。こういった状況で、”化け物”に立ち向かうためには、論理を基準とした道具を使う以外にはありません。この基礎が記号論理[symbolic logic]です。
　参考文献：福良博史「記号論理テキスト(含、Misar-MSE) ～UMLのOCL記述および形式手法(Formal Methods)のために～　追記：関数型言語Haskell」