真正性をつつく0 - 真正性を保証するのは意外と難しい

　連載（システム開発における情報セキュリティ）の方で細かい事を書くと読み難いと思ったので、個別に情報セキュリティネタを書きます。今回のお題は「真正性」です。真正性を簡潔に言うと、情報を要求するオブジェクトが本当に主張通りのオブジェクトなのかを保証する特性です。真正性を保証する為の行動の例としては、本人確認などがあげられます。文章にすると簡単そうに見えますが、システムを開発する方も運営する方も大変です。
　たとえばその人が営業部長の山田太郎（仮名）を名乗っているとします。この人は本当に営業部長の山田太郎なのでしょうか？多くの人は「車の免許証を見せてもらえばいい」と思うでしょうが、免許証が偽造されたものかどうか見抜けるでしょうか？また、「車の免許証を持っていないが緊急の用件なんだ。ちんたらしないで早く通したまえ。もし、君のせいでなにかあったら責任を取れるのか！」と一喝されればどうしますか？
　こうした簡単な例でもセキュリティ対策は大変です。山田太郎部長が本当に免許証を持っていなければどうやって認証するのでしょうか？認証するにしても本当に緊急かつ重要な要件ならばどうしますか？詳細な手順を作ってもバイトの人が面倒を避けて通してしまうかもしれません。特に他社の部長である場合、どうやって認証しますか？・・・真正性を真面目に考えると、簡単な例でも色々考えなくてはならない事が分かってもらえると思います。
　今度は情報システムらしい例を考えます。社内の端末からアクセスする人が、本当にその人なのかをどうやって認証しますか？社内の端末からアクセスされていても安心できません。その端末を使っている人が、本当にその端末を使うべき人なのかわからないからです。他人が端末の持ち主に罪をかぶせるために、なりすましているかもしれません。
　この2つの事例から分かる事は、人間だけがチェックしても駄目（人間は騙される）、コンピュータだけが判断しても駄目（抽象的な事が苦手）だという事です。人と情報システムの連携でようやく真正性を保証できます。ただし、100％の真正性は不可能だという事を忘れてはなりません。どの様な技術でもそれを破る方法を犯罪者は見つけ出します。また、完璧にしようとするとコストがかかり過ぎますし、厳重すぎる情報セキュリティは仕事に支障を及ぼします。
　以上のように真正性を保証するのは大変な事です。この連載では真正性について書きます。

変化を否定する人はオブジェクト指向を理解していない

　私はオブジェクト指向が十分に普及していないと感じています。最近のプログラミング言語の多くが、オブジェクト指向をサポートしているのにも関わらず、オブジェクト指向を理解していない人が多い事が不思議でなりません。この状態は好ましくありませんので、オブジェクト指向の考えを広めるためのこの記事を書こうと考えました。
　オブジェクト指向は、文法を覚えたら理解したと言える程単純なものではありません。プログラミング言語が備える、オブジェクト指向に関する文法は、あくまでも実現するための手段であり、オブジェクト指向そのものではありません。オブジェクト指向は、その考え方を理解して初めて習得したと言えるものです。従って、オブジェクト指向がどの様な概念なのかを深く理解しなくては、マスターしていない事になります。残念な事に日本のIT業界の仕事のやり方を見ると、オブジェクト指向の考えを理解していないと思えてなりません。
　私がそう感じる理由は、日本には変化を頑なに否定し、変化に拒否反応を示す人が多いからです。新しいものを否定し、何でも反対を唱えるその姿勢には、オブジェクト指向を理解しているとは言えません。何故ならば、オブジェクト指向は変化を前提として考えだされた概念だからです。
　オブジェクト指向の前は、構造化プログラミングの考えが浸透していました。予め仕様を完全に決定し、ウォーターフォールに開発を進めていました。このやり方は、変化が少なく、プロジェクトの規模が小さいときには上手くいきました。しかしながら、プロジェクトの複雑化に伴いその考えは脆くも崩れ去り、ソフトウェア危機が唱えられるまでになりました。
　その状況に対応するために考え出されたのが、オブジェクト指向プログラミングです。オブジェクト指向は、今までの問題を改善するべく、データと振る舞いを一体化し、プログラムを局所化し、プログラムに拡張性をもたらしました。構造化プログラミングは、あらかじめ仕様を完全なものにするのが前提でしたが、オブジェクト指向プログラミングではその前提がありません。小さなプログラムを徐々に組み立てて、ソフトウェアおよびシステムを拡張させながら完成させます。
　オブジェクト指向の根底にあるのは、変化に如何に対応するのかです。変化に対応するために、プログラムの影響範囲を狭め、プログラムの拡張性を重視したのです。ですから、変化が早い現実から目をそらし、変化を拒み、無意味な管理をする保守的な態度は、オブジェクト指向の考えを体現しているとは言えません。
　人間は生きているから活動し、時がたつにつれて全てが変化します。その現実を無視し変化を否定するという事は、世の理に背を向けている事になります。人は生き、時は流れるので、変化が起こるのは当たり前の現象であり、それを踏まえたオブジェクト指向の考えはとても自然です。無理して自然の流れに逆らうよりも、現実を直視して自然を受け止め、オブジェクト指向の考えを実践しましょう。
　それこそが技術者として、いえ人そして自然な生き方だと私は思います。

