UML皆でお勉強しよ♪
■ このスレッドは過去ログ倉庫に格納されています
0001ニュージーランド漁夫
NGNG（ ・∀・）＜ お勉強しよ♪
（ ） ＼＿＿＿＿＿＿＿＿＿＿＿＿
｜ ｜ |
（_＿）＿）
0581デフォルトの名無しさん
NGNGそれは禁句だ。
0582デフォルトの名無しさん
NGNG一応説明のあるページを紹介
ttp://www.asahi-net.or.jp/~dp8t-asm/java/tips/UMLClassDiagram.html
オレとしては
集約は共通で使用するインスタンスを管理する場合
コンポジションはインスタンスの管理に特化して所有権が
移動しない場合
その他は関連
でもコンポジション使用しないで集約にしておいて実装時決定する感じ。
0583ゴリ
NGNGなるほど。
考え方ですよね。
同じ実装方法でも、考え方の違い。
0584デフォルトの名無しさん
NGNG何点くらい取られました？
俺、以前から逆に２０点ほど下がってしまった…
受かるのはいつになるやら（＾＾；
0585デフォルトの名無しさん
NGNG読めないからフローチャートで書き直せって言われた(鬱
0586デフォルトの名無しさん
NGNG今度はシーケンス図で再チャレンジだ!（ｗ
状態遷移図ってUML以外でも結構使われるんだけどね。
0587デフォルトの名無しさん
NGNGなんかそのあたりがわからん
0588デフォルトの名無しさん
NGNGオレもあまり詳しく知らないんで間違ってるかも知れないけど
オブジェクト指向設計のための表記法で分析と設計の両方で使われるはず。
DB設計にも流用可能だと思うよ。
0589デフォルトの名無しさん
NGNGクラス＝テーブルって訳じゃないだろ。
0590デフォルトの名無しさん
NGNGhttp://www.gentleware.de/jobs/index.php3
IIOS
http://www.iioss.org/index-j.html
だれか両者の関係知らん？
0591 デフォルトの名無しさん
NGNG0592デフォルトの名無しさん
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あんまり開発方法論に固執すると問題あり
って言うのと同じ程度の意味しかないと思われ
■ このスレッドは過去ログ倉庫に格納されています