アジャイル開発と契約9

　この記事はアジャイル開発と契約8の続きです。前回は、品質保証のうちの1つである、性能保証の概要について記述しました。今回は、性能保証とアジャイル開発について、詳細に記述します。
　日本の企業は責任を避ける傾向があり、今まで性能保証についてはおざなりにされていました。しかしながら、これからは、そんな事を言っていれば倒産するでしょう。というのも、大概の会社は、普通のシステムならば、既に導入済みだからです。また、同じ性能ならば、人件費が安い海外企業に勝てる筈がありません。性能に注目し、契約前から自社の製品をアピールしなくてはなりません。
　性能を追求する場合、ウォーターフォール開発モデルよりもアジャイル開発が有利です。何故ならば、性能向上のキーは現場に存在するからです。プログラミングを知らない人が、性能について考えられる筈がありません。しかし、一言で性能といってもその意味は様々です。ですから、結局のところお客様が価値を判断するしかありません。お客様の要望を聞くのは、上流工程の人で、プログラマには届いておりません。すなわち、性能品質は全行程が共有するべきものなのです。
　ウォーターフォール開発モデルで開発をすると、各工程が持つ知識と技術が分断され、性能に関する情報もまちまちで、統一見解が存在しなくなります。その様な状態で、お客様が満足する性能のシステムが作れる筈がありません。アジャイル開発を採用し、各工程の担当者とお客様がコミュニケーションをとりながら、適切な性能のシステムを開発しなければなりません。
　性能をコントロールする上で、気をつけなければならない事があります。それは、技術の追求をしても駄目、過剰装飾しても駄目だという事です。下流工程の人々は職人なので、日頃技術を追求しています。しかしながら、お客様が求めるシステムは、技術の先にあるとは限らないのです。システムは、実状に合ったものでなくてはなりません。システムは服と同じで、サイズが合わないシステムを導入すれば無理が生じます。一方、上流層の人々は、書類やプレゼンテーションに凝る傾向があります。しかし、過剰なアピールは、現実との乖離を生み、不信感とトラブルを生みます。あくまでも、お客様にあったシステムを、ありのまま提案しなければなりません。

続く・・・

変数は不可変な方が良い

　並行プログラミングで、データを共有する事は困難です。何故ならば、1つのデータに対して、同時に複数の処理を実行した場合、データの整合性を保つには、様々な問題を解決する必要があるからです。しかし、簡単な解決法が存在します。それは、変数を不可変にする事です。今回は、その理由と背景について詳しく述べます。
　変数を不可変にする事の利点を知るには、変数を可変にする事の不利益を知らねばなりません。先ずは、変数を可変にする事により発生する問題について、例をあげて説明します。
　例えば、ある変数を指定値分増加させる加算処理と、指定値分減少させる減算処理を同時に実行した場合を考えてみます。値の現在値が100の時に、指定値が30の加算処理と、指定値が50の減算処理が行われた場合、最終値は80でなければなりません。しかし、注意深く並行プログラミングを行わないと、最終値が130になったり、50になったりします（※他にも色々問題が生じますが長くなるので省略します）この望ましくない結果を防ぐには、同期処理などを行わなければなりませんが、その処理をプログラミングする際に、バグが発生する可能性があります。また、同期処理を行うと、パフォーマンスが下がります。
　この問題の根源は、データが可変である事です。そもそも、データが変更できなければ、矛盾が生じません。プログラムのデータ（変数）を不可変にしておくと、問題が始めから生じないので、同期処理などを行う必要もなくなります。命令型プログラミングに慣れた方は、変数を不可変にしてプログラミングが出来ないと考えるかもしれませんが、やってみると意外と簡単です。例えば、.NETとJavaのString型は不可変です。それでもちゃんとプログラミング出来ている筈です。
　もちろん銀の弾丸は存在しません。変数を不可変にするデメリットも存在します。それは、メモリ消費量が増加する事です。変数を不可変にすると、新たなインスタンスを生成する必要性が生じ、その分だけメモリ消費量が増加します。
　変数を不可変にしておいて、必要なメモリ量が多くなりすぎた時に、改めて削減策を講じるとよいでしょう。

変数のスコープを極力狭くする理由

