月別アーカイブ: 2009年08月

4 posts

セットアッププログラム

5月だったか[ソフトウェアの開発 Etc]で触れましたが、
パッケージソフトであれ受託ソフトであれ、開発が完了したら、
最終的にはそれを顧客のコンピュータにインストールしなければいけません。

そのためには開発とは別にインストールプログラムを作成しなければいけません。
Visual Studio 6では(およそ10年前)、
ディストリビューションプロジェクトというのがあって、これでインストールメディアを作っていましたが、
この仕組みは先にも書きましたように、
必要とする関連ソフトを闇雲にターゲットコンピュータにインストールするので、[Dllの地獄]という状態を作り出していました。

それを解消すべく、マイクロソフトはMicrosoft Installer(MSI)を開発し、あらかじめターゲットコンピュータにこのMSIをインストールしておいて、個別のソフトのインストールはMSIがすべて一元管理するようにしました。今ではMicrosoft InstallerがWindowsでのインストール標準になっています。

Windowsの開発環境であるVisual Studioでは、標準でmsi準拠のセットアッププロジェクトを作成する仕組みが提供されています。ただインストールする条件もいろいろあるため、いわばアドホック(場当たり的)な部分があります。
近年、インストール条件をXMLで記述する技術がオープンソースとしてMicrosoftから発表されました(WIXといいます)。
これによってインストール条件の設定についてはだいぶ透過性がよくなったと思います。がこれも発展途上というところだと思います。

インストールプロジェクト作成ソフトとして日本で最も有名なのは、[Install Sheild]ですが、このソフトは何故か年々高額になって、現在では一本数十万円から100万円を超える価格になっています。

高額なソフトや大量に販売が見込めるソフトのインストールプログラムの作成であれば、[Install Sheild]はベストチョイスでしょうが、そうでなければなかなか手が出ません。

この様な状況の中で、できるだけお金をかけないで、いまセットアッププログラムを作成するのにどのようにすればいいか。私たちのケースをご紹介いたします。

インストール時にユーザにシリアル番号等特に厳密はチェックを必要としない場合は、Visual Studioのセットアッププロジェクトを使うのが便利です。Visual Studio 6で開発したソフト(.NETを使っていない)であれば、Visual Studio 2003のセットアッププロジェクトが使えます。残念なことは、Visual Studioのシリアル番号のチェックは甘いので、厳密なチェックはできません。

あるプロ不ラムをインストールし使うには、別のソフトが必要な場合があります。たとえば.NET Frameworkやクリスタルレポートが必要な場合は、それらのソフトがターゲットコンピュータにすでにインストールされているかどうか調べ、なければこれらをインストールしなければいけません(ランタイムのプレインストール)。

Visual Studioは、このあたりの処理は見事にやってくれます。
Visual Studioの短所は、こまめな処理ができないということです。たとえば、先の例で独自のシリアル番号チェックプログラムを組み込むことができません(少なくとも私たちにはわからなかった)。

 WIXはこのあたりの処理ができます。私はWIXがすきです。WixEditというWIX用IDEツールがあります(Sharp Developも要検討)。なかなかいいのですが、WIXを使いこなすには少し勉強が必要です。
それと、これはWIXの仕様だと思うのですが、ランタイムのプレインストールができないようです。
この部分は、Visual Studioと組み合わせて使うことができるのではないかと考えています。

WIXを時間をかけて勉強する時間がなかったので、私たちはInstall Aware(以下IAといいます)というソフトを使いました。理由は比較的安く、やりたい機能がそろっていたからです。ただし、ドキュメントが悪いし、サポート対応が悪い。それに日本語版(IDEでの日本語表示等)はないのです。
IAにはScriptと称するものがありますが、この言語仕様がない。チュウトリアルもない。手探りで習得するしかない。
Scriptは言語というよりいわばコマンドセットで、ともかくこのコマンドの使い方を習得するのがIA習得の手っ取り早い方法です。
機能や使い方そのものは悪くないのに、このドキュメントの悪さは何なのかと不思議に思います。

LINQ をどうするか 2

いつまでも勉強している訳にもいかないので、我々としてのLINQの評価をしなければいけません。

結論からいえば、LINQの採用は最小限にすることにしました。

理由は、LINQはDBへの問い合わせあるいは更新等(CRUD)については、だいぶ機能がそろっていると思いますが、これらのデータの表示については柔軟性に欠けると判断したからです。

LINQのサンプルとしては読み込んだデータをDataBindでコントロールに表示する例が載っています。しかし私たちはDataBindingを採用していません。ADO.NETの最初期に私たちも一度この採用を検討したのですが、おそらくバグと思われる異常な動きをするため使うのを断念しました。

そのためDBから得た情報をコントロールに表示するとき、すべてFormatし、逆に画面データをDBに書き込むときにはすべてParseしてからDBに書き込んでいます。LINQは遅延読み込みをしているのも一因だとおもいますが、LINQでよみこんだデータを効率よく体系的に(私たちのソフト資産を生かして)FormatなりParseなりをする方法を考えつきませんでした。

また、私たちは米FarPoint社のSpreadを多用していますが、FarPoint社のLINQ DataBindの対応がイマイチなのも理由の一つです。

これらの理由から私たちはLINQを全面的に採用するには時期尚早と結論しました。

