データモデルパターン

　「データモデルパターン」というHPを見つけた。
　DOAに関するパターン集。アナパタのDOA版というイメージ。

　アナパタに出てくるパーティ、責任関係、勘定パターンに似ている。
　DFD、ER図というよりはクラス図っぽく見えるけど、本当はどうなのだろうか？

在庫は商品の集合が示す状態

　「在庫」という概念がモデルに出てきたら、いつもすぐに反応してしまうのだが、今まで完全に理解していなかった。
　在庫って、結局なんだろう？

　はぶさんのBlogでは、下記のように回答されている。すごく納得。

在庫は、商品の集合が示す状態であって個々のインスタンスにはつかないです。クラス変数とインスタンス変数を混ぜて議論するから尺度が合わないと考えています。んで、ステートレスってことを主眼におけば、在庫は在庫管理係ってのを置いてそいつに「教えて」ってするのが整理しやすいアプローチだと考えます。

システム開発のボトルネックはメインフレームに有り

　システム開発のボトルネックは、メインフレーム（ホスト）の存在そのものにあるのではなかろうか？
　JavaでWebシステムを開発していると、いつもそんなことを感じてしまう。

　どこの大企業に行っても、必ず10年以上稼動し続けているメインフレームが既に存在している。メインフレームなしでは企業活動そのものが存続できないようだ。最近の流行であるそのメインフレームをオープンシステムへリプレースすることは、どこの大企業でも殆どありえないように見受けられる。
　そもそも何故メインフレームが存在するのか、本当の理由を僕は知らないが、とあるBlogでは、「企業の基幹システムは最終的に財務諸表を作るために存在する」と書かれていた。
　しかし、財務諸表や損益売上決算書などは、オープン系システムでできないのだろうか？

　普通、どこの大企業でも、メインフレームは顧客データや請求・契約などの会計に関するデータを管理している。つまり、企業にとって死活的に重要なデータは、必ずメインフレーム内で管理している。
　いくらOOAをフルに使ったWebシステムを作ったとしても、Webシステムは、集めた受注データをホストへ送り、入出荷や請求のデータをホストからもらうだけ。業務的には、入り口のシステムに過ぎない。
　Webシステムがダウンするのは当然困るが、企業活動そのものが止まってしまうわけではない。

　僕がメインフレームを毛嫌いする理由は、OO技術者にとって、メインフレームがブラックボックスだから。メインフレームでデータをどのように加工し出力しているのか、全く意味不明だから。

　更に、ホストとのやり取りのために、無駄なインターフェイスが必要になる。
　例えば、受注データをリアルタイムにホストへ送信したり、月次請求や四半期決算のデータをホストから特定の日に受信する処理がある。
　仕組みとしては、ホストはバイト長データしか扱えないため、バッチプログラムがバイト長データを変換してRDBのワークテーブルに一旦保管し、Javaが扱うテーブルへ移し変える。そのプログラムは、典型的なCのプログラムで、オブジェクト指向以前の古い設計に基づく。しかもテストしにくい。

　オブジェクト指向をフルに使った設計やオープンソースのフレームワークを適用したオープン系システムを開発しようとしても、結局、メインフレームとの整合性を取るためのシステムテストがボトルネックになる。
　何しろ、受け入れテストに必要なシナリオやテストデータを洗い出し、実際の業務をシミュレーションするために、1週間とか1ヶ月も時間を費やす。オープン系システム内部で閉じたシステムなら、システムテストは楽なのに、ホストと連携するテストを行うために、無駄なコストがかかる。

　「メインフレームはオープンシステムに取って代われる」という記事を随分昔から見てきたけれど、未だに実現されているとは思えない。それらの記事は、単なるデマだったのだろうか？

【参考記事】「5年後，メインフレームはなくなる」　日経コンピュータ2003年3月24日号

　IT業界に入って、結局いつもぶち当たる壁は、ORマッピングとメインフレーム。
　それらを再考し直すと、結局、メインフレーム・RDB・オブジェクト指向プログラムの3つはどれも思想的に全く異なるシステムであって、それらのインターフェイスを合わせる為に、ORマッピングやバッチプログラムという無駄な中間レイヤーが必要になる。
　企業システムとは、結局、これら３つの相容れない混合システムであるべきものなのか？
　多分そうでないはず、と思うし、皆そう感じているのではなかろうか？

　メインフレームが今もなお存在する理由は、IBM・NEC・富士通・日立等のような大手ベンダーが過去あるいは今までメインフレームを製造し続けてきたからだろう。
　メインフレームというハードを中心にしたビジネスが長らく続き、そのビジネススタイルからなかなか脱皮できない所に原因がある気がする。

ソフトウェアテスト293の鉄則

　テスト仕様書やテスト計画を作るために「ソフトウェアテスト293の鉄則」の本を読み始めているが、理解しきれない部分と、なるほどと思う部分がある。

　今、最も関心があるのは下記の項目。ちょっと書いてみる。

第11章 テスト戦略の立案
鉄則278 テスト計画は戦略，段取り，成果物の三位一体と心得よ

戦略
どの範囲をテストするのか？　どこを重点的にテストするのか？　どのテスト技法を用いるのか？

段取り
戦略を実現するためにどのようにリソースを適用するのか？　誰がいつてすとするのか？

