🍚

技術者のための！かいつまみ哲学(その4完)

2022/04/29に公開

オブジェクト指向

システム理論の対象

我々技術者が扱う対象は大きく3つに分類できます。
・単純な対象・・・要素還元主義的対象
・構造を持たない複雑な対象・・・統計学的対象
・構造をもった複雑な対象・・・システム理論の対象

単純な対象とは構成要素間の相互作用の少ない対象です。要素還元主義で理解できる単純さをもっています。例えば、互いに接する物体間の作用・反作用を考えれば問題が解けてしまう構造力学のような対象です。力学でいえば離れた要素間には相互作用がないため個々の要素ごとに方程式を立てて(要素に分割して)、解いてしまえば全体を理解したことになります(還元する)。

構造をもたない複雑な対象とは、1つ1つの要素間に一定の(固定の)関係を定義できない複雑な対象を意味します。哲学や科学では構造とは要素間の一定の関係を意味します。構造を持たない複雑な対象は統計学的に扱うことができます。統計学には大数の法則というものがあり、要素数が大きいほど統計学的に扱うことで逆に簡単に扱うことができます。

システム理論は構造を持つ複雑な対象を扱います。あることを実現するために、ひとまとまりに組織化した要素が互いに関係しあう集合、つまりシステムとみなして、他のシステムでも成り立つ一定の法則性があるだろうという観点からシステムを研究する分野です。

我々があるシステムを開発するとき、他のシステムでも類似のことが成り立つが成り立つはずです。だからシステム理論を理解している人は"たとえ初めて"開発するシステムでも場面ごとにおいてどのような粒度で見るのが適切なのかよく心得ています。一方、たとえ開発経験はあってもシステム理論を理解していない人は、目の前の仕事を俯瞰的に見ることができません。もちろん個別・具体の事例で他のシステムにない特殊な部分はあるので、一般的なシステムの理論と合わせて考えるべきだと思います。

システム理論

システム理論は1930年代から1940年代にかけてうまれ、戦後アメリカでシステム工学やシステムズエンジニアリングといったシステムの開発方法論が生まれています。ソフトウェアに限れば1970年代に構造化設計、1990年代にオブジェクト指向設計(OO設計)が生まれています。様々な開発方法論がありますが、どれもシステムの構造と挙動をどのように記述するかが異なるだけで背景となるシステムの理論は同じだと思います。

システムを決める要素

MITのLevesonによればシステムは次の6つで定義されるそうです。
“1.システム境界(インターフェース)
2.入力と出力
3.システムの目的や目標
4.構成要素
5.構造
6.構成要素間の関連する相互作用と
　システムがその完全性を保つための手段”
図1.jpg

設計者や分析者がシステムについて記述しようとした瞬間からシステムのこれらを定義していることになります。

1.インターフェース
2.入力と出力
3.システムの目的や目標
構造化設計でいえばコンテキストダイアグラム、OO設計ではユースケース図に対応します。システムはインターフェースの内部を目的にもとづいて入力-出力関係(機能あるいは関数)を定義してしまえばシステム内部はブラックボックスとして扱われます。
インターフェースを定義するのは結構やっかいです。サイバーセキュリティを考える際には守るべきシステムのインターフェースは物理的な境界に限りません。攻撃者はEメールやブラウザの脆弱性をついて攻撃しようとするからです。

4.構成要素
安定したシステムはまとまりのあるより小さなシステム(サブシステム)に分解できることが多いそうです。サブシステムはさらに小さなサブサブシステムからなり、システムはより大きなシステムオブシステム(SoS)の一部と考えます。システムの機能に着目するなら、サブ機能として分割します。この時サブの要素はなるべく互いに独立するように分割するのがベストプラクティス(BP)のようです。システムの機能に着目して分割する方法は機能分割と呼ばれており、プラグマティズムの格率にも沿っておりシステムを明快なもの、説明しやすいものにします。

5.構造
構造というのは数理論理学では言語Lの項の任意の部分集合、関数記号の集合、述語記号の集合からなるものと厳密に定義される難しい用語ですが、以下のように注記すればわかりやすいかもしれません。

項は定数、変数、関数(英語では機能と同じ単語)
関数はそのまま関数(入力を出力に変換する)
述語は関係(単純なものは大小関係など)
つまり、構造は上記の言葉でシステムを表現したものです。これに解釈を加えたものを数理論理学ではモデルと定義されています。UMLという言語では、クラスと属性からなる項があり、関数を記述し、関係(関連、依存、フロー、汎化、実現、使用)からなりシステムのある側面がこれらの言葉で記述されます。UMLの記述の解釈が規定されているためUMLで書かれたものをモデルと呼びます。構造化設計でも構造化言語があります。言語、記述しようとするシステム、解釈の関係はパースが述べた記号そのもの(表現項)と対象と解釈の関係に相当すると思います。

6.システムが完全性を保つための手段
構成要素間の相互作用が整合性がとれていないとシステムが安定しないために入っている仕組みです。例えば、同じプロトコルでやりとりするとか、誤り訂正が入っているとかいった仕組みのことです。

システムは数理論理学で扱える論理的な構造をもっているので、システムの論理的な(静的なそして機能的な)側面は数理論理学に基づいた形式手法で整合性を検証できます。

システムのモデルの記述

システム内部の注目する特性をモデルで記述しようとした場合モデルは次の5つの観点で記述されるそうです。これをモデルの十全分析というそうです。
(1)モデルの静的・動的な特性
(2)モデルで許容される状態
(3)モデルで許容される状態間の遷移
(4)状態遷移を開始するもの
(5)状態と遷移の相互依存関係
システムの注目すべき側面についてこれらすべてを記述する必要があります。

