- PR -

募）モデリングについて意識するタイミングは？

参照元記事 | 同じ記事を参照しているスレッド一覧
«前のページへ 1|2|3|4 次のページへ»
投稿者投稿内容
zaxx_MD
大ベテラン
会議室デビュー日: 2003/04/21
投稿数: 204
お住まい・勤務地: 千葉県柏市
投稿日時: 2003-05-19 16:25
引用:

悪夢を統べるものさんの書き込み (2003-05-19 16:10) より:
ですね．むしろリファクタリングの世界だと思う．

これについては本一冊書かれてますので，詳細は
そちらを参照してください．


何がどう「むしろリファクタリングの世界」なんですか？？
最初からモデリングが正しければリファクタリングは不要で、
モデリングを修正する事はリファクタリングとほぼ同じ意味だと思いますが？
zaxx_MD
大ベテラン
会議室デビュー日: 2003/04/21
投稿数: 204
お住まい・勤務地: 千葉県柏市
投稿日時: 2003-05-19 16:39
悪夢を統べるものさんの書き込みを見ていると一貫した意図が見受けられます。
「給食に出てくるにんじんがきらいで駄々を捏ねている小学生」のような回答です。
私が「人参は栄養価が高い」とか
「子供には甘煮にするほうが、シチューにして出すより食べてもらえる」とか
「グリーンピースよりは人参の方が栄養価が高い」とかいうと、
あなたは
「グリーンピースも嫌いだから食べない」とか回答しているようです。
行き着く先が似たようなものでも、その過程が全く違います。

＃栄養学的な突っ込みは勘弁してください。
ほむら
ぬし
会議室デビュー日: 2003/02/28
投稿数: 583
お住まい・勤務地: 東京都
投稿日時: 2003-05-19 18:09
ども、ほむらです
本筋とは脱線しつつあって申し訳ないですが
---------------
zaxx_MDさんへ
引用:

基本的すぎる・・・と思いました。
いまどきソースコードの整形は良くも悪くもIDEがやってくれますし、
JavaDocのないソースは納品物として認めてくれませんし・・認めません。

はい、コード記述の基本です。
おそらく、なれた人に言ったならば、馬鹿にしているととられてても
おかしくは無いくらいでしょう。
でも、現実問題としてあまり気にされていません。
まぁ、守られていないといっても１と３は大抵あるのですが

問題は２の処理概要ですね。
どうでもいい内容だったり、リファレンス的なことしか書いてなくて
そこから処理に結びつかないコメントが多いんです。

僕はJavaDocについての知識はありませんが、用途を見ただけで受ける印象としては
コメントでなくてユーティリティツール用のパラメータみたいですね。。。
文書として残すならばいいのでしょうが、ソースコードとしてのコメントとしては
これでは、あまり意味無いと思います。(用途しか示さないから)


あとは、整形についてはまぁ、インデントについてもそうなんですが
時々あるんです。。。
どうせ同じ意味だからと何も考えずに一行に詰め込む人が。
ただの文言とかならかわいいもので
文字列でもSQLだったりとか関数のパラメータや論理式だったりと
お願いだからエスケープしてと思う場面も少なくありません。

引用:

IPOに関心されているようですが、
制御指向（フロー指向）のモデリングでは一般的な考え方で、
COBOLの時代からあるかなり古いものです。

IPOを書くということはフロー指向でモデリングすることを意味します。

ＩＰＯ。。。ってなんですか？略語に弱いもので申し訳ないです。
制御からのモデリングというのがどういう形になるのか想像できていないので
実際は違うかもしれませんが、モデリングするときは
イベントからのアプローチになると思います。
なにをしたらどうなるか。とか
どんなときにどうするか　それは何に影響するのか かな？
(あっなんか制御依存な感じですね^^;;;;)

引用:

何指向でも私はかまいませんが、モデリングをしっかりすることは大事ということで
理解してもらえましたでしょうか。