成果物
どんなドキュメントを残すのか？　どのようにバグを管理するのか？

　単体テストやシステム内の結合テストの仕様書や計画を考えるのは簡単。というか、それはプロジェクト管理者がやるべき事柄。
　むしろ、納品したモジュールが本番システムや他のサブシステムと連携して動くか、という受入テストやシステムテストについて、テストスケジュールやテスト仕様書をまとめるのが大変だ。
　その時に上記の本が役立つのでは、と思っている。

　オブジェクト倶楽部MLのスレッドでも、上記の本が絶賛されている。
　また感想をまとめよう。

大いなる力には、大いなる責任が伴う

　プロジェクト管理者にいざなると、割り込みの仕事に忙殺されて、モチベーションが落ちてしまう時がある。
　そんな時に、自分の使命（？）を思い出させて、奮い立つ言葉を見つけた。　

　「大いなる力には、大いなる責任が伴う」

　スパイダーマンが亡き叔父さんから言われた言葉。
　カッコイイ。。(^^)
　確かスパイダーマン１で、スパイダーマンとなった主人公の乱暴な振る舞いに見かねて忠告した場面だったように思う。
　
　プロジェクト管理者になると偉くなった気がするが、実際はそんなことはない。自分がプログラミングすれば早いのに、メンバーにお願いしてプログラミングしてもらっている。理由は、リーダーがプログラミングに携わるとチームが回らなくなるから。
　過去のプロジェクトを思い出しても、リーダー自らが実装していたプロジェクトは殆ど破綻していた経験がある。

　自分ならメンバーの2倍以上のタスクはこなせる自信はあるが、それを内に秘めて、チームの人数分の責任を感じて、チームを回している。
　その責任の重さに疲れる時があるけれど、その言葉を肝に銘じていると自分がスパイダーマンになったような気がして、何故かやる気が出てくる。

　しかし、自分も単純だよなあ(m_m)

モデルの所有者は誰か？

　IT21の会オープンカンファランス2005で児玉公信さんの講演を聞いて、1年間モデリングし続けた概念が全て一つに揃ったような気がした。
　最も印象に残った言葉は「モデルとは、ある人から見たある状況における明示的な解釈である」ということ。
　つまり、モデルを書くには、人が必要。人はモデルの所有者に相当する。
　そして、状況とは、モデルの文脈を指す。

　クラス図でモデルを書く時、とある勉強会でモデルの所有者が誰なのか、という議論がよく出る。つまり、このモデルはどの人が眺めて、どんな文脈でモデル化したものなのか？という質問がよく出た。
　「UMLモデリングの本質 」には、「モデルの所有者はモデルの中に登場しない」という一文がある。当たり前なのだが、クラス図を書いていくと、文脈を忘れて、たくさんのアクタが登場して混乱してしまう時がある。

　下記のクラス図の所有者は誰だろうか？

契約モデル

　児玉さんが講演で説明していたが、売り手と買い手のロールが登場しているから、所有者は売り手でも買い手でもない。所有者は仲介業者になる。
　売り手や買い手が所有者の場合、上記のクラス図から所有者が消えて、何かしらの制約が追加されるだろう。

　他の例として、「本質」の後半の章に「航空チケット予約システム」のクラス図がある。そのクラス図の所有者は、売り手、例えば、旅行代理店になる。

　モデルの所有者が重要なのは、要求から要件を定義し、概念モデルまで落とす作業で意識する必要があるから。
　シナリオを書いている時、普通はユーザの視点からシナリオを書く。例えば、アクタごとのシナリオのように。
　しかし、ビジネスモデリングであるからには、ユーザのアクティビティを追跡してどのサービスから課金するか、を探す。その時に、モデルの所有者がビジネスを提供する人へ変わる。
　そのことを意識する必要がある。

【参考文献】
UMLモデリングの本質　児玉公信著

テスト・ビルドプロセスの重要性

　最近のシステム開発の傾向を眺めると、テストやビルドプロセスを重視しているのが分かる。

　ウォーターフォールモデルでは設計や実装を重視するが、アジャイルやMSの開発フレームワークはテストやビルドを重視している。
　そのような傾向が生じた理由は、開発のボトルネックが、コンピュータ・リソースではなく、いかに変化に対応できる環境を作るか、へ移ってきたからだろう。
　そうなると、作ったシステムの正当性を保障するテストプロセスや、作ったシステムを安定稼動させるビルドプロセスがおのずから重要になってくる。いくら設計や実装をしても、早く実際に動かしてみなければ無意味になる状況が多くなってきたのだろう。

　更に理由の一つとして、テスト・ビルドの技術が面白く、実装と同じレベルのプロセスに組み込めるから、開発者でもテスト・ビルドプロセスに関心を持つ方向へ誘導できるのではないか？
　開発者の視点から眺めると、最近のテストプロセスやビルドプロセスは技術的に面白い。
　テスト駆動の技術としては、モックオブジェクト、プロキシ、リフレクション等の高等技術がふんだんに使われている。
　ビルドプロセスなら、AntやMavenなどがあげられるだろう。特にMavenは、プロジェクトが一つのコンポーネントに対応している特徴があるが、それはオブジェクト指向の再利用性の話につながる。
　
　Mavenの根底にある思想は、プロジェクト管理につながるように感じる。
　Mavenについては、もう少し調査してみたいと思う。