きしだのはてな このページをアンテナに追加 RSSフィード

2005-08-25(木)

[]PM向けフィジカルの問題 05:05 PM向けフィジカルの問題 - きしだのはてな を含むブックマーク

4艘の小船があって、向こう岸を行き来するのにそれぞれ片道1分、3分、6分、9分かかるとする。

ひとりの漁師がこの4艘の小船を向こう岸に持っていこうと思っている。

漁師は一度に2艘の船を運ぶことができるが、そのときにかかる時間は遅い方の小船の所要時間になる。

これらの小船を運ぶための最短時間は19分であるが、n艘の船があって所要時間をそれぞれS1分、S2分、・・・Sn分と与えたときにすべての船を運ぶのにかかる最短時間とその手順を求めるプログラムを、最寄のプログラマに作成させたときに必要になる時間を見積もれ。

・「殺伐とした家族の小船の問題」のソースコードと解説は得られているとする。

トランザクションに余裕がないらしいので、それなりに効率がよいプログラムが求められている


ようするに、コミュニケーションも必要なくて技術変化もビジネス要求の変化もなくて、技術的な問題もあらかた解決してて、カオスでも複雑系でもないとしたらソフトウェア開発は予測可能なのか?という話。

2005-08-23(火)

[]データベースカバレッジを考えたデータ作成 05:55 データベースカバレッジを考えたデータ作成 - きしだのはてな を含むブックマーク

とりあえず、データベースカバレッジを考えたデータ作成を考えてみます。

まず、大きくわけて3つのカバレッジを考えます。

「単一テーブルの条件カバレッジ」というのは、ひとつのテーブルの列の値について、数パターン考えられるときに、それぞれの列の条件を組み合わせるカバレッジです。例えば「受注」テーブルで「受注日」「出荷済」「入金済」という列があったとき、「受注日」について今月、先月、去年、今月末、今月頭、先月末という6パターンの値を考え、「出荷済」「入金済」に関してはそれぞれ「済」と「未だ」という2パターンを考えるとき、6×2×2パターンすべての組み合わせのデータを用意するという考え方です。

このカバレッジの場合は、テストデータを作成するためのツールもたくさんあるし、自作するのも難しくないので、比較的簡単に満たすことができます。


問題は、関連テーブルを考慮したカバレッジです。

「関連テーブルの行数カバレッジ」は、例えば「受注」テーブルと「受注明細」テーブルがあったときに、「受注明細」がない「受注」データ、「受注明細」が1件だけある「受注」データ、「受注明細」が複数ある「受注」データ、のように、関連データの行数の組み合わせを考慮するカバレッジです。

「関連テーブルの条件カバレッジ」は、前の例の「受注明細」テーブルに「取消」列があるとき、「取消」された「明細」を含む「受注」データ、「取消」されてない「明細」だけを含む「受注」データ、のように、関連データの条件の組み合わせを考慮するカバレッジです。

この場合は、ここで例に挙げた「代表」「明細」関連よりも、「データ」「マスタ」関連での考慮が大切になるかもしれません。つまり、取り消された「商品」の「受注明細」、取り消されてない「商品」の「受注明細」のようなデータの組み合わせです。


もちろん、これらのカバレッジは組み合わせて考えることになります。ただし、ここで、すべての組み合わせとまではいかなくても多くの組み合わせを準備しようとすると、簡単に手におえない数の組み合わせになってしまいます。そこで、いかに効率のよいデータの組み合わせ方を考えるかということが、データベースカバレッジという考え方の重要な部分になります。

基本的には

  • 機能ごとにわけて考えること
  • 条件に優先順位をつけること
  • 関連テーブルの行数カバレッジでは、優先度の非常に高い条件だけ考慮すること
  • 関連テーブルの条件カバレッジは、とりあえずまとめてしまうこと

が有効な気がしました。

少し考え込んでしまうと、組み合わせの深みに簡単にはまってしまうので、レアケースのひとつのバグを見つけるよりもメジャーケースを確実に動かすということを頭に置きながら簡単な組み合わせを広く用意したほうがよさそうです。


