企画物の最近のブログ記事

　アンケートシステムの番外編です。番外編を書く暇があったら、アンケーシステムを完成させろよと言われそうですが、気にせず書いていきます。

　レベルの付け足しと今後のプログラミング記事の記事で、アンケートシステムを簡略化すると書きましたが、どれくらい簡略化するかと言うと、一つしかアンケートを出来ないようにします。アンケートごとに関する表示を作成するのが面倒くさいので。メニューにするとこんな感じです。

1.アンケートの作成
2.アンケートの投稿
3.項目の一覧を表示
4.アンケートを削除

「1.アンケートの作成」で作成又は修正する感じです。作り的には、後々複数投稿するシステムに変更するのに、それほど難しくない作りだと思います。Rubyでプロトタイプをぼちぼちと作成しているのですが、作成して思った事を今回の記事では書きます。

　Javaで作成する事に慣れているので、やはりオブジェクト指向で考えてしまいます。Rubyもオブジェクト指向ですが、Javaとは違う箇所やJavaの作りでは出来ない処理も出来てしまいます（Rubyではそのような作りになっているので当然ですが）。

Javaでは、すべての作りがクラスで作成するようになっています。ちょっと待てよ、インタフェースは？と思う方もいるかと思いますが、インタフェースでは処理は作成できません。C言語でも、C言語はすべて関数で作成されているといった場合に、ヘッダファイルやマクロ等があると反論しないと思います。実際マクロや構造体を処理するのは関数の中ですから、C言語はすべて関数で作成されているのだと言えます。マクロの定義は、オブジェクトファイルですべて置き換わっていますし、構造体はメモリ上に領域が確保されるだけです。

今、考えているのは、画面の情報を画面フォームオブジェクトに格納し、実際処理を行って、DBに格納するポーターオブジェクトに代入します。ポーターオブジェクトを使いDBで処理を行います。DBからデータを取ってくる場合は、この考え方の逆で行います。列挙すると以下の感じです。

１．画面から情報を受け取り、画面フォームオブジェクトに格納する。
２．画面フォームオブジェクトのデータを使い、処理を行う。
３．画面フォームオブジェクトをポーターオブジェクトに代入する。
４．ポーターオブジェクトのデータを使い、DAOでDBの処理をする。

上記の考えは、MVCの考え方や三層構造の考え方です。

画面フォームクラスは、画面の情報を基に作成されます。画面とプログラム（VIEW）のデータの橋渡しです。変数名や日本語名は画面名から導き出します。画面が変更されれば、画面フォームクラスも変更されます。又、DBのテーブルや項目の変更に影響されません。

ポータークラスは、DBの情報を基に作成されます。DBとプログラム（DAO）のデータの橋渡しです。変数名や日本語名はDBのテーブルや項目から導き出します。DBのテーブルや項目が変更されれば、ポータークラスも変更されます。又、画面の変更に影響されません。

作りとしては、オブジェクト指向の考え方に合致していますね。

　考え方として問題となっているのは、処理の部分です。オブジェクトで共通する処理がある場合を考えていきたいと思います。Javaでは、共通した処理を使いたい場合に、しばしば親クラスを作成し、継承させてクラスを作成します。それが、「is a」の関係になっていれば、良いのですが、必ずしもそうとは言えません。本来共通した処理がある場合は、処理だけを独立されてクラス等に使わせる必要があります。Javaなら処理するクラスを作成して、そのクラスを各クラスで使用しても良いと考えているのですが、親クラスで定義させることが多いですね。一般的に言われているユーティリティークラスはそのようになっているのですが...

　Rubyでは、Mix-inが利用できます。Mix-inとは、モジュールをクラス等に取り込むことで、クラスならクラスで定義したメソッド等と同じように操作できる事です。このため、クラス間で共通の処理がある場合は、モジュールで作成し、各クラスが共通のモジュールを取り組めば良いことになります。その事により（Javaとは違い）、無理やり継承（is aの関係）させる必要はなく、共通処理を行わせることができます。この考えは、オブジェクト指向の「has a又はpart of」の関係も実現する事が出来ます。Javaでは、「has a又はpart of」の関係を実現させるには、内部クラスで実現できますが、他のクラスで使用する場合は結局、継承させる必要があります。

　又、Javaのインタフェースを適切に利用しているシステムも少ないと思います。インタフェースの役目として、C言語のヘッダファイル（プロトタイプ宣言や定数の作成）、ポリモルフィズムの実現にも利用されなければなりません。

　好き勝手に書いてきましたが、理想と現実は違うという事ですね。と言っても、私に理想的な設計できる能力があるかと言われると、勉強中としか答えられませんが。Rubyのアンケートシステムは早ければ今月中に完成させる予定でいます。

　前回のRubyの記事（Rubyで作成するアンケートシステム　MySQL編）では、RubyからDBの操作を紹介しました。今回は、アンケートシステムで使用するDBの設計書を紹介します。今回はRubyと関係がありませんが何かの題材にでも。

　勉強用なので、設計書と言ってもERDとSQL文です。テーブル設計は無く、あるのはMySQLとPostgresSQLで試したSQL文ぐらいです。SQL文は、主にMySQLに対応していますが、テーブル作成部分は、PostgresSQLでも動作を確認しています。

