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

　この記事は、実践的オブジェクト指向設計入門16の続きです。前回は、設計の最適化について解説しました。引き続き設計の最適化について解説します。
　オブジェクト指向方法論OMTの「効率的なアクセスのために冗長な関連を追加する」とは、複雑な操作の再計算を避けるために、派生属性を保存することだとされています。分析中に冗長な関連は望ましくありません。しかしながら、実装するという観点から見れば、システムの効率が上がる場合もありうるので、冗長な情報を付加するのが望ましい事もあります。
　例えば、データベースに於いてテーブルは基本的に第3まで正規化します。しかし常に第3正規形にしておくと、頻繁に検索されるパターンによっては、逆に効率が悪い場合があります。その様な状況では、第3正規形をあえて崩して、頻繁に検索される列を追加して冗長にする事により、結合コストを低くするとよい場合もあります。ただし、冗長化すると更新コストが上がるので、慎重にせねばなりません。なお、この作業項目は、インデックスの検討も含まれています。
　次に「効率化のための実行順序の再調整」があります。アルゴリズムは、計算手順を変える事により処理効率が上がる場合があります。オブジェクト指向分析では論理的な順序が導き出されますが、実装の観点から言って最適な順序だと限りません。時には実行を変える柔軟な思考が求められています。
　最後に「派生属性の保存による再計算の回避」です。これは、他のデータから派生させることができる冗長なデータを再計算するオーバーヘッドを避けるために、一旦計算した値のままキャッシュしたり保存したりする事です。「効率的なアクセスのために冗長な関連を追加する」と似ていますが、この項目はインデックス等についてであり、派生属性の保存による再計算の回避はキャッシュの事を指しています。ネットワークの設計でよくみられる現象ですが、オブジェクトを使われる場所の近くにコピーしておくと、遠隔地に一々データを取りに行く手間が省けます。これはあらゆるオブジェクトに言える事です。そのよい例がADO.NETのオブジェクトモデルです。
　ADO.NETを使用すると、メモリ内にデータをコピーしておく事が出来ます。これは処理効率を大きく上げます。何故ならば、遠隔地にアクセスしてデータを受信するスピードよりも、メモリからデータを取得する方が圧倒的に速いからです。適切なデータを取得しておけば、パフォーマンスは大幅にアップします。
　こうした事例はシステム開発では頻繁にあります。あらゆる場所にキャッシュがある事からその事実がそれを裏付けています。ハードディスク・CPU・主記憶・・・・それら全てにキャッシュが存在します。しかしながら、キャッシュは更新に関するデメリットがある事を忘れてはなりません。DNSのキャッシュにより、名前解決に関するトラブルを経験した人も多いでしょう。
　前回も言いましたが、最適化にはデメリットがあり、早すぎる最適化は毒となります。十分に注意して下さい。最後に注意するべき点について述べます。オブジェクト指向方法論OMTがいう計算とは、コンピューターの処理全般を指しています。数値処理だけの話題ではないので注意して下さい。

初心者のためのC#プログラミング本格入門83 - 多重定義しよう

　この記事は、初心者のためのC#プログラミング本格入門83の続きです。前回は、仕様と関係しているバグに対する対処法について解説しました。今回は、同一の名前を持つメソッドについて解説します。
　前回全てのエラーがなくなったので、サンプルプログラムに新しい機能を追加します。今現在単一の式は計算できています。今度は複数の式の計算をします。新しい機能を追加したくなったら、テストプログラムから書きます。

class MultiAnalyzerTest : Test
{
    //全てのテストを実行する
    public override void ExecuteAllTest()
    {
        this.AnalyzeSimpleExpression();
        this.ErrorExpressionCheck();
        this.ErrorAndSuccess();
        this.AllErrorExpressionDelete();
        this.CalculateSimpleExpression();
        this.CalculateMultiExpression(); //追加
    }
    
