- - PR -
UMLを用いた開発について
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2002-06-04 12:20
私は、最低限クラス図は書くようにしてます。 実際に書かないと、思い違いというのが、結構ありますから。 ツールとしては、Delphiの場合、「ModelMaker」を使ってます。 当然英語判なので、機能をまだ完全には使い切ってないですけど。 Delphiとの連携は、かなり良いですね！ （でも、BorlandがUMLではラショナル社に傾いてるみたいなんですよね…。）
これに関しては、既にartonさんが書いておられますが、私も同じ意見です。 クラスの継承・インターフェースに関する、ある程度以上の整理はソースを書き始める前に行う必要があると思います。 | ||||||||
|
投稿日時: 2002-06-04 13:20
ちとだけ。
C++ のライブラリ標準化が進まないのは、すでに独自実装が出回ってしまったからでは。 標準化するメリットもあまり感じられないですし。 Javaは、まぁ、Sun が主導とはいえ、うまくチェアマンやってるんじゃなですかね。 regexp にしろ XML まわりにしろ。みてると。 C# の ECMA はちょっと眉唾かなぁという気もします。言語としては規定してあっても、ライブラリが握られてたらそれほど意味はないですし。 # Java の「言語仕様」だけが標準化されててもあんまりうれしいとは思わない。 -- んで UML 話。 ソース→UML ってのは、デザインパターンといっしょですよ。頭の中にあるぼーっとした概念（共通意識）を形式化して明示的に共有する手段として UML が使える、っていう話。 私が UML は業務よりで使う方が幸せだと思ってるのは、この表現方法が、技術者的視点でありながら、業務者にも受け入れられやすいため、「これは UML です」なんてことを言わなくてもなんとなく意識共有できるからです。 # たぶんできてる…と信じたい…。 # 少なくとも既存の表現方法よりは。 | ||||||||
|
投稿日時: 2002-06-04 17:48
表現のしかたが悪くてすいませんでした。
＞過剰な期待はしない。 ＞意思疎通のための ＞「共通表現方法」 ＞として、捕らえると言う考え方は、 ＞どう思われますか？ ＞実際に、ソースに落とすのは、やはり、従来と同じくコーディングした ＞方がいいのでは？ と、書いたのは、ソースを書いて、その説明や整理に、UMLを使うと言う意味ではなく ソースを書くより前の設計や要求仕様の段階での「共通表現方法」と 言う意味なんです。 誤解を与えるような書き方をして申し訳ありませんでした。 私も、インターフェースの部分がUMLで０の状態でソースを書いて、 その説明にUMLを使うでは、本末転倒と思います。 最低限、インターフェースまでは必要でしょう。 UMLから、直接、ソースをコーディングするのはどうなんだろう？ と、思ったんです。 それほどの期待をしていいのかな？と、 すいませんでした。 | ||||||||
|
投稿日時: 2002-06-04 18:30
誤解してました。 けどそれでいいんです。 細かいところはしょむさんと違うかもしれませんが、 言葉を借りれば「UML は業務よりで使う」がまず１つ。 もちろん設計なくしてソースはできません。 インターフェースは決定します。 基本的に継承関係は決めない。（ライブラリアンに任せる） そこにUMLは使用しない。 できあがったソースから「共通表現方法」としてUMLを出力する。 UMLは「見易いがきっちり作成しようと思うと割と面倒」という印象です。 サクサクできるようになれば考えも変わるかもしれませんが．．． それと対象言語が現状JAVAやC#でないあたりも意見の食い違う原因かも？ | ||||||||
|
投稿日時: 2002-06-04 19:35
ああ、そうそう、私も一つ勘違いして抜けてました。
そこまで考えてませんでした。。。 完成後の共通表現としてUMLを使うってのも重要ですね。 一度作ったら、作りっぱなしで済むほど完全な物など出来ないし。。。 出来たとしても、時代や企業や顧客の変化で、先々変更が必要になったりする。 その時に、必ずしも、全員が同じメンバーでするとは限らない。 逆に、違うメンバーの可能性の方が高い。 他人が作った物で、仕様とソースにずれが大きくて、 結局、ソースから仕様を作り直したり、 そのソースを担当した人を探し出して聞いたり、 仕様の表現が把握しにくかったり。 で、困ったことあります（苦笑）。 確かに、それ、非常に重要ですね。 | ||||||||
|
投稿日時: 2002-06-04 19:45
UMLからソースが生成できるとき、恐怖の想像
UMLからのソース生成が、仮にできる様になるとし、現在のそれとは格段に性能があがり、シーケンス図の記述能力、およびそれを使ったソースの生成能力が上がれば必然的に式を埋めるだけでプログラムを開発できる開発ツールになりますよね。 UML自体が開発言語に変貌してしまうわけです。これこそVisual開発。 こうなった状況で図形を常に最新に維持しなさいってのはソース修正と同じですから文句のつけようもありません。 さて、そうなった時に、クラス図を書く作業は設計、実装のどちらの分担になるんでしょう。 ソースだから、実装の仕事ですよね。 その作業をするのにあたって資料としてもらえるのはユースケースだけ？ 設計はえらく楽になりますね。 さて、これは現実的なUMLの運用でしょうか？ UMLその物の有効性は十分に有ると思うのですが、仕様っていう物には何につけても必ず抽象度があります。仮に抽象度０であればそれは仕様を解釈するコンパイラがあって、コンパイルすれば動作するプログラムが生成されるはずです。 クラス図には動作という物が記述されませんので、動作についての抽象度は無限大であると考える事ができます。しかし、構造については抽象度を０にする事も「努力をいとわなければ」可能です。 設計から開発というのは順次抽象度を下げていく作業ですので、UMLで記述するクラス図等に抽象度があっても構わないという論点に経つこともでき、私はこの論点に立ちます。 例えば、クラス図において、何かを１対多で持つとしたら、配列の他にコレクション等多様な手段で持つことが可能ですが、クラス図のレベルではそれを決める必要は無いのです。 数値を持つ必要があるとした場合、実際の型は、IntなのかLongなのかFloatなのか、Doubleなのか決めなくてもこれがクラス図だと言っても良い事になります。 RADとの結び付けでソース生成ができるという使い方を求めると必然的にクラス図の抽象度を下げていく必要があり、詳細で精密なクラス図が育ってしまいます。 設計から開発にかけて、本質的には抽象度を下げていく作業だと私は認識していますので、ある部分における抽象度を設計のサイクルにおいて０にするのは間違いだと思います。 設計が抽象度を限界まで下げる必要は無い、そもそもソースが生成できるような設計は、設計という領域から足を踏み外しているという意味で過剰設計といっても良いでしょう。 この過剰設計を防止するという意味合いで言えばソース生成なんて機能は無くて良い、UMLの表現力はもっと低くてよいと思っています。 UMLをうまく使うには抽象度をうまくコントロールする為の経験と勘が必要なんだろうなと思います。 それを身に付けると結果としてソースとはある程度の抽象度の違いによる乖離が発生するだろうと予想がつきます。 クラス図は捨ててしまいたいと以前書きましたが、よく考えると、「ちょっとしたインターフェース修正で設計を直すほどのことをしたつもりは無いのに、あっちこっち図形を直さなきゃいけなくなる、いっそ無いほうがマシ、捨てたい」という心の叫びだったと思います。 本当に価値のあるクラス図はちょっとした変更では揺るがないシステムの基本構造を記述するものだろうと思います。 そういう観点では、API仕様などに使うのはクラス図でなく、ドキュメンテーションコメントの方が良いでしょう。 クラス図を作るのはソースには程遠い、下手するとクラス名と多重度、参照可能性、継承関係だけが見えればそれだけでも価値があり、それ以上は図形管理の煩雑さから入力しないか、表示しないか、抽象的に書くかの３通りで「過剰設計ではないか？」と自分に聞きながら書くのがちょうど良いと私は思います。 | ||||||||
|
投稿日時: 2002-06-04 22:47
う〜む、「UMLからソースの自動生成」の議論は不毛な気がする。
最初にこのスレッドを立ち上げた時、UMLからソースの自動生成なんて微塵も考えてなかったが、いつの間にか話題の中心になってしまっていますね。 UMLは勉強すればするほど「表記法」です。 | ||||||||
|
投稿日時: 2002-06-04 22:50
ふうすけさん。
現実は、それが正解に近いと思いますよ。 夢を書いてたんですよ。私はそう、このスレッドのソースへ自動的に落とすって 話しは解釈していました。 理論だけでは駄目、技術だけでも駄目、でも、理論も技術も知らないと駄目、 矛盾してることを書いてますが。 レベルの問題だと思います。 概念と理念と構造、ここが、基本出発点じゃないでしょうか？ 今後、それほど大量なPGは、日本で必要となるとはあまり、私は思ってません。 専門性としては、SE、NE、デザイナー、人間工学、他にもいくつもあると 思いますが、専門性として必要とされているのはと言うか、専門家ってのは 日本では、このレベルを言うと思ってます。 で、話しが戻りますが。。。 ----------------------------------------------------------------------- 理論だけでは駄目、技術だけでも駄目、でも、理論も技術も知らないと駄目、 矛盾してることを書いてますが。 概念と理念と構造。 これに、人間関係と交渉力、PMBOKと、調整、制御、リスクを出来るだけ早く 正確に把握して、手遅れにならないうちに、是正すること。 特定業種の業態を把握すること、顧客の置かれている状態の把握。 ----------------------------------------------------------------------- などなど、上げれば切が無いですが、 基礎を抑え、マクロ的な把握をする。 社会情勢や業界地図や業界の優位性その他、あれ、 すいません。また、並べてしまいました。 分かりにくい文章ですいません。 結局何が言いたいのかっていうと、 これは、 PMが必要とする能力だと思ってます。 なぜ？今まで、こんな事を一言も書かず、 夢をそのまま書いていたかは、このスレッドの目的が 見ている限り、理想論をまたは、言葉を変えれば、理想的な将来像を 求めて書かれていると、把握したので、 私はそれに沿って、このスレッドには投稿してきました。 今まで、このスレッドに一生懸命書いてきたり、考えたりした人達に失礼に なりますが、このスレッドを立ち上げた人にも失礼になりますが、 お詫びを一言、言わせて頂いて。 別のスタンスから、書かせて頂きます。 というか、書かせて頂いてます。 PMという、マクロ的見方をすると、現実には現状では、 このスレッドの内容は夢と理想であり、 今、直接、業務に適用出来るとは、私は思いません。 下手をすれば、誰かが何かを思いついて、そう遠くないうちに実現するかも しれませんが、実際は、今後5年10年単位の話しに近く感じます。 私は、現役のPMではありませんが、 現役のPMの人でも、このスレッドに書かれていることを 現時点で取り込んで使ってみようって人は居ないんではないでしょうか？ 実験するにせよ、リスクが大きすぎると思います。 PMとSEは、重なる部分もありますが、重要なキーポイントは、 違うと思います。 PMの観点からは、疑問に思います。 SEの観点からは、こうなって欲しいと言う、切実な願いがあるように感じました。 ふうすけさんの内容は、現実の現時点での、SEから見た考え方として、 最も、現実的に思います。 これを、どうコントロールするか？ PMの観点から考えると、まだ、私は答えが出ません。 ただ、現実的と言う面で、ふうすけさんの考え方が 適当なのではないか？ と、思います。 いつも、私の投稿は長くなってしまいますが、 申し訳ありません。 よろしく、お願いします。 | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。