- - PR -
UMLを用いた開発について
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2002-05-31 15:12
「開発ツール過去最高の売り上げのVS .NET 」スレッドより
UMLに関しては、手を出せないんです。 勉強してないとか不要と思っているとかではなく、「どのように使っていくべきか？」の思想的なところがわかっていません。 UMLに関する本とか読むと、さすがに注目技術だけにわかりやすい記述をされているものが目立ちます。そのレベルの本しか読んでいないのが問題といえばそうかもしれませんが、実際に設計・製造を行う上でどう絡めていくべきかがわかっていません。 例えばオブジェクト指向型言語と言われるものでプログラムを作成したとすると、そのクラス等のソースからクラス図を作り出すのはそんなに難しくないように思えます。ただ、実際にシステム開発する際には当然最初にソースはできません。 製造の前にUMLの図がくるのでしょうが、そこから思い通りにソースができあがる過程がイメージできていないんです。 「これからは○○の時代！」といわれて、後で「あれは何だったんだろう？」というのもあると思いますが、UMLはどうなっていくかがわかりません。 率直なところ「これ全部やるのはしんどいかな？」がUMLに対する今の思いです。 みなさんは、どう思われているのでしょう？ ※「いやいや、そんなんできんでええから」の意味は「その程度なら不要」です。 ※新しいスレッドたてるのって結構緊張しますね。 [ メッセージ編集済み 編集者: ラフィン 編集日時 2002-05-31 16:45 ] | ||||||||
|
投稿日時: 2002-05-31 18:59
分析・設計の各段階で、すべての UML 図を書いていたんじゃ、たまったもんじゃありませんよね。 そんなときにお勧めの本。 (^^; http://www.seshop.com/detail.asp?pid=766 > UML モデリングのエッセンス 第2版 > 著： Martin Fowler / ケンドール・スコット 開発のどんな段階で、どの UML 図を、どのように使うべきか、という視点で書かれています。 | ||||||||
|
投稿日時: 2002-05-31 21:15
「UMLからソースができる」なんていう幻想は捨てたほうが幸せでは。
UML には２つの方向性があって、 1. OOP向けビジュアルクラスビルダー 2. 業務分析の際のデータ整理法 ではないかと。 正直、ビジュアルクラスビルダーは Beans はじめ様々な言語処理系で試されてきましたが、成功してる例ってのも聞かないですよね。なんでまぁ、期待はしないと。 # SmallTalk はおもしろげだったけど。 # WebObject はどうなのかな… で、2 のほうは、けっこう使えそうだと思ってます。業務フローの整理にもそれなりにアレンジして使えますし。ER図とかでやってたことの、まぁ、焼き直しですけどね。 | ||||||||
|
投稿日時: 2002-06-01 00:01
私も、ろくに書いていないし、クラス図とシーケンス図位しか書かないので 大きなことは言えないのですが...。 設定図として書きたい場合には、紙に出して、みんなに説明となりますから そのページに納まるように書きたいじゃないですか。 となると結局、そのページに出てくるクラスとの関係だけに絞り込んだ 図にしたくなるのですが、「UMLからソースができる」系のツールって その辺が、弱くないですか？ | ||||||||
|
投稿日時: 2002-06-01 10:56
ラフィンです。
みなさん返信ありがとうございます。 はやく「幻想」を捨てて幸せになりたいのはやまやまなのですが．．． 
自分のことを棚にあげるわけにはいかないのはわかっていますが、「流行」ってよく理解されないうちは「幻想」を生みますよね？UMLに関しては今そういう人が多いと思います。昨日今日言われはじめたことではないのですが、ほのかな「幻想」いだいたまま先送りにしていました。 データウエアハウスだのデータマイニングだので「当社では導入します。目的は導入することで、その先は考えていません。」みたいなのが結構ありました。言葉は悪いですが、システム開発の仕事やってるとこういうのとある意味戦わなければいけません。さらに言葉は悪いですが、UMLみたいなものになると敵は社内にもいます。
自信を持って「UMLとはですね．．．」と言いたいです。 ※biacさんご推薦の本ですが、目次を見るからに今読んでおきたい本です。 | ||||||||
|
投稿日時: 2002-06-01 12:19
objectです。
日本のUMLに関する本は、CRCカード等を余り取り上げないですね。 だから、UMLで試行錯誤をするという部分が抜けてる感じです。 UMLに期待しないという人もいるようですけど、これもプロセス抜きのUMLでは仕方ない部分があるんだろうと思います。 ハッキリ言って、出来上がったものを表現するだけになりますからね。 （表記が統一出来た、という事だけでも成果なんですが） それでプロセスに関してですが、有名なものに「ラショナル統一プロセス」があります。 Martin Fowlerも先の本の中で少し書いてますが、これに関して学んでみるのも良いかも知れません。 逆に少し前に辿って、Rumbaughの「OMT」等、過去のものを読んでみるのも良いかも？ （良い本を読むのも良いんですが、例えばクラス図を実際に色々書いてみて、それが最終的にどんな形の実装になるかを自分で確認する、というのは一番大切ですよ！） それから、UMLの良い所の一つはドメイン領域を取り込もうとしている所だと、私は思います。 でも、まだまだ不完全だと思います。 これも、どうして良いのか分からないという所に繋がってるような気がします。 「UML モデリングのエッセンス 第2版 、 著： Martin Fowler / ケンドール・スコット」 これは、私も推薦しますね。 確か、Martin FowlerはＸＰにも関係してると思います。実際、この本の中でも、関連項目に言及してますよ。 | ||||||||
|
投稿日時: 2002-06-01 17:36
私も、あまりUMLは詳しくは無いんですが？
UMLは、最上流工程でのみ使った方が効果があるものでは？ UMLから、中流工程へ落としていく。 UMLでの、設計はあっちこっちで言われてますが。。。 設計で考えるならやはり、最上位だけかなと？ どちらかと言うと、エンジニア的要素も多いですが、 管理者的要素の方が多いように感じるんですが？ UMLの本を何種類か読んでいるうちに気が付いたのが、 経営的視点から、トップダウンで、設計に降りてきた技術の ように感じるんですが？ 私の勘違い、誤解でしょうか？ よろしくお願い致します。 | ||||||||
|
投稿日時: 2002-06-01 22:02
私も余り詳しく無いので、間違ってたら許して下さい。 「最上流工程でのみ使った方が効果があるもの」と言う事はないと思います。 エンジニア的要素もと管理者的要素のどちらがが多いかというと、エンジニア的要素が強かったんじゃないでしょうか？ OMTも、GEで実際のプロェクトの中から生まれて来た筈ですよ。 それに、対象をオブジェクトそのものとして理解・整理出来ること。つまり対象に余り制限を受けずに適用出来ることがUMLの良い所だと思います。 「経営的視点から、トップダウンで、設計に降りてきた技術」と言う事は、歴史的に考えても無いと私は思います。 それから、上流、下流工程等の言葉は、まだ使われてますが、ウォーターフォール型の開発プロセスを意識した言葉の様な気がします。 最近は、スパイラルで考えますし、ドメイン・コドメインというカテゴリが自然な気がします。 一連の処理工程の中での位置付けでなく、分析・設計過程を含む全過程をドメインとコドメインというマッピングの世界で考えているんだと思います。 問題をドメイン領域で把握し、それを設計を通してコドメイン領域にマッピングしていくという感じだと思います。 | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。