« 2004年8月 | トップページ | 2004年10月 »

2004年9月

2004/09/27

TDDに必要な技術

 TDDを実践するための最低限必要な技術は「モックオブジェクト」「カバレッジ」の2つであると考えるが、意外とハードルが高いのではないか?
 その理由を考えてみる。

【1】モックオブジェクトが使えるか?
 Webシステムでは、JUnitを純粋に適用したテストプログラムは殆どありえない。例えば、Servlet、EJB、DB接続層等では、どうしてもスタブが必要になる。但し、Servletから業務ロジックを委譲する設計になっていれば、ビジネスロジック層は純粋なJavaのクラスゆえ、ビジネスロジック層のみJUnitがそのまま使える。
 だから、モックオブジェクトを使う必然性が出てくるが、スタブを切り替える設計になっていないと、テストプログラムは書きにくい。プログラムをコンポーネントで組み合わせる発想の元に、モデリングや設計を制御することが必要だが、結局はプロジェクトリーダーの手腕にかかっている。
#DIコンテナを使っていれば、すごく簡単になるだろう。

【2】カバレッジを行っているか?
 単体テストの進捗を数値化できるので、顧客にもアピールしやすい利点がある。(これは重要!)
 しかし、テストケースを単体テストレベルまで細かく落とせるか? テストプログラムのJavaDocがテスト仕様書になる等の仕組み作りが必要だが、その問題解決はプロジェクトリーダーの手腕に依存する。
 
 「テストプログラムがあるから単体テストはクリアしている」というレベルを保つには、少なくとも、モックオブジェクトを使える設計と、テストケースが完全に網羅されていることを保障するカバレッジの2要素が必須ではなかろうか?
 しかも、上記2要素を適用するには、プロジェクトリーダーの切り盛りに依存している所に難しさがあるのではなかろうか?

| | コメント (0) | トラックバック (0)

2004/09/23

TDD本は凄いぞ!

 04/9/21発売の「バグがないプログラムのつくり方 JavaとEclipseで学ぶTDDテスト駆動開発」
以下「TDD本」と略記)を改めて読み直しました。
 PG初心者だけでなく、経験者も惹きつけるだけの内容があります。
 僕が興味を抱いた箇所は下記の通り。

【1】TDDとトヨタ生産方式の比較

 プロジェクトにTDDを導入する時、メンバーを巻き込むのはあまり労力がかからないだろうが、上司にTDDの良さを納得してもらうのはたやすくない。上司がオブジェクト指向をマスターしていれば、TDDのコンセプトを説明するだけで承認されるだろうが、普通は構造化の世界に生きているから、まずありえない(笑)
 では、どうすればTDDの良さを上司に理解してもらえるか?
 TDD本では、「トヨタ生産方式」と持ち出して、TDDのコンセプトと似ている例をあげている。
 例えば、後工程引取方式は、TDDでいうSimpleな設計に当たる。つまり、後工程引取方式とは、後工程が前工程から必要な部品を調達していくという引算の発想であり、JustInTimeの考え方そのもの。TDDなら、テストプログラムを最初に作ることで、開発モジュールのインターフェイスを考えるようになるので、無駄な実装はしなくなる。「徹底した無駄の排除」を貫くトヨタ生産方式とYAGNI原則を貫くTDDは、コンセプトが非常に似ていないか? 「自働化」は、TDDなら「テストの自動化」に相当しないか、と。
 この説明を読むと、最近のアジャイル開発の翻訳本がトヨタ生産方式を絡ませている理由の一つが分かります。

 又、管理者にとってもTDDは進捗管理に役立つ。ウォーターフォール開発で進捗80%と報告を受けても、プログラムはできていないのだから、本当の進捗は10%かもしれないのに、検証する術がない。しかし、TDDなら、テストプログラムでカバレッジを測定できるので、実装ロジックの80%が完了している、という事実を数値で知ることができる。
 更に、システムを前任者から引き継ぐ時、管理者としては、ドキュメントとソース一式よりも、テストプログラムとソース一式の方が嬉しくないだろうか? ドキュメントなんて、保守フェーズですぐに古くなるし。テストプログラムがあれば、引き継いだプログラムの単体テストは保障されているからね。