    //複数の式の計算処理をチェック
    public void CalculateMultiExpression()
    {
        ++this.testCount;
        string expression = "( + 1 2 ) + 3";
        this.target = new MultiAnalyzer();
        this.target.AnalyzeExpression( expression );
        double result = this.target.Calculation();
        double rightValue = 6;
        if ( result != rightValue )
        {
            ++errorCount;
            System.Console.Write(
                expression + "の計算処理が正しくありません。");
            System.Console.Write(
                " 正しい値：{0},", rightValue );
            System.Console.WriteLine( 
                " 処理結果；{0}", result );
        }
    }
}

始めは簡単な物が良いので、このテストでは「 1 + 2 + 3 」を計算しています。まだ、複数の式を計算するプログラムをプログラミングしていませんから、デバッグ実行（F５）するとエラーが発生します。正しくテストが実行されている事を確認するためにデバッグ実行して下さい。なお、System.Console.WriteLineメソッドで新しい方式を使っています文字列内に「{0}」が指定されている点に注意して下さい。「"正しい値：" + rightValue + ","」の様に。文字列の連結を繰り返さないように出来ます。この新しい方法を使うともっと省略できます。使いようによってはプログラムが見やすくなります。

System.Console.WriteLine(
    expression +
    "の計算処理が正しくありません。 正しい値：{0}, 処理結果；{1}", 
    rightValue, result );

「{0}」と「{1}」に注目して下さい。この数値は指定する番号です。0番から指定する事に注意して下さい。
　話しを戻します。複数の式を計算する手順を考えてみましょう。そうすれば、自ずとプログラムが分かります。

【複数の式を計算する手順】

1. 1つめの式を計算。
2. 1つめの式を計算した結果を2つめの式に追加。
3. 2つめの式を計算。

※ただし式は解析済みとします。

この様に1つの式を計算し、後の計算式に値を追加していけば、複数の式の計算が出来ます。次にこのプログラムを追加する場所を考えます。複数の式を計算するのですから追加する場所は「MultiAnalyzerオブジェクトのCalculationメソッド」です。今まで学習した知識を活かして自分でプログラミングしてみて下さい。ヒントは「一時的なオブジェクト活用する」です。
　できましたか？模範解答を示します。

//計算式の計算結果を返す
public double Calculation()
{
    //初期値を設定
    double result = 0.0f;
    
    //複数の式を計算
    System.Collections.Generic.List<Analyzer> temps =
           new System.Collections.Generic.List<Analyzer>();
    temps.Add ( new Analyzer( analyzers[ 0 ] ) );
    if ( analyzers.Count > 1 )
    {
        for ( int i = 1; i < this.analyzers.Count; ++i )
        {
            Analyzer temp = new Analyzer( analyzers[ i ] );
            double backValue = analyzers[ i - 1 ].Calculation();
            temp.AddValues( backValue );
            temps.Add( temp );
        }
    }

    //最終的な計算結果を返す
    result = temps[ temps.Count - 1 ].Calculation();
    return result;
}

自分でプログラミングした人は、ちょっとした問題がある事に気付くと思います。それは、一時的なオブジェクトを作るプログラムと値を追加するプログラムです。今まで習った文法の知識では、違う名前のメソッドを定義しなくてはなりません。ですが、新しいC#の機能を使用すると同名のメソッドとコンストラクタが定義できます。やり方は簡単です。

class Analyzer
{
    //同じ値を持つオブジェクトを作成
    public Analyzer( Analyzer source )
    {
        this.success = source.success;
        this.sign = source.sign;
        this.values =
            new System.Collections.Generic.List<double>();
        this.values.AddRange( source.values );
    }
    
    //値を直接追加
    public void AddValues( double value )
    {
        this.values.Add( value );
    }
}

