ソフトウェア開発において情報はどこまで見せるか 5

個人情報、プライバシー情報、企業の機密情報などと言ったコンピュータ上に存在する守るべきデータは、プログラマーから見ると「どのようにでも扱うことが出来る」ものです。話はコンピュータ上でどのようにデータは扱われているか、どのように扱えるのか、ということです。オブジェクト指向言語では最も一般的であろうと思えるJava言語を参考に考えます。

 

Java言語でデータの公開範囲を考えるには、パッケージという空間がまず大事になります。

 

アプリケーションはパッケージの集合として構成されます。そしてパッケージはクラス名の集合を持ってる。SNSのサービスに登録しようとした時に、自分と同じ名前が重複していて登録出来ないことがあります。

「既に登録されています、違うIDを使用していください」とメッセージが出てくるけれど、すごく残念な思いをしたことはないでしょうか。

本来は使用者から見て、自分が使用したいIDを重複したとしても使ってるように見せてくれればいいはずで、事実FBやG+などはIDは自動的に付与され、使用者は自分の名前を幾ら重複しようが使用出来るようになっています。同じ名前でも別のIDを裏側で扱うことによって衝突をさけているわけです。

パッケージはクラス名の重複を可能にします。パッケージは同じような意味合いで「名前空間」と呼ばれる事があるけれど、それはこのような理由があるからです。

 

プログラマはパッケージを宣言しない事も可能ですが、この場合コンパイラは無名パッケージとして自動登録します。無名パッケージはimport文に指定することが出来ないため、サブパッケージを持つことは出来ません。

 

そしてまたパッケージは、コンパイル単位を意識するべきものです。パッケージは横並びの他のパッケージとメッセージをやり取りすることが出来ますが、その可否を「観測可能性(observable)」と呼びます。観測出来ないパッケージに依存するプログラムはコンパイル出来ません。作成したパッケージが重要な情報を扱う場合、外部のプログラムからどこまでアクセスを可能にするのか。

これはとても難しい問題ですが、そこで参考にすべき言葉が先にあげたジョシュアの言葉「アクセス可能性を最小限にする」です。

 

Javaではプログラミングに有益であり、かつ、観測可能性を縛る必要のないパッケージ(java.langやjava.util等)に関しては、全て「観測可能」な状態をとっています。観測可能であるとはどういうことか。

 

・パッケージの宣言を保持しているコンパイル単位が観測可能である場合

・パッケージのサブパッケージが観測可能である場合

 

上記の2つを満たして真であれば、「常に観測可能である」と結論出来ます。

 

 

====================================================================

※参考文献

Java言語仕様 第3版」(ピアソン・エデゥケーション)

「The Java 仮想マシン仕様」(アジソン・ウェスレイ)

ソフトウェア開発において情報はどこまで見せるか 4

ここまで関数内で宣言されたローカル変数と、関数の外で宣言された外部変数の役割を確認しました。今にいたるまで、1940年代に考案されたノイマン型コンピュータが、アーキテクチャとしてそのまま使用されているのも驚きではありますが、メモリ上にプログラムを読み込み、必要なデータをレジスタに持ち演算をおこなっていく。これは現在もそしてまだまだ先の時代にも変わらなさそうです。

 

ローカル変数はスタック領域。外部変数はヒープ領域。それぞれメモリ上の領域にそのデータは置かれていきます。メモリは揮発性です。揮発性とは半導体メモリにおいて、電源を切ると記憶内容が消える性質のことです。コンピュータの電源を切るたびにデータが消えてしまうので、コンピュータの電源が切れて次に起動したときにもデータを扱えるようにするためには、不揮発性の「場所」にデータを入れる必要があります。

 

その場所はハードディスクで、形式としてはファイルです。テキストファイルやCSVファイルなどに消えてほしくないデータを保存するようになります。

するとそれらのデータはハードディスクのもの、総じてコンピュータのものになります。

 