【2】モックオブジェクトを使ったテストプログラムと依存性注入(Dependency Injection)の説明は非常に分かりやすいです。

 ソースを読むと分かるのですが、モックオブジェクトはインナークラスを使うんですねえー。インナークラスはThreadを使う時しか見かけなかったけど、こういう使い方をするんですね。
 インナークラスをCreateすることでモックオブジェクトを生成するロジックを、xxx.diconに書かれたコンポーネントをSingletonで呼び出すロジックに変えたら、あらま、Seasarそのままじゃないですか!
 Dependency InjectionはFactoryMethodの変形パターンと解釈していいのだろうか?

 TDD本はお勧めです。是非、皆さんもご購入を(^^)

| | コメント (0) | トラックバック (0)

2004/09/21

「デッドライン」にもシステムシンキングが載っていた!

 「デッドライン―ソフト開発を成功に導く101の法則」10章のP.103 に、Systems Thinkingとそのツール(ithink)について補足説明があった。
 つまり、トム・デマルコは既に知り尽くしている、といこと。
 プロジェクトマネジメントにシステムシンキングを使う発想は、知っている人には当たり前なのかもしれない。

| | コメント (0) | トラックバック (0)

2004/09/20

プロジェクトマネジメントの問題解決に
システムシンキングは役立つのか?

 プロジェクトマネジメントで現れるアンチパターンは、システムシンキングで出る因果ループ図を使うと、解決に役立つのではないか?
 そんな指摘をしている記事「システム思考で複雑な問題に対処する」があり、色々と考えさせられた。

 システムシンキングとは、下記の分析手法です。(詳細は、「「システム・シンキング」
最強組織の法則」(参照)

【A】時系列変化グラフと因果ループ図UMLモデリングの本質: にも一部説明あり)を使う。
【B】問題事象に対するシステム構造と時系列変化の関係を洗い出し、8つのシステム原型でパターン分けする。

 上記記事では、「プロジェクトマネジメントで現れる問題は、原因を優先順位付けすることで解決できる手法は有効でなく、問題の構造を変えるやり方(システムシンキング)が有効だ」と主張している。
 確かに、現場ではリソースの制約があるため、問題を根本的に解決する手法(設計をやり直す、計画を書き直す等)が取れず、悪循環に陥ることが多いので共感できる。
 しかし、下記の疑問が自然に湧く。

【1】プロジェクトマネジメントにおいて、システムシンキングが使える問題の種類や範囲は何か?
【2】更に、プロジェクトマネジメントのアンチパターンにシステムシンキングの8つのシステム原型は現れるのか?

 上記の疑問を、ちょっとラフに考えてみた。

【1】「プロジェクトが遅延している」「プロジェクトが暴走している」等のいくつかの状況において、悪循環のように、問題と原因がループしている場合に、因果ループ図が使えるのではないか? つまり、難しい問題に適用すべきであるという気がする。
 ある勉強会で因果ループ図を使ってみたが、無限ループに陥っている感じがして、救いがない印象を受ける。技法としては、肝心の変数を抽出するのが難しい。概念モデル作成時よりもスキルが必要である気がした。

【2】上記記事では、プロジェクトの遅延で悪循環に陥る問題の構造として「成長の限界」や「問題の転嫁」という因果ループ図があげられている。
ShiftingBurden.jpg

「問題の転嫁」の因果ループ図

 又、「アンチパターン―ソフトウェア危篤患者の救出」の本によると、プロジェクト管理には下記のアンチパターンがあげられている。

【2B】分析地獄(ウォーターフォール開発では工程を後戻りできない)
【2B】計画倒れ(計画の過剰で失敗する)
【2C】横紙破れ(扱いにくい人物の破壊的言動によって開発チームに問題をもたらす)
【2D】理性の欠落(プロジェクト管理者が意思決定できない。人使いが下手)
【2E】暴走プロジェクト(設計や技術をコントロールできず、システム開発が破綻してしまう)

 上記のアンチパターンは、システムシンキングのどのパターンに相当するのだろうか?
 又今度考えてみることにする。