初心者のためのC#プログラミング本格入門62 - エラーテストもしっかり行おう

　この記事は、初心者のためのC#プログラミング本格入門61 - テストを使って思考を整理整頓しようの続きです。前回は、テストファーストに考え方について少し解説しました。今回はテストについて解説します。
　前回で式の有効性を判定できるようになりましたが、それだけではプログラムが正しく作られているとは言い切れません。何故ならば、現在Successがtrueの時をテストしていますが、エラーであるfalseの時がテストされていないからです。より簡単に言うと、偶然Successプロパティの値がtrueなのかもしれません。
　プログラムの正しさをより深く確かめるためにエラー処理が正しく行われているのかをチェックするテストプログラムを作ります。

//間違った式が指定された場合の解析処理をテストする
public void ErrorExpressionCheck()
{
    string value = "1 ; 2";
    this.target.AnalyzeExpression( value );
    if ( target.Success == true )
    {
        System.Console.WriteLine( 
            "誤った式を解析できていません。" );
    }
}

　テストプログラムを作ったら、メインプログラムから呼び出します。

class TestProgram
{
    static void Main()
    {
        MultiAnalyzerTest multiTests = 
            new MultiAnalyzerTest();
        multiTests.AnalyzeSimpleExpression();
        multiTests.ErrorExpressionCheck();
    }
}

このテストを実行して何のエラーメッセージも表示されなかったら、ひとまず簡単な式に対するエラーチェックは、正しく行われていると判断できます。
　人間はどうしても、正しい事例ばかりを考えてしまいがちですが、正しくない事例も考えなくてはなりません。1つのテストを考えたら、その反対のテストを考えるという風に、色々なテストを作って実行しましょう。そうすれば、バグを減らせます。

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