ハードディスク上の話はまた後で進めていくとして、オブジェクト指向言語でのデータの扱いをまとめていきます。

ソフトウェア開発において情報はどこまで見せるか 3

Aという関数がもっているデータを使用して、Bという関数に仕事をまかせる時には、引数と呼ばれるデータの入り口に、その値をメッセージとして渡すことが出来ます。Bという関数は自身のローカル変数に受け取った

値を入れて仕事をはじめることになります。これは関数同士の間でかわすメッセージ量が少ない場合は問題ありません。問題がないどころか、安全に関数同士でメッセージを伝えることが出来ます。

 

しかしメッセージの量が多くなったり、種類が増えたりすると、あまり賢く便利なやり方だとは言えなくなってきます。関数同士で複数なデータの結合などを生むことにもなり、プログラムが煩雑になってしまいます。またデータの長さが解らない場合には、決まった大きさを確保するスタック領域に場所を確保することは困難です。そこで広域なデータの扱いが出来る必要があります。

 

関数の内部で使用されるローカル変数に対して、関数の外で宣言されるのが外部変数です。関数間で自由にアクセス出来るデータになるだけでなく、データの長さを自由に、動的に扱うことが可能になります。外部変数はメモリの動的記憶領域に置かれることになりますが、この領域はヒープと呼ばれます。ヒープ上に置かれたデータは、ローカル変数のように関数が終了しても自動的に削除されません。

 

ローカル変数と外部変数では、「通用範囲」「存在時間」に違いがあります。ローカル変数は一つの関数内で通用し、その関数が終わるとデータは消えてしまいます。一方外部変数は複数の関数からなるプログラム全体で通用し、一つの関数の終了に影響されず存在します。

 

ヒープ領域はリストデータのような動的で大きなデータにも使用されます。その時、メモリを管理するのはプログラマです。malloc()関数により使用するメモリ領域を指定して、使用後にfree()関数で領域を解放する、という手続きをおこないます。ヒープ領域は一定量の使用出来る範囲があるため、解放せずに要求を続けると、メモリリークを起こしてしまいます。プログラマは明示的に領域を確保し、解放する必要があります。

 

情報は誰のものか。

 

外部変数は、プログラム全体のものであり、またプログラマのものであると言えます。そしてデータはヒープ領域におかれています。

ソフトウェア開発において情報はどこまで見せるか 2

C言語において変数や定数など扱うデータは、まず局所的(ローカル)なものと広域(グローバル)なものにわけて考えられています。関数の中で宣言されるデータは局所的なものです。ローカル変数に使用するメモリ領域はスタック領域と呼ばれ、関数がその仕事を完了するとそのデータは無くなってしまいます。

 

関数の中で定義され使用されるデータは、「自動変数」とも呼ばれ、次にまた関数が呼ばれた時にもデータは引き継がれることなく、新たなデータとしてスタック領域に置かれることになります。

 

関数が一度呼ばれ、その仕事が完了する間だけ使用される、ということは、その関数の柔軟性を高めることになります。その関数を呼ぶたびに、何度も値を変えたとしても、独立して使用出来るからです。スタック領域は静的にデータを扱うので、データの大きさなども全て定義されてから使用されます。

 

なので必要なデータが沢山あればあるほど、その関数内で全て定義することになります。

 

情報は誰のものか。

 

局所的に使用されるデータを扱う、という事でローカル変数とは「関数のもの」であると言えます。そのデータの置かれている場所はメモリのスタック領域です。

ソフトウェア開発において情報はどこまで見せるか 1

ジョシュア・ブロックの「Effective Java」ではその項目13にこうあります。「クラスとメンバーへのアクセス可能性を最小限にする」。

 

「アクセス可能性を最小限にする」

 

情報のカプセル化オブジェクト指向言語の大きなテーマとなっています。これはプライバシー情報を考える上でも、建築言語であった「オブジェクト指向」がソフトウェア開発に有効だったように、使える可能性があるものだと考えています。

 