| | コメント (0) | トラックバック (0)

2004/09/18

Aspectセミナー感想

 昨夜、SEA関西プロセス分科会「アスペクト指向プログラミング」に行ってきました。
 面白かったー。(ソフトウェアパターン勉強会よりも面白かったはず、と負け惜しみを言ってみる)
 講師の小林さんと山根さんのお話は下記のように刺激的でした。
#Aspectは素人なので、おかしな箇所はご勘弁を。

【1】小林さんの話

 Aspectの鳥瞰的な説明でしたが、Aspectの原論文を紹介して下さったのには驚きでした。原論文では、Lispを用いたモノクロ画像処理のプログラムが例にあげられていて、理解しやすいが処理が遅いソース、処理は速いが理解しにくいソース、Aspectを使って理解しやすく処理もそこそこ速いソースの3種類を比較してました。
 Lispは詳しくないんですが、ピクセル単位の論理操作や上下操作を組み合わせて、輪郭線を抽出する機能を作るのは、CやJavaと同じ感覚で理解しやすかったです。
 機能分割の構造と実行時のデータフローの構造が全然違うのは、関心事が違うからだ、という説明を受けて、Aspectの由来がようやく腑に落ちました。Javaなら、クラス図とプロファイラに相当するのかな?

 簡単なサンプルとして、銀行の口座引き落としで、CommitやRollbackの保障とか、DBからSelectしたデータをキャッシュとして使い回せるようにする所にAspectを用いると、見通しが良くなると説明されてました。
 ただ、いつも気になるのは、Aspectを複数混ぜ込んでしまう時、スレッドはどうなるのだろうか? 後で聞いたら、Aspect実行の順番は指定できるらしいです。でも、やはりきちんと設計しないとスパゲティになる、と飲み会で聞きました。

【2】山根さんの話
 AOPを現場で使ったノウハウを惜しげもなく披露して下さって興味深かったです。
 山根さんのAOP概念の下記の説明は非常に分かりやすい!

●関心・・・・・・・・・・サービスを実現する機能
●横断的関心・・・・複数のオブジェクトを跨る機能

 「関心」と聞いても「機能」と何が違うのか、いつも疑問に思っていたのですが、色んな視点から切り分けた機能の関連なんですね。(小林さんの話なら、機能分割と実行データフローの違い)
 「横断的関心」を機能分割する手法として、従来のオブジェクト指向では、「継承」と「委譲」が使われていますが、両方とも弱点がある、とのこと。

●継承
 当たり前ですが、Javaなら多重継承できない。

●委譲
 オブジェクト指向では推奨されているが、下記の弱点がある、と説明されてました。