便利に使えるところは使いますが、全面的には使わないことにいたしました。

LINQ をどうするか

O’Reilly の[Programming Entity Framework]の9章まで読んで、開発途中のプログラムをLINQで書き換えています。[LINQ in Action]と2冊の拾い読みでは、なかなかスイスイとLINQは使えません。実際書いてみるといろいろな問題が発生します。

これまでADO.NETを使って、DBとは非接続で作業をしていました。LINQは遅延接続でむしろ「非接続の時間を少なくする」というコンセプトのように思います。既存のプログラムを大幅に書き換えないで、LINQの長所をどのように取り入れるか。

また、単純なことですが、クエリであるテーブルを使用したとします。LINQ to SQLやLINQ to Entity Framework のWizardを使うと、テーブルに対応したクラスが自動的にプログラム内に作成されます。
別のクエリーで再度そのテーブルを使用しようとすると、すでに最初のクエリでそのテーブルに対応したクラスがありますので、クラスの再定義になりエラーになります。逃げる方法があるのか。

このように検討しなければいけない問題が多々あります。
必要に応じて文献等を読み返し、実務に沿って勉強していきたいと思います。

[プログラミング LINQ]は訳が悪いし、[LINQ in Action]は話題が少し古い。[Programming Entity Framework]は解説書としては余りにも不親切です。新たに[Murach’s ADO.NET 3.5, LINQ, and the Entity Framework With VB 2008]を注文しました。勉強する情報としてはこれらとオンラインヘルプで充分でしょう。

LINQあるいは[Entity Framework]そのものの学習は当然ですが、新しいコンセプトによる技術はそれなりの「癖」がありますので、これを使いこなすとなると、この習得には少なくとも後1ヶ月はかかるだろうと予想しています(たぶん甘い)。

ADO.NETでも、従来のデータベースプログラミングと大きく異なりましたので、これを使いこなすまでに半年程度かかりました。
ADO.NETは、David Sceppaの[プログラミング ADO.NET]で勉強しました。何か不満が残る本です。「要所をキッチリ押さえていない」と感じました。

予断ですが、Visual BasicのFrancesco Balenaは100%信頼しています。とても要領よく的確に解説します。VB6の解説書から3つのシリーズを買いました。「頭のいい人なのだろう」と勝手に想像しています。この人の解説書なら出版されれば文句なく即座に購入します。

建築設計とソフトウェア開発

ソフトウェアの信頼性をどのようにして確保したらいいのかという議論がされ始めた時、そのお手本を建築設計に求めたと思います。

オランダのダイクストラが”Structured Programming”(日本語訳「構造化プログラミング」)を提唱したのは1960年代のことです。
彼のなんと言う本だったか、私も買ってかじりつきましたが、記号論理学や数学基礎論等を使って色々な証明をしていました。せいぜい200ページ程度の本でしたが、私には難しくて最後まで読むことができませんでした。
それはともかく、ダイクストラがどの程度建築設計の方法論を意識したかは知りませんが、少なくともタイトルに建築を想起させる「構造化」という用語を使用したのは、象徴的であったと思います。

建築設計は数千年の歴史をもちます。建築設計の方法論は古くて新しい議論です。
通常、建築では施主からの要求条件が出されると、まずエスキース(スケッチ)という段階で基本的な案を練ります。次の段階は基本設計です。建物の基本的な配置や形状が決定されます。続いて詳細設計で必要な詳細図を書きます。更に工事にかかると、実施図を書き、これを見て職人が仕事をします。建築設計では、設計の後戻りはありえません(もちろん現実にはあるが、それはあってはいけないことです)。

ソフトウェア設計の研究者は、このような建築設計の諸段階も研究したと思います。開発手法として最初期に提案された手法は、建築の設計手法と同じく後戻りしない手法で、後にこれをウォーターフォールといっています(建築設計とソフトウェア開発では、何かの違いがあると思います。ウォーターフォールの欠点が指摘され、最近のアジャイル開発まで様々な提案があります)。

またオブジェクト指向プログラミングの時代になって、デザインパターンの提唱がなされましたが、この原案は建築家のクリストファー・アレキサンダーがやはり1960年代に提唱したものです。

建築もソフトウェアもゼロから「もの」を作る創造の世界です。
似たところが沢山あります。しかし、決定的に異なる部分があります。建築設計は視覚的です。設計図も図面という視覚的な媒体を使いますし、建築そのものも視覚的です(もちろん物的、空間的です)。ソフトウェアはIDEを通して視覚化できますが、それはソフトウェアの一側面を表示しているだけです。ソフトウェアの本質はロジックで、基本的には設計者(あるいはプログラマ)の頭脳の中で構築していきます。

建築設計での図面のミスは、ベテランの技術者であれば、即座に指摘することができます。
しかしソフトウェアでミスを見つけることは大変難しい作業です。

人間の視覚によるパターン認識は、ロジックによる認識の何十倍何百倍も強烈です。そこに建築設計とソフトウェア開発の根源的な差異があるのだと思います。

建築の方法論では、たぶんに恣意的な面があり、人によってその解釈に差異が生じます。デザインパターンは建築の分野では、話としては分かるが広く明快に理解され、普及したわけではありません。

その点ソフトウェアのデザインパターンは、明確に定義づけられ、それなりに役立つ手法になっています。