このカバレッジの中に「単一テーブルの行数カバレッジ」を含めなかったのは、単一のデータベースで網羅できないからです。

「受注」テーブルにデータがない状態と「受注」テーブルにデータが一件ある状態と「受注」テーブルにデータが複数ある状態は共存できないからです。データの条件は共存できますが、テーブルやデータベースの条件は共存できません。

そういった意味では、「データベースカバレッジ」ではなく「データカバレッジ」というほうがいいのですが、組み込み系で「データカバレッジ」という言葉が使われているので、ここでは「データベースカバレッジ」と呼んでみました。

2005-08-22(月)

[]データベースカバレッジという考え方 09:53 データベースカバレッジという考え方 - きしだのはてな を含むブックマーク

データベースアプリケーションのテストデータを用意するとき、どういうデータを用意しますか?

「注文があって出荷してないデータ」「注文があって出荷していて入金がないデータ」という風に業務の流れにそってデータを考えることが多いと思います。


ただ、テストの本を見ても、どうやってテストデータを用意するかということが書かれていることは多くありません。というか市販の本で見たことがありません。

データベースアプリケーションでは、ひとつの処理でまったく分岐がなく上から下にSQLを順番に発行するということが少なくありません。そういうとき、C1とかC2とかの処理カバレッジというのは簡単に100%に近くなってしまい、テストがアプリケーションの状況を網羅しているかどうかという指標にはなりにくくなります。

データベースアプリケーションでは、「すべての処理を行ったかどうか」という処理カバレッジでは充分ではなく「すべてのデータの組み合わせで処理を行ったかどうか」というカバレッジが大切になると思います。つまりデータベースカバレッジ

このときのデータの作り方を、業務の流れを考えるものではなく、もっと機械的に考えれるようにしたほうがいいんじゃないかと思います。


データベースアプリケーションというのは、多数の状態が同時に存在する中で、興味のある状態を抽出して次の状態に遷移させるという独立した処理を集めたアプリケーションです。そうすると、すべての状態を用意することができれば、処理の流れをテストする必要が低くなり、単独の処理をテストするだけである程度の品質が確保できるようになります。

実際に今回つくった業務アプリで、あらかじめ「データベースカバレッジ」ということを意識したデータを用意しておいたのですが、そうすると

  • 処理を組んだときに、すでにその処理を動かせる状況になっている
  • 特定の処理を動かすために、処理の流れを追う必要がない
  • 処理を軽く流すだけでも不具合が洗い出せる

という風になって、処理の安心感が高くなりました。

データベースアプリケーションにおいては、それぞれの処理に影響のあるデータの組み合わせをすべて用意すること、データベースカバレッジをあげることで単体テストの質をあげることができます。


おそらく、同じことを考えている人は多いと思います。むしろ、日ごろ体系的なテストをしないぼくよりも確立した考えを持っている人も多いのではないかと思います。そういった考えをもっと明文化されていけばいいなぁと思うわけです。