　変数のスコープを極力狭くするべきなのは、並行プログラミングに限った話ではありません。実務を経験している人は、大概同じ事を考えますし、情報隠蔽の原則として有名な事ですが、その原則を破る事も出来ます。しかし、並行プログラミングに於いては、破る事が出来ない原則なので理由を詳しく書きます。
　並行プログラミングをしていなくとも、グローバル変数（大域変数）を多用すると、スパゲッティプログラムになりやすく、バグを生む可能性が高くなります。しかし、余分な労力をつぎ込めば、何とか動作できます。一方、並行プログラミングの場合、正常に動作させる事自体が困難になります。その理由は、処理結果が予想できなくなり、それを防ぐために同期処理を使用すると、デッドロックや優先順位逆転問題などが発生する可能性があるからです。つまり、スコープが広い変数を使う事のコストとリスクが高すぎるのです。
　その理由から、理想的には変数は局所的（ローカル）であるべきです。ローカル変数を使用すると、始めから値の不整合が起こりません。それ故、同期処理の必要もなくなります。では、何故その様な事が起こるかというと、ローカル変数をアセンブラレベルで考えれば分かります。
　順を追って説明します。グローバル変数は、プロセスごとに決められたメモリアドレスの範囲に配置されますので、同じプロセスに属する個々のスレッドがアクセスできます。一方ローカル変数は、スレッドごとに持つスタック内に保持するので、他のスレッドの影響を受けません。
　スレッドがスタックを持つ理由は、各スレッドは通常異なる手続きを呼び出し、異なる実行履歴を持つからです。関数呼び出しを実現するには、呼び出し前にいた場所（アドレス）と引数の値をスタックという形で保持しなくてはなりません。また、ローカル変数の値もスレッドごとに違いますので、スタックに保存しなくてはなりません。もし各スレッドがスタックを持たなければ、必要な情報をレジスタに保存する必要がありますが、レジスタの数は限られていますので、非常に少ない数のスレッドしか実行出来ず、ローカル変数の数も制限される事になります。それでは不都合が多すぎるので、スレッドごとのスタックに保存される形で実現されています。
　ローカル変数が使用できない場合は、スレッドローカルストレージ（TLS）を使用します。スレッドが持つスタック内の、決められた場所に変数を保存する事により、他のスレッドの干渉を防ぐ事が出来ます。この変数の名前は定められておらず、プライベート大域変数、TLS内に保持された変数・・・等と、文脈に沿って表現されています。

アジャイル開発と契約8

　この記事は、アジャイル開発と契約7の続きです。前回は、品質保証のうちの一つである機能保証について書きましたので、今回は他の品質保証内容である性能保証について書きます。
　性能保証とは、システムもしくはソフトウェアの処理性能や、セキュリティの強度などを保証する事です。つまり、1時間で1万件のデータ処理を行えるだとか、個人情報流出事件を避けられる・・・などといった性能に関する保証をするのが性能保証です。
　性能保証については、実務経験者の方でも聞いた事がないかも知れません。というのも、性能保証をしない会社が多いからです。会社が性能保証を渋る主な理由は、3点あります。
　1つめは、システムの性能を定量的に測れない点です。システムは複雑な要素から成り立ちます。それ故、システムの性能値を一定にすることもできなければ、公平かつ正確に測る方法はありません。これは、本質的なものなので今後とも不可能だと思われます。
　2つめは、サービスの品質を一定に保つ事が出来ない点です。日本のIT産業は、昔からウォーターフォール型モデルを根拠にした、多重請負で仕事を引き受ける体制でした。ですから、下請業者が度々変わります。また、分業体制が長く、元請けの実装能力が不足し、下請けの実力を正確に測る事が出来ません。
　3つめは、セキュリティレベルを決定する事が難しい点です。システムもしくはソフトウェアは、セキュリティレベルを無闇に上げればいいというものでもありません。しかし、適切にセキュリティレベルを決定し、それを実施するには全行程でセキュリティに取り組まなければなりません。しかしながら、日本の場合、分業体制が強く、全行程を知っている人材が殆どいません。
　こういった理由から、今まで性能保証があまり契約に盛り込まれませんでしたが、セキュリティリスクが高い事を考慮すると、今までどおりエンドユーザーが黙っているという事はないでしょう。何故ならば、セキュリティを無視すると、多大なる損害を負うからです。昨今では、個人情報の流出により、億単位の出費と、社会的信頼の失墜を招いた会社が出現しました。また、サービス品質を保てないというのは、明らかにベンダ側の都合であり、エンドユーザーには関係のない事です。エンドユーザーは、他のサービスと同様に、高い性能保証を求めるでしょう。この世の中の動きに対応するには、アジャイル開発を採用し、対応するしかありません。

続く・・・

拡張メソッドの使い方