モデリングについては、大変参考になりました。
前投稿でも書きましたが、積極的に使用していこうと思います。
おそらく、すぐに形にすることは無理でしょうけど
こつこつと経験をつめばいずれ形くらいは出来そうです。。。
へげもん
ベテラン
会議室デビュー日: 2002/04/14
投稿数: 87
お住まい・勤務地: 埼玉県
投稿日時: 2003-05-20 11:42
既に書かれていますが、モデリングとはモデルを作成することです。
そして、そもそもモデルとは、複雑な事象から特定の側面を切り出すことで単純化し、理解を深めたりコミュニケーションの役に立てるためのものです。
つまり、モデルの価値とは「必要十分な情報を、いかに単純化して表現するか」の一点に尽きます。

しかしなぜか、ソフトウェア開発の現場ではまったく逆の価値を持たされてしまっているように見受けられます。
すなわち、「モデルを極限まで詳細化しよう」という動きです。その目論見は、「極限まで詳細化すれば、モデルからコードを自動生成できる」からだとされています。
理論上は、確かにモデルから実装コードを生成することが可能ですし、MDAなどは、そうしたツールの実用化を目指しています。
とはいえ、そこまで詳細化されたモデルは、ソースコードと大差ない可読性となります。また、そのためにかかるコストは、手作業でソースコードを書き上げるのに比べて、劇的というほどには短縮されないでしょう。
さらに、モデルが完成されて始めて実装コードが手に入るという点は、従来の手法と変わりなく、仕様書や設計書をモデルに置き換えたに過ぎません。

これに対して、XPをはじめとするAgile方法論では、テストファーストとリファクタリングという道具を用いて、いわばコーディングとモデリングを並行して進めることを主張してます。
まず、要求仕様をテストコードという形で記述していきます。このとき、分析レベルのモデリングが行われます。UMLで言えば、大まかなクラス図やアクティビティ図が「発生」します。
次に、テストコードが通るだけの実装コードを記述します。このとき、設計レベルのモデリングが行われます。UMLで言えば、詳細なクラス図やシーケンシャル図などが「発生」します。
そして、書かれた実装コードは即座にテストされ、すべてのテストが通った時点で、実装コードはひとまず完成となります。
その次に来るのがリファクタリングです。ここでは、いったん完成した実装コードを、より単純でわかりやすい実装へと洗練化していきます。このとき、設計モデルも同時に洗練化されていきます。当然ながら、洗練化された実装コードは必ずテストされ、以前と同じ動作であることが確認されます。

わざわざ「発生」としたのは、単純なものなら頭の中に思い描くだけで十分だからです。描かないと考えがまとまらないほど複雑であれば、紙やホワイトボードに手描きしますが、出来るだけ単純化して描きます。また、通常は保存しません。なぜなら、モデルの情報はすべて、テストコードや実装コードの中に盛り込まれているためです。
とはいえ、開発チーム内や顧客とのコミュニケーションのために、コードの背後にあるモデルを利用したいという場面はたくさんあります。その場合は、実装コードやテストコードからドキュメントやUMLの図などを自動生成すれば済むだけのことです。

XPはモデリングもドキュメント作成も否定はしません。ただ、それらの完成をコーディングの前提としないだけです。必要なすべての情報がテストコードや実装コードで網羅される（されなければならない）以上、別途ドキュメントなどの形で二重に記録し管理するのは、不経済である以上に危険だと考えるからです。

XP等の推進者の間で、しばしばモデリングやドキュメントが攻撃されるのは、上記のような理由からです。しかし、だからといってそれらがまったく不要だとするのは、明らかにXPの精神に反しています。
未記入
ぬし
会議室デビュー日: 2002/03/28
投稿数: 255
投稿日時: 2003-05-20 13:47
>つまり、モデルの価値とは「必要十分な情報を、いかに単純化して表現するか」
>の一点に尽きます。
＃そう言えば大学の授業でもやりましたねー．懐かしい．

>しかしなぜか、ソフトウェア開発の現場ではまったく逆の価値を持たされて
>しまっているように見受けられます。
>すなわち、「モデルを極限まで詳細化しよう」という動きです。
>その目論見は、「極限まで詳細化すれば、モデルからコードを自動生成できる」
>からだとされています。
ソフトウエア開発の現場ではなく，現場経験のないモデル中心主義者の
コミュニティにおいてだと思います．プログラムと同程度に微細化した
モデルは，既にモデルじゃなくプログラムなんですけどね．それが
「モデル中心主義者」にはわかってないらしい．

