- PR -

連載の「初歩のＵＭＬ」について

«前のページへ 1|2
投稿者投稿内容
MamezouHagimoto
常連さん
会議室デビュー日: 2001/10/27
投稿数: 24
投稿日時: 2003-01-30 00:51
引用:

スロッター１３さんの書き込み (2003-01-28 19:06) より:
遅いレスですみません。

Development Style・・・
こんなところがあったんですね。
てっきりバナーかと・・・

駄文に対するレスの方が反応が良かったですね。
ＵＭＬでモデリングって言うところがいまいち掴めません。
ＵＭＬ初心者の方は誰でも経験があると思うんですけど
ユースケースまではなんとか書けるんですが
クラス図とかシーケンス図を書く段になると思考が途切れてしまうとか
なにが正しいのか判断しづらいというかなんというか。
一応、書ける事は書けるんですがこれで本当にプログラムが作れるのか？
って不安が常によぎってしまいます。
で、ｊａｖａでプロト作ってみて、あ、ここはこんなクラスがいるかもとか
メソッドが足りないなぁ・・・とか。

ＵＭＬへの入り方がまずいのかも。


私も不思議なのですよ「Development Style」がなぜあんなにわかり辛いバナーにしているのか？？

話を本題に移して、
私は豆蔵のオブジェクト指向分析・設計コースの講師をやることもあるのですが、１日目がユースケース中心で演習を進め、２日目が分析モデルということでクラス図中心で演習を進めていきます。私はたまに２日目の最後に参加者の方々に下記の質問をするのですが、この結果面白い現象に気がつきました。開発経験者は２がわかり易いと答え、開発非経験または開発から遠ざかった管理者は１がわかり易いと答えるのです。

１．１日目のユースケース演習がわかりやすかった人？
２．２日目のクラス図を使った分析モデルの演習がわかりやすかった人？

これは、ユースケースモデルとクラス図に代表されるオブジェクトモデルの考え方が根本的に異なることからくるのではないでしょうか。前者は、ユーザから見た機能の構造を捉えていますので機能中心の考え方、後者は、ユースケースモデルで定めたシステム境界内部の概念構造を中心にモデル化していきます。両者のモデリングアプローチは直交関係にあると思います。後者は、少なくとも要求の構造からソフトウェア構造へマッピングする過程を誘いますので、ソフトウェア開発者にはわかり易いのだと思うのです。

スロッター１３さんのクラス図、シーケンス図を書く段階になって思考が途切れる原因を推測すると、おそらくユースケースモデルの延長でクラス図を見ているからではないでしょうか。そもそも２つのモデルの役割は異なるものですから、ユースケースとは別の観点でクラス図等を考えなければなりません。

クラス図やオブジェクト図、シーケンス図、コラボレーション図を書く際には、ユースケースモデルで定義したユーザから見た機能を実現するための構造（クラス関係）はどうあるべきかを、頭の中でオブジェクトたちのコラボレーションをイメージしていくことが重要となります。そのイメージからUMLのクラス図に落とし込んだり、シーケンス図に落とし込んだりするわけです。

結局、よいモデリングを行うには、UMLの表記を理解することが重要ということではなく、頭の中でオブジェクトのイメージができるかできないかにかかっています。そのイメージが明確に沸いて来るまではJavaプログラムを徹底的にやりながらオブジェクトのイメージにマッピングしていくようなトレーニングが必要なのかもしれません。






MamezouHagimoto
常連さん
会議室デビュー日: 2001/10/27
投稿数: 24
投稿日時: 2003-01-30 00:54
引用:

スロッター１３さんの書き込み (2003-01-28 19:06) より:
遅いレスですみません。

Development Style・・・
こんなところがあったんですね。
てっきりバナーかと・・・