　C#の拡張メソッドを読めば、無闇に拡張メソッドを使用してはならない事が分かると思います。では、どのような状況で使うべきなのかといいますと、既存の型の機能が足らず、変更も出来ない場合に適していると思います。
　例えば、他社から購入したライブラリは、大半はソースコードが含まれていませんし、仮にあったとしても著作権上、直接ソースコードを書き変えて販売できない場合が大半です。その様な場合、拡張メソッドを使用すれば、可読性を高め、開発効率を上げられる可能性があります。
　他には、一時的に型の機能を拡張したい場合、使用するとよいでしょう。正しくオブジェクト指向開発をする場合、積極的に再利用可能な型を設計＆実装しています。しかし、何事にも例外はつきものです。そのプロジェクト特有の事情で、既存の型を拡張したい場合があります。この場合、既存の型を継承したクラスを作れる時もあれば、作れない時もあります。何故ならば、継承を想定した型だけではないからです。この様な状況下では、拡張メソッドが役に立ちます。
　あと、複数のメソッドが使用する、ヘルパーメソッドとして定義するとよい場合があります。プログラミングをしていると、共通した処理が発生する場合があります。この場合、ヘルパーメソッドを拡張メソッドとして定義すると、コードの可読性が向上する可能性があります。
　そろそろ纏めます。拡張メソッドは、一定の状況下で役に立ちます。しかし、多用すると混乱を生みますので、よく考えて使用して下さい。

拡張メソッドの正体

　拡張メソッドの仕組みが気になる人がいると思いますので、拡張メソッドの細部について解説します。
　拡張メソッドは、C#特有のものではありません。.NET Frameworkにある属性（System.Runtime.CompilerServices.ExtensionAttribute）を使用すれば、他言語でも拡張メソッドの宣言を行う事が出来ます。
　拡張メソッドの実現方法も簡単です。ILレベルでは、静的クラスなどに定義されている、ExtensionAttribute属性を適用したメソッドを、素直に呼び出しているだけです。例えば、C#の拡張メソッドに掲載したSample1の場合、ローカル変数iを引数として扱い、ConsoleUtility.Printメソッドを呼び出しています。

C#の拡張メソッド

　今回は、C#の拡張メソッドについて解説します。先ずは、拡張メソッドの宣言方法を見てみましょう。

//Sample1
using System;
using Utility;

namespace Utility
{
    static class ConsoleUtility
    {
        public static void Print( this int val )
        {
            Console.WriteLine( val.ToString() );
        }
    }
}

class Program
{
    static void Main( string[ ] args )
    {
        int i = 100;
        i.Print();
    }
}

　サンプルプログラム「Sample1」を実行すると、コンソール画面に100が表示されます。int型はPrintメソッドを持っていないところが、拡張メソッドを理解するポイントです。
　Printメソッドの持ち主はint型ではなく、ConsoleUtilityクラスです。それにも関わらず、int型のインスタンスはPrintメソッドを呼び出せます。これが拡張メソッドです。拡張メソッドを使用する事により、既存の型の機能を拡張できます。
　拡張メソッドを宣言する方法は簡単です。静的クラス内で、パラメータにthisキーワードをつけた静的メソッドを宣言するだけです。使用するのも簡単で、拡張メソッドが定義された静的クラスを参照するだけです。以上で、拡張メソッドの概要が分かったと思いますので、詳細な説明に入ります。
　Printメソッドの引数の型がint型になっているので、int型でPrintメソッドを呼び出す事になります。従って、次のプログラムはコンパイルエラーになります。

long m = 100;
m.Print();
byte b = 100;
b.Print()();

　コンパイルエラーを一見すると、暗黙の型変換が出来る場合でもエラーを出しているので、拡張メソッドは厳密に型を判定しているように見えます。しかし、拡張メソッドは、そこまで厳密に型を判定しません。子クラスが、拡張メソッドを使用する事を許します。これは一般的には望ましい事ですが、良く考えないで拡張メソッドを使用すると、この動作がもとでバグを生む可能性があります。

//Sample2
using System;
using Utility;
namespace Utility
{
    static class ConsoleUtility
    {
        public static void Print( this Parent obj ) 
        {
            obj.Method();
        }
    }
}
class Parent 
{
    public virtual void Method()
    {
        Console.WriteLine( "Parentクラスのメソッド" );
    }
}
class Child : Parent 
{
    public new void Method()
    {
        Console.WriteLine( "Childクラスのメソッド" );
    }
}
class Program
{
    static void Main( string[ ] args )
    {
        Child obj = new Child();
        obj.Print();
    }
}