リアルタイムが要求されるシステムでなければ静的(論理的そして機能的)な側面の記述で十分かもしれません。リアルタイムが要求されるシステムでは論理的なモデル記述のみでは不十分です。システムの時間的な側面をトップダウンで記述しても最後の物理層の部分のモデル化が難しいので、物理層を抽象化・モデル化するか、過去の経験に頼って単純化するかをしなければなりません。そしてこれはかなり経験を要することです。

システムの法則「創発と階層」

システムは階層構造をもつことが知られています。システムが安定しているためには安定した中間状態が必要だそうです。確かに、頻繁に更新されるミドルウェアで安定したソフトウェアを構成するのは大変だと思います。ある階層に特徴的な特性(創発特性)をもつことが知られています。創発特性は下位のレベルでは存在しません。例えば、安全性は創発特性であると知られています。部品それぞれが安全であることは、装置全体が安全であることを保証しないことが知られています。逆に信頼性のある部品を使うことは装置全体の信頼性を高めます。システム上位で作りこみしなければならないことを下位で頑張ってもなかなかうまくいかないのはこのためです。

システムの法則「制御と通信」

システム上位が下位を制御することで創発特性がうまれるそうです。下位が上位を制御するのはセオリーから外れているのだと思います。望ましい創発特性を持たせるためにはシステム上位の制御をうまく設計する必要があります。また、開かれたシステムは環境との通信手段が必要だそうです。
図2.jpg

システムの仕様記述

システムは階層構造を持ちますが、仕様も階層構造を持ちます。構造化設計のころ？から仕様はwhat（何が要求されるのか）－ how(どうやって実現するのか)という関係によって詳細化されるようになりました。時々仕様書が説明書になっているケースを見ます。whatとhowが混在しており、何が要求なのかまったくわからず困惑してしまいます。また頻繁して登場する記述パターンはデザインパターンとして知られています。

以上でかいつまみ哲学は終わりです。今回はシステム理論を中心に述べました。システム開発方法論はまだ発展途上であり、国際規格がどんどん作られている状況なので、まだまとめられずにいます。昔まとめた自分用のメモノートに基づいてまとめてみましたが、おもしろいのかよくわかりません。こういう本があってもっといいこと書いてあるよとかコメントいただけると励みになります。

用語

(現代形而上学という本や数理論理学の本から引っ張ってきた、技術の用語を理解する助けになるかもしれない。)

述語論理に基づく狭義のモデルの定義
ある記法SIGと解釈Iからなる言語をLとする。
ある言語Lにおいてある理論Tが言語LとLの式の集合Aの組として与えられたとする。
SIGの構造SがAのすべてを満足するならば理論Tのモデル(多くのモデルのうちの一つにすぎない)という。構造とは記法SIGのSort(変数など)の任意の部分集合、関数記号の集合、述語記号の集合からなる。

その他モデルとは現実の現象又は想像された現象を表すためのある構造と解釈とも定義される。

実体(エンティティ)：
ある空間と時間において他の何物にも依存しないもの

性質（または属性)：
それを担う何かに依存するもの
*プログラミングの世界では変数という用語に置き換えられる気がする。

本質：
本質とはある対象が当の対象であるためにもっていなければならない性質、よってもしその性質を失ってしまうともはや当のものであることができなくなるような性質である

具体的：
特定の時間・空間的な位置を占めるということ

抽象的：
特定の時間・空間的な位置づけを持たないということ

具体的個物（ないし単に個物）：
*個物は実体(substance),個体(individual)ともよばれる
個物は例えば次の特徴を持つ
・局在性：この個物は現時点においてはこの場所だけに存在し、同時にほかの場所に存在することができない
・不可入性：この個物が位置する場所には、同時にほかの個物が位置することはできない。つまりこの個物は、ある空間位置を独り占めしている。
・他の個物との類似性：この個物は、色や重さや大きさ等々に関して、別の個物やそのほかの個物と類似しうる
・変化可能性：この個物は先月は小さかったが、現在は大きい。そしてこれらの変化を通じてこの個物は同一であり続ける。
・認識可能性：この個物は知覚などの経験を通じてその本性(本質)が知られうる。

性質の束説：
個物を経験を通じて知られるひとまとまりの性質と同一視する考え方

参考文献

[1]セーフウェア,翔泳社
[2]Engineering a safer world, The MIT Press
[3]科学とモデル, 名古屋大学出版会
[4]ワードマップ現代形而上学: 分析哲学が問う、人・因果・存在の謎, 新曜社
[5]情報科学における論理, 日本評論社

システム関係の国際規格
[1]JISX0166:システムおよびソフトウェア技術－ライフサイクルプロセス－要求エンジニアリング
[2]JISX0170:システムライフサイクルプロセス
[3]JISX0160:ソフトウェアライフサイクルプロセス
[4]ISO/IEC/IEEE 42010:Systems and software engineering — Architecture description

構造化設計については
[1]リアルタイムシステムの構造化分析, 日経BP社
[2]構造化システム設計への実践的ガイド, 近代科学社

オブジェクト指向開発については
[1]UMLによる統一ソフトウェア開発プロセス, 翔泳社

辞書系 (オクスフォードの辞書のクオリティが高すぎるので紹介、専門書の用語を正しく詳細に解説している。最近の国際規格の用語も豊富に解説されている。)
[1]Oxford Dictionary of computer science
[2]Oxford Dictionary of electronics & Electrical engineering