駄文に対するレスの方が反応が良かったですね。
ＵＭＬでモデリングって言うところがいまいち掴めません。
ＵＭＬ初心者の方は誰でも経験があると思うんですけど
ユースケースまではなんとか書けるんですが
クラス図とかシーケンス図を書く段になると思考が途切れてしまうとか
なにが正しいのか判断しづらいというかなんというか。
一応、書ける事は書けるんですがこれで本当にプログラムが作れるのか？
って不安が常によぎってしまいます。
で、ｊａｖａでプロト作ってみて、あ、ここはこんなクラスがいるかもとか
メソッドが足りないなぁ・・・とか。

ＵＭＬへの入り方がまずいのかも。


私も不思議なのですよ「Development Style」がなぜあんなにわかり辛いバナーにしているのか？？

話を本題に移して、
私は豆蔵のオブジェクト指向分析・設計コースの講師をやることもあるのですが、１日目がユースケース中心で演習を進め、２日目が分析モデルということでクラス図中心で演習を進めていきます。私はたまに２日目の最後に参加者の方々に下記の質問をするのですが、この結果面白い現象に気がつきました。開発経験者は２がわかり易いと答え、開発非経験または開発から遠ざかった管理者は１がわかり易いと答えるのです。

１．１日目のユースケース演習がわかりやすかった人？
２．２日目のクラス図を使った分析モデルの演習がわかりやすかった人？

これは、ユースケースモデルとクラス図に代表されるオブジェクトモデルの考え方が根本的に異なることからくるのではないでしょうか。前者は、ユーザから見た機能の構造を捉えていますので機能中心の考え方、後者は、ユースケースモデルで定めたシステム境界内部の概念構造を中心にモデル化していきます。両者のモデリングアプローチは直交関係にあると思います。後者は、少なくとも要求の構造からソフトウェア構造へマッピングする過程を誘いますので、ソフトウェア開発者にはわかり易いのだと思うのです。

スロッター１３さんのクラス図、シーケンス図を書く段階になって思考が途切れる原因を推測すると、おそらくユースケースモデルの延長でクラス図を見ているからではないでしょうか。そもそも２つのモデルの役割は異なるものですから、ユースケースとは別の観点でクラス図等を考えなければなりません。

クラス図やオブジェクト図、シーケンス図、コラボレーション図を書く際には、ユースケースモデルで定義したユーザから見た機能を実現するための構造（クラス関係）はどうあるべきかを、頭の中でオブジェクトたちのコラボレーションをイメージしていくことが重要となります。そのイメージからUMLのクラス図に落とし込んだり、シーケンス図に落とし込んだりするわけです。

結局、よいモデリングを行うには、UMLの表記を理解することが重要ということではなく、頭の中でオブジェクトのイメージができるかできないかにかかっています。そのイメージが明確に沸いて来るまではJavaプログラムを徹底的にやりながらオブジェクトのイメージにマッピングしていくようなトレーニングが必要なのかもしれません。






KOUJI YAKOU＠IT
＠ITエディタ
会議室デビュー日: 2002/07/05
投稿数: 16
投稿日時: 2003-01-30 02:28
＠IT編集局のヤコウと申します。

引用：------------
Development Style・・・
こんなところがあったんですね。
てっきりバナーかと・・・

引用：------------
私も不思議なのですよ「Development Style」がなぜあんなにわかり辛いバナーにしているのか？？

申し訳ないです･･･。
この件につきましては、現在（本当に！）宮下ともども議論をしておりまして、近日中に
改善をする方向で作業を進めています。2月中には必ず変わります。

その他、Development Style全体に関しましては、幸いながら読者の皆さまから暖かいご声援を受けていることもあり、ご意見を取り入れながら、少しずつですが良い方向に向かってメンテナンスを行っております。

砂漠をテクテク歩く駱駝歩みのようですが、オアシス目指して頑張っています。予想外の砂嵐に見舞われることもたびたびなんですけどね･･･。

ともあれ、今後ともよろしくお願いいたします。














«前のページへ 1|2

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