　Sample2を実行すると、「Childクラスのメソッド」と表示されると思った人も多いでしょう。しかし、実際は「Parentクラスのメソッド」と表示されます。理由は、Childクラスがメソッドを隠蔽しているからです。このサンプルプログラムは短いので、そんな事をしないと考える人がいるかもしれません。しかし、拡張メソッドの内容が複雑で、大量のプログラム内で仮想メソッドを呼び出している場合、このバグの発見は難しくなります。また、拡張メソッドが実装された後で、新しい子クラスが仮想メソッドを隠蔽するかもしれません。従って、拡張メソッド内で仮想メソッドを呼び出さないのが得策だと言えます。
　拡張メソッドは、ただ便利だからという理由で、気軽に使ってはなりません。実務で使用する際には、よく検討する必要があります。 　

中の人の徒然草375

こんばんは♪読書に精を出しているインドリです♪
ここ最近、すっかり秋らしくなってきましたね。
秋の虫の声を聞きながら、夜遅くまで本を読み、存分に秋を味わっています。
どんな本を読んでいるのかというと、プログラミングに関する書籍、設計に関する書籍、OSの実装に関する書籍、コンパイラに関する書籍、CPUに関する書籍、並列処理に関する書籍、業務知識に関する本、ビジネス書です。
頑張って500冊以上集めているので、その時の気分に合わせて読みあさっています。
私は幼いころから本が好きなので、今すごく幸せです。
話しは変わりますが、最近ようやくブログの楽しさが分かってきました。
ブログは自由に好きな事が書けます。
大した事がないように感じるでしょうが、意外と書ける場所がないんですよね。
記事を投稿したりもしましたが、制約が色々あって、自由に書けませんでした。
紙面も限られているし、他にも色々不便な点がありました。
その点、ブログはその様な制約がなく快適です。
情報処理技術全般を書いていきたいので、私が書きたい事を全て書くのは不可能だと思いますが、制限はありませんのでどんどん書いていきます。
並列処理ひとつにしても、専門書にすると数千ページの大著になります。
その分量の知識を書くのは、ブログが最適だと最近思いました。
課題はどのようにして、情報を纏めるかですが、ひとまず書きたい事を書いて、纏めていこうかと考えております。
これからも当ブログをよろしくお願いいたします。

アジャイル開発と契約7

　この記事はアジャイル開発と契約6 の続きです。前回は機能保証について解説しましたので、今回はアジャイル開発特有の事柄について書きます。
　情報処理特有の問題として、バグが実質0にはならず、機能保証をする事は困難です。しかし、その困難さは、アジャイル開発を採用する事により軽減されます。多くの問題は、エンドユーザーとの認識の違いにより発生するものですから、アジャイル開発によりエンドユーザーの要望を積極的に聞いていれば、認識の違いによるバグは確実に減らせます。そこで、基本契約にエンドユーザーと購入者の参加に関する条項を盛り込むべきです。
　具体的には、エンドユーザーが積極的に参加しない場合、機能保証は出来ない旨を表す条項を設けます。そうする事により、理不尽な訴訟のリスクを避け、提供する商品の品質を上げる事が出来ます。また、保証内容の曖昧さが原因で起こる摩擦もなくなります。これは、販売者と購入者、双方に利益がある事なので、これは契約書を作成する上で絶対に押えておくべき点だと言えます。
　機能保証に関する条項に於いて、注意するべきなのは、保証するべき機能が変化する点です。ですから、基本契約時には細かい事まで踏み込んで書いてはなりません。細かい事柄は、個別契約時にその都度決定しなくてはなりません。ウォーターフォール開発モデルを採用している会社でも、契約時には別の書類に書かれた事を保証するという条項を書く場合が大半であり、同じだと感じる人もいるでしょうが、変化を当然起こるものだと考え、個別契約にて対応する事を前提とする点が違います。この違いは重要なので、十分に注意しましょう。アジャイル開発を採用しても、ウォータ-フォール開発モデルと同様の考えで契約を結べば、真にアジャイル開発を活用している事にはならず、機能保証に関するトラブル生む結果になります。

続く・・・

並行処理の要約

