初心者のためのC#プログラミング本格入門58 - 類似した処理から考えよう

　この記事は、初心者のためのC#プログラミング本格入門57の続きです。前回は、オブジェクトコンポジションのオブジェクトを作る際に考える事を解説しました。今回は、初心者がプログラムを作る際の思考法について解説します。
　「複数の式を個々の式へと分割する。 」について考えてみましょう。初心者の方はいきなりプログラムが思い浮かばないかもしれません。初心者用のプログラミング本を読んだのはいいが、自分が欲しいプログラムが思い浮かばない人が沢山いるそうです。
　私の場合は、10年以上システムを開発しているので、お客様の言葉を聞けばその場で思いつきます。おそらく、他のプロの方もそうでしょう。初心者の方はこういったプロの技は真似できないと感じるでしょうが、それは特別な才能ではないと思います。慣れの問題でしょう。
　プロと初心者の違いは何よりも経験の量です。それを補うには、初めの内は「似たプログラムを探しそれを元に改良する」行為を繰り返すと、自然とプログラム言語が日本語と同じように使いこなせるようになります。C#はプログラミング言語なので、使っているうちに自然と日本語と同様に慣れてくるのです。心配要りません。
　「複数の式を個々の式へと分割する。 」と似た処理をこの連載の中で解説しています。そのプログラムを元に考えれば、初心者であってもプログラムが作れます。読み進める前に、この連載を通じて作ってきたプログラムから、類似したプログラムを探してみましょう。
　答えは「式から数値を取り出す」処理です。1つの文字列から複数の式を取り出す行為は、1つの文字列から複数の数値を取り出す処理と酷似しています。その処理をしているのはAnalyzerオブジェクトのAddValuesメソッドです。

public void AddValues( string inputValues )
{
    bool loopFlag = true;
    string tmp = inputValues;
    do
    {
        System.Tuple<bool, float, string> value = TryValue( tmp );
        loopFlag = value.Item1;
        if ( loopFlag == true )
        {
            this.values.Add( value.Item2 );
            tmp = value.Item3;
        }
    } while ( loopFlag == true );
}

このプログラムを元に、複数の式を個々の式へと分割するDivisionAnalyzerメソッドを作りましょう。

private void DivisionAnalyzer( string inputValue )
{
    bool loopFlag = true;
    string tmp = inputValue;
    do
    {
        System.Tuple<bool, string, string> value = CutExpression( tmp );
        loopFlag = value.Item1;
        Analyzer analyzer = new Analyzer();
        analyzer.AnalyzeExpression( value.Item3 );
        this.analyzers.Add( analyzer );
        tmp = value.Item2;
    } while ( loopFlag == true );
}

DivisionAnalyzerメソッドは少し長くなっていますが、大まかな考えはAddValueメソッドと同じです。違いは、CutExpressionメソッドを使って式を分割している点と、個々の式に対応するAnalyzerオブジェクトを初期化して格納している点です。
　この様に類似したものを探す能力を鍛えるのが、プログラミング上達のポイントです。堅苦しい言葉で言えば、物事を抽象化して考える力です。初心者が陥りやすい落とし穴は、文法主義と暗記主義です。
　文法を暗記してもプログラミングはできません。また、プログラミング本を読んで「サンプルをそのまま暗記」してもプログラミングをする力は身につきません。文法もサンプルプログラムの暗記もある程度必要ですが、何かを実現する創造力は反復して磨く必要があります。
　どんな凄い人でも初心者の時代があります。それを才能という言葉で逃げるのは簡単です。ですが、凄い人は才能の一言で済ませられない地道な努力をしています。努力が出来るか否かが明暗を分けています。貴方も磨けば宝石になるかもしれません。磨いてみないと分かりません。
　未来のプロがこの記事を読んでいる事を願って今回はこれで終わります。実はこのプログラム、このままでは正常に動作しません。次回、プログラムを改良をします。お楽しみに。

システム開発における情報セキュリティ14