　この記事は、実践的オブジェクト指向設計入門4の続きです。前回は、ハードウェア構成の決定について解説しました。今回は、データストアの管理について解説します。
　システムは必ずデータを取り扱います。従ってシステム設計では、どの様にデータを扱うのかを決定しなくてはなりません。データの「扱い」については色々ありますが、オブジェクト指向方法論OMTでは、インタフェースを定義し、サブシステム間の分割点をはっきりさせる目的でデータストアの管理について検討します。
　オブジェクト指向方法論OMTでのデータストアとは、メモリか2次記憶装置に実装されたデータ構造、ファイル、データベースの組み合わせです。これらの組み合わせには、コスト、アクセス時間、容量、信頼性など様々なトレードオフが存在します。それらトレードオフを考慮しつつ、システムのデータストアを決定します。
　オブジェクト指向方法論OMTではこれぐらいの扱いしかありませんが、実務ではシステムに如何なるトランザクションがあるのかを明確化し、それらのACIDを保証するのかを決定しなくてはなりません。また、セキュリティ対策、データの管理方法、バックアップ体制・・・など検討するべき事は山ほどあります。
　システムに於いてデータは非常に重要です。オブジェクト指向方法論OMTではあまり言及されていませんが、データをシステムのインタフェースとして考えるのはもちろんの事、様々な角度からデータの取り扱いについて考え抜かねばなりません。データについての様々な検討事項は、ネットワークの構成にも影響を与える事に注意が必要です。
　業務系のシステムに必要とされるデータ量は増え続けており、データベースサーバーで管理するのが普通になっております。そのサーバーを如何に管理するのかは、ネットワークしいてはハードウェアの構成に関わってくる事項です。システムの成否は、データの取り扱いで決まると言っても過言ではありません。データストアの決定は、広い視野を持ち漏れがないように行いましょう。

初心者のためのC#プログラミング本格入門61 - テストを使って思考を整理整頓しよう

　この記事は初心者のためのC#プログラミング本格入門60の続きです。前回は、テスト用のプログラムを作り、新しいプログラムを徐々に完成させる手法を解説しました。今回は、エラーを出しつつ前に進む事について書きます。
　前回の最後で「エラーを出す方がいい」という旨を書きました。それは、実務的な観点から言える事です。プログラミングをする時、人は色々な事を考えます。その行為は混乱をもたらします。特に初心者の頃はそうです。ならばさっさとテストプログラム実行して結果を確認する方が早いと言えます。前回の例がこれに該当します。今現在正しく式が解析できるのかどうかは実行してみれば分かります。結果は「解析出来ない」です。その結果を確認すれば前に進めます。もし、プログラムを見て悩んでいるだけならば、その結論を出すのに時間がかかるかもしれません。
　この考えをさらに発展させ、これから実現するプログラムを予め作ると、プログラミングが早くできるようになります。予め作っているわけですから、エラーが出るのは当たり前です。従って、エラーを出しつつプログラミングを進めるという事になります。この様な考え方をテストファーストと呼びます。テストファーストの概念はそれだけではないのですが、一度に全てを理解できませんので少しずつ解説していきます。
　サンプルプログラムの作成に話しを戻します。「解析が出来ていない」という事柄をよく考えてみましょう。解析の成功有無はどうやって判定していますか？それを考えれば自ずと答えは出ます。

//簡単な式が指定された場合の解析処理をテストする
public void AnalyzeSimpleExpression()
{
    string value = "1 + 2";
    this.target.AnalyzeExpression( value );
    if ( target.Success == false )
    {
        System.Console.WriteLine(
            "簡単な式が解析できていません。" );
    }
}

答えは「Successプロパティの値がtrueの時、解析は成功していると判断している。」です。つまり、Successプロパティをtrueに設定すればよいのです。
　それを念頭に置き、改めて解析処理を確認しましょう。

public void AnalyzeExpression( string inputValue )
{
    //式を分割
    DivisionAnalyzer( inputValue );
}

確認すると式を分解する処理しかしていない事が分かります。という事は・・・

public void AnalyzeExpression( string inputValue )
{
    //式を分割
    DivisionAnalyzer( inputValue );

    //式の有効性をチェック
    ValidityExpression();
}

以上のように式の有効性をチェックすれば、解析の成功有無が正しく判定できるようになります。では、何を持って式が有効とするのでしょうか？その答えは、実のところ答えは既に出ています。
　オブジェクトのコンポジションをして、細かい処理を別のオブジェクトに任しているのですから、式の有効性はAnalyzerに聞けば分かります。早速、ValidityExpressionメソッドを作ってみましょう。

private void ValidityExpression()
{
    foreach ( Analyzer obj in this.analyzers )
    {
        if ( obj.Success == false )
        {
            this.success = false;
            return;
        }
    }
    this.success = true;
}

