最近、オブジェクト指向と、構造化分析にかんしての話題のブログが多いと思います。
そこで、この人気？に乗じて、ウィリアムのいたずらも、ひとつ。
まず、この手の話の場合は、自分のおかれている環境を書くようだ。なので、ウィリアムのいたずらの立場。
ウィリアムのいたずらは、バブルのころは、ビジネスのモデルを作るお仕事（システムやさん）をしていましたが、その後、落ちぶれて？？いまは、業務系のアプリケーション作成や業務系のドキュメントからプログラム、テストデータを自動生成するようなプログラムを作ったりしてます。
が、一番大事なことは、今は、下請けだということです。
で、下請けの立場としては、方法論はえらべません。元請けが、「これをつくれ」といわれたら、それを作るしかありません。
その立場だと、オブジェクト指向と、構造化分析、１つのシステムで、両方やらされます。
理由は、DBのテーブル設計のドキュメントとして、ER図
JAVAのプログラムのドキュメントとして、クラス図
システムの内容を示すのに、ユースケース図を入れさせられる
のが、最近、多いからです。
ER図を入れさせるのは、RDBのテーブルのドキュメントとして、まっとうな話だと思います。
でも、ER図は、DFDと同じく、構造化分析のときに作る図です。
一方、クラス図を入れさせるのは、Javaで作っている場合、これまた、それほどはずした話ではありません。
でも、クラス図は、UML,オブジェクト指向で作る図です。
下請けの場合、この両方の図を入れさせられるので（RDBをつかって、Javaで開発させられる場合）、結局、両方の分析が必要になります。しかし、両方の分析を別々にやったら、時間がない上、話が合わなくなる危険もある（おなじエンティティを違う名前で、違う視点で分析してしまう可能性もある）ので、オブジェクト指向から構造化分析にもってくる方法、その逆、両方できなければなりません。つまり、下請けの場合、オブジェクト指向と、構造化分析は、優劣をきそうものでなく、分析の過程で、相互交換できないと、まずいものになります。
で、相互交換の方法。
１．ユースケースのユースケース（楕円）を、DFDのプロセスとします。
２．シナリオ中、ユースケース（動詞かサ変動詞）を修飾したり、目的格、主格となる名詞が、
データの保管先・保管元（エンティティ）または、データの発生源・行き先
３．で、データのエンティティがでてきたら、そこにリレーションをいれる
という手順でER図をつくる
DFDからの場合は、ユースケースに変換します（プロセスをユースケースに）
こういう意味で、DFDのプロセスは、ユースケースとおなじく、機能であり、
COBOLは、プログラムモジュールで機能（プロセス）を実装し
オブジェクト指向の場合、機能は、メソッドになります。
これが、「のものも」さんのブログ単体テストあれやこれやにでてくる以下の文
COBOL時代の「モジュールの定義」とオブジェクト指向時代の「モジュールの定義」とがうまくリンクしていないところがあるようです。聞いた話ですが、COBOL時代からの品質管理担当者の意見では、「Javaのメソッドは単体テスト、クラスは結合テスト」なんて言っているところもあります
のキ・モ・チかなあ？と、勝手に思っております。
さて、じゃあ、オブジェクト指向と、構造化分析、どこでわかれるかというと、情報隠蔽をするところでわかれます。
プロセスに関しては、DFDでも大きな機能から小さな機能へ詳細化していく形になりますし、オブジェクト指向でも、上位クラスの中に、詳細な下位クラスを書いて、細分化できます。
問題は、データのほうです。
RDBの特徴は、「一貫性・共有制・独立性」といわれるように、データを共有します。
共有＝隠さないということです。
この共有化を行うための作業が、正規化になります。
一方、オブジェクト指向は、データを隠すことができます（カプセル化で）。
ここで、問題が起こります。データを隠してしまうと、共有制が崩れます（もちろん、一貫性も）そうすると、RDBを構造化分析で使う前の問題である、データの矛盾がおこったり、おなじデータを違うように定義して、わけわかんなくしてしまったりします。
これが、「いがぴょんさん」のブログにでてくるオブジェクト指向レス開発という選択肢にでてくる「逆正規化」のキ・モ・チかなあ？と、勝手に思っております。
で、たしかに、オブジェクト指向で、データを隠されると、失敗しやすい。。。
たいへんなのよ。データが関連しちゃってね。。
この前、テストのとき、テストデータをつくるときね。。。（；＿；）
って、私の体験談は、どうでもいいね。。。次！
しかし、データの情報隠蔽に関して言えば、これを行わないと、困ることがあることもたしか。
たとえば、DTP（で作る本）とWeb、同時に公開するシステムにおいて、赤といったら、Webの人はRGB系で、DTPの人はCMYKで欲しい。
で、このRGBからCMYKの変換法則は、プロファイルを利用して。。。。っと、かなり長いプロセス＆多くの人に知られていない＆たまーに、業務と関係なく仕様変更になる可能性あり！が必要なんだけど、それはみんなに見せたくない。
これなんかが、「さとし」さんのブログ構造化手法とオブジェクト指向に出てくる
オブジェクト指向で新たに導入されたアプローチを利用しなくてもそれなりの設計は可能である。でも、よりよい設計をするためにはオブジェクト指向で導入されたアプローチは必須である
の例なのかなと、かってに思っております。
あ、ついでにいえば、上の例が、たぶん「ペーペープログラマの日記」さんのブログや、arclampさんのブログに出てくる、「賢いデータ」の例でもあるかなと勝手に思っています。
つーことで、みかままさんのブログのおっしゃるとおり、構造化分析・設計はOOと対立する概念じゃなくて、ウィリアムのいたずらの場合、両方やらされるんだけど、問題となるのは、オブジェクト指向らしい機能である「情報隠蔽」なんです。
どこまで情報を隠して設計するかというのは、これは、コンピューターシステムの開発だけじゃなくって、リアルのビジネスモデルを開発する上でも「何を、どこまで機密にして、だれに知らせるか」、「どこまで公開していいか」という、かなり大きな問題となります。
国の場合、この問題は、個人情報保護法のように、きまりがあるけれど（？？？）
業務では、ないので、どこまで情報隠蔽するか。。。
の基準りは、実はウィリアムのいたずら的にはあるんだけど、それを書くと、さらに長くなりそうだし、きょうは、いろいろな人から引用してしまったので、みんなから、「おまえの考えはちがーう！！」とぼこぼこにやられそうなので、「今日のところは、ここまでにしておいてやろう」（吉本新喜劇風に）
そこで、この人気？に乗じて、ウィリアムのいたずらも、ひとつ。
まず、この手の話の場合は、自分のおかれている環境を書くようだ。なので、ウィリアムのいたずらの立場。
ウィリアムのいたずらは、バブルのころは、ビジネスのモデルを作るお仕事（システムやさん）をしていましたが、その後、落ちぶれて？？いまは、業務系のアプリケーション作成や業務系のドキュメントからプログラム、テストデータを自動生成するようなプログラムを作ったりしてます。
が、一番大事なことは、今は、下請けだということです。
で、下請けの立場としては、方法論はえらべません。元請けが、「これをつくれ」といわれたら、それを作るしかありません。
その立場だと、オブジェクト指向と、構造化分析、１つのシステムで、両方やらされます。
理由は、DBのテーブル設計のドキュメントとして、ER図
JAVAのプログラムのドキュメントとして、クラス図
システムの内容を示すのに、ユースケース図を入れさせられる
のが、最近、多いからです。
ER図を入れさせるのは、RDBのテーブルのドキュメントとして、まっとうな話だと思います。
でも、ER図は、DFDと同じく、構造化分析のときに作る図です。
一方、クラス図を入れさせるのは、Javaで作っている場合、これまた、それほどはずした話ではありません。
でも、クラス図は、UML,オブジェクト指向で作る図です。
下請けの場合、この両方の図を入れさせられるので（RDBをつかって、Javaで開発させられる場合）、結局、両方の分析が必要になります。しかし、両方の分析を別々にやったら、時間がない上、話が合わなくなる危険もある（おなじエンティティを違う名前で、違う視点で分析してしまう可能性もある）ので、オブジェクト指向から構造化分析にもってくる方法、その逆、両方できなければなりません。つまり、下請けの場合、オブジェクト指向と、構造化分析は、優劣をきそうものでなく、分析の過程で、相互交換できないと、まずいものになります。
で、相互交換の方法。
１．ユースケースのユースケース（楕円）を、DFDのプロセスとします。
２．シナリオ中、ユースケース（動詞かサ変動詞）を修飾したり、目的格、主格となる名詞が、
データの保管先・保管元（エンティティ）または、データの発生源・行き先
３．で、データのエンティティがでてきたら、そこにリレーションをいれる
という手順でER図をつくる
DFDからの場合は、ユースケースに変換します（プロセスをユースケースに）
こういう意味で、DFDのプロセスは、ユースケースとおなじく、機能であり、
COBOLは、プログラムモジュールで機能（プロセス）を実装し
オブジェクト指向の場合、機能は、メソッドになります。
これが、「のものも」さんのブログ単体テストあれやこれやにでてくる以下の文
COBOL時代の「モジュールの定義」とオブジェクト指向時代の「モジュールの定義」とがうまくリンクしていないところがあるようです。聞いた話ですが、COBOL時代からの品質管理担当者の意見では、「Javaのメソッドは単体テスト、クラスは結合テスト」なんて言っているところもあります
のキ・モ・チかなあ？と、勝手に思っております。
さて、じゃあ、オブジェクト指向と、構造化分析、どこでわかれるかというと、情報隠蔽をするところでわかれます。
プロセスに関しては、DFDでも大きな機能から小さな機能へ詳細化していく形になりますし、オブジェクト指向でも、上位クラスの中に、詳細な下位クラスを書いて、細分化できます。
問題は、データのほうです。
RDBの特徴は、「一貫性・共有制・独立性」といわれるように、データを共有します。
共有＝隠さないということです。
この共有化を行うための作業が、正規化になります。
一方、オブジェクト指向は、データを隠すことができます（カプセル化で）。
ここで、問題が起こります。データを隠してしまうと、共有制が崩れます（もちろん、一貫性も）そうすると、RDBを構造化分析で使う前の問題である、データの矛盾がおこったり、おなじデータを違うように定義して、わけわかんなくしてしまったりします。
これが、「いがぴょんさん」のブログにでてくるオブジェクト指向レス開発という選択肢にでてくる「逆正規化」のキ・モ・チかなあ？と、勝手に思っております。
で、たしかに、オブジェクト指向で、データを隠されると、失敗しやすい。。。
たいへんなのよ。データが関連しちゃってね。。
この前、テストのとき、テストデータをつくるときね。。。（；＿；）
って、私の体験談は、どうでもいいね。。。次！
しかし、データの情報隠蔽に関して言えば、これを行わないと、困ることがあることもたしか。
たとえば、DTP（で作る本）とWeb、同時に公開するシステムにおいて、赤といったら、Webの人はRGB系で、DTPの人はCMYKで欲しい。
で、このRGBからCMYKの変換法則は、プロファイルを利用して。。。。っと、かなり長いプロセス＆多くの人に知られていない＆たまーに、業務と関係なく仕様変更になる可能性あり！が必要なんだけど、それはみんなに見せたくない。
これなんかが、「さとし」さんのブログ構造化手法とオブジェクト指向に出てくる
オブジェクト指向で新たに導入されたアプローチを利用しなくてもそれなりの設計は可能である。でも、よりよい設計をするためにはオブジェクト指向で導入されたアプローチは必須である
の例なのかなと、かってに思っております。
あ、ついでにいえば、上の例が、たぶん「ペーペープログラマの日記」さんのブログや、arclampさんのブログに出てくる、「賢いデータ」の例でもあるかなと勝手に思っています。
つーことで、みかままさんのブログのおっしゃるとおり、構造化分析・設計はOOと対立する概念じゃなくて、ウィリアムのいたずらの場合、両方やらされるんだけど、問題となるのは、オブジェクト指向らしい機能である「情報隠蔽」なんです。
どこまで情報を隠して設計するかというのは、これは、コンピューターシステムの開発だけじゃなくって、リアルのビジネスモデルを開発する上でも「何を、どこまで機密にして、だれに知らせるか」、「どこまで公開していいか」という、かなり大きな問題となります。
国の場合、この問題は、個人情報保護法のように、きまりがあるけれど（？？？）
業務では、ないので、どこまで情報隠蔽するか。。。
の基準りは、実はウィリアムのいたずら的にはあるんだけど、それを書くと、さらに長くなりそうだし、きょうは、いろいろな人から引用してしまったので、みんなから、「おまえの考えはちがーう！！」とぼこぼこにやられそうなので、「今日のところは、ここまでにしておいてやろう」（吉本新喜劇風に）
アクセス
トータル
ランキング