特にこれと言った文法はありません。同じ名前を持つメソッドとコンストラクタを定義できます。違うのは引数の型だけです。これはオブジェクト指向プログラミングの機能で多重定義もしくはオーバーロードと呼びます。多重定義を使用すると、同じ内容のメソッドに違う名前をつける苦労から解放されます。初心者の方は、これが意味するところが良く分からないと思います。ですが、この機能があるのとないのとでは大きな違いがあります。
　例えば、もしC#に多重定義の機能がなければ、System.Console.WriteLineToInt、System.Console.WriteLineToFloatの様に微妙に名前が違うメソッドを型の数だけ定義しなくてはなりません。これではオブジェクト使う人が大変です。
　些細な事だと思う人もいるでしょう。しかし、もともとプログラミングは細かい作業なので、些細な差がプログラミングに大きな影響を与えます。プログラミングだけの話しではなく、プログラムの設計にも影響を与えます。違いが分かる人になる事もまたプログラミング上達の道なのです。

初心者のためのC#プログラミング本格入門82 - 仕様と関係しているバグの対処法を学ぼう

　この記事は、初心者のためのC#プログラミング本格入門81の続きです。前回は抽象メソッドについて解説しました。今回は、仕様と関係しているバグに対する対処法について解説します。
　連載を通じて作成しているサンプルプログラムを、デバッグ実行（F5）して下さい。剰余に関するテストに失敗している事が確認できます。処理結果をみると、NaN（非数値）となっています。このNaNは浮動小数点規格の規格IEEE754で定義されている表現です。浮動小数点の動作を定めた規格で、.NETではfloat型やdouble型がこの規格に準拠しています。どうしてそういう規格（取り決め）があるかというと・・・
　コンピュータの最初の使用目的は、数学的観点から問題を解決する事でした。それで、多くの開発者が思考錯誤しながら、有限の数しか表せない道具であるコンピュータを使っていました。そうこうするうちに、個々のコンピュータが独自の算術的工夫をしていたので統一する必要が生じました。何故ならば、使用するコンピュータごとに結果が異なったら困るからです。
　たとえば、コンピュータAで10.11、コンピュータBで10.12、コンピュータCで10が導き出されたとします。この状態では、使用するコンピュータが違えば結果が違う事になります。こんなあやふやな結果では困ります。ロケットが壊れるかもしれません。
　そういった事から、開発者達は共通の約束を決めました。それがIEEE754規格です。NaNはその規格で定められた表現のうちの1つです。数学的に定義された値の範囲外の不正な値が出た時に出す定義エラーです。
　今回示した例の様に、プログラムの仕様に関するエラーは、どうやって対処すればいいでしょうか？それについては、唯一絶対の答えがありません。自分でよく考えて、明確な答えを出さねばなりません。その場限りの対処では駄目です。統一した答えを考えます。
　このサンプルプログラムでは、現時点でまだ十分な文法を学んでいない事と、数学は本題でない事を考慮して、一時的に0で剰余を求めた場合は0であると決めます。この仕様に従ってプログラムを修正しましょう。

class Analyzer
{
    //関係のないプログラムは省略
    
    public double Calculation()
    {
        //途中のプログラムを省略・・・
        case '%':
            result = this.values[ 0 ];
            for ( int i = 1; i < this.values.Count; i++ )
            {
                if ( this.values[ i ] == 0 )
                {
                    result = 0;
                    break;
                }
                else
                {
                    result %= this.values[ i ];
                }
            }
            break;
    }
}

これでエラー件数が0になりました。
　プログラムの仕様に関するエラーは厄介ですが頻繁に遭遇します。この手のエラーに遭遇した場合、現時点で考えられるある程度納得できる答えを決め、それをメモしておきましょう。そうすれば、あれこれ悩んで時間を無駄にする事が無くなります。この手のエラーは殆どの場合、プログラミングを進めないと答えが出ません。学習目的でプログラミングする場合は、思い悩まずどんどん前に進みましょう。
　なお、仕事では仕様に関するエラーは、お客様や関係者と協議して決めます。その場合でも自分の意見を求められるので、素早く答えを出す練習をしておくのは良い事だと思います。