Analyzerオブジェクトは複数あるので、全てのAnalyzerオブジェクトに指定された式の有効性を聞いています。それだけでは面白くないので新しい文法foreachループを使っています。
　今までforループ、whileループ、do-whileループの計3つのループを紹介してきました。いずれのループを使っても実現できるのですが、コレクション系のオブジェクトを使ってループ処理をする時は、foreachループを使った方が簡潔に表現できます。コレクション系のオブジェクトを使って処理をする時は、foreachループを使用しましょう。
　以上で今回は終わりです。テストファーストをすると思考が整理されます。その事が少しでも味わってもらえればいいなと考えています。今回は思考の整理が実感できなかったという人も、サンプルプログラムを複雑化していくのでいずれ味わえると思います。次回はさらに話しを前に進めます。お楽しみに。

初心者のためのC#プログラミング本格入門60 - テストと共に歩もう

　この記事は、初心者のためのC#プログラミング本格入門59の続きです。初心者が類似したプログラムを改良していく方法について解説しました。今回は、テスト用のプログラムを作り、新しいプログラムを徐々に完成させる手法を解説します。
　前回は類似したプログラムを元に「式を分割するプログラム」をある程度作りました。ですが、このプログラムはまだ完成していません。新しいプログラムを完成させるには、テストしながら作り込むのが一番です。実は既にそのための準備が整っています。56回で用意したテストプロジェクトを有効活用します。
　先ずはテストプログラムを「スタートアップ プロジェクト」に設定しましょう。やり方は簡単です。ソリューションエクスプローラでFirstProgramTestプロジェクトを右クリックしてポップアップメニュを表示します。表示したら「スタートアップ プロジェクトに設定」という項目があるのでそこで左クリックします。そうすれば、直ぐにテストプロジェクトを起動できるようになります。
　次に「MultiAnalyzerTest」という名前のクラスを追加します。MultiAnalyzerTestクラス用のファイルを用意できたら以下のプログラムをそこに書いて下さい。

class MultiAnalyzerTest
{
    private MultiAnalyzer target;
    public MultiAnalyzerTest()
    {
        this.target = new MultiAnalyzer();
    }
}

今度はテスト用プロジェクトにあるProgram.csファイルの内容を以下のプログラムに変えて下さい。もしProgram.csファイルがなければ追加しておきましょう。

class TestProgram
{
    static void Main()
    {
        MultiAnalyzerTest multiTests = new MultiAnalyzerTest();
    }
}

これで準備万端です。MultiAnalyzerオブジェクトのテストを行うプログラムをどんどん書いていきます。
　簡単なテストから作っていきます。初めにつくるテストプログラムは、「 1 + 2 の式が正しく解析できているのかチェック」する内容のテスト用プログラムです。

class MultiAnalyzerTest
{
    //他は省略

    //簡単な式が指定された場合の解析処理をテストする
    public void AnalyzeSimpleExpression()
    {
        string value = "1 + 2";
        this.target.AnalyzeExpression( value );
        if ( target.Success == false )
        {
            System.Console.WriteLine(
                "簡単な式が解析できていません。" );
        }
    }
}

テストプログラムはメソッドとして用意しておきます。テストはこのメソッドを呼び出す形で実施します。

class TestProgram
{
    static void Main()
    {
        MultiAnalyzerTest multiTests = new MultiAnalyzerTest();
        multiTests.AnalyzeSimpleExpression();
    }
}

「デバッグなしで開始」でこのテストプロジェクトを実行してみましょう。何も表示されなかった筈です。何故かと言いますと、DivisionAnalyzerメソッドが呼び出されていないからです。MultiAnalyzerオブジェクトのAnalyzeExpressionメソッド内にDivisionAnalyzerメソッドを呼び出すプログラムを追加し、再度テストプロジェクトを実行してみましょう。今度はエラーメッセージが表示されます。
　簡単な式すら解析できていない事に驚いた人が多いでしょう。ですが初めはこれでいいのです。「エラー」というとショックを受ける初心者が多いと思いますが、エラーを出しながらプログラミングをした方が逆に上手くいきます。次回その理由について解説します。