makotanmakotan 2005/08/22 09:58 データの状態の管理をするライブラリがあれば見える化できて良いんですよ・・・ぶり2みたいに(w

nowokaynowokay 2005/08/22 12:21 ぶり2の見える化きぼんぬ。

2005-07-22(金)

[]オブジェクト指向とクラス指向 17:16 オブジェクト指向とクラス指向 - きしだのはてな を含むブックマーク

今、オブジェクト指向とよばれているものは、結局のところクラス指向です。

オブジェクトを見出して、そこからクラスを見出して、クラス同士の関連を見出すという流れになります。

その結果として、たとえば僕が今この文章を書いているパソコンと、あなたが今この文章を読んでいるパソコンは、同じパソコンクラスに属するものとして、非常に近い関係になります。*1

この関係は、僕のパソコンで電源ボタンを押したときとあなたのパソコンで電源ボタンを押したときにだいたい同じ動きをすることをあらわすのには効果的です。

パソコンクラスを書いて、電源ボタンメソッドを書いて、僕のパソコンとあなたのパソコンがパソコンクラスのインスタンスであることを示せばいい。


ところが、僕のパソコンの上に置いてある空き缶は、クラス設計上まったく関係がありません。

パソコンクラスの属性に空き缶コレクションを持たせようとすると、きっとキレイ好きでパソコンの上に空き缶が乗っているのを許せないあなたは強く反対するはずです。

代わりにパソコンクラスの属性としてボトルキャップフィギュアコレクションを持たせたいと主張するかもしれません。おしゃれなあなたは観葉植物コレクションの属性が必要であるというかもしれません。

そんなことされたら、ぼくの本の置き場がなくなってしまう。まっぴらごめん。


この「ただ隣り合っている」関係を、クラス図を先に書くようなオブジェクト指向で記述するのは非常に難しく、まず「場」となるクラスを持ち込む必要があります。

慎重に「場」のクラスを設計したら、そこに「パソコン」や「空き缶」「ボトルキャップフィギュア」「観葉植物」を放り込めるようにして、それらの位置関係を記述できるようにします。

そうしてできたクラス図を見てみると、ぼくのパソコンの上の空き缶群も、あなたのパソコンの上のおしゃれな観葉植物も、まったく想像できない無機質な図ができあがりです。

パソコンの上の空き缶を表現するためには、また一作業。

そうすると、どこかで情報がかけて、ぼくの机がちらかっているという情報がどこにも記述されなくなったりするわけです。あなたがぼくの机の上を見ることになって、でもぼくは机の上がちらかっていることを忘れてしまっているので、見事にちらかった机が目撃されてしまうことになります。

ぼくは机の上のちらかり具合を常に把握して、必要に応じて片付けなくてはならない。ましてや写真とられて本に載るとなったら、一日かけて大掃除ですよ。


要するに、今の「オブジェクト指向」はオブジェクトに対して無頓着で、オブジェクトの関係を表すのが非常に苦手だということです。

クラスを記述することでオブジェクトも記述できているつもりになっているようにも思えます。

で、実際にはオブジェクトの関係を表現するための場を記述することで力尽きてしまいます。

UMLの表記でStrutsの画面遷移がInputActionからResultActionに移るということを示すのに、どんな作業が必要でしょうか?

クラス中心のオブジェクト指向では、作業の途中でオブジェクト同士の関係が消えてしまいやすいというのが、大きな問題点じゃないかと思います。

*1:この2つの「今」の違いが大好き

higayasuohigayasuo 2005/07/22 18:06 オブジェクト間の関連を表すのがDIですよ。

nowokaynowokay 2005/07/23 02:04 DIは隣あってる関係を表すための「場」になりますね。

2005-07-12(火)

[]イデアとしてのソフトウェア要求、そしてエロス 11:27 イデアとしてのソフトウェア要求、そしてエロス - きしだのはてな を含むブックマーク

実装すべきソフトウェアの、理想的な、でも記述不可能な要求・仕様がイデア界にあるとすれば、仕様書やソフトウェアは、そのイデアの影ということになる。

で、完全な要求や完全な仕様を求めることがエロス。

さわださわだ 2005/07/13 02:27 ちょ、なにそんな楽しげなことやってるんですか!この燃料高騰のご時世にターボ車で!(足はノーマル?
僕は週末レースです。バネ切らなきゃ。

nowokaynowokay 2005/07/13 15:04 フルブースト(0.8kg/cm2)かかったときに、100円玉燃やしながら走ってる気はする(^^;
足はノーマルだけど、それなりによくて、きついコーナーで底ヅキする以外はあまり問題なかった。乗りなれたら付属のビルシュタインに取り替え。

前オーナー前オーナー 2005/07/19 22:30 あんたの走り方は正解です。フロントまるちりんくは粘るよ。逆バンクでシルビアより相当強い。(一歩間違えるとつっこみそうだけど)
フロントヘビーはカーボンボンネット+バッテリートランク移設がベター。
クリッピングでクキッと曲がってブーストONで荷重が後ろによると四輪スライドで加速します。
あ、ハイキャスカットしてないから、そのうちしてね。