書籍をつつく148 - 圏論の基礎復活！

モナドが気になる人が読めばいいとされている専門書が復活したピヨ。



ボクは手に入らなくて困っていたんだよね。そんな人多いと思う。そんな人はチャンスだピヨ。また廃刊になるかもしれないピヨ。廃刊になる前にゲットしよう。ただし、僕も読んだ事がないからこの本でモナドが分かるかどうかは不明ピヨ。ボクは新しい知を求めて数学を啄んでいるから気にしないけど、数学が嫌いな人は注意した方がいいピヨ。

中の人の徒然草412

今日も虐め事件のニュースを見て考えました。法治国家であるのにもかかわらず「虐め」の一言で刑事事件が放置されている現状は酷いですね。まるで無法国家です。ただ、私達有権者にも問題があったかと思います。
虐め問題でおかしなことは、警察が動けない事と教育機関が防げない現実です。関係機関をただ責めるのは簡単です。ですが、まさか虐めという名の犯罪を助長したいわけではないと思います。ですから、そこにはそれなりの理由があると思います。
私達有権者がするべき事は、この理由を徹底的に聞き出し、警察や教育者が動けるシステムに変えるべきだと思います。社会システムの基本は法律ですから、きっと法律に不備があるのでしょう。なければ故意に虐めを放置している事になりますから、それはないと思いたいです。もし故意ならば犯罪幇助です。
法律に問題があるとなれば、その法律を変えるために我々有権者は、自らが選んだ政治家に立法を依頼せねばなりません。感情論だけで騒ぎ立てても虐めはなくなりません。私達は理性を持つ大人なのですから、冷静に再発を防ぐシステム作りをするべきなのです。
纏めます。私達が現時点でするべき事は、警察が9カ月間動けなかった理由と虐めを止められなかった理由を知る事です。私達は彼らがまともに仕事をしやすい環境をつくるお手伝いをする為に、徹底的に原因を聞き出しましょう。そうすれば、私達が選んだ立法者に依頼し、再発を防止できるシステムを作れます。
責めるだけならば子供でも出来ます。私達大人は、法治国家の精神に基づき理性的かつ冷静に行動しなくてはなりません。

ネタつつき135 - システムの不備に対する行動原則

　最近社会システムの不備が目立つので、システムの不備に対する対処法を書こうと思いました。どんなシステムでもそうなのですが、システムに不備があった時は犯人捜しや責任論を後に置いといて、先にシステムの不備を詳細化するべきです。問題が起きた時人は感情論に走りがちですが、そんな事をしても問題は解決しません。感情を押し殺して、システムの不備に関する情報を徹底的に集めなければなりません。情報があれば犯人探しは後でも出来ます。
　情報を集めた後は、二度と同じ事が起きないように徹底的に対策を考えます。この時は性悪説で考え、集めた情報だけで考えるのではなく、どうしたら同じ問題を発生できるのか考え、その原因を徹底的に潰す方向で考えます。
　虐め問題を例にあげましょう。この問題で考えるべき事は、被害を与えたくてもできないシステム作りです。これはあくまでも一例なのですが、AさんがBさんを殴った時、その場にいた全ての人間が全員写真機能で証拠を撮り、教師・保護者・教育委員会・関係省庁・警察などに一斉に報告するようにすれば、二度と殴れなくなるでしょう。証拠の取得が出来ない場合は、事実を詳細に述べましょう。そうすれば、少なくとも自殺に至らないでしょう。
　セキュリティは多重防御が基本です。被害が起きる都度、それ以上深刻にならないように、複数の情報ルートを使って解決を図ります。日本は問題が深刻化するまで放置、もしくは問題が起きた後でも認めない傾向がありますが、それは最悪の方法です。それでは加害者の方が有利になります。そんな愚かな行為を続けないで、深刻化する前に解決しましょう。そうすれば、深刻な事態が起こる可能性が0に近くなります。
　あとは権限と責任を明確化しましょう。日本は権限と責任が曖昧な時が多いです。これがセキュリティホールとなりシステムの被害を拡大しています。セキュリティホールを潰し、徹底的に問題を起こしたくともできないようにする。それがシステムの不備に対する行動原則です。この原則はどの様なシステムでもあてはまります。