　この記事は、システム開発における情報セキュリティ13の続きです。前回は、セキュリティポリシーについて解説しました。今回は、セキュリティ技術の学び方について解説します。
　連載を通じてシステム開発で情報セキュリティをどう取り扱うべきなのかを、駆け足で解説してきました。今までの記事を読めば、情報セキュリティは、情報技術全般はもちろんのこと人間心理にまで及ぶ、非常に範囲が広いものである事が分かって頂けると思います。
　この範囲が広い情報セキュリティを、どの様に学ぶのか気になる方が多いと思います。そこで今回は、連載の締めとして情報セキュリティの学習方法について書きます。
　残念ながら、情報セキュリティの学習方法にも銀の弾丸は存在しません。一応情報セキュリティという分野は存在しますが、結局のところOS・コンパイラ・ネットワーク・データベースといった情報技術に関する知識全般と、人間心理と行動を深く広く学ばなければなりません。かくいう私も、情報セキュリティを意識して学んだわけではなく、情報技術全般を学び、仕事を通じ実践と分析を続けているだけです。
　健全な好奇心があれば自ずと情報技術全般を深く学びますし、仕事をしていれば組織や人間心理が分かってきます。技術者として人生経験を積むしかないと言えます。ですから何よりも大切なのは、小手先だけの方法論ではなく、心の持ち方だと言えます。
　この世に当たり前な事や絶対に保障されているものは存在せず、あらゆる知識を学び、それら知識の裏を読む姿勢が大事です。その知識は、所詮人間が使うものであり、人間は不完全な生き物である事実を受け入れれば、自ずとクラッカーの手口が分かり、その対策方法も考えつきます。
　すなわち、あらゆる知識を吸収しつつ、絶対的な真実や完璧なものは存在しないという前提の下、常に知識の裏を読み、人間の弱みを受け入れ、その理論の不完全さと弱みを如何にカバーするのかを日常的に考え続けるのが、情報セキュリティの学び方だという事です。
　この連載はひとまずこれで終わりです。ですが、情報セキュリティは語るべき事が無限にあります。たとえば、セキュリティポリシー１つとっても1冊の本が書けます。また、人が人である限り、あらゆるシステムに虚弱性があります。情報セキュリティは人間にとって永遠の課題なのです。
　機会があれば、セキュリティポリシーなどの1つの題材に特化した記事をかきます。終わり。

実践的オブジェクト指向設計入門3

　この記事は、実践的オブジェクト指向設計入門2の続きです。前回は、システムの分割について解説しました。今回は、並列性の識別について解説します。
　システムの分割が終わったら、並列性の識別を行います。分析段階では現実の世界が本質的に並列なので、ほぼ全てのオブジェクトは並列で動作しますが、システムとして実現すると物理的な制約があります。システム設計の段階では、それらの制約を考慮し、システムでどの様に並列性を実現するか考えなくてはなりません。
　物理的な制約とは、ハードウェアとソフトウェアの両面から生じるものです。具体的には、マルチコアプロセッサをどれだけ用意できるのか、サーバーのスペックはどうするのか、ネットワーク構成は・・・などといった予算とハードウェアの構成により実現できるシステムの構成が変わります。また、処理の相互依存、業務手順・・・などといったソフトなものから生じる制約もあります。
　並列性を大別すると2つのタイプがあります。本質的な並列と非本質的な並列です。本質的な並列性を持つシステムは互いに独立しており、別のハードウェアを使用し同時に処理ができます。一方、非本質的な並列性をもつシステムは、処理手順に相互作用がある状態を指します。
　個々のサブシステムがどの様に相互依存しているのかを考える、もしくはどの様に実現するのかにより、並列性の識別を行う事が出来ます。ただし、サブシステムだけを考慮しても不十分であり、動的モデルを参照しオブジェクト間の相互依存性に注目する必要があります。状態遷移図が役に立ちます。
　オブジェクトとサブシステムを考慮する事により大半の並列性は識別できますが、最後の仕上げとしてタスク間の並列性を考えます。タスクレベルでみると、相互依存している処理があります。これらの関係を見極めないと並列性を見誤ります。タスクの並列性を考える際にはユースケースが役に立ちます。
　まとめると並列性には、オブジェクト単位（小）、サブシステム単位（中）、タスク単位（大）で存在するという事です。これらの並列性は、システムの物理構成とソフトウェア構成が制約となります。
　OMTでは以上の様になっておりますが、私個人の経験から言うと、システム処理をトランザクション処理として捉える視点が必要だと思います。実際のシステムはACID特性を保証しなくてはなりません。また、並列性とトランザクション処理は密接に関係しており、トランザクション処理を考えない事には、並列的かつ実用的なシステムを設計できません。
　並列性の識別の解説はこれで終わりです。次回は次の段階の解説を行います。

ネタつつき122 - 楽をする為に苦労をする