【A】横断的関心は、概念モデルに存在しない機能(Non-functional-Consern)であることが多い。
【B】委譲にしても、結合度は比較的高い。構造化チックになる時が多い。
【C】委譲した場合、参照箇所のGrepが面倒。

 非常に納得です。僕の現場の感覚では、委譲はそれほど使い勝手は良くないと思ってます。
 委譲したとしても呼び出し元は元オブジェクトに残るし、引数に制御フラグがあったりして、制御結合や論理的凝集度になる時が多い気がします。だから、ソースとしては正直綺麗でない。長々と書いてくれた方がいいと思う時もあります。
 僕の現場の感覚では、継承を使っている時が多いです。Webシステムなら、トランザクション制御やセッション処理、ログ出力は全てのServletに必須ゆえ、全Servletの親クラスにそれらの機能を持たせる事が多い。StrutsのActionクラスを継承した独自クラスを作り、それらを継承して業務Actionクラスを作るとか。ただ、このやり方がBestだとは皆思っていませんが、労力と保守を考えるとBetterなのかもしれません。

 それから、Aspectの利点として、非機能要求(Non-functional-Consern)の開発にAOPは相性が良い、と言ってました。
 確かに実際の現場では、概念モデル作成時には、トランザクション制御やログ出力は考えないから、アーキテクチャ設計をきちんとやらないと、設計時に漏れてしまう事は多い。しかも、テストしにくい難点もあります。Aspectを使えばそれらの機能を後付けすることができるわけです。
 役立つ例として、System.outやprintStackTrace等をLog4jで乗っ取ってWarnigだけ出力するサンプルのデモを見たのですが、他のサンプルにもこのAspectが読み込まれてしまい、ログを見れなくなった時には、会場の皆さんも笑ってました(^^) Aspectの怖さを見せ付けられたデモでした。
 他にも、SingletonはAspectで実装した方がいいというサンプルや、一時的改修にAOPでパッチを当てるという裏技の紹介もありました。現場の感覚では、AOPのパッチは怖い気がしますが。
 最後に、DIやSpringの説明もありました。

 感想としては、Aspectで非機能要求を実装し、オブジェクト指向で機能要求を実装するのが現在のBestな組み合わせなのかな。だから、Aspectを使って、EJBよりもお手軽な軽量コンテナを皆作りたがっているでしょうね。
 AOPからしばらく目が離せません。

| | コメント (0) | トラックバック (0)

2004/09/16

ORマッピングに最適解はない

 下記のORマッピングの議論を読んで改めて、ORマッピングがシステム開発のボトルネックであり、ORマッピングにBestな解はないことを確認した。
#かのファウラー氏も悩んでいる(「ドメインロジックとSQL」)のだから、当然かも。

●ドメインロジックとSQL
●ポストRDB(前編)
●ポストRDB(後編)
●データベース系アプリケーションで、データや処理をどこまでクラス化する?
●Entity Bean批判

 ORマッピングの実装方法は、下記の3パターンに分類できると思う。しかし、どれも致命的弱点があるように見受けられる。

【1】JDBCを使う
【2】EJBを使う
【3】ORマッピング用フレームワーク(Torque、Hibernate等)を使う

 それぞれの弱点は下記のように感じる。

【1】ソースにSQL文を埋め込んでしまうため、うまくレイヤー化しないとスパゲティコードになる。しかも、トランザクション制御や排他制御のロジックをアプリケーション側できちんと作りこまねばならない。

【2】EJBサーバーを起動する必要があるので、ただでさえ重い。よく言われる「永続化は欲しいが分散機能は不要」という議論は確かに一理あり。
 実際の開発で使うEJBは、CMPとStateless SessionBeanしか見たことがないが、それだけでも作るのに労力がかかりすぎる。

【3】TorqueにしてもHibernateにしても、SQLをJavaで書けるようにしただけ。余計にロジックを解読しにくくなる。レスポンスもあまりよくない。

 多分、RDBを使う時点で、オブジェクト指向の技術が解決に向かないのではないか?
 ORマッピングは、オブジェクト指向の最大の弱点だと思う。

| | コメント (0) | トラックバック (0)

2004/09/14

SharpReader使ってます

 お気に入りのBlogを読むためにSharpReaderを使ってます。
 最近、あちこちの場で知り合った同じ業界の人たちのBlogを読むためです。
 Freeの割には、Outlookに似ているので使い勝手はいいです。
 .NET Framworkをインストールしないと使えませんが。



画面はこんな感じ

| | コメント (0) | トラックバック (0)

2004/09/13

