入門の手引き 第 6 章 | 前の章 次の章 |
ここには、入門コースの最終課題を終えた方のために、 これまでの練習を振り返りながら読んでいただくことがら、およびよくある質問 (FAQ) への回答などが書いてあります。
なお、合わせてマニュアル 「MANDALA.net 基本仕様」 の注意事項一覧をご参照ください。
再度、機械生成が必要なのは次の場合です。
フックメソッドの上記以外の変更、すなわち中身の変更については、 再生成を実施する必要がありません。ですから、統合開発環境を用いた開発の特徴である短いサイクルを損なうことなく、修正・デバッグを進めることができます。
ちなみに、再生成が必要な理由は、アプリケーションの構成要素が変更になった場合にその調整する必要があるためです。
たとえば、フックメソッドのパラメタが変更になれば、それを呼び出すプログラムの変更を必要とするからです。
一般に、アプリケーションの構成要素を削除したり変更したりしたときには、MANDALA.net が生成したモジュールの中で文法エラーが発生する場合が多いので、再生成が必要なことがすぐに分かります。
しかし、文法エラーが発生しなくても、上述の場合には再生成が必要です。
たとえば、構成要素を追加したときには文法エラーとはなりませんし、構成要素を削除したり変更したりしたときにも文法エラーとはならない場合があるからです。
したがって、再生成が必要なのは、文法エラーが発生した場合だけとは限りません。
MANDALA.net が提供する、または生成するプログラムコードと手作りのプログラムコードは、原則としてモジュール単位に分離されるようになっています。
MANDALA.net が提供したり生成したりするモジュールは次のとおりです。
これらのモジュールは、 障害調査の場合を除いてプログラムコードの中身を解読することが禁止されていますし、 解読の必要はありません。
さらに、これらの中身を変更することも、禁止されています。 そして、誤って変更することのないように、 上記の上の 2 種類のモジュールに読取り専用のファイルにしています (ソリューションエクスプローラで見ると、カギがついた表示になります)。 なお、機械生成したモジュールの中身の変更を禁止している理由は、 再生成する度にその変更を反映しなければならなくなるので、 面倒であり生産性が上がらないからです。ですから、機械生成された部分の変更は、 絶対になさらないようにお勧めしています。
これら以外のモジュールは、原則としてアプリ開発者の方々が手作りするか、 以前に手作りしたものを再利用することになります。
手作りモジュールの主要部分は、項目フッククラスと画面フッククラスからなります。 これらは再利用性を高めるように標準化してあるので、 以前に手作りしたものが蓄積してあれば、それを利用できる可能性が高いといえます。 特に、項目フッククラスは、項目名で検索することができるので、 再利用の可否を容易に判断できます。
機械生成は、ビルドエラーを修正してから行うことをお勧めいたします。 なぜなら、ビルドエラーを含むようなソースコードを MANDALA.net コード合成ツールにインプットすると、誤りを含むプログラムコードを生成することがあるからです。
なお、以前に機械生成を実施してある場合には、手作りのプログラムコードを変更することによって、機械生成されたコードにビルドエラーが発生することがあります。 これは、一時的に不整合が発生しているためです。 このような場合は、機械生成によって再調整がなされることになるので、ビルドエラーを実施しても全く問題ありません。 また、とにかく機械生成を実施してみて、ビルドエラーがなくなるかどうかを調べるのも有効な手段です。
ちなみに、ビルドエラーを含むようなソースコードかどうかを間違いなく判定するには、以下のクラスモジュールをプロジェクトから削除してみればよいでしょう。 このクラスモジュールを取り除いてもビルドエラーが発生するようなら、手作りのプログラムコードに誤りがあると考えられるからです。 ただし、ここで述べたようなことは、ほとんど問題になることはないので、あまり厳密になる必要はありません。また、慣れてくると手作りのプログラムコードのエラーかどうか自然に判定できるようになることでしょう。
以下のステップアップのための課題をこなす上で、MANDALA.net の基本的な考え方を理解していると、作業がスムーズにはこびます。
開発をすばやく行うために、また開発に携わらなかった方々にとってもメンテナンスしやすいプログラムにするために、プログラムを“業務仕様に関係する部分”と“操作仕様に関係する部分”に分離することは効果的です。
MANDALA.net を用いて開発すると、自然にこの分離がなされるようになっています。 つまり、操作仕様に関係するプログラムは、MANDALA.net が機械的に生成するか、実動フレームワークとして標準提供されます。 したがって、アプリ開発者の方々は業務仕様に関係するプログラムだけをフックメソッドとして開発すればよいことになります。
注: 「フックメソッドとして開発すればよい」 と書いてありますが、より正確にいうと 「新たな開発」 が必須だというわけではありません。 すなわち、フックメソッドはソフトウェア部品として望ましい性質を備えているために、すでに開発済のものが蓄積してあれば、それをアプリ開発者がプロジェクトに組み込むだけで済む場合が多いのです。 ですから、常に新たに開発する (すなわちプログラミングする) 必要があるわけではありません。
ところで、アプリ開発者の方々は操作仕様に関係するプログラムを絶対に書けないということではありません。 うっかりすると、従来の開発スタイルに慣れている方は、操作仕様に関係するプログラムを書くことが習慣になっていて、そうしてしまうかもしれません。 しかし、そうすると MANDALA.net を用いることによる効果が少なくなってしまいます。 ですから、操作仕様に関係するプログラムは MANDALA.net にまかせるようにお願いします。
基本的は、操作仕様に関係する部分と業務仕様に関係する部分を分離して、MANDALA.net とアプリ開発者の方々が分担してプログラム開発を行うことが原則です。 ところで、奇麗に分離できないボーダライン上のプログラムも少しばかり残るかもしれません。 このようなボーダライン上のプログラムについては、操作仕様に関係するものなのか業務仕様なのかを区別して分離するのだという意識をもって開発にあたるとよいでしょう。
VB や C# のイベントは、マウスボタンやキーのアップおよびダウンなどハードウェアに密着した体系になっています。 このようなローレベルのイベント体系は、ハードウェアを思い通りに制御するには都合がよいといえます。
しかし、ビジネスシーンに登場するイベント (たとえば注文を受けたとか月末のしめを行うなど) とのギャップが大きいために、 これらの間を埋めるためのプログラムを大量に必要とするのが普通です。
この問題の解決策を突き詰めていくと、ハードウェアに密着したイベント体系よりもビジネスシーンに登場するイベントに近いところでイベントを体系化すれば、 ギャップが小さい分だけ必要なプログラム量が少なくなることが分かります。 MANDALA.net のフックメソッドの体系は、このような考えに基づいて設計されています。 したがって、VB や C# のイベントハンドラがハードウェア側に近いとすれば、フックメソッドは業務の側に近い高いレベルにあるということができます。
裸のままの VB や C# をダイレクトに使用する場合には、数多くのイベントハンドラを用意することで業務プログラムになります。
VB や C# と MANDALA.net を併用する場合には、数多くのフックメソッドを用意することで業務プログラムになります。 フックメソッド以外のプログラムは、基本的に MANDALA.net が機械的に生成されたもの、 または標準提供のライブラリでまかなうことができますから、アプリ開発者の方々はプログラムを作成する必要がありません。 基本的には、フックメソッドだけを用意すれば、業務プログラムが完成することになります。
そのフックメソッドは、次の特徴を備えているために、大変にプログラミングしやすく、また理解しやすいということができます。
VB や C# のイベントハンドラには、操作性などに関係するプログラムと 業務に関係するプログラムが混在するのが普通です。 これとは対照的に、フックメソッドは、操作性などに関係するプログラムが混在しにくいインタフェースになっています。 すなわち、業務に関係するプログラムだけを取出して記述しやすいインタフェースになっています。
VB や C# のイベントハンドラは、各項目ごとに分かれていますが、 そのイベントハンドラの中に複数の項目に関係するプログラムが混在することがあります。 これとは対照的に、フックメソッドは、複数の項目に関係するプログラムが混在しにくいインタフェースになっています。 すなわち、一つの項目に関係するプログラムだけを抽出して記述できるインタフェースになっています。 ですから、フックメソッドは、各項目ごとにすっきりと分離されることになり、 再利用できる可能性が非常に高くなります。
以上をまとめると、業務プログラムを開発するには、 業務仕様に関係するプログラムを標準的な型にはめこんだもの、すなわちフックメソッドを用意して (用意するとは、すでに開発済みのものを集めて組み込むか、新たに開発するという意味です)、 MANDALA.net に機械生成の指示を与えればよいといえます。 こうすると、フックメソッドが糊付けされて、実際に動作する業務プログラムになります。
MANDALA.net の利用者の方々の経験からも裏付けられることですが、
業務仕様に関係するプログラムの大半は、初期値設定仕様、チェック仕様、表示仕様の三つに関するフックメソッドの形式にあてはめて記述できることが分っています。
なお、この三つでカバーできないプログラム部分に関しては、これら以外に十数種類の別のフックメソッドがありますから、
それらのどれかの形式にあてはめればよいことになります。
この後に取り組むべきステップアップのための課題としては、ここで作成した画面アプリを Rensyuu4 と同様のものにレベルアップすることをお勧めいたします。 これには、まず Rensyuu3 と同様のものにしてから、Rensyuu4 へと段階的に進むのがよいでしょう。
Rensyuu4 のレベルにするには、まず画面部品 (画面フッククラス) を追加し、 画面フックメソッドおよびファイルアクセスルーチンを用意することが必要です。
マニュアル 「MANDALA.net 基本仕様」 を参照の上、この課題に取り組んでください。
画面フックメソッド (画面フックメソッド) が呼び出されるタイミングについての理解を深めるためには、そのログをご参照ください。
プロジェクト Rensyuu4 を開いて、VS2008 のもとで実行させる (デバッグ開始の指示を与える) と、出力ペインに 画面フックメソッドのログが時々刻々と表示されるようになっています。
画面フックメソッドがどのような場合に発生するのか、 画面アプリを操作しながら VS2008 の出力ペインを見ることによって理解を深めることができます。
これにならって、項目フックメソッドのログも表示するように プログラムを追加してみましょう。 Debug.WriteLine というメソッドを使うと簡単にログを表示することができます。
これにならって、項目フックメソッドのログも表示するように プログラムを追加してみましょう。 System.out.println などを使用することで eclipse のコンソールウィンドウにログを表示することができます。
入門の手引き 第 6 章 | 前の章 次の章 |