中の人の徒然草411

虐め問題に怒りを覚えているインドリです。この種の問題を聞いていつも思うのが隠蔽にデメリットがなさすぎるという事と、行動が遅すぎるという事です。
隠蔽をする方が得ならば誰で隠蔽します。そんな当たり前の事を戦後ずっと放置しているのはなぜなのでしょうか？私には理解できません。また、アジャイルに働いている私にとっては、あまりにもスローな行動スピードが信じられません。
システムでトラブルが起きた時、数時間以内に解決できないと二度と注文がきません。それに、2・3日以内に根本的な解決方法を考えられなければ、やはり二度と依頼は来ません。1分1秒を争うこの時代に、あのスローペースは本当に信じられません。いつの時代の話しだと思ってしまいます。
怒りを書きなぐるだけだと意味が無いので対処法も書きます。この手の問題は隠蔽される事を前提に考えた方がいいです。隠蔽されないかもしれませんが、隠蔽された時に想定外では話しになりません。ですから常に最悪の事態を想定して行動しなくてはなりません。
実は私達は既に解決策を手にしています。それは、情報ツールです。Windows8が指し示す様に、今の時代はいつでもどこでも誰でも情報で繋がっています。隠蔽される前に情報を収集し、それを公開していきましょう。
ただし、誤解されないように先に明言しますが、プライバシーは十分に配慮しましょう。私達は法治国家で生きているので、犯行をされたからと言って自分が加害者になってはいけません。「目に目を歯には歯を」は犯罪者の第一歩です。くれぐれも情報ツールを悪用しないでください。
それはそうと、何故日本はこの様な状況を想定して法律の整備をしてこなかったのでしょうか？いつもの想定外かな？それにしても戦後数十年過ぎているのですから、国民の命にかかわる事を、想定外ではお話しにならないのではないかと思います。
なにはともあれ、政治家の人達は今が仕事をする時だと思います。離党・新党結成・連立などと言った政治劇をしている暇があったら、国民の命を守る法律を作るという本来の仕事をして頂きたいです。そうすれば自然と支持率がアップすると思います。我々国民が見ているのは本来の仕事の成果です。こういう問題が起きた時こそ、真剣に仕事をしている事を指し示す必要があるのではないでしょうか？
なにはともあれ、こういった悲劇が二度と起きないように、全ての人が知恵を合わせて行動して欲しいと切に願います。

ネタつつき134 - システムが人に牙をむき人は放置する