ユニットテストとアサーションをどう扱うのか？

　事前条件、事後条件、不変表明をチェックするためにアサーションを使用する技法が一般化しています。これは防御的プログラミング／攻撃的プログラミングの一種であり、趣味と実務の違いを如実に表していると思います。というのも、初心者用のプログラミング本ではかかれないものの、多くのプロが実務で使用しているからです。初心者用のプログラミング本で書かれていないので、初心者やアマチュアはアサーションの重要性が分からないと思いますが、実務でアサーションの使用が一般化しており、それは非常に重要な技法だと考えて下さい。
　初心者のために簡単に説明すると、バグを減らすために使用する技法です。大体こんな感じでアサーションを使用します。

#include <assert.h>
int foo( int value ) 
{
    int result;

    //事前条件
    //引数は0以上でなければならない
    assert( value >= 0 );
    
    //何らかの処理をして戻り値を導出する
    result = value;

    //事後条件
    //返す値は-1以上でなければならない
    assert( result >= -1 );

    return result;
}

int main()
{
    //制約違反！
    //foo( -10 );

    //OK
    foo( 0 );
    return 0;
}

これはC言語を使った非常に簡単な例です。実務でこの様な関数は使用しませんが、雰囲気は伝わると思います。
　テストにはもうひとつ、有名かつ頻繁に利用される技法があります。それは、ユニットテストです。大半の人がユニットテストを書いている事でしょう。特にJavaプログラマは殆どの人がJUnitを使用していると思います。
　ここで一つの疑問が生じます。アサーションとユニットテストをどのように扱うのかです。アサーションを使用した技法は一見、ユニットテストと相性が合いません。事前条件、事後条件、不変表明の3つのチェックをソースに一切書かず、テストプログラムに記述すれば可読性が向上して良いと考える人がいても当然です。特にJavaや.NET系の言語は例外処理を使用する事もあり、アサーションをどのように使用するのか悩む人が多いでしょう。
　私も悩んだのですが、今は両方の技法を使用した方がいいと結論付けています。その理由は設計意図とテストプログラムは別種のものだからです。プログラムに設計の意図を書くのと、テストプログラムを書くのは別の意味を持っている行為です。
　まず、アサーションの方ですが、これは設計の意図を示すものです。ただ単にエラーが発見できればいいというものではなく、設計者の意図を示すのが本意です。関数もしくはメソッドがどういった制約を持つのかは、明らかに設計に属する事柄なのです。
　一方、テストプログラムはバグの撲滅が本意です。テストプログラムを書くと、自然とオブジェクトデザインが明らかになったりしますが、それは副次的な効果であり、テストはバグをなくすために行う行為です。むろん下手なインタフェースはバグの元であり、テストとオブジェクトデザインは無関ではありませんが、だからと言って両方を詰め込むのは頂けません。集団作業で本来の意味とは違うものを詰め込むと、コミュニケーションを阻害する恐れが高いです。コミュニケーションに支障が生じると、バグの発生件数が多くなるのは言うまでもないでしょう。
　以上の考えから私は、設計の意図とテストを明確に分離するために、2つの技法を併用しています。ただし、プリプロセッサを併用しなくてはなりません。それが少し美しくないのですが、アサーションを使用した報告機能を用意しておくと、万が一運用時にバグが生じても解決が速くなるので利点があります。運用時に1つのバグもないのが理想ですが、絶対安全神話を唱えずに、もしバグがあっても解決できるように準備しておくのが当然だと言えるでしょう。
　この話題に限らず、分離性は大事だと時だと私は考えております。物事を分離しておく方が明瞭かつ単純に保てます。先の事を考えるのであれば、明瞭であるべきだというのが私の持論なのです。この記事が誰かのお役にたてば幸いです。