ファイルにまとめました。説明もファイル中にあります。
QNS_RD.xls
テーブル作成.sql

　自分が住んでいる土地は現在いくらか知りたくありませんか？プログラムを使って算出してみます。今回は、簡単に土地の評価額を算出するためのプログラミング作業の準備段階になります。

今回のテーマとねらいです。

●テーマ
　土地の評価額をシンプルな計算で算出する。

●ねらい
　土地の評価額に必要な路線価の調べ方を知ってもらう。

　土地の評価額には、1平方メートル当たりの価格に路線価を使い算出します。路線価とは、国税庁のホームページ「財産評価基準書」（http://www.rosenka.nta.go.jp）から調べることができます。土地の評価額を算出するのに一般的に使用されます。調べたい土地は、路線価図を使用することにより路線価が調べられます。

　路線価の単位は、1000円です。例えば、200と書かれていれば、200千円です。数値以降のアルファベットは、借地権の割合を示しています。借地権の場合は、地主ではないのでその分評価が下がるということです。

　土地の評価額は、「路線価×面積」で計算されますが、その他にも細かく算出する場合には土地の形状、接道条件、高低差、用途地域などを配慮する必要があります。ブログの最終目的は、プログラムで自動的に行うことが目的ですので、なるべく配慮したいところです。例えば、奥行価格などです。奥行価格に対する説明は、２－４．（１）奥行価格補正に詳しく書かれています。

　最終目的は、プログラムでの自動化（プログラムの勉強が主目的）ですが、すべてを配慮すると市販のソフトウェアのように複雑になってしまうので、プログラミングを楽しめる程度、勉強できる程度にしておきたいと考えています。

　次回は、シンプルな方法の算出でシンプルなプログラミングを作成します。

　先日、ICレコーダーを買ってきて、何か試せないかと思い以前書きました効率 その1　Java アクセサ の 作成を音声による説明をテスト代わりにしてみました。テストということもあり、言い間違えがありますが、そのまま投稿します。

ブログもそうなんですが、私自身完璧にやろうとはせず（例えば、ブログなら毎日投稿など）はじめは地道に進めます。これから私が作成したプログラムぐらいは音声付きの解説ができればよいと考えています。音声を投稿するのははじめてなので、初心ということで投稿して後々の変化がわかればと考えています。もちろん、解説がうまくなることを願ってです。

今回は、編集も何もしていないので、効率 その1　Java アクセサ の 作成に追加せず、ここに投稿しました。

音声ファイルです。

  080729_004.mp3

約7分間収録されています。記事なら3分ぐらいで読めてしまう内容なのでいかにコンパクトにまとめ、要点を押さえられるかが課題です。営業道のように、はじめはこんなものだと思ってがんばります。はじめの踏み出す一歩が大事ということで。

　ICレコーダーの事や今回使用したICレコーダーの説明は後々投稿します。

　資格は仕事に役立つのか　その1 単体テスト編2では、ブラックボックスについて書きました。今回は、ホワイトボックスと網羅についてです。

　単体テストの一つである構造テストは、テストの範囲をプログラムコードから分析しコード全てが網羅しているかどうかを調べます。プログラムコードから分析することにより本来起こらない条件もテスト出来ることからホワイトボックスなテスト（中身が見える）と言えます。

試験では、「命令網羅」、「判定条件網羅」、「条件網羅」、「判定条件／条件網羅」や「複数条件網羅」が出題されますが、通常はカバレッジツールを利用して、テストを行うのでチェックリストの作成段階では意識する事はありません。

カバレッジツールを利用していれば、カバレッジモニタで網羅の基準となる「C0」、「C1」、「S0」、「S1」が表示されるので簡単に状況を知ることができます。通常は100%になるようにテストします。チェックリストですべて100%になるようなテストを作成できれば一番好ましいのですが、チェックリストをすべて行っても網羅が100%にならない場合は追加テストなので補完します。

通常起こらないテストとは、例外処理が中心となるでしょう。例えば、JavaならDBに障害が起きてアクセスできない事を想定して、例外をわざとスローさせます。例外がキャッチできて適切にプログラムコードが想定した動作をするのかなどをチェックします。私はまだ通常時にIOExceptionが発生した事はないのですが、当然ここもわざと例外をスローさせて対応をみます。

プログラム作成から当然例外処理を意識して作成しているので、特に大変なの事はないですが、構造テストでしっかりとログを見ることが大事です。ログも当然単体テストの為、エビデンスを残すのですが、それだけではなく構造テストはすべてのパターンのログが出力されることになります。出力されたログで本当に内容がわかるのもチェックすると後々のテスト時の後戻りがなくなります。

ログの出力はすでに設計時にばっちりと決められていることが多いですが、ログ時に出力するメッセージやバグ用に出力する内容は変更できることもあります。変更できる時には、自分の能力を発揮するチャンスでもあります。単体テスト以降に続くテストは当然ですが、運用時に問題が起こった時にもログが重要だからです。