　近頃のニュースを見ていて改めて思ったのですが、下手なシステムは人を傷つけます。私はシステム屋なので、そうした事例を沢山見てきました。近頃のニュースにもそれが当てはまります。例えば、政治のごたごた、年金問題、虐め問題・・・といった事例は正しくシステムの問題です。今回はその事について書きます。
　日本の悪い風習は言われた事を忠実に従って疑問すら持たない事だともいます。最近ニュースでとりあげたれる事が多い虐め問題にしても、問題は今に始まった事ではありません。それにも拘らず、日本は戦後数十年もそれを放置してきました。これは非常に悪い癖です。
　問題がある社会システムを改善せず、事件が起こったら騒ぐだけでは何の問題解決にもなりません。再び悲劇を繰り返さないためにも、問題がある社会システムは改善せねばなりません。しかしながら、日本は戦後からシステムを改善するという事が殆どありません。一体どれだけの命を犠牲にしたら済むのだろうかと私は思えてなりません。私がシステム屋だから気になるのかもしれませんが、原発にしても年金にしても選挙にしても・・・様々なバグがあるシステムをそのままにしておいて、何か良い事でもあるのでしょうか？
　虐め問題が発生すれば、学校側も激しくバッシングされます。加害者に加担しているかのように見えてしまうので、それも当然の事でしょう。バグがあるシステムの中で働いている人達は、そのバッシングに対して何もする事はできません。下手すれば被害者なのかもしれません。もちろん、被害者やその親族にとってバグあるシステムは憎しみの対象です。誰もが怒り悲しんでいます。
　それにも関わらず、日本人はシステムを改善しようとしません。バグがあるシステムをそのままにしておけば、未来永劫被害者が増え続けます、時がたつにつれて問題が大きくなります。システムは時がたてば改善するなんて事ありえません。問題が重なり酷くなるだけです。何の意図があって放置し続けるのでしょうか？私には理解できません。
　バグがあるシステムを運用している人も、システムによる被害者にも、誰にとっても何の得もありません。報道して、騒いで、騒ぎ疲れたらお終い。なんて事を繰り返していては、私達は知性があるとは言えません。1つ1つの事件をエラーだと捉えて、真面目に改善していくのが本当の社会人だと私は考えております。システムが牙を剥き、人を喰い殺します。そのシステムは私達人間が創ったものです。その私達が牙をむくシステムのいいなりになっていいのでしょうか？
　1つ1つ問題がある社会システムを改善する。そんな当たり前の事が行われてほしいと私は願っています。

初心者のためのC#プログラミング本格入門81 - 抽象メソッドを具象化しよう

　この記事は、初心者のためのC#プログラミング本格入門80の続きです。前回は多態性について解説しました。今回はその続きです。
　今度は次の警告とエラーが表示されます。

【警告】 'AnalyzerTest.ExecuteAllTest()' は継承されたメンバー 'Test.ExecuteAllTest() を隠します。現在のメンバーでその実装をオーバーライドするには、override キーワードを追加してください。オーバーライドしない場合は、new キーワードを追加してください。
【エラー】 'AnalyzerTest' は継承抽象メンバー 'Test.ExecuteAllTest()' を実装しません。

この2つを解決する方法はメッセージに隠されています。C#が「override キーワード」と言っているので、ExecuteAllTestメソッドにoverrideキーワードを追加します。

class AnalyzerTest : Test
{
    //重要でないプログラムは省略
    
    public override void ExecuteAllTest()
    {

    }
}

class MultiAnalyzerTest : Test
{
    //重要でないプログラムは省略
    
    public override void ExecuteAllTest()
    {

    }
}

overrideキーワードを追加したら、ソリューションのビルド（F6）を押して下さい。全てのエラーと警告が消えます。
　この事からabstractキーワードをつける抽象クラスの利点が2点見えてきます。1点目はプログラムの幅が広がる事です。2点目は、子オブジェクトに対して実装を強制できる点です。実装を強制する事による利点は、集団作業がやりやすくなる事です。集団でプログラミングをしていると、他の人がExecuteAllTestメソッドをいると思っても、通達ミスなどにより守られないかもしれません。しかし、抽象クラスを定義するとC#がエラーを出してくれますのでそういう事はありません。他にも理由はありますが、徐々に分かってくると思います。
　なお、abstractキーワードがついたメソッドの事を抽象メソッドと呼びます。オブジェクト指向プログラミングではよく使う言葉なので覚えて下さい。

初心者のためのC#プログラミング本格入門80 - オブジェクト指向プログラミング最後の要素「多態性」を知ろう。