※注意:.NETの場合はアサーションではなくコードコントラクトを使用するべきです。

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

　この記事は、実践的オブジェクト指向設計入門3の続きです。前回は、並列性の識別について解説しました。今回は次の段階である、ハードウェア構成の決定について解説します。
　システムはハードウェアがないと実現できません。そこで、並列性の識別が終わった後、サブシステムをどの様にハードウェアへ割り当てるのかについて考えます。システム単位で考えても、必要とするハードウェア資源を考えにくいので、サブシステムと並列性が分かった後に考えるのです。
　最初に考える事柄は必要な性能です。ハードウェアを決めると言っても、具体性がなければ、どの様にハードウェアを構成すのか決定できません。従って、ハードウェア構成を決めるのに当たって、最初に要求される性能を明らかにします。つまり、要求を数値化するという事です。
　クライアントの要求はえてして曖昧な部分があります。しかしながら、要求分析をしっかりと行えば、自ずと必要となる要求が見えてきます。要求が分かったら、開発者が具体値を決定しなくてはなりません。要求を数値化しておかないと、システムに必要な性能が分かりませんし、一般的に酷いパフォーマンスはバグと看做されます。また、数値化する事によりシステムのあるべき姿が見えてきます。
　ハードウェア構成はネットワーク単位、および個々の端末レベルまで考えます。ネットワーク単位では、サブシステムをどの様に実現するのかを広い視野で考えます。具体的には、物理装置を接続するトポロジ―、接続チャネルの形式、通信プロトコル等を決定します。そして端末レベルでは、主に必要なプロセッサの数と割り当てるタスクを決定します。
　また、ソフトウェアとハードウェアのトレードオフについても考えなくてはなりません。ハードウェアは、融通がきかないものの高度に最適化されたソフトウェアと看做す事が出来ます。たとえば、ルーターの機能をPCとソフトウェアで実現することも可能ですし、専用のハードウェアで実現することも可能です。システム設計段階でそういった様々なトレードオフを決定します。
　ハードウェアの構成が決まったら次の段階に進みます。

ネタつつき123 - 理想のプログラミング言語を追い求めて

　私はシステム開発をする時、お客様と会話をしながら、分析／設計／実装／運用などを並列実行して思考しています。その時の頭の中には、システムの情報集合体が沢山存在しており、それと1対1で対応するプログラミング言語は、今のところ存在しません。ですから、実装の際には既存のプログラミング言語に落とし込む作業が必要になります。ある種の非効率さがそこに存在します。
　既存のプログラミング言語にマッピングする非効率さを解消し、さらなる生産力を得るために、自分の頭の中にある情報集合体をそのまま実装できるプログラミング言語が欲しいと考えた事があります。程度の差こそあれ、誰しも「理想のプログラミング言語」が欲しいと考えた事があるのではないでしょうか？
　この理想のプログラミング言語は非常に複雑なものです。宣言型／並列型／オブジェクト指向／関数型／論理型などを全て兼ねそろえたものでなくてはなりません。私が追い求める言語は、自然言語に近いのかもしれません。しかしながら、日本語や英語の様な自然言語では、余分な情報が多くて適しておりません。サポートしている文法が沢山あれば何でもいいというのものではなく、ハードウェアに密着した処理から高度に抽象化した概念まで、全ての情報を表現したいのです。
　コンパイラ実装者側の目線で「理想のプログラミング言語」を考えれば、その考えはナンセンスなものです。何故ならば、その要求に矛盾をはらんでいるからです。たとえば、アセンブラの様に抽象度が低いものと、自然言語の様な抽象度が高いものを、同時にサポートする文法を実現するとなれば、要求を満足させる美しい言語が出来上がりません。
　インラインアセンブラの様な機能を、実装すればひとまず良いと思う人もいるでしょうがそれでは不十分です。インラインアセンブラの様な特別な構文には不自然さがあり、プログラミング言語の美しさが損なわれます。「美しさ」は思考を助け、「醜さ」は思考を損なうのであって、美しさで妥協してはなりません。また、プログラミング言語が持つ機能の統合性が損なわれる恐れがあります。
　この記事で示唆する統合性とは、「個々の文法を自由に込み合わせられる事」です。インラインアセンブラの様な文法は「浮いて」おり、他の機能と十分に連携できません。そうすると、思考の連続性が失われ、生産力が低下してしまいます。しかしながら、他にもこういった相反する要求は沢山存在し、今のところ美しく解決できません。
　理想のプログラミング言語が存在しないので、今のところ複数のプログラミング言語を使いこなす事によりこの問題に対処しています。しかしながら、これは満足できる解決策でありません。自分が理想とするプログラミング言語を自らの手で作らないと、真の意味で解決した事になりません。誰かが作った言語が自分の好みと完全に一致する確率は極めて低いでしょう。
　この手の話題はプログラミング言語に限った話しではありません。どの様なツールでも共通する問題です。現実的に考えるのであれば、既存のツールに満足するしかないのでしょう。ですが、理想を実現する野望を持たない技術者は、技術者として「死んでいる」と私は思えてなりません。
　現実と向き合う姿勢も大事ですが、かといって理想を失っては生きがいがありません。今あるものに妥協しては、新しいものを生み出す創造力が生まれません。その矛盾を抱えている存在が技術者なのかもしれません。技術者の人生とは何かをたまに自身に問いかけますが、私自身まだ答えを見いだせません。
　ただ、私はこうも考えています。全ての問題に対する答えがでたら、そこに生きる意味を見いだせるのかと・・・。「現実と理想のギャップ」という言葉は、一般的にはネガティブな単語です。しかしながら、このギャップこそが生きる上で大切なものなのかもしれません。

