UML皆でお勉強しよ♪
■ このスレッドは過去ログ倉庫に格納されています
0001ニュージーランド漁夫
NGNG（ ・∀・）＜ お勉強しよ♪
（ ） ＼＿＿＿＿＿＿＿＿＿＿＿＿
｜ ｜ |
（_＿）＿）
0592デフォルトの名無しさん
NGNGいまさらなタイミングで書くけど、MagicDraw 5.0SP1 だと、メニューバーから
1. [オプション] - [環境] で「環境のオプション」ダイアログを開く
2. 左側のツリービューで [一般] を選択
3. 右ペインに表示される [WMF文字セット] を「シフトJIS」に設定
で出力した WMF ファイルを Word2000 に張ったら、印刷できたよ。
0593デフォルトの名無しさん
NGNG0594デフォルトの名無しさん
NGNGDBのテーブル設計のための図は雰囲気の似た別のやつがあるでしょ。ER図だっけ？
UMLのクラス図の文法ってこれを下敷きにして作ったような気がする。
0595デフォルトの名無しさん
NGNGはたしてUMLのバイブルになりうるのか？
誰か読んだ人感想プリーズ
http://www.amazon.co.jp/exec/obidos/ASIN/4894712679/qid=1014735082/sr=1-5/ref=sr_1_2_5/250-0132920-0658615
0596デフォルトの名無しさん
NGNG0597デフォルトの名無しさん
NGNGこの本、もう古いよ。もしかしてUML1.1なんじゃないの？
今はもう1.4が標準的に使われつつあるよ。それでもいい、
基本的な概念が知りたいんだっていうならいいかもしれないけど。
0598デフォルトの名無しさん
NGNGオブジェクト-リレーショナル・マッピングの手法
(いかにRDBとOOPLのセマンティック・ギャップを埋めるか)って、
Rationalがなんか名前付けて出してた、と思う。
漏れは Infomix Universal Serverで有名な
Stone Brakerさんのブックレット(ORDB本)読んで、
試行錯誤したクチだけど、
こないだDOA向けCASEツールの説明会パンフレット見せてもらってたら、
「OOにもこんなに対応できます」みたいな説明にその手法が載ってて、
初めて知りました(鬱
0599デフォルトの名無しさん
NGNG有名な本となるとやっぱりboochのこれかもしれません。
http://www.amazon.com/exec/obidos/ASIN/0805305947/
が、しかし如何せん古い。RUPに則した形でかつ
もっとつっこんだ内容の本はないでしょうか？
英語の本で構わないので。
0600デフォルトの名無しさん
NGNGRational.com近辺の、大量のドキュメントの中とか、
日本ラショナルの教育で、そーいうのを扱ってると思うんですけど...
漏れも知りたいので、ご存知の方お教え下さい。
0601デフォルトの名無しさん
NGNGrationalのサイトみたけど、いいドキュメントは
なかったな。
いろいろアマゾンで検索しても
boochの本より良さそうなのはなかった。
上のヤツを買うよ。
0602デフォルトの名無しさん
NGNG情報なし/意味なしかと考えていたんで、
RUPでのプロジェクト管理について本気で探していませんでした。
今日探してみます。
んで、RUP DQNな漏れは、こんな本読もうとしてますです。
「ソフトウェアプロジェクト管理―21世紀に向けた統一アプローチ」
http://www.amazon.co.jp/exec/obidos/ASIN/4894715597/qid=1015207724/sr=1-14/ref=sr_1_2_14/250-4956143-4769858
"反復型ソフトウェア管理プロセス" に関する本で、
RUPに限らず スパイラル開発、反復型開発全般に通用する話だろうと予測してます。
Smalltalkの親玉が書いた、こっちの本も興味あるけど、まだ買えてない...(泣
「オブジェクト指向開発のプロジェクト管理―ケーススタディとフレームワーク」
http://www.amazon.co.jp/exec/obidos/ASIN/479529707X/qid%3D1015207855/250-4956143-4769858
0603デフォルトの名無しさん
NGNG>>602
この本はレビュー読む限りじゃRUPに則しててなかなかよさげですね。
翻訳は日本ラショナルがやってるからどっちにしようか迷いますｗ。
（基本的には個人で翻訳したOO関連書籍は買わないことにしてるので、）
0604デフォルトの名無しさん
NGNGDB設計は往々にしてUMLの静的分析のみで行われがちであるのは
ダイアグラムがER図のみであることから容易に推測できる。
UMLのクラス図の様にユースケースや状態変移図、シーケンス図等
の動的分析の工程加えることにより洗練された設計が可能とおもわれる。
と個人的見解をカキコしてみるtest
0605デフォルトの名無しさん
NGNGhttp://www.tech-arts.co.jp/oo/uml.html#003_4
参考になると思われ
とカキコしてみるtest
0606デフォルトの名無しさん
NGNGhttp://www.hic-soft.co.jp/news.html
0607デフォルトの名無しさん
NGNG「2002年発売予定」っていつのことだろう。
Webページの最終更新日が去年の11月だよ、大丈夫かいなこの会社。
実際どうなんだろう、この手のツールって生産性あがるのかな。
個人的には手書きとVisioで充分な気もしてるんだけど。
0608デフォルトの名無しさん
NGNG> 実際どうなんだろう、この手のツールって生産性あがるのかな。
絵を書くのは楽になる。
特に、
- 一度書いた絵に修正を加える。
- クラス図で、ある図では A, B, C クラスを、別の図では B, C, D, E, F クラスを
含めるような場合に、最初の図で設定した依存関係や継承関係を、簡単に次
の図に反映できる。
ってあたりが便利。
私は昔は UNIX で Tgif という汎用ドローツールを使ってたんだけど、細かい
修正が面倒で使うのやめた。今は MagicDraw 使ってるけど、それなりに便利
だよ。
ただメソッドの仕様なんかを細かく書くと、ソースコードと同期をとるのが面倒
なんで、
- 主要部分だけ MagicDraw で図に書いておく
- メソッドの仕様などは doxygen 形式でソースコード埋め込み
と使い分けてる。
MagicDraw は試用もできるから、とりあえず試してみたら？
0609デフォルトの名無しさん
NGNGMagicDrawは作図機能は評判がいいみたいだけど、
そっちはどかな？
0610デフォルトの名無しさん
NGNG0611デフォルトの名無しさん
NGNG>- クラス図で、ある図では A, B, C クラスを、別の図では B, C, D, E, F クラスを
> 含めるような場合に、最初の図で設定した依存関係や継承関係を、簡単に次
> の図に反映できる。
別にコピペでいいじゃん、、という気もするが（藁
ある程度の規模のダイアグラムを書いて、継続的にメンテしなきゃならないような
状況だと効いてくるんだろうな。
0612デフォルトの名無しさん
NGNGVisioでは辛いと思うのはオレだけですか？
0613デフォルトの名無しさん
NGNGもしプロジェクトで掲示板（Webアプリケーション）をUMLで表現しようと思ったら、
何から始めるのでしょうか？
その際なんですが、クラス図とか、シーケンス図、とか全てが必要になってくるのでしょうか？
自分はプログラマなんですが、普通のアプリケーションならクラス図とかは必要だと思うのですが、
掲示板とか簡単なWebアプリケーションならクラス図はいらないと思ったりするのですが・・・。
そこんとこはどうなんでしょう？
例えば、掲示板で書きこみをDBに保存して、その１つの書きこみを１つのクラスとして
java ex)
public class message{
private String date;
private String author;
private String email;
private String message;
....
}
扱う（マッピングする）なら、クラス図とかも使用できると思うのですが、
現実では、１つの書きこみをわざわざ１つのクラス（インスタンス）にしたりしませんよね？
表示するときは、書きこみをDBから取ってきて、直で表示するようにしますよね？
ん〜、難しい・・・。
オレは、UMLを根本的に理解してないんだろうな・・・。
0614デフォルトの名無しさん
NGNGhttp://www.molips.com/jp/index.html
0615デフォルトの名無しさん
NGNG自分と全く同じところで全く同じ悩みに嵌まってますな。（ｗ
自分は一度すべてをオブジェクトとして扱うようなＵＭＬの諸図を書いて、
いざ実装しようとしてワケワカに陥った末、結局ベタにコーディングしてから
リファクタリングしていくほうがうまくいったというオチでした。
ＵＭＬを設計の道具として使うか、発想の道具として使うか、日本人は前者と
して抱え込んでしまいがちだけど、業務として要求されない限り後者として書
き捨てていくほうがいいように思った。
0616デフォルトの名無しさん
NGNGこれってパッケージのネストは出来ないの？
0617デフォルトの名無しさん
NGNGUML は実装する前に方針を決めるとき、特にイテレーションの過程で次の機能を
実装するときに、
- 今、どうなってる？
- 次に、どこをいじればいい？
というのを見るために使ってる。主要なものだけ書いておいて、詳細は含めない。
書き捨てちゃっても良いけど、図の量を減らして常に up-to-date に保てる程度に
しとくと、役に立つ場面も多いよ。
0618デフォルトの名無しさん
NGNGそれにしても遅いな。やっぱりJavaアプリは
1GHzぐらいないと厳しいかもね。
0619デフォルトの名無しさん
NGNG617>>
お〜、同士がいたかぁ〜。
やっぱりそんなものなのかにゃ〜。
0620デフォルトの名無しさん
NGNG俺もそう考えちゃう。気持ちがわかる。
>>613のような状況ではどうすべきだったわけ？
・ちゃんとUMLで設計したように、プログラミングすべきだった。
・べたでコーディングしてからUMLにする。→どうやって？
だれか教えてクレー
0621デフォルトの名無しさん
NGNG私の理解だと、
要求される機能の分析のための最初はユースケースです。
次に抽出されたアクタからクラス図を書きます。
次に要求される機能から管理者ログインなどの手順のシーケンスを図にします。
フローは不要でしょう。あれはソース読めない人が
設計がおかしくないかと騒いだときに出す資料だと思います。
だって、ソースより可読性悪いもん。
今時のアルゴリズムの本だってフローチャート載せてなくて
片言ALGOLかPascalかJavaかCだし。
0624名無しさん＠Ｅｍａｃｓ
NGNGフローって昔懐かしいフローチャートのこと？
それとも別の何かですか？
0625デフォルトの名無しさん
NGNGUML でフローチャートっぽい図と言うと、アクティビティ図かねぇ。
0626デフォルトの名無しさん
NGNG>>623
の方は、何故、自分自信に返信しているんですか？
コールバック？ それとも再帰？ (W
0627デフォルトの名無しさん
NGNG1.画面遷移のモックアップを作成 紙に手書きしてから HTML でざっと
2.使う技術・ライブラリを選定し、クラスを大雑把に抽出しておく
3.ユースケースを書く。たまに変なシナリオを書くのに熱中
4.クラス図を書く。前に抽出したクラスは半分忘れておく
5.必要に応じてシーケンス図、ステートチャート図、アクティビティ図を書く
6.コードにおとしつつ 3-5 を繰り返す
7.コードを書きつつ 4-5 を繰り返す
0628デフォルトの名無しさん
NGNG（データフロー＋フローチャート）／２ぐらいだと思いますが
0629デフォルトの名無しさん
NGNGモックアップって何なんでしょうか？
0630
NGNGそんな私は組み込み系…
0632デフォルトの名無しさん
NGNGプロトタイプでもいいや。
｜モックアップ
｜ 【mock-up】
｜原寸模型。実物大の模型。
0635デフォルトの名無しさん
NGNG>現実では、１つの書きこみをわざわざ１つのクラス（インスタンス）にしたりしませんよね？
いや、すると思うけど。普通に。
その例の場合は message クラスを RDB のテーブルにマップして、インスタンスをその
テーブルの行にマップするのが定石じゃないかな。
0636デフォルトの名無しさん
NGNG613の質問をした者です。
>いや、すると思うけど。普通に。
え？ 普通に？ マジで？ しかも、定石なの？
その際の、利点とスピードは？
掲示板の例でいうと、１画面でもしも２０個の書きこみを表示する場合は、
２０個のmessageクラスのインスタンスを作っちゃうの？
EJBのEntity beanは、そういう方法だけど、やっぱり重すぎないですか？
0637デフォルトの名無しさん
NGNG613さんはプログラマなのかな。実装レベルの話と分析・設計レベルの話を
ごっちゃにしてる節が見受けられるような。。。
UMLはあくまで記法なので、その奥にあるオブジェクト指向開発への理解を
深めるのがいいと思うですよ。
オブジェクト指向分析の過程で現れたエンティティをRDBにマップする例で
参考になりそうなWebページを紹介しときます。
5、UMLを使用したデータモデリング
http://www.tech-arts.co.jp/oo/uml.html#005
UMLによるオブジェクト指向開発
http://www.mamezou.com/tec/Tips/umlForPractice/index.html
0638デフォルトの名無しさん
NGNG613じゃないけどありがと。
他スレで触発されてRUPの本を読み始めてたけどどうも分からんかった。
637さんの一言でなんとなく糸口見えてきたかも。
0639デフォルトの名無しさん
NGNGモデル分析で抽出したモデルをインターフェース／抽象クラスとして、
設計・実装過程で、インターフェースをクラスで実装する、
という感じらしいですね。
でも、モデリングになれていなかったり、アーキテクチャ・レベルの課題を解いていると、
前半部分をすっとばしがち。
(PGオンリーだと、モデルは天下りに決定済、という前提が多いしね)
んで、リファクタリングでインターフェースやモデルを抽出したりしてね。
ボトムアップな作り方をする人やグループが、
いきなりトップダウンに移行するのは、難
0640デフォルトの名無しさん
NGNGなにかしらのものとセットで覚えないとだめかもね。
おれはとりあえずRUPの本で色々試しながらやってみるよ。
一人で顧客になってみたり、ユースケースエンジニアになってみたり・・・
おままごとみたいだな（藁
0641デフォルトの名無しさん
NGNG0642デフォルトの名無しさん
NGNG誰もEJBの話なんてしてないよ・・・。
0643デフォルトの名無しさん
NGNG「作って分かるRUP」を書いて欲しい！
0645613 & 636 & 643
NGNG掲示板でEJBとか言ってるんじゃなくて、DBのROWを１つのクラスのインスタンスにマッピングする
方法がEJBのEntity Beanと同じって言っただけです。
前のメッセージをさかのぼってもらえれば分かります。
0646デフォルトの名無しさん
NGNGRoseの評価版にチュートリアルがある
0647644
NGNG＞DBのROWを１つのクラスのインスタンスにマッピングする方法
ﾏｲｸﾛｿﾌﾄの DAO とか ADO あたりのクラス設計でも、
御馴染みですよね。
ﾏｲｸﾛｿﾌﾄ環境では「パフォーマンス悪いから」と、
わざわざODBCレベルでプログラミングするC/C++ プログラマの方が、
私の周りには結構いたみたいです。
0648デフォルトの名無しさん
NGNGそれやりたいんだが量が多すぎてめんどくさいなり。
ま、実際には(Delの話だが)TDataSetが代用になるからいいんだけど。
Javaに移行したら本格的に取りかかってみよ〜。
0649デフォルトの名無しさん
NGNG２．普通に買い物をする
３．なにくわぬ顔で店を出る
４．数分後、息を切らしてコンビニのレジにかけよる
５．「お、おい！さっき俺がこなかったか！」と叫ぶ
６．「あなたが買い物していったんですよ？」と店員に言われる
７．「ば、ばかもぉ〜ん！それがルパンだ！追えぇ〜！」と、叫びながら店を出る
＃６．で「知りません」と言われたら以下のシナリオを実行。
７’．「キ、キサマがルパンだなぁ〜？」と店員のむなぐらをつかむ
８’．警察へ通報される
９’．「ま、まて！！わ、わしゃあインターポールの銭形だぞ〜！」と叫びながら連行される
↑このコピペはユースケース記述を中途半端に知っている人物が
書いたのだろうか？
0650デフォルトの名無しさん
NGNGクラス図だけでいいんだけど。
Jude1.2,1.3とArgo/UMLを試してみたけど、どっちもしばらく使ってるとデータがぶっ壊れて
図が２度と開けなくなったり、いきなり無言で落ちたりして使い物にならん。
JREのバージョンをとっかえひっかえしてもたいして効果なし..
0651デフォルトの名無しさん
NGNGフリーバージョンがある、
Pattern WeaverやMagic drawは？
Magic drawはセーブ時に要素数の制限があるから、一生懸命書いてセーブできないと悲惨だけど。
0652デフォルトの名無しさん
NGNGあとIIOSかな？
JAVA向けのページだけど此処結構揃ってるYO!
ttp://www.geocities.co.jp/SiliconValley/6064/java_link.html
0653デフォルトの名無しさん
NGNGあんなクソ言語つかわねえっつーの
0655デフォルトの名無しさん
NGNG圧倒的に多いし、RDBMSは設計、管理...でERが便利で手放せそうにないし。
クラス図だけだとちょっと辛そう。UMLとERを両方とも使っていきたいんだけど
どんなもんだろう。
0656narucy56 ◆wMOjCT4s
NGNGプロジェクトで UML 使うってのは、どういうことでしょうかね。
「かんたんUML」とかに書かれていることを、そのままやろうとしたら
多分、うまくいかない（と、思うんだけど、どうでしょう）
XP的には
「どうせクラス構成なんて開発中に変わるもの」
「せっかく作ったクラス図だって時間がたてば古くなる」
「その種のドキュメント書きは無意味」
0657デフォルトの名無しさん
NGNGホワイトボードかA2くらいの紙を壁に貼った上にね、マジックでぐりぐりと。
みんなの見えるとこにおいといて、そこに書ききれないような細かいのは書かないの。
使用がかわったらすぐに書き直し。
プロジェクト終了後と社外の人に見せるときだけ瞬間的に清書。
開発が再開したら、また、同じことするんだぞ。
0659デフォルトの名無しさん
NGNGクラス図は手書きでも構わんけど
状態変移図とかはどうしてるの？
手書きだと修正がつらくね、やり直したい時とか？
オレの場合は一応紙とツールで書く、ただし細かい部分は省略、
プロトでとりあえず自分の中で不明確な点を確認、思いついた
アイデア等は図をコピーして反映する。
>655
すでにDBが存在するならUMLの出番はDB設計においては殆ど無し。
ただし新規作成ならUMLの分析は有効なはず。>604のリンク先参照
>656
>「どうせクラス構成なんて開発中に変わるもの」
これはUMLでも同じ考え、ただし変化を考慮してパターン等
を使用して大幅に変わらんようにする。
>「せっかく作ったクラス図だって時間がたてば古くなる」
>「その種のドキュメント書きは無意味」
UMLは厳密言うとドキュメントではない気がする。
ただの設計過程での思考経過を表すメモでしかない。
それにドキュメントは時間がたてば古くなるのは嘘
仕様変更が無ければドキュメントも常に最新
UMLは設計変更に対応する際の対応方法を考えるのにも当然使用される
べきでその結果UMLは常に最新になるはずなんだけど･･･
現実にうまく行ってる所は知らない。
0660デフォルトの名無しさん
NGNG>>「その種のドキュメント書きは無意味」
>UMLは厳密言うとドキュメントではない気がする。
>ただの設計過程での思考経過を表すメモでしかない。
んだね。「クラス構成が変わる」というが、そのクラス構成をより良く変える過程で
道具として使うものだと思う
メンバ変数やメソッドを逐一記述するヤシはそういないだろ
0661657
NGNG「書き直すのが面倒な図は、悪い設計」
てことなの。
状態遷移図は、細かく書き始めると確かに大変かもしれないが、
紙の上で書き直してて、もしくは付け足してて面倒だと思ったらね、
「この状態遷移は悪い遷移。もっと簡単にしる」
ってことなの。
経験からいってもね、手書きでOKなレベルでないと、
プロジェクトの他の人がその図を見たとき、
把握できないのよ。
大切なのは、何が重要なのか、を見せること。
重要な何かが、どれと関わっているのか、を見せること。
状態遷移は、定型的なパターンを図示できればOKで、
部分ごとの細かい遷移については、あくまで、壁に貼ってある図の
「発展系」なんだって認識でやればいいの。
具体的に一個一個書きたい気もわかるけど、
重要なパターンというのは数えるほどしかなくて、
しかも大体それは、小学生でも書けるような、簡単な遷移図であるべきなんだよ。
0662デフォルトの名無しさん
NGNG大雑把なところをプロジェクト参加者全員で共有するという話だと「手書きレベル
で OK な図で留めとけ」というのは、間違ってないとは思う。
ただ通信プロトコルにせよ何にせよ、実際には複雑な状態遷移と対峙すること
が多い。簡単にしすぎると
性能
効率
安定性
どこかで致命的な妥協を要求されるから。(TCP/IP も基本的な部分は簡単だ
が、実際に OS 組み込みのプロトコルスタックを組もうと思ったら、タイマーが
並行して何個も走ってる複雑な状態遷移機械になるよね）
俺は、実装者向けの図としては詳細まで書いた方が良いと思うよ。もちろん、
図に書かずにコードで書くという選択肢もあるが、経験的には図を書いた方が
ロジックミスを防ぎやすいし。
0663657
NGNG実装者が、詳細レベルまで書き下ろすことについては否定しない。
で、そういう実装レベルの図を、ドキュメント化して、実装と同期をとることも
否定しない。
そもそも、いままでそういうのを図示する共通のやり方がなかったわけだからね。
そして、たぶんその図は壁には貼られないだろうけど、
仕様のレビュー時と、コードのレビュー時に、大いに役立つだろうね。
でもおれんとこのだと、そこまで細かいものは、書く人は書く、
書かない人は書かない、で仕事しちゃってるんだよね。
徹底させてるのは、例の、壁に貼るやつだけなんだ。
0664デフォルトの名無しさん
NGNG>659
>すでにDBが存在するならUMLの出番はDB設計においては殆ど無し。
>ただし新規作成ならUMLの分析は有効なはず。>604のリンク先参照
これは分か気がするし勉強してみるけど、すでにDBがある場合は、
コードの設計をUMLでやりたいし、新規作成の場合も、最後はERから
DBへ落としたいので、いずれにしても最終的にUMLのドキュメント
と、ERを共存させたいんだけど。
それとも切り替えるのかなー。ここらをどうやってるか聞きたかったわけ。
あと、手書きでホワイトボードうんぬんの議論は分からないではないし、
議論はそれでやるけど、実際、それだけではプロジェクトは崩壊する。
8人ぐらいならまあいいかもしれないけど、100人以上の規模になると、
ER、DB定義なんかみんなのバイブルだし、ステート遷移、通信プロトコル
あたりも同じ。全体設計にかかわるところは文書化して、配布しないと
どうにもならんと思うが。
もちろん、いろいろ壁に貼っとくけど（これらのバージョン管理は大変ね）。
だいたい、ホワイトボードを永遠に消さないつもり？
議論の結果はドキュメントにしなけりゃ時間の無駄だよね。
だったら、最初からドキュメントにすること考えて作業したほうがいいと思うけど。
量的にも、ERにしても1000個近く表があったりする手書きで済む話じゃないし。
実装と完全に同期が取れていなくても、ドキュメントが無意味であることに
はならない。手書きで書ける簡単な図にしたって、納品うんぬんより電子
ドキュメント化して共有しなけりゃ議論もできない。
簡単に全体が把握できる図が必要ということはまったくそのとおり。
でもそれだけじゃ無理だし、そもそもUMLって階層的に概略から詳細まで
落とせるんだよね？ まず全体見るし、必要なら詳細見れるように書くん
じゃないの？
細かいクラスの定義なんかは、コード見ればいいけど。どこのコード見
ればいいのかのガイドはいるだろ。
あと、自分のプロジェクトではないのし、アプリの内容にもよると思うが、
プログラマーに最後までクラス図書かせてるプロジェクトは、コーディング
量も少ないし、従ってバグも少ないようだが、いかが？。
0665657
NGNG他も大体同意。
ホワイトボードは会議中だけ。
0666デフォルトの名無しさん
NGNG0667659
NGNG基本的にはUML->ER図への変換し別々に管理する。
別の手として三階層サービスモデルでテーブルを
データ層に直接記述する。もちろんデータの取り込みや
管理等も一緒に。これは大規模には使用できないかな？
でもUMLを作図した際の情報を考慮すると自然とキーや
リレーションっと言った感じが見えてくるし何より処理
に対して必要なデータが判り易くER図だけより良いのではと思ってる。
やっぱ開発規模によって使い方は変わってくるな。
これかはレスするときには分析者、実装者と開発規模とかも
記述した方がよさげ。
ちなみにオレは実装者、小規模
0668デフォルトの名無しさん
NGNGなんかおもろい活用法ないかなーと、
ちょろちょろうろつく予定です。
0669668
NGNG鬱氏
0670デフォルトの名無しさん
NGNGなんかよさげな物あった？
0671デフォルトの名無しさん
NGNG会社が金だしてくれたんでチュートリアルにでてきたよ。
というか、上司に「チュートリアル逝け」といわれた。
「超入門」というだけあって、内容は簡単だったよ。
ただ途中の「メタモデル」の部分だけはサパーリだったよ。
社内の報告＆内容発表ではそこはとばすつもりだよ。
資料がおおすぎて、時間が足りなくなって、とばしまくりだったよ。
事例が多かったので社内のUML化推進の材料にはなりそうだったよ。
質問はあまりでてなかったよ。
ただ途中いかにもオタクあがりのへんなやつが時間がないって急いでいるのに
意味不明の質問をしてからんでたよ。
昼休みにみたUMLでモデリングした自走ロボットカーのレースはおもしろかったよ。
0672デフォルトの名無しさん
NGNGやはり、そんな感じになるのね。
別の手のほうだが、データアクセスのところ（DAOね）は高スキルの人間に
任せたいので、その手法をとっているプロジェクトもある。大規模200人以上。
ただ、クラス側にあまりSQL書かないで、PL/SQLでストアードで実装し、
DAOをそれを呼ぶだけで簡略化しているようだ。
これをうまくやればＵＭＬ系の人と、ER系の人をある程度分離できるかなー？
ただ、667が言うように、両方使いたいんだよね。
DBがオブジェクトDBとしてもっと進化するか、UMLのステレオタイプが進化して、
詳細レベルはDBの物理実装まで記述でき、DBスキーマと対応取れるようになるまで、
インピーダンスミスマッチはごまかして行くしかないんだろうか。
あと、方法論と開発規模の件も同意。最近読んでる本によると、規模に応じた選択を
考える方法論がかかれているらしい（まだ、翻訳されてないみたい）。
ただ、開発中のコミュニケーション、問題発見のためのドキュメント等は規模依存と
思うけど、開発しちまったもののドキュメントは量を除き、システム規模でそんなに
変わらない気がするが、いかが。
0673667=670
NGNG>事例が多かったので社内のUML化推進の材料にはなりそうだったよ。
いいな！うちの職場もUML推進してほすい。
>672
両方使うときの最大の問題点はやっぱり同期なんだよね。
これを解決するいい方法が俺には思いつかない。
ツールもたぶん存在するだろうけど熟練度が低いと邪魔なだけ。
それに最悪1プロジェクト内に2文化が発生して実装側が混乱
し、それに伴いバグ頻発するし。いいアイデアがあれば教えて欲しいです。
ドキュメントについては同意。
でも大規模な開発に関わったことがないの正直分からんけど
オブジェクト数はどれくらいなるんだろ？
100を超えてくると混乱するからそれを解決するためにレベルが
発生してくるのでは？。
レベルがどのように分けるべきかははっきりと見えてないけど
それを管理するドキュメントみたいなものが別途必要なのかな。
0674671
NGNG一番上の人は推進せよっていって、
折れにいろいろ勉強させてくれてありがたいんだけどね、
開発の実質的な中心人物の先輩は「あんなもんは必要ない」って
感じの人なんで間に入る折れはちょっと苦しいかも。
もともとチュートリアルもその先輩に話があったのが
「忙しいから」と断わって折れに振られたわけだったし。
0675デフォルトの名無しさん
NGNGいわゆる抵抗勢力というやつですな。
0676デフォルトの名無しさん
NGNG俺もチュートリアルでたが、UMLを学ぼうと意気込んでいった
俺には前半以外は難しかった…。超入門とは思えない。
あれはなに？UMLを使うっていうよりは、UMLを研究している人たちの
場なのかい？
自分が場違いな感じがして情けなかったよ…。
> ただ途中いかにもオタクあがりのへんなやつが時間がないって急いでいるのに
> 意味不明の質問をしてからんでたよ。
あの人は他の会場にも出没して意味不明だった。
0677デフォルトの名無しさん
NGNG「UMLエディター作成者のための機能自慢大会」みたいで痛かったYO!
方法論のないUMLなんて...
0678デフォルトの名無しさん
NGNGあまり方法論に固執する問題あり
って言うてみるテスト。
0679デフォルトの名無しさん
NGNG君はおおむね正しい。
って言ってみるテスト。
0680デフォルトの名無しさん
NGNGあんまり開発方法論に固執すると問題あり
って言うのと同じ程度の意味しかないと思われ
0681デフォルトの名無しさん
NGNG方法論のない開発なんて、学習中の初心者か、
混乱しきって予測不可能になった開発現場にしか存在しないんじゃないかー。
そういう基本前提があるからこそ、
開発方法論の差異を超えた、共通のモデル記述言語＝UMLが、
重要なんだよね。
0682678
NGNGそうなんだよね。開発方法論は重要なのは確かだけどUMLだと
この開発方法でやらなきゃダメみたいな感じになってる人が
多い気する。>680が言うようにUMLで有効である開発手法は
ある程度決まってるが型にはまったやり方だけしか許されない
わけではない。
っていうかそれだとつまらんでしょ。（ｗ
0683デフォルトの名無しさん
NGNGようはある程度の方法論があった状態で、UML考えたような
気がするのは私だけ？
0684デフォルトの名無しさん
NGNG当然しょ。
最終的には普及のために方法論と独立を目指すとはいえ
開発方法論から生まれた話なのは間違い無し。
0685デフォルトの名無しさん
NGNG課のみんなに、使いにくいぞ。ゴルァ。とか言われるの怖いんですが、
UMLツールの選定、この選択で正しいと思いますか？ 当方、Java。
0686デフォルトの名無しさん
NGNG絶対、間違い。紙とペン。これがマジ最強。
0687デフォルトの名無しさん
NGNGうちも、とりあえず一つ買ってみた。
結構いいと思うし、コストパフォーマンスは優れていると思う。
とりあえず気になるのは、
○設計情報がXMLで交換できるはずなんだが、rose評価版とうまくいかなかった
○シーケンス図とコラボレーション図の自動変換ができない
以上は、まだ使い方よく分かってないからかもしれない。あと、多人数での
設計まとめるサーバは使ってないのでわからない。
オージスから出ているツールもよさそう。値段はMagicDrawの倍。
だれか使ってみたひといたらどんな感じ？ なんか、評価版が落とされまくった
らしくて、現在ダウンロード停止されているので、評価できない。
紙とペン派は、多人数で、コミュニケーション共有しなけりゃならない状況は
わかっていないと思われ。そもそもUMLはコミュニケーションツールなので
その手の方たちには必要ないだろう。
手書きのコピーを配布するなら、彼らには、ワープロも、visioもいらないだろ-な。
068830年前から時空を越えてレス
NGNG0689デフォルトの名無しさん
NGNG>○設計情報がXMLで交換できるはずなんだが、rose評価版とうまくいかなかった
XMI？XMIはまだ標準仕様が固まってないのでツール間での連携はあまり期待しない
方がいいと思います。
>○シーケンス図とコラボレーション図の自動変換ができない
普通はどちらか一つだけ書くものだと思うんですが、必要なんですか？
＃私はOMTから入ったので慣れたシーケンス図しか使いません
>紙とペン派は、多人数で、コミュニケーション共有しなけりゃならない状況は
わかっていないと思われ。そもそもUMLはコミュニケーションツールなので
その手の方たちには必要ないだろう。
最初あーでもない、こーでもないってやってるうちはホワイトボード最強ですね。
でもある程度固まったらツール使って清書するし、一人で考えてるときもツール
使って書いたり消したりしながら考えます。
ただUML使って設計を覚えようという人は、ツールをいきなり使うより手書きで
書いてみるといいと思います。OOA/Dの手法とUMLの記述法とツールの使い方を
いっぺんに覚えようとしたら挫折してもおかしくないでしょうからね。
0690685
NGNGマジレスありがとうございます。
とりあえずのリヴァース、フォワード、
あとチーム開発ができる安価なツール、
ということでMagicDrawを選定しましたので
Roseとの互換性はさほど気にならないんですが、
>○シーケンス図とコラボレーション図の自動変換ができない
はちょっと痛いですね。これだと、
リヴァース時のシーケンス図生成も行われないんだろうか……（；´д⊂）
というか、体験版さわってみたものの、
リヴァースしたクラスをクラス図に反映できん。
0691デフォルトの名無しさん
NGNG>689
シーケンス図とコラボレーション図は用途によって両方欲しいことが
多いと思う。ぱっと見はコラボレーションが全体像がつかめていいし
少し詳しくシーケンスを考えるときはシーケンス図。いずれにしても
同じ情報だから、いちいち書き直したくないなー。
XML形式はXMIと思われます（よく知らないものでスマン）。
そもそも、MagicDrawはセーブするとXMLのZIPファイル
しかファイルが作られません。これ、展開するとテキストで読めます。
これがXMIの構造になっていると思うんだが。
おっしゃるとおり、互換性はよくない模様（ツールメーカー何とかして欲しいな）。
>690
クラス図と、継承関係ぐらいまではリバースできた。シーケンスとかは無理と思う。
ただ、開発方法論の話になっちゃうけど、リバースはあまりやらないほうがいいと思う。
クラス図から直すのは大変だけど、トータル、長期的にはメリットも多しと思うのだが。
せっかくの設計が...とうことになりかねないと..。
もっとも、開発サイズとか、時と場合によりけりは方法論の常ですが。
チーム開発環境としては、結果レポート希望。
あと、紙＆ペンは否定はしてないが、これだけですむはず無し。
だれだって、メモ、走り書き、ホワイトボード図はかくに決まってるが
それだけだと、プロジェクト期間中もしくはその後メンテまでのスパン
でコミュニケーションできない。
ちょっと話がずれるが、昔、アクタとかMoreとかいう、MACでのアプリが
あったのを知ってるでしょうか。思考支援ツールといわれ、まあ今で言う
アウトラインエディタですな。ようは、ワープロは清書するだけでなく
これで書いていろいろ動かしていることで思考支援されると思われ。
論文書くときは、目次が一番苦しむからね。
いろいろあるカード利用の方法なんかも同じかな。で、ノートにUMLツール
いれて、プロジェクターでやってみようと思ってる。プロジェクター高いけど。
クラス図をカードにして、ボードであれこれ動かして議論するとよいと言う本
もあったが、あとでその結果を写すのが面倒。うまくいくと思うんだがだれか
やってみたことあります？ ERのレビューはこれでやったことあり（紙の配布も
同時にやったけど）。
0692narucy56 ◆wMOjCT4s
NGNG「コミュニケーションにコンピュータ使うことは人の視点を
コンピュータに向けてしまい、ダメ。視点は常に人に向いて
ないといけない。」
とのことで。
それ以前に、どうしても、印刷された UML図 が必要なシーンとい
うのが思い浮かばない。
わざわざ難しい設計にしてしまってるんじゃないの？ どうなの？
■ このスレッドは過去ログ倉庫に格納されています