そもそも「モデルと実装は異なるものだ」という意識さえあるかどうか．
＃少なくともJavaVMでは明確に区別されています．だからこそ
＃実用的なアーキテクチャニュートラル性が実現されている．
uk
ぬし
会議室デビュー日: 2003/05/20
投稿数: 1155
お住まい・勤務地: 東京都
投稿日時: 2003-05-20 15:39
へげもんさんの書き込み (2003-05-20 11:42) より:
>既に書かれていますが、モデリングとはモデルを作成することです。
そして、そもそもモデルとは、複雑な事象から特定の側面を切り出すことで単純化し、理解を深めたりコミュニケーションの役に立てるためのものです。

これはその通りですね。設計とモデリングは混同されがちです。

よく「UMLだけで設計できるか」という質問を見かけますが、UMLはあくまでモデリング言語
であって、モデル化できない設計情報は別に記述する必要がありますね。

>これに対して、XPをはじめとするAgile方法論では、テストファーストとリファクタリングという道具を用いて、いわばコーディングとモデリングを並行して進めることを主張してます。

XPは確かにそうですが、Agileメソッドすべてがこのような方法を取るわけではありません。
FDDなら、

1. ドメインモデルの構築
2. フィーチャリストの構築
3. フィーチャ実装の設計
4. フィーチャの実装
＃かなり簡略化しています

というプロセスであり、3と4だけをフィーチャごとにイテレーションします。
モデリングを行なうのはプロセス1とプロセス3になります。もちろんそれぞれで作成する
モデルの抽象度レベルは異なります。
ほむら
ぬし
会議室デビュー日: 2003/02/28
投稿数: 583
お住まい・勤務地: 東京都
投稿日時: 2003-05-20 16:23
ども、ほむらです。
----------------
へげもんさんの書き込みより興味を持ったので
Agile方法論を調べていたらＸＰ(eXtreme Programming)に関するサイトを見つけました
僕と同じでＸＰに興味を持った方はどうぞ。。。
僕自身は今目を通しているところですが・・・

# 本命の Agile方法論 がでてこなかったりｗ

サイト名：eXtreme Programming FAQ
RootURL:http://objectclub.esm.co.jp/eXtremeProgramming/
おもわずＭＬに参加してしまったりして＾＾；；；；
でぽん
会議室デビュー日: 2003/05/14
投稿数: 3
投稿日時: 2003-05-20 18:02
これは私の少ない経験からの雑感なのですが、
どうもモデリングという言葉は独り歩きしやすいようで、
個々の解釈により、あらぬ方向に向かうこともしばしばあるようです。

雑誌、書籍をみても「ＵＭＬ書くならモデリング」と駆け抜けてしまい、
かつ、ＵＭＬを前面に押し出すあまり本質的な部分がお座なりに
なっているように感じますし、数年前の記事なんかＵＭＬをまるで魔法の
開発手法のようにもてはやすものもあったように記憶しています。
そしてそれを鵜呑みにしていた自分。
今思えばＵＭＬは表現方法のひとつに過ぎないのですが。

結局は何のためにモデリングするのか？なぜＵＭＬで書くのか？と
いうところを曖昧なまま進めようとするから理解できなくなり、
「モデリングしなければならない」に目的が変わってしまう。
そしてモデリングにこだわった結果、粒度が細かくなりすぎる。
このことに気がつくまで私自身、かなり遠回りしてしまいました。
（まだまだ理解不足ですが）

また最初から完璧なモデルなんてできるわけが無く（少なくとも私には無理（苦笑））
ましてや変更などがあるわけですからリファクタリングの大切さというのも
理解しておく必要があるし、それらの積み重ねでモデリングのコツが掴めるの
でしょうね。

すみません。
取り留めの無い文章で。

スレッドの最初のほうにあるKO-JIさんの書き込みは非常に参考になりました。
どこかでちゃっかり引用させてもらおうかと。（笑）
«前のページへ 1|2|3|4 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）