初心者のためのC#プログラミング本格入門59 - 類似したプログラムとの差を考え改良していこう

　この記事は、初心者のためのC#プログラミング本格入門58 - 類似した処理から考えようの続きです。前回は、類似したプログラムを元に、新しいプログラムを作り出す初心者用の思考法について解説しました。開始地点としてはこれでよいのですが、やはり世の中には全く同じプログラムは殆ど存在せず、プログラムを改良しなければなりません。そこで今回は、初心者が類似プログラムを改良していく方法について解説します。
　前回のサンプルプログラムは、いくつか改良するべき点があります。その中で最も大きな違いは、呼び出すメソッドです。AddValuesメソッド内では、個々の値を取得するためにTryValueを呼び出しています。一方、DivisionAnalyzerメソッド内では、式を分解するためにCutExpressionメソッドを呼び出しています。その違いが成否の大部分を占めています。
　その差を考えるために、両方のメソッドを見比べてみましょう。

static System.Tuple<bool, float, string> TryValue( string inputValue )
{
    //各種変数を準備
    int startIndex = 0;
    int endIndex = inputValue.Length;
    bool startFlag = false;

    //数字の初めと終わりを記録
    for ( int i = 0; i < inputValue.Length; i++ )
    {
        if ( System.Char.IsDigit( inputValue[ i ] ) == true )
        {
            //初めて数字が出たら位置を記録
            if ( startFlag == false )
            {
                startIndex = i;
                startFlag = true;
            }
        }
        else if ( startFlag == true )
        {
            //数字が途切れたら位置を記録してループ終了
            endIndex = i;
            break;
        }
    }

    //数値を取り出す
    int count = endIndex - startIndex;
    string outputValueString =
        inputValue.Substring( startIndex, count );
    float outputValue = 0;
    bool success =
        float.TryParse( outputValueString, out outputValue );
    if ( success == false )
    {
        System.Tuple<bool, float, string> result =
            new System.Tuple<bool, float, string>(
                false, 0, inputValue );
        return result;
    }

    //取り出した数値以外の文字列を取得
    string remain = inputValue.Remove( startIndex, count );

    //結果を返す
    System.Tuple<bool, float, string> result1 =
        new System.Tuple<bool, float, string>(
            true, outputValue, remain );
    return result1;
}