　並行処理は古くからある重要な概念です。昨今はマルチコアCPUが普及し、ますます重要になってきました。しかしながら、並行処理を正しく理解しようとすれば、OS・ハードウェア・コンパイラ・複数のプログラミング言語と多くの知識が必要な上、一般的なプログラマにとってなれない概念が多数あり、敷居が高い事は否めません。そこで、忙しいプログラマの為に、並行処理の要約を書く事を思い立ちました。並行処理の全てを書こうとすれば、数千ページの大著になりますので、この記事ではポイントだけを書きます。
　OSに並行処理の概念が生まれたのは1965年～1980年です。それ以前のコンピュータは、一つのジョブが、テープなどの入出力装置の入出力操作の完了を待つために、実行中のジョブが止まると、CPUはその入出力操作が終わるまでアイドル状態でした。商用分野のデータ処理では、全実行時間の内、待ち時間が80％～90％を占めましたので、CPUのアイドル時間を減らす方法が必要となりました。そこで考えだされたのがマルチプログラミングです。
　マルチプログラミングの考え方は、メモリを複数のパーティションに分けて、パーティションごとに異なるジョブを入れるというものです。こうする事により、1つのジョブが入出力を待っている間、他のジョブを実行する事が可能となりました。これで、アイドルタイムを削減する事に成功しましたが、応答時間が長いという問題が残りました。例えば、プログラムを一文字打ち間違えただけで、コンパイルが通らずに半日無駄にすることがありました。
　応答時間を速くするために、時間ごとにジョブを割り当てる時分割方式が考えだされました。この考えは、マルチプログラミングを進化させました。
　マルチプログラミングシステムを備えたコンピュータは、同時に複数の事が出来ます。例えば、音楽を聴きながら原稿を書いたりできます。しかし、単一CPUは1つのプログラムしか実行できません。複数のプログラムが同時に実行されているように見えるのは、OSが短い時間でプログラムを切り替えているからです。OS設計者は長年にわたって、並列性を容易に扱う為に概念的なモデル（逐次プロセス）を発展させてきました。その結果、プロセスモデルが誕生しました。
　プロセスモデルは、コンピュータ上で実行する逐次的なプログラムを、プロセスと呼ぶ概念で考えて扱います。プロセス深く考えると難しい概念ですが、仮想的なCPUであり、CPUがプログラムを実行するにあたって必要な情報を集めたものと考えるとよいでしょう。
　プロセスは、リソースのグルーピングと実行の独立した2つの概念でなりたっています。プロセスは扱いやすいものの、リソースと実行がセットであるため、色々な不便な面がありました。それで、この2つの概念を分離する方法が模索されました。その結果、実行の概念をスレッドと呼ぶものに任せ、プロセスはリソースのグルーピングをサポートする形態が考えだされました。今日マルチスレッドプログラミングと呼ばれる並行処理プログラミングは、このスレッドを操作する方式のプログラミング方法です。
　スレッドが考えだされたおかげで、並行処理が行いやすくなりました。その反面、各スレッドは、所属しているプロセスのリソースを共有する為、難しい問題が生まれました。同じプロセスに所属するスレッドが、共有リソースを操作する場合、意図しない結果を生みます。例えば、複数のスレッドが、グローバル変数の値を変更する場合、値はスレッドの実行順序とタイミングにより変化しますので、予測できないものになります。この状態では、正常にプログラミングが出来ませんので、色々な概念が考えだされました。
　色々な概念が生み出されましたが、共通している考え方があります。それは、1つのリソースに対して、複数処理を同時に行わないという考え方です。あるスレッドがリソースを操作する権利を獲得（ロック）すると、他のスレッドはそのリソースの権利が放棄されるまで待ちます。こうすれば、リソースの破壊、値の喪失、・・・といった問題が解決します。しかし、デッドロックや優先順位逆転といった、新しい問題が発生しました。
　その新たなる問題から得た教訓は、ロックの期間は極力短くしなければならないという事です。また、リソースが確保できるまで待つという考えは、並列に動作できるスレッドの数を制限する事も意味しました。この状態では、複数のCPUがあっても、パフォーマンスが向上しません。マルチコアCPUが一般化している現在では、これは重要な問題です。
　そこで、アトミック命令が考えだされました。アトミック命令というのは、単一不可分な命令の事を指します。例えば、並列処理では++iといった単純な命令でも値が予測不可能となります。この原因は、インクリメントは、読み込み・変更・書き込みの三つの操作から成り立っているからです。これを単一の命令で行う事が出来れば問題は発生しません。また、同様の考え方で、アトミック変数も考えだされました。
　その他にも、ロック範囲を狭めるという考えから細粒度ロックが生み出され、そもそもロックをしなければいいという考えからロックフリーアルゴリズムが生み出されました。
　今まで述べた概念は優れていますが、並行処理プログラミングは難しいものです。また、マルチコアCPUは一般化し、搭載できるコア数は上昇し続けています。そこで、並行処理を簡単にかつ、コア数の増加にも耐えられるように新しい技術が生み出されています。例えば、インテルTBB、OpenMP、並列パターンライブラリ (PPL)、並行指向プログラミング言語Erlangなどです。それと並行して、並行処理の概念の高度化は進み、データベースの世界から来たと思われるソフトウェアトランザクショナルメモリ（STM）、アクターモデルなどの新しい概念も登場しています。