概念を抽出するには
クラスとインスタンスの区別から始まる

 エンティティを抽出する時、イメージしている概念はインスタンスなのか、クラスなのか、区別することが意外とできていないのではないか?

 ある勉強会で、「日頃具体的な実体(インスタンス)と思って会話している内容が、実は殆どが概念(クラス)で話をしているのではないか?」という問題提起があった。例えば、「顧客」「商品」という言葉で、ユーザとSEの議論が噛み合わない時、「顧客」「商品」から想像される機能がお互いに異なるにもかかわらず、知らずに議論しているように思う。そんなケースは非常に多い。

 他には、「本質」では、「ロール名は極力クラスにしない」という原則を提示している。「販売先」「仕入先」という概念は「取引先」のロール(つまりインスタンス)にすべき、という例をあげている。クラスにしてしまうと、柔軟性が失われるからだ。

 アナパタでは、クラスとインスタンス以外にも、パワータイプを導入して、モデルを更に柔軟にしようとして複雑にしている部分がある。クラス=集合、インスタンス=集合の要素とするならば、パワータイプ=族集合に相当する。
 責任関係パターンが難しいのは、クラスとインスタンスを区別することさえも労力がかかるのに、パワータイプが出てきて混乱しやすいから。

 結局、オブジェクト図がモデリングの基本であり、慣れてくると、クラス図だけでオブジェクト図が見えてくる。
 インスタンスがはっきりすれば、関連によってどの機能を委譲すればよいか、見えてくる。

| | コメント (0) | トラックバック (0)

2004/09/12

アナパタは難しい

 アナパタで良く使われるパターンは、責任関係パターンと勘定パターン。
 ある勉強会で、アナパタ2にある「結合ルールで補正した責任関係パターン」を発表したのだが、うまく説明できず、わだかまりが残った。確かに難しい。

 勘定パターンは、「本質」によれば、在庫で使われる。
 ストリームラインモデリングで翻訳すれば、協調パターン「コンポジットトランザクション-明細-特定品目」に相当する。
 クラス図もエンティティしか出てこないから分かりやすいし、実装も自然に書ける。

 しかし、責任関係パターンは、知識レベルというメタモデルが出てきて、クラス図からイメージしにくい。
 最初に違和感を感じた箇所は、知識レベルで多対多の関連になっている所。そのままではオブジェクトの一意性が保たれないのではないか?
 
元々の責任関係パターン

 結合ルールを導入することによって、多対多の関連は解消されるので、オブジェクト図は描きやすくなる。
 
結合ルールを導入した責任関係パターン

 サンプルソースを解読すると、結合ルールクラスで、パワータイプに紐づくクラスの型の生成チェックを行っている。
 つまり、FactoryMethodで実装している。
 知識レベルは、パワータイプでモデルをコントロールするから、型チェックのロジックが入るのは自然ゆえ、納得できる。
 とはいえ、実際のモデリングで使うには、抽象的過ぎて難しいのではなかろうか。

| | コメント (0) | トラックバック (1)

2004/09/11

ついに出版!

 「バグがないプログラムのつくり方 JavaとEclipseで学ぶTDDテスト駆動開発」のレビュアーとして参加した縁で、昨夜執筆ご苦労会へ行ってきて、執筆者3人(川端さん、倉貫さん、兒玉さん)他の方々と飲んできました。
 執筆の裏話、アジャイルの話、色々あって面白かったー。

 宣伝向けに書いておくと「バグがないプログラムのつくり方 JavaとEclipseで学ぶTDDテスト駆動開発」は、オブジェクト脳に続く初心者向けのテスト駆動本です。テスト駆動開発に関わる物語がリアルなので、取っ付きやすいと思います。
 本のカバーに書かれている「バグを潰すのが大事なんじゃない。バグを作らない事が大事なんだ」というフレーズはすごくいいです。

 気になるのは、カバーにある3人の似顔絵。たしか、星野阪神元監督と金本ともう一人だったような? 執筆者3人の似顔絵だったら、もっと面白かったかも(^^)



9/21出版予定「バグがないプログラムのつくり方 JavaとEclipseで学ぶTDDテスト駆動開発」strong>

 

| | コメント (1) | トラックバック (0)

2004/09/10

xUnitはDbCの実践方法

 JUnitによるテストプログラムは、DbCを実際に実現しているものではなかろうか?

 「@IT:実行可能な知識とソフトウェア(2)」と「知識とソフトウェアのギャップ、それをどう埋めるのか?」の記事を読むと、「検証による正しさ」と「仕様の妥当性の正しさ」は異なる、という事実が書かれている。