static System.Tuple<bool, string, string> CutExpression(
        string expression )
{
    //()記号の範囲を決定
    int startIndex = -1;
    int endIndex = -1;
    for ( int i = 0; i < expression.Length; i++ )
    {
        char tmp = expression[ i ];
        if ( tmp == '(' )
        {
            startIndex = i + 1;
            continue;
        }
        if ( tmp == ')' )
        {
            endIndex = i;
            break;
        }
    }

    //エラー判定
    if ( startIndex == -1 | endIndex == -1 )
    {
        System.Tuple<bool, string, string> error =
            new System.Tuple<bool, string, string>(
                false, expression, "" );
        return error;
    }

    //()内の式を取り出す
    int count = endIndex - startIndex;
    string cutExpression = expression.Substring(
        startIndex, count );
    System.Tuple<bool, string, string> result =
        new System.Tuple<bool, string, string>(
            true, expression, cutExpression );
    return result;
}

2つのプログラムを簡単に見比べるために、コメントを見てみましょう。そうすれば、2つのプログラムの違いが、大まかに分かります。TryValueメソッドにある「//取り出した数値以外の文字列を取得」に該当するプログラムが、CutExpressionメソッド内にはありません。という事は、「取り出した式以外の文字列を取得するプログラムが足りない事が分かります。
　足りないプログラムを足すと次の様になります。

static System.Tuple<bool, string, string> CutExpression(
 string expression )
{
    //()記号の範囲を決定
    int startIndex = -1;
    int endIndex = -1;
    int parenthesis = -1;
    for ( int i = 0; i < expression.Length; i++ )
    {
        char tmp = expression[ i ];
        if ( tmp == '(' )
        {
            parenthesis = i;
            startIndex = i + 1;
            continue;
        }
        if ( tmp == ')' )
        {
            endIndex = i;
            break;
        }
    }

    //エラー判定
    if ( startIndex == -1 | endIndex == -1 )
    {
        System.Tuple<bool, string, string> error =
            new System.Tuple<bool, string, string>( 
                false, expression, expression );
        return error;
    }

    //()内の式を取り出す
    int count = endIndex - startIndex;
    string cutExpression = expression.Substring( startIndex, count );

    //取り出した式以外の文字列を取得
    int coutCount = endIndex - parenthesis + 1;
    string remain = expression.Remove( parenthesis, coutCount );

    //結果を返す
    System.Tuple<bool, string, string> result =
        new System.Tuple<bool, string, string>(
            true, remain, cutExpression );
    return result;
}

これで完成に近づきました。まだ改良するべき点がありますが、次の改良は次回で行います。
　この様に初心者は、上手くいったプログラムと比較して改良する方法を採るとプログラミングがしやすいと思います。初心者の頃は、いきなり正しいプログラムを作ろうとしても大概は上手くいかないと思います。その頻度は違いますが、たとえプロであっても躓く事があるかと思います。
　初心者の頃は、特にじっと考えているよりも、手を動かした方がうまくいく場合が多々あります。とはいえ、ただ闇雲に手を動かせばよいというものではありません。考えながら手を動かす必要があります。
　その思考方法は多々ありますが、初心者が実行できるのが今回紹介した方法です。私も初心者の頃はこの思考方法を使って、既存のプログラムを弄って思考錯誤を繰り返し学習しました。人は成功と失敗を繰り返して成長します。何事も失敗を恐れて何もしなければ成功する可能性は0％です。
　最後に一つ注意をかきます。個の思考方法を試す場合は、成功したプログラムをこまめに別の場所へ保存しておきましょう。間違ってプログラムを元に戻したい時に、成功したプログラムのファイルがなければ、元に戻せない恐れがあります。失敗を予想して予め手を打っておきましょう。
　無策に失敗するのと、あらかじめ準備して失敗するのとでは、結果に天と地の差が生まれます。くれぐれも注意しましょう。