　この記事は、初心者のためのC#プログラミング本格入門79の続きです。前回は、継承について解説しました。今回は、オブジェクト指向プログラミングの効果を示します。
　前回、共通の性質を持つ親オブジェクトを定義して、複数の子オブジェクトにプロパティを追加しました。これは、あるオブジェクトの定義をベースとして、そのオブジェクトの機能を拡張する、新しいオブジェクトを定義した事を意味します。これにより、同じプログラムを書く作業から解放されます。しかしながら、こうしたオブジェクト指向プログラミングの機能は、プログラムを書く労力を減らすだけではありません。オブジェクト指向プログラミングを行うと幅が広がります。
　初心者の方は、現時点でオブジェクト指向プログラミングというものが何なのか分からないと思います。ですが実のところ、何度もオブジェクト指向プログラミングを行っています。今まで何度も書いたプロパティは、カプセル化というオブジェクト指向プログラミングの概念を実現したものです。また、前回紹介した継承もオブジェクト指向プログラミングの概念です。オブジェクト指向プログラミングには、もうひとつ多態性という概念が存在します。文章では分かり難いのでプログラムを見てみましょう。

class TestProgram
{
    static int errorCount;
    static int testCount;

    static void Main()
    {
        //全てのテストを実行する
        Test[] tests = new Test[] { 
            new AnalyzerTest(), 
            new MultiAnalyzerTest() };
        foreach ( Test t in tests )
        {
            ExecuteTest( t );
            System.Console.WriteLine();
        }

        //テストに関する情報を表示
        System.Console.WriteLine("***** エラー件数：" 
            + errorCount + " *****");
        System.Console.WriteLine( "***** テスト件数："
            + testCount + " *****" );

        //デバッグ実行しやすいようにする
        System.Console.WriteLine();
        System.Console.WriteLine(
            "Enterキーを押すと終了します。");
        System.Console.ReadLine();
    }

    static void ExecuteTest( Test obj )
    {
        obj.ExecuteAllTest();
        testCount += obj.TestCount;
        errorCount += obj.ErrorCount;
    }
}

このプログラムの内容は前回と同じです。内容は同じですが、テスト対象が増えた時、新しいテストオブジェクトを配列に追加するだけになり、追加しやすいプログラムになっています。ただし、多態性という概念を使用していますので、現時点ではデバッグ実行できません。これからデバッグ実行できるように、プログラムを修正していきます。
　始めに問題になるのは、親オブジェクトであるTestがExecuteAllTestメソッドを持っていない事です。ならば追加しましょう。

//テストオブジェクトに共通した定義
class Test
{
    //他のプログラムは省略

    //全てのテストを実行する
    abstract public void ExecuteAllTest();
}

abstractキーワードが気になると思います。これについては、メソッドの中身が無い事を示していると考えてください。Testオブジェクトは何のテストを実行するのか分かりませんから、メソッド内のプログラムを書けません。ですから何も書けません。そこで、C#に中身が無いメソッドを書く事を知らせているのです。このプログラムを書くと、2つの警告と1つのエラーが発生します。
　エラーは・・・

'Test.ExecuteAllTest()' は抽象ですが、非抽象クラスの 'Test' に含まれています

となっています。これは、C#が「ExecuteAllTestメソッドの中身が無いけど、Testはインスタンスを作れる。どうする？」と言っています。つまり・・・

//こうされたらどうするの？
Test t = new Test();
t.ExecuteAllTest();

このプログラムは、メソッドの中身がないから実行できません。これでは困るのではないかとC#は事前に言ってくれているわけです。
　ここで今回のTestオブジェクトのインスタンスを、作る意味を考えてみましょう。Testオブジェクトは、テストの共通定義だけを表したオブジェクトです。ですから、Testオブジェクト自身は何も実行できません。いや、何のテストでもないので実行したくないと言った方が適切です。ならば、それを素直にC#に伝えましょう。

//インスタンスを作れないオブジェクト
abstract class Test
{
}

classキーワードの前にabstractキーワードをつけて、インスタンスを作れないオブジェクトである事をC#に伝えます。
　いいところですが、長くなったので次回へ続きます。