#数学基礎論にある「証明可能性」と「論理的正しさ」の違いを連想させる。

 契約(DbC)は、仕様そのものの妥当性を保証する。しかし、抽象的すぎて、包括過ぎて、実際には使い物にならない。
 JUnitは、テストプログラムから書き始めることによって、仕様を満たす条件を実際に実装できる。モジュールの構造と粒度を適度に設計すれば、大きなシステム仕様の妥当性をチェックすることもできる。

 xUnitが流行しているのは、契約という概念の具体例として扱えるからではなかろうか?

| | コメント (0) | トラックバック (0)

2004/09/05

プロセス改善が流行している理由

 ビジネスでプロセス改善が流行している理由は、ビジネスがムーアの法則のスピードに追いつこうとしているからではなかろうか?

 近くの図書館で「思考スピードの経営―デジタル経営教本」(ビル・ゲイツ)を偶然見つけて借りた。
 借りたきっかけは、「ビジネスの進行速度がある限度を超えると、ビジネスそのものの性格が変わる。売り上げの変化に対し、週単位ではなく時間単位で対応できるメーカーや小売業者は、もはや製品取扱企業ではなく、売出中の製品をさばくサービス会社なのだ」という序論の一節に興味を抱いたから。

 IT技術の特徴は「1年半で処理速度が2倍に上がる」ムーアの法則にある。IT技術をビジネスに取り入れるということは、ムーアの法則に巻き込まれる事も意味する。例えば、POSを導入すると、週単位から時間単位に業務が変化する。その影響は、業務に関わる人たちがPOSを使いこなせるようにするだけでなく、人員の配置も変わることも意味する。しかし、以前の業務プロセスと異なる手法に慣れる必要があるのに、人間はその変化に付いていけない時が多い。

 つまり、プロセス改善とは、IT化された業務プロセスに人間を合わせるための手法であると思う。
 その方向は、どう考えても非人間的である気がする。

| | コメント (0) | トラックバック (0)

2004/09/04

デッドラインは面白い

 「デッドライン―ソフト開発を成功に導く101の法則」を1週間読んで、はまっている。
 興味のあるフレーズは下記のとおり。

【1】優れたプロジェクトはデバッグに費やす時間がはるかに少ない。設計に費やす時間がはるかに多い。
  殆どのバグはインターフェイスの欠陥に原因がある。その原因を解決するには、設計段階で欠陥を除去すべきである。

【2】あいまいな仕様書は、ステークホルダー間の対立を解決できなかった証拠である。

【3】理想の人数配分は、設計は少数精鋭で始めて、実装とテストで大量の人数を投入すること。
  設計で人数が多いと、全員に仕事を与えなければならないので、作業グループ間のインターフェイスを最小化できず、重要な設計作業を省略せざるをえなくなる。

 僕個人の少ない経験からしても、下記のように肯く事ばかり。

【1】あちこちの勉強会で知り合った優れたプログラマは、デバッグせずにログ出力だけでプログラミングしている。彼らは、デバッグしなくても、プログラム内部のロジックを全て理解できているから。
  テスト駆動開発も、テストがインターフェイス設計になっている所が重要であると思う。

【2】ユーザ企業のシステム部とSI企業のSEの間には必ず、お金と時間に関する対立がある。SEが対立を解決する役割を担うには、現実の制約条件から、ユーザの要望を実現できる機能へ一つずつ切り分けていく技術が必要になる。
 SEに要求される技術は、プログラミング技術よりも、業務フローの洗い出しと細分化にある気がする。

【3】この事実は僕の現場にいる人は結構知っているようで実践されている。だから、プログラマは日雇い労働者の立場に追い込まれている。

 ソフトウェア開発を掘り下げていくと、プログラミング技術だけでなく、チーム運営手法や業務フロー分析まで行き着いてしまう。
 結局、マネジメントとは何か、ビジネスとは何か、という問題をどこまで深く考えて本質を理解しているのか、が問われている気がする。

| | コメント (0) | トラックバック (0)

« 2004年8月 | トップページ | 2004年10月 »