　カバレッジ(coverage)とは、コードの網羅度のことでステップ法に続いてテストの品質を決める要素でもあります。テスト数はテストを行う目標値として扱われるので最初に作成したテスト数の数をこなせば単体テストが終了するというわけではなく、ガバレッジが100%にならないと単体テストが終了と認めらないことのほうが多いでしょう。

ガバレッジと網羅の言い方は、私が経験した中では人それぞれなのでどちらでも言いように感じます。

 資格は仕事に役立つのか　その1 単体テスト編1では、テスト数を決めるステップ法について書きましたが、今回の単体テスト編2は、ブラックボックスに付いてです。

　単体テストには、大きく分けて機能テストと構造テストに分ける事ができます。機能テストは、ブラックボックス技法を使い、構造テストは、ホワイトボックス技法を使います。

機能テストとは、テストの範囲を機能からテストすることにより仕様書通りに動作するかどうかを調べます。コードを意識しないことからブラックボックスなテスト（中が見えない）と言えます。ブラックボックスは、資格同様に「同値分割法」、「限界値分析法」がメインなのは、実際も同じと考えて良いでしょう。

私が苦労した点といえば、画面系のテストです。画面では、入力させない文字や最大入力桁のテストなどを行い項目が6以上になるとテスト数が増え大変でした。項目1つに大体15個で5項目なら組み合わせのテストで80ぐらいの数になっていました。プログラミングしながらテストをする為、15程度なら大したことはないのですが、単体テスト編1にも書きましたエビデンス（証拠）を残さないといけません。中には入力不可の文字テストなどのエビデンスが撮れない場合があり、その場合には「目視」と単体テスト書に記述する事もあります。

画面項目はテスト項目に応じてですが、DBがかかわってくると、テスト項目１個に対して3個ぐらい証拠の過程が必要でした。例えば、追加なら、登録する内容を示した画面、実際に処理が行われているコード（ビーンやポーターなどに適切に値が入っているか）、結果のメッセージ、DBのテーブルの中身、ログ（SQL文など）などです。画面で適切なテストが行われていれば、「同値分割法」、「限界値分析法」を行わなくても前提条件が終了している為、テスト数は低減できますが、当然追加の場合には主キーが既に行われているなどのテストがあります。1つテストを作成すれば（例えばDB関連のテスト）自ずとそれに従うテスト項目が浮かんでくるでしょう。

次回は、ホワイトボックスに付いてです。

　効率 その3では、効率をする上での私なりの実践方法を紹介します。

　プログラミングだけに限りませんが、物事は細かく分け目標というよりかはTODOを利用することにより、確実に仕上げるのがベストだと考えています。TODOを利用するのに、色々なフリーソフトなどが利用できますが、一番は身近なアプリケーションを利用することだと思うので、私はExcelを使用しています。以前、GW企画で進行具合がわかる管理表を用意しましたが、見てもらうと分かると通り、非常に簡単なものです。

TODOを利用していると書きましたが、TODO以外にもアイデアマラソンで有名な樋口健夫さんの著書（図解　仕事ができる人のノート術）で紹介されている「マラソン日記」を利用しています。また、私は常に5冊ぐらい（ジャンルが違う本）を同時並行で読むため、どこまで読んだかわかるように本の管理にも使用しています。

実践している管理は、すべてExcelを利用しているのですが、毎回入力しなくてはいけない作業も多くいくら先行投資をしているとしても面倒なことには変わりありません。そこで、私は、VBAを利用して少しでも無駄な作業を減らしています。少し紹介をします。ここ（ Management.bas）からダウンロードできます。ダウンロードできるように、プログラムを修正しましたが、汎用性はほとんどありませんので、自分で修正する必要がまだありますが、書き方を覚えれば、問題なく使用できます。利用方法は、ここ（ Management_ReadMe.txt）からダウンロードできます。

参考URLです。

アイデアマラソンへようこそ

attr_accessor:変数名

　Rubyを簡単に紹介すると、プログラミングにデフォルトを用意し、デフォルトと違う処理だけを独自に作成すると言えます。デフォルトとは、「attr_accessor:変数名」のように決まった処理の事で、アクセサ設定の場合に限れば、他にも「attr_reader:変数名」や「attr_writer:変数名」があります。それぞれ説明すると、最初がアクセサ、次にゲッタ、最後にセッタの設定です。これらの指定は、変数の値を取得・設定をする場合に使用し、デフォルト以外の処理をする場合（例えば、範囲チェック）は「attr_xxxx:変数名」を指定せずにJavaのようにメソッドを作成して、プログラミングを行います。

　プログラミングを知ろう、学ぼうと言う企画で全7回説明してきましたが、7回目は6回説明してきた事やこれからどう勉強するかについてまとめます。

　この企画の受講状況を各自で管理してもらおうと思い管理表をGW_firstJava.xlsからダウンロードできますので使ってもらえると各自の進行具合が分かります。学び終えた場所の「日付」に「Ctrl+;」を「時刻」に「Ctrl+:」を押せば終了した日付と時刻を記憶できます。PDF版はGW_firstJava.pdfからダウンロードできます。なお、ファイルはウィルスバスターでウィルスチェックしています。