　私はシステム屋を営んでおり、学習をする毎日を送っています。空いている時間を全て学習につぎ込むその姿を見て、よく「何故そこまで苦労（もしくは努力）をするのか」と尋ねられます。その答えが「楽をする為」です。それを言うと笑われますが私は本気です。その意味が、一部のIT業界の人には理解できないようで、他の業種の人は全然理解できないようです。
　他の業界の人に分かりやすいように「楽をする」と言っておりますが、より正確に言うと「仕事の処理効率をあげるために学習をしている」です。仕事の効率が良くなれば仕事が早く終わり、自由に使える時間が増えます。人間は基本的に怠惰な生き物だという説があり、私も例外ではありません。総合的な労力を減らすために学習という労力をしているのです。
　こういった事を言うと、多くの人が「私は勉強が嫌いだから・・・」と言いますが私も勉強は嫌いです。「勉めを強いている」という感じがして嫌です。余程マゾな人でない限り、他者から苦痛を強いられるのは嫌いだとい感覚は、人として当たり前の感覚ではないでしょうか？
　私は情報処理を溺愛しており、楽しいから如何なる労力も苦労だと感じません。漫画を読むのが好きな人と同様の感覚で専門書を読んでいます。高度な専門書を読むと自然に笑みが浮かびます。ですから、あらゆる学習が苦になりません。知を堪能して味わっています。
　かく言うと、「じゃあ、何故、学校の勉強は嫌いなのか？」と質問されますが、学校の勉強は学問ではないからです。受験というシステムのために暗記させているだけなので、学問を教えていると感じなかったからです。私は数学や科学も好きなので、普通に考えれば学校の授業が好きな筈なのですが、お受験のための暗記は学問に対する冒涜だとしか思えないからです。
　何故ならば、学問とは人間の生活を楽にする為に考えだされたものであり、「楽をする為に」という観点がなければ成り立ちません。学問は「試験に出るから暗記する」のではなく、人間の思考ツールであり、道具として使えなければ何の意味もありません。その様なものを詰め込むのは苦痛以外のなにものでもありません。
　私が思うに、恐らく不毛な暗記教育が「学習は苦痛だ」と感じる元凶になっているのではないでしょうか？改めて考えると、日本の社会は「効率」や「楽」を悪だと捉え、苦痛を伴うのが仕事だと考えている節があります。「楽をする」という事を悪と捉え、非効率的な行為を肯定しているからブラックな会社が氾濫し、理不尽な行為がまかり通るのでしょう。
　私は子供から「なぜ勉強するの？」と聞かれれば、「大きな目で見て楽が出来るから」と答えると良いのではないかと思います。「楽」を否定すると「楽しく」ありません。正当な「楽」を肯定する事から全ては始まると私は考えています。楽があるから苦も受け入れられるのです。

初心者のためのC#プログラミング本格入門57 - オブジェクトコンポジションを行う時の思考

　この記事は、初心者のためのC#プログラミング本格入門56の続きです。前回は、テストプロジェクトの作り方を解説しました。今回は、オブジェクトコンポジションのオブジェクトを作る際に考える事を解説します。
　コンポジションをするオブジェクトを作る際に重要なのは、何のオブジェクトで構成されているのかを考える事です。つまり、オブジェクトの構成要素を考えなくてはなりません。オブジェクトの構成要素は、インタフェースと仕様から考えます。
　第54回「コンポジション（合成）を行うオブジェクトの作り方」にてインタフェースと仕様の概要を決定しました。これで、オブジェクトのインタフェース（ひとまず外見と考えて下さい）は一応できています。このインタフェースを元に作り込んでいくと、自ずとオブジェクトの構成要素が見えてきます。
　54回の「自由に指定した計算式を計算するプログラム」のMainメソッドを見ると、コンポジションをしているMultiAnalyzerオブジェクトは、AnalyzeExpressionメソッドを呼び出し、計算式の解析を行う必要がある事が分かります。計算式はどの様にして解析するのでしょうか？
　「 1 + 2 」の様な単一の式を解析する方法は既に、AnalyzeオブジェクトのAnalyzeExpressionメソッドが行えます。従って、複数の計算式を分割し、個々のAnalyzeオブジェクトに計算式を解析してもらえば実現できます。初心者の方はその手順を私と一緒に書き出してみましょう。

【AnalyzeExpressionメソッドの大まかな手順】
1. 複数の式を個々の式へと分割する。
2. 分割した式の数だけAnalyzeオブジェクトのインスタンスを作る。
3. 個々の式の解析はAnalyzeオブジェクトのAnalyzeExpressionメソッドが行う。

書き出してみて意外と簡単だと感じた人が多いでしょう。コンポジションの真価はこの点にあります。細かい処理は他のオブジェクトに任せて楽をするためにコンポジションを行います。
　MultiAnalyzerオブジェクトの作り方に話を戻します。「AnalyzeExpressionメソッドの大まかな手順」で、複数のAnalyzeオブジェクトがいる事が分かりましたので、複数のAnalyzeオブジェクトを格納するオブジェクトを用意します。

class MultiAnalyzer
{
    private System.Collections.Generic.List<Analyzer> analyzers;
    public MultiAnalyzer()
    {
        this.analyzers = new System.Collections.Generic.List();
    }
    
    //他は省略
}

コンストラクタで用意している点に注目して下さい。コンストラクタは、オブジェクトを使う為の準備を行うために定義します。ですから、コンストラクタで必要なオブジェクトのインスタンスを生成します。
　長くなったので今回はこれで終わりです。