ソフトウェア開発における情報のスコープの問題を通して、我々の日常の情報の扱いをみつめてみたいと思います。

証拠は誰のものか?

当事者主義。

 

裁判は弁護側と検察で争われるわけですが、無罪、有罪に結びつくような情報は、当事者主義で扱われている、という話が以下のページで紹介されています。

 

証拠は誰のものか

 

裁判は「推定無罪」利益原則が基本である、と通常は認識されているのではないでしょうか。少なくても私は根拠なくそう思っています。根拠なくそう思っているというのは、法の精神や日本の裁判を盲目的に信用しているところがあるからです。これは自分の今の生活がおおよそ裁判の当事者である必要がない状態である事と、性善説的に裁判を取り行う環境を信じていること、またある程度治安は守られ、自分たちは平和に生活している現状を保守しようとしていることに起因していると思われます。

 

感情を持った人間が、事実をただ列挙していく、というのはとても難しいことです。弁護側は無罪を主張する時に「怪しまれるような証拠」をあえて出すような事はしないでしょうし、検察は逆にあいまいさを表してしまう証拠は出したくないでしょう。

 

「結論ありき」で論理を組み立てるのはとても危険なことです。結論に都合のよい情報を集め、都合の悪い情報は語らず、あいまいなものは都合よく改変してしまう。論文であったり、製品開発であったり、世間話でさえもそういう誘惑にかられる話はあります。ページの内容を見ると、直感的には冤罪を生むような検察のやり方が悪に感じます。しかし「犯罪者を利することになる」という側面があるのも事実でしょう。検察が証拠は不十分ではあるけれど、複数の面から考えて犯人である可能性は高い、という判断が出来る時に、「推定無罪」を基本に考えることが出来るものだろうか。

 

現在の状況では裁判で有罪判決が出る前に、逮捕の段階でニュースは流れ本名は開示、その人の積み上げて生きた日常は破壊されます。なので裁判は「推定無罪」よりも「当事者主義」という言葉がより現実的な言葉に思えます。であれば「フェアな当事者主義」を目指すのが一つではないでしょうか。

 

弁護側、検察それぞれが得た情報は公開する。同じ土俵の上で裁判を行う。米では州によって「証拠」は全てデジタル化し共有する、という形になっているようです。情報がデジタル化されるとなれば「情報セキュリティ」「プライバシー」を配慮する必要が出てきます。「証拠」はどこにどのように管理され保管されることになるのか。共有の方法はどのようになされるのか。そこにはセンシティブな情報が多く含まれることになるでしょうし、関係者の情報も巻き込んでいくいくになります。

 

また、ネットワーク上の行動も「証拠」となる現在です。掲示板やブログ、メールやSNSなどプロバイダやビッグデータと言った場所の情報は「証拠」となるはずですが、それらはいったい誰のものなのか。弁護側と検察の間に「証拠」に関する利害関係者が複数出てくることになります。内部統制としての証跡管理が、裁判に必要なデータを持つ時には企業も大きな利害関係者となることもあるでしょう。

 

事件があった時に、証拠は誰のものか、という問いかけと環境づくりは、冤罪をなくすためでもあり、同時に犯罪者を利することのないようにしていく必要があります。

Head First C 2章

今、C言語を学ぶ理由は幾つかあると思いますが、メモリ制御を考えた時にはやはりC言語を選択することになります。

 

ポインタやアドレス指定は、C言語習得の壁であると、ほとんどの教則的な書籍に書かれています。しかしC言語の特徴がメモリ制御であるならば、この話はまったく別が本質です。

 

ポインタやアドレス指定で、メモリ制御を行える言語がCである。

 

2章という早い段階でポインタに踏み込む内容になるのは当然で、それを使用してどうプログラミングしていくか、というのがC言語を学ぶ内容になるはずだと思うのです。

 

なので、本当に Head First は満を持して感を強く感じてるわけです。