5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

■ おまえらUMLで設計書いていますか ■

1 :非決定性名無しさん:02/03/07 10:47

こいつを使えばシアワセになれると言わんばかりの統一設計表記法、UML。
が、未だに設計をUMLで書いたプロジェクトには遭遇していない。
おまえらの周りでUMLを使った設計は使われていますか?

UMLについて語ってください。



2 :非決定性名無しさん:02/03/07 11:08
>>1
お前が書け。お前が前例を作れ。お前が社内標準を作るのだ。

3 :非決定性名無しさん:02/03/07 11:53
>>1
UMLで設計記述したプロジェクトなんぞけっこうあるあるよ。

4 :非決定性名無しさん:02/03/07 11:55
UMLをプロジェクトに持ち込むと、プロジェクトに携わる奴ら全員がUMLを
マスタしていなければいけない。これは大きなコスト負担になってしまう。
UMLも中学生高校生が読めば簡単に理解できるようなモノではなく、
オブジェクト指向対応プログラミング言語の総合的な理解と
実務経験などがあってはじめて理解できるようなものであって、
自在に操れ、ユースケース図、クラス図などを見てシステムの全体像が
客観的に把握できるようになるまでの道のりは長い。しかも全員が
ある程度のレベルまで達していないとプロジェクトの進行にも影響が出る。
結局は絵に描いた餅=UMLということになりかねない。
UMLをプロジェクトに導入することは、ちゃんと舗装された危ない橋をわたっているようなものだ。


5 :非決定性名無しさん:02/03/07 11:55
UMLとクラスってなんか繋がり悪いようなー。言語よりじゃないよね。
VBが消えて、主流言語が、Java、C#、Delphi/Kylixと実装継承ベース1色になるんだから、
それらに寄り添って欲しいね。

6 :非決定性名無しさん:02/03/07 13:22
>>5
いみふめ

7 :非決定性名無しさん:02/03/07 14:07
>6
JavaやDelが出来る人でも、何かUMLって読めないじゃん。

8 :非決定性名無しさん:02/03/07 15:39
>>4
そんなレベルの人達じゃもともとだめでしょう…

9 :非決定性名無しさん:02/03/07 16:03
確かに、そんなレベルなら逆にUMLで勉強になるね。

10 :非決定性名無しさん:02/03/07 17:01
情報処理試験にUMLを標準で組み込んで欲しい。

11 :10年目:02/03/07 19:36
>>5
UMLの何がクラスとつながり悪いの?
>>10
禿同。


12 :非決定性名無しさん:02/03/07 22:02
開発プロセスどれつかたらいいの?

13 :非決定性名無しさん:02/03/07 22:15
RUP

14 :非決定性名無しさん:02/03/07 23:17
xp

15 :非決定性名無しさん:02/03/08 00:14
半角小文字で書かれると、なんか頼りないねぇ?

16 :非決定性名無しさん:02/03/08 09:46
uml

17 :非決定性名無しさん:02/03/08 16:27
>11
クラス宣言に比べて情報が激減してない?
Rationalの宣伝でもUMLで全てを表せるわけじゃないって書いてたよ。

18 :非決定性名無しさん:02/03/08 17:30
こんにちは
ミントメールというのをご存知ですか?
これはアメリカで運営されていて、登録者は企業の広告メールを1通受け取るごとに
月に10ドルもらえるというサービスです。
メールを受け取るだけで良いので英語が読める必要はありません。
もちろん登録料・維持費は一切かからないためノーリスクです。
興味のある方は以下の手順に沿って登録してみてください。

↓まずはこのサイトを開いてください。
http://www.MintMail.com/?m=2316004

ここから(sign-up)をクリックします〜!!そしたら加入画面が出ます。
下記の説明通り入力すればいいです。
(*がついている部分のみ正確に入力します。)
- First Name*: 姓 → TANAKA
- Last Name*: 名 → TAROU
- Company Name: 書かなくていいです
- Street Address*: 市区郡より →MINATOKU TORANOMON 1-2-3 SUMAIRUMANSYON 101
(住所は正確に入力して下さい。この住所に小切手を送ります)
- City*: 都市名 → TOUKYOUTO, JAPAN
- State*: そのまま
- Zip*: 郵便番号 → 000-0000
- Country*: 国 → JAPANを選択
- Phone*:電話番号 → 国家番号(日本):81 + 地域番号の前0を除いた電話番号
03-1111-1111 → 81-3-1111-1111,090-1111-1111 → 81-90-1111-1111
- Fax:書かなくてもいいです。
- E-mail*: メールアドレス(全てがメールで処理されるから正確に書いてください)
- Confirm E-mail*: メールアドレスもう一回入力
- Year of birth*: 出生年 → 1970
- Gender*: 性別 → Male(男性), Femaie(女性)
- Password*: 暗証番号 (6文字以上)
- Confirm Password: 暗証番号確認, 上記と同じ
- how do you want to receive commissions that you earn?プレゼント選択
*gift certificates(double$$) プレゼント券(2倍) *cash現金
- do you want to be notified when your referrals sing up?*あなたの会員が登録された場合お知らせしますか?
 yes を選 択
- 興味ある分野10個まで選択します。(10個以上だった場合、エラーになるから10個まで)

- Submitをクリックすれば画面に thank youというメッセージと一緒にあなたのID番号と
 暗証番号が出ます。そして5分以内にあなたのメールアドレスに加入完了のメールが届きます


19 :非決定性名無しさん:02/03/08 18:41
分厚過ぎる「ドキュメント」
http://objectclub.esm.co.jp/eXtremeProgramming/thud-j.html


UML 使うと何かカッコイーからとかいう理由で使うのだけはやめよう。
必要になったら書こう。

20 :非決定性名無しさん:02/03/08 23:29
クラス宣言の情報 >>>>> UMLの情報 >>>>> UMLから読み取れる情報

UMLの冗長さ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> クラス宣言

ま、オブジェクト指向はクラスベースだけじゃないけどさあ。

21 :非決定性名無しさん:02/03/08 23:35
http://www.inkando.com/cgi-rankingplus/rankin.cgi?id=0511030508

22 :非決定性名無しさん:02/03/09 01:40
>>10

無理。問題作成者と試験を教える講師がUMLとオブジェクト指向の
意味を理解していない。

23 :RAS:02/03/09 19:10
>>22 UML認定試験とかあるから、真似っ子するかもね。

24 :非決定性名無しさん:02/03/13 19:48
>23
剥げ堂!!でもないけど…情報処理試験には組み込んで欲しい。
Javaを入れるよりもフローチャート削除してUMLを組み込んで欲しかった。

25 :1年生:02/03/14 18:38
クラス図のロール名がよく判りませんです。
かんたんUMLと独習UMLを読んでやっています。
どういう基準でロール名をつけていくのか、ということと、
Javaへ展開(?)した時どういうプログラムになるのか、がイマイチ見えてきません。
みなさんの経験談を教えてください。プリーズ


26 :1年生:02/03/14 18:40
あと、会社の命令でRationalRoseか、Visioを使うことになったんですが、
先輩のススメもあってRoseを選択しました。
これって、使いやすい方ですか?30分ほど使いましたけど、
なんかちょっと、なじまないというか。UML自体をよく判ってないっつーのも
あるんですが、みなさん、これ使ってますか?

27 :非決定性名無しさん:02/03/15 13:08
ラショナルからスペアプが来た age

28 :非決定性名無しさん:02/03/15 13:17
>26
使ってない、という結論が出てるが。。。

29 : :02/03/15 13:27
>>19
に禿げ同だ。

30 :非決定性名無しさん:02/03/15 13:40
NTT系はUMLでドキュ提出すると喜ばれるだろうな。
それにしても、大して普及してないのに、Lモード申請ドキュの量多すぎ。
イターイ何様か。

31 :ずれずれ:02/03/15 21:47
>>30 普及台数が4桁言ってないとか...
  でも、UMLと禿げしく無関係。

32 :非決定性名無しさん:02/03/16 10:29
Rose高すぎ。
今の値段知らないけど。。。


33 :非決定性名無しさん:02/03/16 17:32
インドの会社はUMLしか受け付けてくれない。
それでもArtifactは安い、早い(+実行速度速い)、品質高い。
今後、このようなながれで、UMLが急速に普及すんじゃないかしら。

34 :非決定性名無しさん:02/03/16 17:37
つまり、ソフトウェア開発海外発注時代の共通言語であると、いう感じ?

35 :非決定性名無しさん:02/03/16 20:30
漏れも今の会社で、部下に超優秀なインド人PGがいるけど、
彼らの能力を最大限に引き出すためには、UMLは格好の道具
だと思った。
UMLなんて所詮道具なんだから、道具の使い方を覚えるための
勉強をしている自分に酔ってしまってはいけないと思う。



36 :非決定性名無しさん:02/03/16 20:38
ぇ、もしかすると、国内法人があるインド系ソフトウェア会社ですか?

37 :非決定性名無しさん:02/03/16 20:47
>>36
てか、
>国内法人があるインド系ソフトウェア会社
から常駐PGを受け入れてる某オブジェクト指向系ソフト会社です。


38 :非決定性名無しさん:02/03/16 20:49
関数言語だと、フローチャート書いちゃうとプログラムできちゃうし、
いくらUMLの情報がクラスより少ないとはいえ、UMLからコードできちゃうよね。
ま、フローチャートやUMLは概念勉強用で、実務で使うと無駄ということだが。
OOP言語でドキュメントクラスしちゃうと、開発も性能も速いよ。
だから、ボッタくられてるだけだよ。

39 : :02/03/16 21:55
>ま、フローチャートやUMLは概念勉強用で、実務で使うと無駄ということだが。

どのレベルの「実務」?
それに業務を向上させようと思わない?

40 :非決定性名無しさん:02/03/17 00:09
>>34
ソフトウェア開発海外発注時代の共通言語

同意。
これが、アメリカを中心とした流れでしょう。


41 :非決定性名無しさん:02/03/17 03:14
某スレより>
>やっぱ、夢で彼女がUMLの形で出てきてそれ課長とレビューして、
>そのあとの試験工程で、使ってたStarfire下宿にもって帰って
>ガワはずしてヤっちまうような夢みて夢精してたらいけないなと思った。

やっぱこのくらいまで腕が上達すると、
いい設計ができるようになるんでしょうか?

42 :非決定性名無しさん:02/03/18 09:42
>39
実務にも業務向上にもフローチャートを使う人は居ません。

>40
幻想の中のアメリカですか?

43 :非決定性名無しさん:02/03/26 16:28
いまのプロジェクトは、ユーザーさんがUML研修まで行ってくれてるぞ。
おかげで、ちゃんとUMLで用件定義から設計から全てまかなえている。

シナリオからユースケースチャート、ステートチャートを起こして、クラス図とシーケンス図を書いて。
コンピュータっぽい専門用語を使わずともシステムの道理に基づいて用件定義や設計を行えるっつーのはありがたいよ。

シーケンス図で流れを追ってるうちに、
「このオブジェクトはこの時点で作られてないから、このデータはまだ扱えませんよ。
 シナリオに矛盾がありますね」
なんてユーザーに平気で言えるのは、手戻りも無くなるし嬉しいことばかりだよ。

プログラマがUMLを読めないのはもはや論外。


44 :非決定性名無しさん:02/03/26 17:19
>43
その人達も、システム開発があるからUMLしてるだけで、
業務改善にUMLが有効なわけじゃないでしょ?

45 :非決定性名無しさん:02/03/26 19:46
業務の流れを図にして見なおす事は、いい契機になると思うぞ。

今までの流れが社内の一部の者しか見えていなかったって事は
良く在りそうだ。

システムって、コンピュータ化の部分だけじゃ無いよな?

46 :43:02/03/26 22:39
>>44
シナリオを書いているうちにユーザー自身が矛盾に気付くこともある。
シーケンスチャートやクラスチャートで業務の流れや起票される書類を洗ううちに、
情報の重複や無駄な事務を発見できることもある。

「こともある」って書いたけど、矛盾や無駄はほぼ必ずある。
これらを認識するためのツールとしてUMLは能力十分だと思う。

ユーザーがシステム開発のためにUML研修に行ったのは確かだけど、
その適用範囲が広いことも分かってきてる。

俺は業務改善にUMLがとても有用だと考えてるし、このユーザーを見ててもそう思える。



47 :非決定性名無しさん:02/03/27 13:18
>46
「○○チャート」や「UML」をダサダサな「JCLフロー」と書き換えても、その文は成立しちゃうね。

実際に役にたった、チャートを見ないと納得出来ないな。

48 :非決定性名無しさん:02/03/27 15:36
普及しなきゃ意味無し。

49 :非決定性名無しさん:02/03/27 15:47
>>48
あと5年もすればかなり広がると思われ。

50 :出張32:02/03/27 16:39
別にUMLが優れてるとは思わないし、使いたい人は使えば良いんじゃないの?
ってところですな。

# あんま、流行にばかり目線を合わせてると振り回されるだけですよ。
# 所詮は「素人の為の...」グッズですからね。

51 :非決定性名無しさん:02/03/27 19:07
>>47
当然成立するでしょう。UMLが何か分かってるの言ってる?
UMLじゃないと出来ない事なんて無いでしょうに。

>>50
その為のUMLなんだから。
それを所詮と呼ぶか…

52 :非決定性名無しさん:02/03/27 19:08
>>45
>システムって、コンピュータ化の部分だけじゃ無いよな?

45がイイコト言った。これものすごく重要。
あたりまえ過ぎることだが、これができるのとできないのでは
全然違う。よくいわれるところのSヨか優秀なSEかの分かれ目の
一つかとオモワレ

53 :非決定性名無しさん:02/03/27 19:31
いま漏れがSヨとして関わってるプロジェクトでは、コーディングの
発注先がインドの会社で、仕様書はUMLで書くことを義務づけられ
ている。
それが本当に有用であるかどうかは別にして、権威ある機関が定めた
共通の土台に沿ったコミュニケーションをするためにUMLは有効な
手段だと思う。


54 :出張32:02/03/27 19:53
>>53
だからさぁ、「権威ある機関が定めた共通の土台」なんて修飾は不要なんだって!(汗
単に、「プログラムする側がUMLを要求した」ってことで十分なんだわさ。
その要求に見合っただけの低コスト高品質が実現されるか否かが重要であって
UMLが云々じゃないんだってばさ。

55 :非決定性名無しさん:02/03/27 20:22
>>54
最近は、データベース屋さんが一所懸命勉強しているよ。
ER図もUMLで書く日も近い。
遅れていない?

56 :出張32:02/03/27 20:38
>>55
一生懸命勉強しなけりゃならない程の深みはないよ。
精々5日だな。(覚えるならね)

57 :非決定性名無しさん:02/03/27 20:54
大事なのは”統一された”コミュニケーションの言語って事だな。
なかばエスペランド化されつつある。

次のステップはそれを作成するツールやビュアーをフリーにする事かな。
(今のままじゃ高価すぎる。)

58 :非決定性名無しさん:02/03/27 21:05
>>57
イーオスだっけ?

59 :55:02/03/27 21:28
>>56
表記法としては1日で新人に教えている。
分析・設計としての手法としてはもっと奥が深い。
表記は、DFDとフローチャートとか言わないでね!

60 :出張32:02/03/27 22:17
> 分析・設計としての手法としてはもっと奥が深い。

そうか?
手法論になってる段階で既に底が見えてると思うのは私だけか?
そもそも情報伝達の整合性や合理性だけを捉えて「分析・設計」と称するのは
些か疑問に思っておりまする。

61 :43:02/03/27 22:27
せいぜい5日とか1日とか書かれてるけど、
そのくらい簡単だというのは大きなメリットだよ。


62 :出張32:02/03/27 22:40
>>61
確かにメリットはある。(そのことを否定はしない。
唯、使える場面が限られるのも事実なので結局状況次第であるんだわさ。


63 :55:02/03/27 22:56
>>60
RUPとかの方法論は表記と区別する必要がある。

開発現場はかなり混乱している。
OOで分析設計 => UML表記
でもER図も必要ね => DB屋登場 IDEF1X表記
OO屋のツッコミ 「テーブルもUMLで書けるよ」
DB屋 UML勉強「なんだDOAでもOKじゃん」

これが文化の違いを超えた情報伝達と思っている。

64 :非決定性名無しさん:02/03/27 22:59
>>63
方法論あっての表記法。

>>60,>>62
結局、何がたりないんでしょうか?

ビジネス・モデリング(経営戦略を具体化したモデル)?
顧客の要求をうまく引き出すノウハウとか、要求変更への対応ノウハウ?
あるいは、手戻りとかイテレーションと呼ばれる、
下流から上流へのフィードバックの効率化?

65 :非決定性名無しさん:02/03/27 23:27
どーだろーねー?

66 :出張32:02/03/27 23:28
>結局、何がたりないんでしょうか?

ずばり言うと、自由度が足りません。
設計というものは、顧客との共同制作物である訳ですから
お客様の要求に沿った資料にまとめ上げるのが重要です。
この場合、表現法も顧客により異なり記載事項も現場優先での表記を求められる
ケースも多くコンピュータのシステム開発に直接関係ない部分も表記する場合も
多いんですわ。
画面デザインやテーブルデザイン及び遷移なんてものは設計の一部でしかなく
画面デザイン等は、場合によってXP方式でのチューニングが必要だとも言えるわけです。
つまりは、テーブルデザインを項目名と属性のみで押さえて居ては有機的な設計は難しく
補足事項が最重要であることを失念する結果に繋がると危惧しております。

67 :55:02/03/27 23:52
>>64
 方法論と言った時点で、開発現場では受け入れられないのでは?
だから、表記で使えるとこだけ使えばということです。
 方法論は各社の内部ノウハウだから、そう簡単に変えられません。

>>66
 上流の要求分析に利用するユースケース図は、新もの好きの
お客さんなら使います。
 内部設計での設計者同士の情報伝達には、使用人口が増えれば
効果があると思います。
 普及がある臨界点を越えると現場にも根づくようになるでしょう。

68 :64:02/03/28 00:20
>>66 表記方法とか、視点が違うんでしょうか?
   例えばUMLを、お客様の会社で使われている表記方法に変換できれば、
   解決する問題もあるのでしょうか? (どこかのベンダーがやっていそう...)
   でも、お客様の表記に、きちんとした定義がないのかもしれませんね。

>>67 UMLを使い込むと、何らかの方法論が必要になってくるような気がします。
   UMLは、仕様定義〜実装まで広範囲をカバーしており、
   ある工程で厳密な記述をすると、上流や下流とのマッチングとか、
   上流へのフィードバックといった、記述ノウハウが必要になります。
   その記述ノウハウこそが、開発方法論に近いもの(というより一部か)
   ではないでしょうか?

   方法論を、現場で苦労して体系付け、組織全体で統一を図るよりも、
   専門化が綿密に考えた方法論(RUP,UP,DOA系等々)を軽く導入して、
   現場の実情に合わせたカスタマイズをした方が、効率的かと思います。

   従って、今後の現場では、品質管理担当や、EJBとかのアーキテクトと同様に、
   開発プロセス/開発方法論の専門家/担当者が必要になるのではないでしょうか?


69 :非決定性名無しさん:02/03/28 13:03
関連リンク:

「UMLとMDAでシステム構築を根本から変える 」
http://www.atmarkit.co.jp/news/200203/28/omgmda.html

「UML皆でお勉強しよ♪ 」
http://pc.2ch.net/test/read.cgi/tech/980236172/l50


70 :69:02/03/28 18:18
ここも追加しておく。

「国産UMLツールPatternWeaverを語ろう 」
http://pc.2ch.net/test/read.cgi/tech/1013134433/l50

71 :非決定性名無しさん:02/03/28 21:12
>>68 ってゆーか、
 無意識に「ウォーターフォール」と「構造化分析設計」の専門家ばかり育成してしまって、
 より新しい優れた方法論への移行努力が足りないよーな気がする

72 :非決定性名無しさん:02/03/28 23:23
オブジェクト指向に慣れた目で見ると、
構造化分析設計って違和感ありまくり(美味しい最適化を無視してる...)だなぁー。


73 :非決定性名無しさん:02/03/28 23:32
>>72
でも、オブジェクト指向の分析設計手法って、
結局、構造化分析設計やデータ中心アプローチの上に築かれてるんだろ。

分析設計手法の連続性を察知できない >>72 は勉強が足りない?

74 :55:02/03/28 23:43
>>72
 オブジェクト指向に慣れた目で見ると、
DOAの完成した方法論が美しく見える。

 100テーブルある規模のプロジェクトの分析・設計は、
現場経験豊富なDB屋には安心してまかせられるが、
OO屋がユースケース図を描き始めたら納期までに
終わりそうにない。

75 :出張32:02/03/28 23:49
>>74
確かに終わらんだろうね。
そうかと言って概略部分のみに留めるのなら、これまた信頼性に欠けるしね。
思考の正しさをお客にどうやって伝えるのかも疑問です。

76 :72:02/03/28 23:50
オブジェクト指向が染み込んだ体では、
構造化分析設計の本は痛すぎて読めないよー!

77 :出張32:02/03/29 00:01
>>76
そりゃ、君が単に「スマートで在りたい」って妄想を持ち続けたいだけだからろう?
まあ、場数を多く踏んで現実を知れば多少は改善されるさ。

78 :非決定性名無しさん:02/03/29 00:19
「スマートで在りたい」ではなく「合理的扱いができるものを不可知論で扱うことはできない」です。

一度知ってしまうと、知らなかった頃には戻れない...

79 :55:02/03/29 00:31
>>72
「オブジェクト指向」を否定している訳ではないよ。

 プロジェクトへの投入順は、DB屋、OO屋と思っている。
その時、DB屋とOO屋の意思疎通の共通記法としてUMLが役立つと思う。

 上流から下流まですべてOOでやろうとするところに無理がある。

80 :出張32:02/03/29 00:41
>>78
設計の初期において、一見して非合理なものや、合理的では在るが手法が多様に存在するものも多い
状況でどのようにオブジェクトを考えると言うのか聞かせて欲しい。
現状分析の過程では、未発見項目も多く最適なオブジェクトモデルを考えれる状況には当たらない。
現状をそのまま事実とした伝達モデルを考え、各項目に置いて真偽の確認及び情報経路の特性と合理性
・実運用の可能性を詰めている段階で既に概要設計は始まってるんですよ。



81 :非決定性名無しさん:02/03/29 01:31
>>79 DB屋の方が、OO屋よりも、経験と実績が長いから、
  信頼できるのはDB屋だ、とおっしゃっているようにも聞こえます。
  おそらくここでおっしゃっているDB屋とは、
  DB技術からボトムアップに業務分析を行える、
  DB技術者兼業務コンサルを指して居られるのではないでしょうか?

>>80 いくつかの方法があると思います。
  でも、国外はともかく、国内では経験者不足(ほとんど居ない?)と
  オブジェクト指向技術者(つうか新しい技術)を育てる土壌が少ないので、
  経験豊富な非オブジェクト指向技術者兼コンサルさんのように
  結果を読みきる事は難しい気がします。

 とりあえず、今すぐ御回答できる案はこれ。
   DOA手法と、アナリシス・パターンの対応関係を理解した上で、
   >>78さんが信頼を置いている DB屋さんが定義するテーブルを、
   OOのデータ・オブジェクトのクラスと読み替えて、設計を行う方法。




82 :78=81:02/03/29 01:57
>>82
 別案です。文面が稚拙で申し訳ない。行間を読み取っていただけると幸いです。

  オブジェクト指向の特徴である「現実世界のモデリング」能力を前提に、
  具体的なシステムを前提としない、汎用のオブジェクト・モデリングを
  行い、その上で現状のデータや処理の詳細を検討する。

  具体的なシステム化については、それまでの自分の経験や、
  あるいは信頼できるシステム構築事例への当てはめを試みて、
  できるだけ予測可能な範囲に収める。

  予測可能な範囲に収まらない部分は、できるだけ早い時期に、
  技術情報と事例情報の収集を図り、リスクの低減と、新技術導入をする。
  #含:パッケージ製品、ライブラリ製品、構築経験者の確保

  最終的に、リスクが高い部分は、オブジェクト指向以外の手法への置き換えるか、
  あるいは、よりリスクが低い実現方法を使えるように、要求内容の変更を依頼する。


83 :ふぅー、読み直したら読みにくい文だった...:02/03/29 03:05
×オブジェクト指向の特徴である「現実世界のモデリング」能力を前提に、
  具体的なシステムを前提としない、汎用のオブジェクトモデリングを行い、

○オブジェクト指向の特徴である「現実世界のモデリング」能力を使って、
 具体的なシステム化を前提とせずに、汎用のモデルを作り、


84 :出張32:02/03/29 03:50
うーん、どのように伝えたら判って頂けるのか...
えっとね、オブジェクト指向にする段階は概要設計の最終段階なんですわ。
それまでは出来るだけ機能特化を行わず柔軟に検討したいんですわ。
そうでないと、画一的な設計に陥り枝ぶりの特性を十分に吟味しないまま
物事を進めてしまう危険が伴うんだわ。
「白紙から物事を捉える」サイクルを重視するのは設計者として重要なのよ。

勿論、UMLを全否定している訳じゃないし資料を読む限り経験の浅い設計者に
取って良いツール(手法)だと思うけどね。

まあ、XPと同じで使える場面を考えてメリハリ宜しく使うのが効果的だと思うわ。

85 :55:02/03/29 20:57
>>81
 DOAでも概念モデル、論理モデル、物理モデルとトップダウンに
分析・設計を進めていけます。

 顧客要求と現実の予算や納期の制約があれば、現実解として
上流はDOAを選びます。
 DBの論理設計が終わった頃、OO設計が出来るプログラマを
投入しています。
 アナリシス・パターンは、MVCモデルとかJ2EEパターンの
ことを差しますか?

86 :非決定性名無しさん:02/03/31 01:03
Smalltalk-80のMVCモデルとMVCモデル2の違いの説明キボ〜。

87 :非決定性名無しさん:02/03/31 11:03
ということなので、新入社員はUMLを覚えるように。

88 :非決定性名無しさん:02/04/03 03:21
>>84
前半は特に言うことはないけど
>勿論、UMLを全否定している訳じゃないし資料を読む限り経験の浅い設計者に
>取って良いツール(手法)だと思うけどね。

経験は関係ないでしょ。コミュニケーションのためのツールなんだから。
それとも経験が深い設計者にとってよくない点があるとか?
もしあるなら説明キボー。

89 :出張32:02/04/03 03:27
>>88
何度も言うけど、自由度が足りない。
必要に応じ多様な手法で表現するほうが効率がよいし、相手(ユーザー含む)にも伝え易い。


90 :非決定性名無しさん:02/04/03 03:54
>>89
自由度が足りないとは、どのような自由か述べよ。
馬鹿だから理解できないって言えよ。

91 :出張32:02/04/03 03:55
>>90
表現方法の自由を言ってる。
一つのツールに縛られる理由など何処にもない。

92 :非決定性名無しさん:02/04/03 04:03
>>91
まぁ無理だと思うけど、具体例で述べよ。

93 :出張32:02/04/03 04:08
>>92
はー、じゃまい奴だね。
コンピュータ関連の知識を持たない顧客へ概要設計書を見せて説明及び確認を取る場合等は
相手の理解力に応じた書式にまとめるのが宜しいと言っているんですわ♪

94 :非決定性名無しさん:02/04/03 04:11
>>93
UMLを理解できない顧客はある種の病院に行かれたほうが良いいです。
再度問う。
具体的に何を表現したい時にどのように記述力自由度が不足するか述べよ。

95 :出張32:02/04/03 04:24
>>94
> UMLを理解できない顧客はある種の病院に行かれたほうが良いいです。

私は君と違ってプロなので顧客様は大事なんですわ。
スマンね。


96 :非決定性名無しさん:02/04/03 04:31
>>95
そこじゃなくて、
>具体的に何を表現したい時にどのように記述力自由度が不足するか述べよ。
こっちに答えてください。

97 :非決定性名無しさん:02/04/03 04:46
ありゃ?
今日の当番さんは、持久力ないなぁ。
仮眠とります。おやすみー

98 :出張32:02/04/03 04:47
>>96
> こっちに答えてください。

>>93へ戻る。
(無限ループしてて下され)

99 :非決定性名無しさん:02/04/03 05:00
>>98
あきた。

100 :非決定性名無しさん:02/04/03 05:22
私はどうもimplementation diagramだけは顧客にわかりやすいと思えません。
ふつうの顧客は日経ほにゃららとかに載っているような概念図を
見慣れていますから、UML標準のアイコンを使ったネットワーク図は
いまいちだと思います。表現力の問題ではなく、とっつきにくいというだけですが。

しかし、自由度の高さは仕様を作成するときには
あまりいいことではない気がしますが?>出張32

101 :出張32:02/04/03 05:55
>>100
> しかし、自由度の高さは仕様を作成するときには
> あまりいいことではない気がしますが?>出張32

開発側だけを考えればその通りですわ。
だけども、我々は顧客相手の商売ですから手法を限定する訳にもいかない。


102 :非決定性名無しさん:02/04/04 03:42
32死ね。いらない。つまらない。あきた。

103 :出張32:02/04/04 06:06
>>102
ん?
どうした!
君の遊び場が狭くなってつまらなくなったのかい?

遊び方を変えると楽しめるんじゃないのかい?

104 :非決定性名無しさん:02/04/04 07:33
>>102 お砂場の取り合いとはメデタイですね。
   お砂場では、喧嘩せず、仲良く、犬猫には糞をさせないでね♥

105 :非決定性名無しさん:02/04/04 08:29
>>100
たしかにUMLの実装図は、判りやすい「概念図」というのとは違うね。
・コンポーネント図 ソフトウェアの構成要素(ソース、文書、プログラム、実行時結合ライブラリ等)
          間の依存関係や、クラス/オブジェクトの配置を表す図
 http://www.ogis-uml-university.com/tutorial/design/images/compo1new.gif

・配置図      実行時のシステム構成。
          ソフトウェア(コンポーネント, プロセス, オブジェクト)
          ハードウェア上(ノード、分散サーバ)への配置と、
          その間の通信の簡単な記述
 http://www.ogis-uml-university.com/tutorial/design/images/dep1.gif


ハードウェア構成図とか、ネットワーク構成図だとかは、
UMLの範囲外って感じで、PowerPointかVISIOでテキトーに書くよね。

もっと上流の、ビジネス寄りの図面
・ビジネス・フロー図
 http://www.cosmos.jp/product/xupper/images/doc05.gif
・ビジネス・プロセス図
・組織図
ってあたりには、判りやすい標準記法とか、便利なツールって
ないのでしょうか?

漏れの守備範囲でないので、よくわからないです...。

106 :a:02/04/04 21:29
a

107 :55:02/04/06 15:15
>>105
>ハードウェア構成図とか、ネットワーク構成図だとかは、
>UMLの範囲外って感じで、PowerPointかVISIOでテキトーに書くよね。
実践的でよろしいかと思います。

108 :55:02/04/06 15:21
>50 :出張32 :02/03/27 16:39
>別にUMLが優れてるとは思わないし、使いたい人は使えば良いんじゃないの?
>ってところですな。

>84 :出張32 :02/03/29 03:50
>勿論、UMLを全否定している訳じゃないし資料を読む限り経験の浅い設計者に
>取って良いツール(手法)だと思うけどね。

 せっかくここまで変えたのに、プログラム板に比べてこのスレの
レベル低すぎです。

109 :_:02/04/06 22:26
あるプロジェクトに先週から加入させられました。他社さんのお仕事に。
Javaなんですが、オブジェクト指向、UML、初めてなので戸惑ってます。
そこでUMLに詳しい皆様に聞いてみたく駄文書いてみました。
シーケンス図に、存在しないメソッド(それともメッセージというべきですか?)が
書いてあるのは、現場では普通なのでしょうか。
あと、UMLには関係ないと思うんですけど、DBのテーブル名が設計書によって
微妙に違うってのは、どうなんでしょうか。(誤字脱字なんか普通です。)

UMLにあんまり関係ないですね。書いといてなんですが、この書き込み
放置しといてください。酔ってるもんで。スマソ

110 :出張32:02/04/07 15:01
>>109
UMLは単なる表現ツールです。
UMLを使ったからと言って正しい設計が自動で出来訳じゃない。(勘違い君多いけどね)
オブジェクト指向のメリットを幾ら上げたところで機能特化に不備があれば絵に書いた餅
精々、見かけ上の整合性を確認するぐらいのもんですわ。

ふー、技量がなけりゃどんなツールの使い方や概念覚えたところで役に立たんってところです。

# 勘違い君が多く存在するのは「ツール理解=完璧!」って短絡思考のお人が多いからですわ。

111 :非決定性名無しさん:02/04/07 18:21
>>110
> # 勘違い君が多く存在するのは「ツール理解=完璧!」って短絡思考のお人が多いからですわ。

そのな人がどこにいる?
仮想敵を作って自分を比較優位に見せようとするんじゃなくて、具体的に挙げよ。

112 :出張32:02/04/07 18:32
>>111
> そのな人がどこにいる?

2chの情報システム板に沢山居ると思われます。
まあ、私の感想なので宜しく♪


113 :55:02/04/07 19:16
プログラム板の方がまともです。
http://pc.2ch.net/test/read.cgi/tech/980236172/l50


114 :出張32:02/04/07 19:27
>>113
概設レベルのお話が殆ど無いのが寂しいなぁ。
それと、開発者視点と効率視点に特化し過ぎる嫌いがあって
実務レベルでの戦略が少ないように感じたね。

まあ、見た目にはまともっぽいけど

115 :非決定性名無しさん:02/04/07 20:22
しかし出張32氏のレスはそういう視点を批判するだけで、
代案として実際にどうすればよいのかの《具体的な》示唆がないから、
ぜんぜん役に立たない議論しか生んでないんだと思うが?
ex. >>84, >>93, >>101, >>110

116 :非決定性名無しさん:02/04/07 21:25
>>115
だって出張32は
オブジェクト指向はおろか
構造的アプローチ、DOAもできないDQNだから(藁
そういうやつに限って「俺は上流しかやらないから」とほざく

117 :55:02/04/07 21:35
>>114
 うちのOO屋さんはあんな感じかな。

>概設レベルのお話が殆ど無いのが寂しいなぁ。
 それは、OO屋さんに期待しちゃだめ!



118 :55:02/04/07 21:42
>>116
105さんが示した「ビジネス・フロー図」
http://www.cosmos.jp/product/xupper/images/doc05.gif
これの「ユースケース図」と「シナリオ」書いてみて。


119 :出張32:02/04/07 21:48
>>117
> うちのOO屋さんはあんな感じかな。

そうなの?

> それは、OO屋さんに期待しちゃだめ!

ふーん、だとしたら概設はどなたがするのですか?

# 概設されない方が機能特化するのは危険な感じだけど...
# まあ、動けばいいってことなのかもね。

120 :55:02/04/07 22:02
>>119
74で書きました。
結局、専門特化したチームを牽引するとき共通語がほしくなる。


121 :109:02/04/07 22:05
>>UMLを使ったからと言って正しい設計が自動で出来訳じゃない
そんなこと思ってません。あまりにもひどすぎない?と言いたかっただけ。
完全にスレ違いでした。というか板違いかも。タダ愚痴書いただけですし。
すいません。2度と来ません。
それにしても、私に対して言っているのではないかもしれませんが、書き方が不快ですね。
どの板にもいるものだな、こういう輩。

122 :非決定性名無しさん:02/04/07 22:19
>>118
いいですよ。
ビジネスユースケースがいい?
それともシステムユースケースがいい?

123 :出張32:02/04/07 22:20
>>120
> 74で書きました。
サラット流してました。(すまんです

> 結局、専門特化したチームを牽引するとき共通語がほしくなる。

確かに...
まあ、意思統一しか手がないと考える今日この頃です。

>>121
> それにしても、私に対して言っているのではないかもしれませんが、書き方が不快ですね。

不快にして申し訳ない。 m(_ _)m

君に対して言ってるつもりは全くない。
この板の特徴として、XX知らない奴はOOって投稿が多いんでね。
ともすると手法先にありきなる展開になるので釘を差したつもりだったんですわ。


124 :非決定性名無しさん:02/04/07 22:38
>>123
>この板の特徴として、XX知らない奴はOOって投稿が多いんでね。
>ともすると手法先にありきなる展開になるので釘を差したつもりだったんですわ。
おっしゃるとおり、OOだろうとDOAだろうと使いこなしてナンボ。
手法レスでも、十分に仕事をこなしている人もいっぱいますよね。
でも、一番望ましいのは、手法を使いこなして、きちんと業務分析、設計、実装で
きることではないでしょうか。

ちなみに、出張さんはどんな手法が得意なのでしょうか

125 :出張32:02/04/07 22:47
>>124
手法は相手や環境によって変わるね。(資料毎に変わってたりするよ)
それと、私独自の記述方もあったりします(コード設計書等は関連記述を用いて判り易く)ので
一般には邪道って処でしょうね。

結局、情報関連と扱う情報群の特徴を明確にして連携した説明に力を注いでいます。

126 :55:02/04/07 23:00
>>122
 書けた?
 それをUML知らない客先に持っていって、
どのぐらい時間をかけて説明する自信がありますか?



127 :非決定性名無しさん:02/04/07 23:17
>>126
>書けた?
ひととおり生産、販売、仕入、在庫に関しては
ビジネスユースケースとビジネスオブジェクトは一般的なモデルを
用意しています。
もっともユースケースのワークフローは作ってあるけど、シナリオ
はさすがに作っていないです。
シナリオも欲しい?

>それをUML知らない客先に持っていって、
>どのぐらい時間をかけて説明する自信がありますか?
組織ユニット+ビジネスオブジェクト図はとてもわかりやすいと
この前、客先に言われました。
確かに、システムユースケースやBCEモデルをお客さんに
いきなり見せるとつらいものはありますよね。

128 :横スレスマソ。:02/04/07 23:30
>>123
>君に対して言ってるつもりは全くない。
>この板の特徴として、XX知らない奴はOOって投稿が多いんでね。
>ともすると手法先にありきなる展開になるので釘を差したつもりだったんですわ。

あんたが、やっている行為はXX知ってる奴はOOって投稿ですよ。

確かに煽りも有りますが、XXについて語らないと、手法ありき以上の議論は出来ないよね。

なぜか、ここにもし、まだ、本当のプロの情報システム屋が残っているとしても、
XXについて語ることを通してでしか、自分の導入事例、苦心した点、壁にぶつかった点、
そういった議論は出来ないからね。

議論が進む前に、あんたが一々、XX知ってる奴はOOって投稿でレスを潰している事に
気がついてい下さい。

もっとも意図的議論潰しをやっている気もしますね、自作自演、七氏になったり、
何でそこまで頑張れるのか不思議です。

129 :出張32:02/04/07 23:49
>>128
そりゃ君の思い込みだわ。

私はUMLを否定などしていない。
唯、表記手法であるから必然的に制約も多いのでそのことを踏まえた論議を
して欲しいだけですわ。

XPに付いても、「工程の全てが設計だ!」とか騒ぎ出されると
本来の良さなど何一つ見えて来なくなる。

OOの良さは機能特化別に階層化を行い各機能の関連を定義することにより
下流での制御構造を規定しているとこです。
これを言葉を変えていれば、「制御構造は上流でやるから従え」ってことです。
それ以上でもそれ以下でもない。

130 :横スレスマソ。:02/04/08 00:03
>>129
だから、間違っているって。
説明したくなくなるほど

131 :55:02/04/08 00:10
>>127
 UMLに理解のあるお客さんには、私もやっています。

 もし出張32さんが客先のコンサルに入っていたら、
初回の打合せは、用語と表記方法のすり合わせです。


132 :55:02/04/08 00:48
>>129
>OOの良さは機能特化別に階層化を行い各機能の関連を定義することにより
>下流での制御構造を規定しているとこです。

「機能特化別に階層化を行い」は、何を意味していますか?
「下流での制御構造を規定」するのは、アーキテクチャー
パターンとの理解でよろしいですか?
(用語すり合わせ中)


133 :非決定性名無しさん:02/04/08 06:25
>>129
えっとー、UMLを実際に使ったことありますか?
#使いたいやつは使えばいい。俺は使いたくないから使わない、とか?
#具体的な話がぜんぜん出てこないのはそのせい?

なんか表面的な部分だけ見て「ああ、こういうもんか」って自分勝手に判断してる気が。

もっと本質的なところまで突っ込んで見ていったほうが面白いですよ。


134 :非決定性名無しさん:02/04/08 08:31
>>133
漏れも実を言えばUMLには当初(というか最近まで)
懐疑的だった。またあやしげな頭でっかちな理論優先のが
でてきたなぁって。でも、最近ではすごく興味がでてきたよ。

考えてみれば、他の工業では設計書に使用する書式や
設計図の記法なんかが標準化されてるのにこの業界は星の数ほど
表記法はあれど、何一つ万人共通ってのがないもんね。そろそろ
みんな(設計者、管理者、ユーザー)がある程度共通で把握できる
統合的な表記法がでてきてもいいんじゃない?って思ってた。

まあ、UMLがその役目を果たせるかどうかはまだ定かではないけど
期待を込めて今ちょっと本なんかを読んでみてる。それにOO設計では
少なくとも従来のフローチャートやDFDでは限界があるし。

話をちょいずれるがやっぱりXP開発だけはどうしても現実的な手法
とは思えない。どうやって大規模な開発にそれを適用するのか未だに
想像がつかないよ。ホントにまともな適用事例ってあるのかな?
だれか知ってたら具体的に教えて

135 :非決定性名無しさん:02/04/08 09:56
>>134
そうそう。"U"に意味があるんだよね。


136 :非決定性名無しさん:02/04/08 15:22
出張32ピィ〜ンチ!!

137 :非決定性名無しさん:02/04/08 23:29
いや、だから出張32は何かを主張しているようで実は何も主張してないから、
ぜんぜんピンチにならないぞ。

「UMLを否定などしていない」の一言がすべての免罪符になると
信じていると思われ。

138 :非決定性名無しさん:02/04/08 23:45
老兵は死なず。ただ消え去るのみ。

139 :55:02/04/09 01:28
>>125
>それと、私独自の記述方もあったりします(コード設計書等は関連記述を用いて判り易く)ので
>一般には邪道って処でしょうね。

これがいけません。いったい誰が改造、保守をやるのですか?
他のベンダへの参入障壁ですか?

140 :55:02/04/09 01:50
>>131
 コンサルタントを含めた客先打合せの終了後。
客先担当者との会話
他社技術者 
「コンサルタントさん、現場での場数を踏んでいるし、
 業務知識も豊富ですが、最新の技術動向に疎いのではないでしょうか?」
客先担当 「私もそう思っているのですが」
他社技術者「あの人が現役でやっている内は良いですが、
      その後、いったい誰が保守すると思っているのでしょうか?」
客先担当 「私も上司に進言しているのですが、社長の古くからの友人で
      このシステムの立ち上げから関与しているので、コンサルタントの言いなりなんですよ」
他社技術社「結局、ああいう人が現役を引退したころにはUMLが普及していますよ」
客先担当 「根は真面目な技術屋さんなんで、うまく御指導をお願いします」

141 :非決定性名無しさん:02/04/09 17:57
そーだ。これに答えてよ>32

142 :非決定性名無しさん:02/04/09 18:58
>>139
うんうん、でもホントのトコ、今の現場では、
ドキュメントの書き方は顧客や担当によって
マチマチだって聞いたよ。

要は「伝えたい内容を図面に表現するセンス」の問題だと。

143 :非決定性名無しさん:02/04/09 19:38
出張32沈没??

144 :142:02/04/09 20:24
>>143 洩れは出張ではないが?
   何がチン没したんだよ、失敬な奴だなー


145 :142:02/04/09 21:00
>>132
多分、「構造化分析設計」系の用語だと思う。

>「機能特化別に階層化を行い」は、何を意味していますか?
divide and conquer; 実装内容が明確になるまで、機能を分割細分化するて事でしょ

>「下流での制御構造を規定」するのは、アーキテクチャー
対話型プログラムなら、階層メニュー
一括処理プログラムなら、プロセス・フローってあたりを意識しているのでわ?

146 :55:02/04/09 22:34
>>145
解説ありがとうございます。これなら分かります。

>実装内容が明確になるまで、機能を分割細分化するて事でしょ
 構造化分析設計では「機能階層図」というのを書きます。
water fall開発で上流から分割するフェーズと、コーディングを
折り返しにして統合するフェーズになると思います。

>対話型プログラムなら、階層メニュー
ツリー構造の「メニュー一覧図」(呼び方は色々あると思いますが)

>一括処理プログラムなら、プロセス・フロー
バッチ処理ならDFD表記でしょうか?

 ここまでは良く分かるのですが、
何ゆえ「OO」の良さに成るのでしょうか??

147 :非決定性名無しさん:02/04/10 00:01
なんか眩暈がしてきました。
いつの間にか新旧用語解説スレになったのですね(藁

148 :55:02/04/10 23:23
フローチャート
データフローダイアグラム
ER図(IDEF1X)
UML
結局、全部新人に教えることにします。

149 :非決定性名無しさん:02/04/11 00:05
>>148
これ全部使いこなせるくらいの才能がなければSEというなかれ。
って思わない?
#ついでにIDEF0もヨロシク

150 :非決定性名無しさん:02/04/11 00:09
>>148 なんか、情報処理の試験みたいに幅広いですね。
 現状で、構造化〜DOA〜OOまで、
 各種方法論が適材適所?で使われている以上、
 UMLだけ教えるのは、コミュニケーション上必要ですよね。

 ・ところで、単に図面の内容だけ考えると、
  DFD,ERD はの範囲はUMLでカバーしているかと思うのですが...

 ・構造化、データ中心設計、オブジェクト指向間のマッピングとか考える新人さんが居たら、
  はまっちゃいそうでかわいそうですね。

151 :非決定性名無しさん:02/04/11 00:20
なんか文意が通ってない...
○ UMLだけ教えても、実務に役立たないかもしれませんね。
× UMLだけ教えるのは、コミュニケーション上必要ですよね。


152 :非決定性名無しさん:02/04/11 00:58
客がUML読めないから、UMLは使いづらい。

客から「UMLを使え」って言われる世の中になる事を望む。

UMLが「無駄なドキュメントを生成する」って論調もあるが、
それは「MouseOnClick」の説明に「マウスのクリック」って書いて
「設計書を記述しました」というSEがいるから悪い。
UMLのせいとは違う。

客、SE、PG、みんながUMLを使う世の中になることを強く希望

153 :非決定性名無しさん:02/04/11 01:15
EVSは使いづらい

154 :非決定性名無しさん:02/04/11 01:16
>客から「UMLを使え」って言われる世の中になる事を望む。
それはあなたの顧客教育もとい顧客誘導次第...

155 :非決定性名無しさん:02/04/11 01:31
>>153 アンチEVSのヲタは、例の隔離スレで遊んでて下さい。

156 :非決定性名無しさん:02/04/11 01:33
>>155
UMLヲタはEVS。
Ota objOta = new EvsOta;

157 :非決定性名無しさん:02/04/11 01:37
低レベルな厨房は、大人の話に首を突っ込まないでね。


158 :出張32:02/04/11 01:56
このツリーを見ていると構造化設計が叫ばれた時代の様々な手法論争を思い出してしまう。
いや〜、全く懐かしいよ。
しかしこれほど皆さんが使える表現手法を求めているとは思わなかったです。
結構皆さん苦労しているようですな。

コミュニケーションの確立が如何に大変なことかが良く判る事例ですね。
特に、設計をされてる人とされていない人との間でのコミュニケーションは
非常に難しい...
眺めてる視点が異なるとお互いが自分の得意な方向へ会話を進めようとする。
だけどそれでは意思疎通は難しい。



159 :非決定性名無しさん:02/04/11 02:33
>>158
信者絵

160 :55:02/04/11 07:09
>>158
>このツリーを見ていると構造化設計が叫ばれた時代の様々な手法論争を思い出してしまう。
>いや〜、全く懐かしいよ。
私が新人の時は、テンプレートが支給されて、手書きでフローチャート書いてました。
(先日やっていた「プロジェクトX」で思い出しました)

>コミュニケーションの確立が如何に大変なことかが良く判る事例ですね。
結局、最近はこれしかやっていない気がします。
万人に通用する言葉がほしい。



161 :出張32:02/04/11 11:48
>>160
> 私が新人の時は、テンプレートが支給されて、手書きでフローチャート書いてました。
> (先日やっていた「プロジェクトX」で思い出しました)

手書きって非常に便利なのよ。
私は今でも絵コンテ使ってます。(打ち合わせ時にその場で作成したりしてますわ)

> 結局、最近はこれしかやっていない気がします。
> 万人に通用する言葉がほしい。

言葉は通じても意味・意図・思考を伝えるのは難しいからね。
お互いに考え方も価値観も異なりますからね。
まあ、相手の視野を見付けることから始めるしかないでしょうね。




162 :55:02/04/11 23:29
>>161
>私は今でも絵コンテ使ってます。(打ち合わせ時にその場で作成したりしてますわ)
 討議しながらホワイトボードに、ラフスケッチを書くことが多くなりました。

 UMLの用語のアクター、シナリオなど映画製作を意識しているのに、
絵コンテというのはないな〜。

163 :じゃましてスマソ。:02/04/12 11:10
オレ厨房だけど、ひとつだけおしえて。
UML極めんのに(オブジェクト指向分析設計能力極めるのに)
実装経験(オブジェクト指向言語で)って何年くらい必要なんだ?あくまでも目安で。
スタートはJCPを取ったくらいで業務はじめたとするとってことで。
(すでにCやVBなど非オブジェクト指向言語はある程度かける(業務経験3年以上)
ものとして。)スマソ。

164 :出張32:02/04/12 15:35
>>163
お答えします。
UML=5日〜1ヶ月
オブジェクト指向=5日〜1ヶ月
設計=永久に極められません。

165 :じゃましてスマソ。:02/04/12 21:39
マジレス?

166 :出張32:02/04/12 22:00
>>165
はい、マジですよ。
設計は非常に奥が深いです。

167 :じゃましてスマソ。:02/04/13 01:12
>>166
そんなもんなんですか。OOの設計って。
よくわかんないけどそれだけ不確定要素が多いってことですかねぇ?
なんなんでしょう?

ちなみに設計する上で必要となる実装経験(JAVAとかの開発)って
どのくらい必要なんでしょう?
NEXT ENJINEERって雑誌で「OOの設計には
優れた実装能力が必須です」みたいなこと書いてあったからどういうレベルなのか
疑問に思ってました。
どうかご教授願います。

DQNでスマソ。。










168 :非決定性名無しさん:02/04/13 02:57
ENJINEERとか書くヒトには説明しても無駄です。

169 :出張32:02/04/13 03:42
>>167
> そんなもんなんですか。OOの設計って。
> よくわかんないけどそれだけ不確定要素が多いってことですかねぇ?
> なんなんでしょう?

オブジェクト指向は概念なんです。
設計とも異なりますし、実装技術とも異なります。

> ちなみに設計する上で必要となる実装経験(JAVAとかの開発)って
> どのくらい必要なんでしょう?

オブジェクト指向技術と実装技術は異なります。
オブジェクト指向言語とは言っても本来のオブジェクト指向そのものではありません。
所詮は制約だらけの品物ですから、実装技術は言語に精通する必要があります。

で、OOの設計と言った場合は、実装する言語に沿った範囲でのオブジェクト指向型の
設計を言います。
この場合、詳細設計やテーブル設計がオブジェクト指向型に沿った形で行われるだけのことです。



170 :非決定性名無しさん:02/04/13 08:49
>>169
おいおい出張!
あたかも自分がオブジェクト指向分析設計やっているような
知ったかぶりすんなよ
しかも間違いだらけだし(藁

171 :じゃましてスマソ。:02/04/13 13:43
>>169
こんな感じ?↓
<(要求分析)/設計> ← 設計=永久に極められません。
ユースケース
コラボレーション図  
クラス図       ←この辺がオブジェクト指向技術??
---------------------
<開発>
クラス図(実装レベル) ←OOの設計=詳細設計やテーブル設計
実装 
・・・

----より上と下が別物ということは、上(要求分析/設計)をやる人は
実装レベル(オブジェクト指向言語)の経験や知識は全く必要がないってこと?

てっきりOO言語をやっていけば設計(ここでいう"OOの設計"以外)の技術が見えて
くると思ってしまっていたけど、関係ないのですね。
じゃあ要求分析/設計をする(---より上)に必要なスキルってなんなんでしょうか?
”設計の奥深さ”っていうのをもう少しだけくだいて教えてもらえないですか?

>>170
意味わかりません


172 :非決定性名無しさん:02/04/13 15:55
>>171
170だけどさ、そもそも出張32がオブジェクト指向わかっていないって
このスレを読んでいればわかるじゃん。(藁
それはそうと、
OO分析とOO設計の差は、言語実装だけじゃないよ。
設計ではアーキテクチャ(ソフトウェアアーキテクチャ)が重要。
分析においては、問題領域の詳細がBCEモデルで抽象的に表現
される。
設計では、アーキテクチャ仕様すなわち、
2層なのか3層なのか、どのようなコンポーネントモデルなのか等
が重要になってくる。
そういったあたりの方針決定を行うのがソフトウェアアーキテクト。

173 :非決定性名無しさん:02/04/13 16:52
ヤコブソンのBCE(Boundary- Control- Entity )
 http://www.mamezou.com/tec/Tips/umlForumJp2001/umlArchi.html
って、3層アーキテクチャとか4層アーキテクチャってあたりでしょ。

出張32の得意とする所は、業務ドメインの分析って感じだから、
>>172 の話はポイントを外しているんじゃないかな?

業務ドメイン知識を縦糸に、アーキテクチャ知識を横糸にして、システムが織り上がるって感じ?


174 :173:02/04/13 17:40
>>172 でも、ソフトウェア・アーキテクチャって大切だよね。

 1つのアーキテクチャで、何10年も食ってる人が居るくらい、
 奥が深くて、しかも風通しが悪い...(笑


175 :非決定性名無しさん:02/04/13 19:03
>>173
まあ、いいんだけどね。
ちなみに引用した○本さんの解説だけど
BCEとソフトウエアアーキテクチャ(MVC、PAC..)
を同じレベルで語っているのはどうかと思うよ。

176 :非決定性名無しさん:02/04/13 19:19
まるで、みんな伏せ字で設計について語っているようで
素敵だ!
>OO分析、OO設計

177 :出張32:02/04/13 20:11
>>171
貴方はプログラムの実務経験を持ってる方なので判ると思うのだけど
言語を覚えるのとアーキティクチャを開発する技能は異なるよね。
プログラマならば、与えられた条件に沿ってプログラミングするのが
お仕事だけど、条件によっては非常に複雑になっていたり装置の性能や
扱う言語の範囲を逸脱しそうな場合もあり必ずしも今までの技量が極める
とは言い切れない場面に出くわすとおもうのよ。
勿論、上記の問題は新しい装置や新しいアーキティクトが表れて来て解決
されるものも多くあるのが現状でしょう?
つまりは進化し続けているわけで極めるに至らないってことなのね。
設計も同じで常に要求は高度化しており歩みを止めるとたちまち置いてきぼり
って訳です。

>>172
その会話は余りにも低レベルなのでご遠慮下され。(君は学生さん決定!)
知識習得時間=1時間程度のお話をされてもね。

178 :非決定性名無しさん:02/04/13 21:07
>>176
本当に(藁。
10年前に真顔で、そのOOって何が入るんですか?
と質問した思い出が…

信者絵>出張32

179 :非決定性名無しさん:02/04/13 21:13
>>177
まあ、出張32に低レベルと言われてもね(藁
>知識習得時間=1時間程度のお話をされてもね。
どこがそう思った?それともお得意の煽り?

180 :出張32:02/04/13 21:23
> OO分析とOO設計の差は、言語実装だけじゃないよ。
> 設計ではアーキテクチャ(ソフトウェアアーキテクチャ)が重要。
> 分析においては、問題領域の詳細がBCEモデルで抽象的に表現
> される。
> 設計では、アーキテクチャ仕様すなわち、
> 2層なのか3層なのか、どのようなコンポーネントモデルなのか等
> が重要になってくる。

この辺ですわ。
重要なのは判るけど発言するほどのものじゃない。

181 :非決定性名無しさん:02/04/13 22:41
>>180
アナタハナニサマデスカ?


182 :非決定性名無しさん:02/04/14 00:13
>>181
>重要なのは判るけど発言するほどのものじゃない。
どういう意味で言っている?

183 :非決定性名無しさん:02/04/14 00:17
あほばっか・・・

184 :非決定性名無しさん:02/04/14 00:19
(土曜日の深夜に2ちゃんの情死す板にとぐろ巻いてる奴に )
(ろくな奴がいるわきゃーない。             )
(さっさと寂しい人生終了してくだちい          )

185 :非決定性名無しさん:02/04/14 00:21
=====嵐警報発令中=====

186 :出張32:02/04/14 00:25
>>182
サルでも...(いや失礼)
基本中の基本を挙げられても意味が無いのでは?
ってお話をしてるのです。

187 :55:02/04/14 00:27
>158
>眺めてる視点が異なるとお互いが自分の得意な方向へ会話を進めようとする。
>だけどそれでは意思疎通は難しい。
またか!

188 :非決定性名無しさん:02/04/14 00:35
BCE(Boundary-Control-Entity)で思い出したんですけど
データベース・アーキテクチャにも
ANSI SPARC 三階層 {アプリ層,論理層,物理層} とかいうのがあったね。

BCEって、なんか似てない?
  

189 :出張32:02/04/14 00:37
話変わるけどDEV_KIT使ったことある人いますか?
使ったことあるなら感想を聞かせてほしい。

190 :非決定性名無しさん:02/04/14 00:50
DEV_KITって何?

漏れの記憶にある、OpenWindow純正のGUI構築ツール?の事じゃないよね?


191 :非決定性名無しさん:02/04/14 11:22
>>180
それは177の発言のこと?


192 :非決定性名無しさん:02/04/15 01:00
>>190
それDevGuideでないかい?
DEV_KIT知らないな。

193 :出張32:02/04/15 04:46
>>190,192
ありがとう。
DEV_KITは、DBのバーチャルエンティティやBO(ビジネスオブジェクト)を作成するツールなんだわ。
一応、オブジェクト指向って謳ってるんだけど...(笑
結局、小さなシステムなら使えるけど複雑で大きなシステムだとかえって非効率だったりするのよ。(笑

194 :じゃましてスマソ。:02/04/15 19:15
>>177
>つまりは進化し続けているわけで極めるに至らないってことなのね。
>設計も同じで常に要求は高度化しており歩みを止めるとたちまち置いてきぼり
>って訳です。
なるほど、そういうことならわかります。
ご返答ありがとうございます。

>>172,173,174
おかげ様でリンクとソフトウェアアーキテクチャ(本・・・まだ半分くらい)
よんで知識だけつけてます。
でもよく読むと無意識に似たようなことをやっていたのもある気がする。。
(自分は組み込みの設計だったけど)

>でも、ソフトウェア・アーキテクチャって大切だよね。
>1つのアーキテクチャで、何10年も食ってる人が居るくらい、
>奥が深くて、しかも風通しが悪い...(笑
マジですかぁ?かなり驚き。

自分はPG色が強いせいでソフトウェアアーキテクト的SEってあんまり知らないん
だけどSIファームの上級SE=ソフトウェアアーキテクトでいい?
できるアーキテクトは10人〜20人に1人って聞いたことあるけど。。
(自分はソフトウェアアーキテクトをめざしたいけどソフトウェアアーキテクト
として”磨かれる道”があんまり見えない(知らないだけかも)んで知ってたら
教えてください。。いやいやこれで最後の質問にしますんでどうか。)

195 :55:02/04/18 21:33
>>189
「DEV_KIT」ヒョットして出張32さんのところで出している製品ですか?

196 : :02/04/18 22:19
>>194
SIファームってSIerの事かな。
だとしたら違うと思う。

SIerがある程度強い部分はハード系のあたりとかプロジェクトの仕切り、
いいとこビジネスロジックのあたりだろ。
ソフトウェアアーキテクトに関しては使う側だから、
ソフトウェアアーキテクトに強いのは
技術系の強い中規模ソフトハウスとかなんじゃないかな。


197 :出張32:02/04/18 23:17
>>195
違うよ。
某大手が躍起になって開発し、今は中堅大手への適用実績を作る為に無理やり開発に使ってる状態です。
で、その開発がトラブル続きで私に助っ人を依頼して来たって訳ですわ。

まあ、何とでもするけどね。

198 :じゃましてスマソ。:02/04/28 19:06
>>197
なるほど、「技術系の強い中規模ソフトハウス」あたりですね。
OOで一次受注ぐらいのあたりって感じすね。
どうもです。

199 :非決定性名無しさん:02/05/06 07:38
書いてませんage

200 :非決定性名無しさん:02/05/22 23:26
javaのみならず.NETでVBもOOになっちまったんだからそろそろ
設計書はUML使うっきゃないんじゃない?
まぁUMLじゃなきゃOOできないわけじゃないんで別にERとDFDでもいいけど。

201 :非決定性名無しさん:02/05/24 20:37
MSな人ってUML使うの?
VBの人、VC++の人、C#な人は、UML、OO世界の人と話が合わない気がする。
宗教が違うから?

202 :非決定性名無しさん:02/05/24 22:02
えっ?でも.NETになって、あのVBですらオブジェクト指向言語に
なっちゃったって聞いたもんだからこれからUML知らないと
VBヤーですらハジかくのかなぁなんて思っちゃった。

203 :非決定性名無しさん:02/05/24 22:20
統一設計表記法、UML。そもそもこれが?
統一形式化言語ってことであって、いわゆる設計図
ではないんです。単に対象を形式化して表現する
ための道具であって、形式化=設計ではないです。
いってみれば誰もが読める地図ですな。

204 :非決定性名無しさん:02/05/25 01:27
 図式や図法の取り決めがあって、現実世界を射影したのが地図。
 誰でもが地図が読めるとは限らないし、方向音痴もいて迷子が発生、
行くあてもなく彷徨うプロジェクト多々有り。

205 :非決定性名無しさん:02/05/25 16:20
UMLでダイアグラム書き始めるとモデリングに夢中になり
字を書かなくなっちゃう、あるいは軽視するプロジェクト多し。
一昔前で言えばモジュールツリー書いたけどそれぞれのモジュールの定義書
書かずって感じ。

206 :出張32:02/05/25 17:21
いや〜、UML自体に不満はちょっともありません!
不満なのは、UML表記する+αオブジェクト型エセ開発ツールの貧弱さですわ。(笑

まともなのは一つも無い!!
にも拘らず、「開発コストが1/2になるから使うべし!!!」って強要され
実際には2倍以上のコストが掛かってしまうのが現状なんだわ。
更に、強要した本人(SIらしい)自らがクローズした内容を好き勝手に訂正改竄する為
必要なリンク(連係情報)が失われ再度構築し直さねばならない羽目になる。

# アホとクソツールと無意味な捨て銭の三悪に泣かされるのが現実のようですわ。

207 :非決定性名無しさん:02/05/25 19:09
>>206
失敗をツールのせいにしてもしょうがない。
そもそも、アフォが使ってもプロジェクトが成功するようだったら
SEなんて商売にならんでしょうが。
素直に、「強要した本人」と出張師がアフォだから失敗したと
認めなさい。
>「開発コストが1/2になるから使うべし!!!」って強要され
だまされる出張師が悪い
>更に、強要した本人(SIらしい)自らがクローズした内容を好き勝手に訂正改竄する為
>必要なリンク(連係情報)が失われ再度構築し直さねばならない羽目になる。
構成管理・変更管理しなはれ

208 :出張32:02/05/25 21:03
>>207
私がタッチしてから、正常にプロジェクトは機能してますわ。(笑
因みに、ツールを使う人を全て新人にしロボット化しております。 >> 大正解!

で、本来の技術者は全てツールを使わずにこれまでの泥臭い方式にし完了したものを
新人が流れ作業で登録しておりまする。

勿論、ツールの壁は大きくコーディングの制約も多いので私が全ての基本モジュールを
作成し配布&講習してます。(これで安心 (^^)/v2


209 :非決定性名無しさん:02/05/25 21:49
UMLのモデリングツール?
自分のは構造化分析設計時代の本数出ていないCASEツールよりはマシだった。
っが、メジャーなIDEよりずっと本数出ていないので比較して質は悪いっす。
経験的にはツールメンター、モデリングガイドライン無しにプロジェクト
はじめちゃうのは危険と思ふ。
参考までにどこのツールか知りたいなぁ..


210 :非決定性名無しさん:02/05/25 22:25
>で、本来の技術者は全てツールを使わずにこれまでの泥臭い方式にし完了したものを
>新人が流れ作業で登録しておりまする。
すなわち、アフォがコーディングした結果をCASEでリバースして
UML化しているわけだ。

>(これで安心 (^^)/v2
本当にめでたいやつだな。

211 :非決定性名無しさん:02/05/25 23:01
ところで、ユーザインターフェースの設計と
その設計結果は、UMLでどうやるんじゃの?

212 :あぼーん:あぼーん
あぼーん

213 :出張32:02/05/25 23:24
>>209
残念だけど教えることは出来ません。(スマン

>>210
ちがうな!
もう少し無い知恵絞って考えてね♪

>>211
ユーザーインターフェイスなんてものは、とっくの昔に細部まで設計済みですよ。
(そんなとこで躓くわけないって...)




214 :非決定性名無しさん:02/05/25 23:32
ユーザビリティやアクセスビリティは、元も変わりやすい
というか、使ってみんとわからんところだで。
そこを、設計済みとかいってるんだからヤバイな。
UMLのモデリングが、ユーザビリティやアクセスビリティに
影響しないかい?ユースケース考えたら、画面に項目が
足りないとか、使い難いとかないんかのう。どうでもええが..

215 :非決定性名無しさん:02/05/25 23:33
ROSEでリバースしたのを適当にパワーポイントで適当に配置かな。

216 :非決定性名無しさん:02/05/26 00:09
どうも出張が乱入してくると、話題が本質から外れるな。
あやつは、自分がわかっていないことをさもわかっているフリして
適当に語り、弱いところをつかれると巧妙にかわすからね。
一番いいのは無視することさ。

217 :出張32:02/05/26 00:12
>>214
うん、無茶苦茶使い難いですよ♪
まあ後は適当に処置されるでしょう >> 元受のお人達! (笑

218 :非決定性名無しさん:02/05/26 00:22
結局、UMLでは「シアワセになれません」ってことですよね。

219 :非決定性名無しさん:02/05/26 00:31
>結局、UMLでは「シアワセになれません」ってことですよね。
表記法かえたところでシアワセになれるわけないでしょが

220 :非決定性名無しさん:02/05/26 00:39
図面の清書屋さんがいてもいいじゃない。
設計するわけではないので、単価安くていいんだから。
「清絵」って何て読むか知ってる人は、手をあげて!

221 :出張32:02/05/26 00:46
表記法に欠陥がある訳ではない。
下手なツールによって無謀とも思える作業工程の手順に問題があるんですわ。
結局、バラバラに切り刻み結合は各パーツが出揃うまで頭の中でのみ行うのが宜しい。



222 :非決定性名無しさん:02/05/26 03:09
出張はRUP理解してるの?

223 :非決定性名無しさん:02/05/26 10:02
>>222
 RUPを理解していても意味なし。
 RUPを適用してプロジェクトの納期、コスト、品質を
守って開発したことあるの?

224 : :02/05/26 10:42
モデリングツールを評価しようと思って
小プロジェクトでPatternWave(スペル違うかも)とROSE使ってみたが、
正直使いずらい。
たまに落ちたり固まったりするし。
Wordで原始的にゴリゴリUML書いてた時の方が楽だった。
その時より設計書作成の生産性が上がったとも思えない。

ちなみにリバースするつもりは無い。
コード生成も重要視していない。

お勧めってある?
あとVisioはどうなんだろ。
UML対応してから使ってないんだけど。

今んとこ、次からはまたWordに戻すか、
なんて思ってるんだけどさあ。


225 :非決定性名無しさん:02/05/26 11:40
>>223
>RUPを適用してプロジェクトの納期、コスト、品質を
>守って開発したことあるの?
ちゃんとやってますが、何か?

226 :非決定性名無しさん:02/05/26 12:17
>>225
あなたに聞いてない。

227 :非決定性名無しさん:02/05/26 12:34
>>221
> 下手なツールによって無謀とも思える作業工程の手順に問題があるんですわ。
> 結局、バラバラに切り刻み結合は各パーツが出揃うまで頭の中でのみ行うのが宜しい。
日本語がよくわからんのやけど、主語と述語を補って説明してもらえる?
だれが何をすることに問題があるのか、
誰が何のパーツの結合を頭の中で行うのがよろしいのか。

228 :非決定性名無しさん:02/05/26 12:40
>>226
少なくともちゃんとやっているプロジェクトいくつもある。
>RUPを理解していても意味なし。
と言い切れる根拠、小一時間ほど聞かせて欲しいもんだ。

229 :通りすがり:02/05/26 14:40
うちではUPやる一番の脅威は顧客の情報システム部門とそこに何十年も
寄生しているベンダー、他のサブシステムを請け負ったソフト屋。
ウォーターフォール感覚でビッグバンなマスタースケジュール引こうとするからね。
UPはデスマーチを早期に回避できるし、不景気な客にもってこいな開発プロセス
なことは実感しているものの、もうちょいメジャーにならないといちいち説明必要。
日経なんとかあたりで基幹系の成功事例をばんばんだせば、そんな人々も
あっという間に気が変わると思うけどね。

230 :出張32:02/06/11 00:39
>>228
> と言い切れる根拠、小一時間ほど聞かせて欲しいもんだ。

基本的に「RUPを理解している云々」を論議しようとする低レベルな貴方を評価するのなら
「まあ、君の実績を挙列してから会話をしましょう」って感じなんだよね♪
手法等は大きな障害にならないことを実力者は知っています。(そりゃ多少の効率は違うけどね)


231 :ユースケース図さん:02/06/22 14:16
あげ

232 :非決定性名無しさん:02/06/22 16:05
>>229 ウォーターフォール感覚でビッグバンなマスタースケジュール
言いえて妙。
#よく使われる言い回しなのかな?

ウォーターフォールって、最初に機能レベルでシステム分割しちゃって、
末端レベルで本来期待される分割位置の修正や、共通機能の括りだしや、
モジュール数の削減によるシンプル化ってあたりが全然期待できないから、
俺は係わり合いにならないように気をつけてる。

分割統治だけでなく、「モジュールの融合、シンプル化」ってあたりを優先しないと、
無意味な作業が爆発的に増えて、無意味な人生を送る事になるんじゃないかな

233 :出張32:02/06/22 20:45
>>232
それって手法論の問題ではなくて、単に技術レベルの高低差って所に落ち着く論議じゃ無いでしょうか?
有能な技術者が少ない為、高技術を必要とする「ウォーターフォール」だと結果的に
開発効率が低下するってことから様々な手法論が出て来ている事を失念しているように思います。

# どんな手法をもちいても未熟者の設計だと開発効率が低下するのは必定。
# 逆に言えば、高技術者がウォーターフォールで設計した開発効率は他の手法より高効率であると言えます。

234 :非決定性名無しさん:02/06/22 21:31
>>232
全体の見通しがあれば、流れる水の如し。
末端の方とは視点が違う。

235 :非決定性名無しさん:02/06/22 22:27
ってゆーか、確立され、誰もが飽き飽きした仕事なら、見通しも良い事だろうね。

ウォーターフォール嫌がってる奴の大部分は、
探索的プログラミングとか、確立されていない技術開発に燃えてるんだと思うよ

236 :235:02/06/22 22:29
ホントに有能な技術者なら、確立され、飽き飽きした仕事はさっさと引き継ぎやって、
別の未開拓分野探すと思う

237 :非決定性名無しさん:02/06/23 00:41
Java/J2EE関連だと変化が激しく全体の見通しも立つことが無いので
いっぺんにはウォーターフォールの水が流せません。
次の案件にゃ実行環境も開発環境もアーキテクチャも検証や学習が必要。
〜80年代のようにはいかないデス。
だからUPで早期にそれらを少しでもこなれたものにするのが安全。
イテレーションでミニウォーターフォールを何度も流してそれまでの仮説を検証ス。
某大きい会社はローテク・ロークオリティ・ハイコストでも仕事取れるんで
土石流のようなウォーターフォールしてます。

238 :出張32:02/06/23 01:03
>>236
それって有能って言うより趣味に走っているだけだと思うわ。
そりゃ、リスク無くて遊べるのなら誰でもやりたいとは思うけどね。

商売にはならんでしょうな。

239 :非決定性名無しさん:02/06/23 01:20
>>237
おっしゃる通り。
本当に、最近の大規模システム開発ではアーキテクチャが重視されるよね。
考えてみれば、かつてのメインフレーム開発よりも、今のJ2EE関連
のオープンシステム開発のほうがかなり性能要件・信頼性のハードルが高い。

最近、こういったシビアな開発に対応できる力がある企業って
大手SIでもかなり限られているよね。
>某大きい会社はローテク・ロークオリティ・ハイコストでも仕事取れるんで
>土石流のようなウォーターフォールしてます。
そういう会社向けのローテク案件が最近激減しているみたいだよ。

240 :出張32:02/06/23 03:25
>>239
そのSIって単なるコーディネータじゃんか!(笑
勿論、自社製品を中核に位置付けている会社も多いけどね。
でだ、実際の開発は要件定義も含めて全て外注へ投げてるケースが殆どだよね。
彼らのやることは、工程管理とツールの説明程度だしね。


241 :非決定性名無しさん:02/06/23 05:23
>>240
>>239のどの部分を指して
> そのSIって単なるコーディネータじゃんか!(笑
といっているのでしょうか?

242 :ユースケース図さん:02/06/23 10:57
繰り返しage

243 :ごめん、割り込む:02/06/23 11:21
>>237
Java/J2EEって、
さっさとオブジェクトの桃源郷に逝きたい急進派(OOベンダー)と、
Javaと同期して自社技術を構造転換しつつWebサービスも牽引してる某大企業と、
上記二つのバランスをとりつつ、限られたアーキテクトと開発者でのろのろ仕様決めてる某企業、

で成立している世界だから、変化は激しいけど、最適点に到達する速度は遅いという罠。
#自社技術なら、日進月歩で進歩すると思うけど、Javaの場合せいぜい半年〜1年スケールの変化じゃないかな。

同じ事は、Webサービスにも言えるよね。

それぞれの技術が目指している所を、
それらの技術を開発している人(JavaSoft,MS,IBM,...)の立場に立ってよく理解した上で、
・今すぐ利用できる技術はどれか、
・1年後に利用可能になる技術はどれか、
・標準技術が決まっていない領域で、とりあえず使える製品はどれで、相性や将来性はどうか、
・自プロジェクトで開発しなければならないのはどの範囲か
ってな事を実践するスキルは必要だろうね。いわゆるオープソ系ってのと一緒。

244 :ごめん、<textarea>狭すぎて間違えた</textarea>:02/06/23 11:24
○ ってな事を調査するスキル
× ってな事を実践するスキル

245 :非決定性名無しさん:02/06/23 12:20
>>237
見通し悪くて暗中模索というのは、技術の限界を露呈。
そんな方には、UPで匍匐全身をお勧めします。


246 :非決定性名無しさん:02/06/23 14:16
>>236
技術仕様策定に参画しない人は、単なる技術の追っかけ。
技術をコントロール出来なければ、見通しなどあるはずがない。
流行もの好きは、有能な技術者とは言い難い。


247 :非決定性名無しさん:02/06/23 16:08
賛否はともかく、
オープソ系やMS系の、ベンダー-デベロッパー間コミュニケーションは、
かくのごとく行われるのだよ。

通常、ベンダーからデベロッパー/ユーザへの情報流し込みは、
前倒しで行われる(前宣伝ともいう)ので、
現場で使い物になるかどうか判定できた頃には、
・アーキテクチャ設計上のトレードオフとか、
・今後どっちの方向に持っていきたいのか、
といった重要な判断材料が、入門者向けのつたない情報に埋もれてしまうから、
宣伝に付き合って状況判断しておく必要があるんだよ。


248 :非決定性名無しさん:02/06/23 16:12
>>246 さん自身は、技術仕様策定に参画しているようですが、
 そこでの判断が世の中に広まり役に立ったのか、小一時間程(略)

 オープン・ソース系に慣れ親しんでいる人であれば、
 そーゆー格式ばったヒエラルキーを一蹴するんだけどね(ワラ

249 :248:02/06/23 16:25
明確に書いときますと、
「最近の技術標準(IETF等)は、昔の標準化(ISO,IEEE)とは違い、
 基礎技術開発者と標準策定者と末端開発者/ユーザ間の緊密なコミュニケーションを前提として成立している」
「技術的理解をよりよく進めるには、一度、そのアーキテクチャの基礎技術を作った人の視点視点に立つと良い。
 それは決して特殊な事ではなく、基礎技術開発者も標準策定者も、その技術を普及させるために、
 末端開発者/ユーザの視点を重視している。
 互いの理解を進め、より良い技術発展を願うのであれば、互いに一歩歩み寄って互いの視点を想像してみる事が重要」
「オープンソースについては、例えばSourceForge.netには 数千件のプロジェクトが登録されており、
 その気になれば誰もが技術仕様策定の初期段階に参加できる。」
って感じかな

250 :非決定性名無しさん:02/06/23 16:32
でもね、どんな手法が発明されようとも、
結局は個人の技術力がプロジェクトの成否を決定するんだよなー。


251 :非決定性名無しさん:02/06/23 16:33
マネージャのマネージメント力も含めてね。

252 :非決定性名無しさん:02/06/23 16:35
>>224
Visioは単に絵を図を描きやすいツールとしてWordよりはずーっとまし。
(軽くないのでそれなりのスペックのマシンが必要ですが。)

それ以上踏み込んで使おうとは思わないけど。。。


253 :非決定性名無しさん:02/06/23 16:51
Togetherってどうよ?
俺的にはROSE XDEのほうがいいと思われ

254 :出張32:02/06/23 17:31
>>249
わたしゃ参加したくないね。
今まで通り、傍でジックリ観察しながら常に二番手を歩みたい。
で、まぁ二番手として一言言わせて貰えば「良い着目点なんだから出来るだけ簡素な機能に留めて欲しい」
ってところかな?(笑

いや、別に良いんだけどさぁ無駄無理に拡張されるとバランスの悪い非効率なツール(概念含む)になって
使い辛いですわ。


255 :非決定性名無しさん:02/06/23 19:21
>>254
「雪道は二番目を歩く」
斥候隊は「マドル スルー」に励め。

256 :非決定性名無しさん:02/06/23 20:52
>>254
技術を「観察」するなんて行為が可能なら、みんなそうするだろうね。 バカじゃないんだし。

257 :出張32:02/06/23 21:49
>>256
優秀な人は「観察」によりその殆どを習得してますわ。(笑
いちいち顔を突っ込んでたら切りが無いからね。



258 :非決定性名無しさん:02/06/23 21:59
Java/J2EE関係であまり後手な開発ってできませんよね。
Java自体全然成熟していないから例えばパッチ等でそれなりにこなれた1つ前の
アプリケーションサーバー選ぶとJDKや関連するAPIが古くて逆に
アーキテクチャが制限うけちゃいますよね。EJB、XMLパーサー、Strutsとか..
そんなわけでカレントのバージョンでUPで雪道に小さく歩いて
固めていくような開発しています。
1年前2年前のアーキテクチャがまんま使える時代になればいいんすけど。

259 :非決定性名無しさん:02/06/23 22:07
>>258
>Java自体全然成熟していないから例えばパッチ等でそれなりにこなれた1つ前の
>アプリケーションサーバー選ぶとJDKや関連するAPIが古くて逆に
>アーキテクチャが制限うけちゃいますよね。EJB、XMLパーサー、Strutsとか..
状況はかなり良くなってきたと思うよ。
以前はEJB1.1すらまともに動くAPPサーバーは少なかったもんねぇ。
それよりも、古いバージョンで構築するとサポートが短いのが痛くない?

260 :出張32:02/06/23 22:08
>>258
javaに限らずWeb系は発展途上ですわな。
後数年も経てば安定もして来るし真の実力もはっきりしてきますわ。

# まぁ、あんまし無茶な期待はせぬ事です。
# されど、そこそこ安定してプロードバンドの通信スピードも更に向上してくれば
# 期待が膨らむのも止むなしか?

261 :非決定性名無しさん:02/06/23 22:26
>ということなので、新入社員はUMLを覚えるように
大半の新入社員にとっては、うわーん、もうこねーよ、Language になる罠だな。

262 :非決定性名無しさん:02/06/23 22:35
>>260 おっしゃる通り、2005〜6年頃までは、現在と同じく技術変動の時代が続くと思う。
 ムーアの法則が半導体プロセスの制限を受けて成立しなくなる、2010年以降になると、
 現在のように「3年後のCPU性能を前提とした重い技術を開発する」ってストーリーは
 成り立たなくなるかもしれませんが。
 そーなったらようやく、出張さんのいうアプリ・エンジニア/業務エンジニアの時代かな?

263 :非決定性名無しさん:02/06/24 16:54
>>257
妄想極まってきたな。
というか、リアル厨っぽいな。

264 :非決定性名無しさん:02/06/24 22:03
それも1つの考え方だとは思うよ。俺は嫌だけど。
#つうか、>>263の方が業界の現状知らないっぽい。まぁ、一生学生しててください


265 :ユースケース図さん:02/06/24 23:28

 うえーん、もうこねーよ、Language になる罠
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
            ∧_∧
          ( ´Д⊂ヽ
          ⊂    ノ
           人  Y
          し (_)

266 :出張32:02/06/24 23:45
>>263
> 妄想極まってきたな。
> というか、リアル厨っぽいな。

うーん、お話が通じていないようですな。
じゃ少しだけ説明して置くわ。

何故に「観察でその殆どを習得出来るか?」ってことなんだけど、
一言で言えば「応用技術であって根本的に異なる事柄ではないから」なんですわ。
優秀な技術者ともなれば、「多かれ少なかれ自身で開発ツールを作成する技量」は持ち得ている筈です。
つまり「ツールを使う立場ではなく、作る立場の視点に立って眺める」能力を有しているってことですわ。
ですから、開発者の視野を探る技量に長けていますのでツールの長所と欠点を早期に見極めれる訳です。

勿論、細かな点に付いてまで洞察出来る訳じゃないけど着目点が判っておれば観察としては十分なんですわ。

267 :非決定性名無しさん:02/06/25 00:22
優秀な技術者ほど、自分の事を優秀とは言わないと思う。

268 :出張32:02/06/25 01:09
>>267
説明を簡素化する為に「優秀な技術者」って言葉を用いているのだけどコンプレックス感じますか?

# あんまし気にするのは良くないと思うよ。(自ら壁を作っちゃダメだわ)

269 :非決定性名無しさん:02/06/25 22:37
>>268
さすが出張、嫌味を言ったら天下一品だね。
イヤーナ性格だ。

270 :出張32:02/06/25 23:27
U・・・うんこ
M・・・モリモリ
L・・・Lサイズ!

271 :非決定性名無しさん:02/06/26 01:57
優秀な人材は、社内には非常に少ないか、全くいないのどちらかってのがほとんどだろう。


272 :出張32:02/06/26 03:00
>>271
まあ、大体そんなところですね。
一箇所に集まってることなど有り得ないからね。

基本的に0.5%と言われてるので非常に少ないですね。

273 : :02/06/26 07:20
今日も天下一品の餃子セットで腹いっぱい。

274 :やこぶ〜:02/06/26 12:38
(;´Д`)ハァハァ

275 :非決定性名無しさん:02/06/26 13:00
>>272 それって哀窮180以上?つう人の存在比率と同じだね。構成人員が同じだとは思わないけど。

276 :非決定性名無しさん:02/06/26 13:03
天一ネギだくギョクきぼん

277 :非決定性名無しさん:02/06/27 23:18
>>275
学力だけがものさしというわけではないが、
普通の学歴主義大企業なら、新卒採用者は皆、
日本の上位2%以内の学力だろう。
そんないわゆる頭のいい人たちで構成される企業のシステム部門の中でさえ、
できる人はほんの少しだ。
180以上っていうのも、嘘じゃないと思うぞ。

278 :非決定性名無しさん:02/07/06 02:26
あげ

279 :非決定性名無しさん:02/07/06 20:04
agileに手書きでダイアグラム書いて設計するのって本当に大丈夫?
UMLよりず〜っと昔々、ホワイトボードでシーケンス図とかワークショップで
書いてみんな納得したものの、冷静に清書しているとモレがままあった。
その点はRAD提唱者J.マーチンもRAD本で書いていてツール必須と
してるんだけど...

280 :非決定性名無しさん:02/07/06 22:45
頭の中で完璧に動いているから平気です。
ツールでお絵かきする人が翻訳するときモレが生じますが、
実装者の理解がどこまで私の頭の中に追いついているか
レビューすればOKです。

281 :非決定性名無しさん:02/07/09 23:40
こういうのって律儀に守ろうとしても中々うまく行かないでしょう。
プロジェクトに合せて、使えそうなとこだけ利用すればいいと思う。


282 :非決定性名無しさん:02/07/10 00:40
>>279

問題は漏れの存在ではなく、プロジェクトのライフサイクルを通してコードとUML
の整合性を保つことの困難さにある。
ツールを導入しようが手書きしようが2重管理であることには変わりない。
ドキュメント管理のコストを切り詰めてるようなプロジェクトにUMLを持ち込むの
は破綻への第一歩。

283 :非決定性名無しさん:02/07/10 08:34
http://www.ogis-uml-university.com/outline/outline.html

これってどうなの?

284 :非決定性名無しさん:02/09/05 01:18
まだ、ユースケース図もろくに書けません

285 :名無しさん@Emacs:02/09/08 21:02
UMLで設計なんてしてるの?
フロー図あれば十分

286 :非決定性名無しさん:02/10/02 01:48
おれなんかHIPOしかかけないもんね。

287 :非決定性名無しさん:02/10/02 02:39
>>286
オレなんか、ぺ鳥ネットしか掻けないモンネ。

288 :非決定性名無しさん:02/10/11 22:29
UMLで設計書を書かなくても仕事できるって幸せな職場だね。
社内システムか何か?

289 :非決定性名無しさん:02/10/11 22:32
ore nannka
feynman diagram kakenai monne

290 :出張32 ◆Rb.XJ8VXow :02/10/11 23:04
>>288
ってか、UMLで設計書作成しているところってWEB系の非常に単純なシステムで
過去の資産を守る必要も無い新興企業が殆どだと思うんですけど..(笑


# 私の認識間違ってますか?(笑

291 :非決定性名無しさん:02/10/11 23:13
まちがってるよ。あんたのとこが新しい案件をとる能力がなく、過去の
結び付きのみでしか仕事をとることができない会社なんだろ。
あんたが単純な古いシステムのみの仕事しかしてないってことだ。

292 :非決定性名無しさん:02/10/11 23:39
どこが間違ってるの?>291

293 :非決定性名無しさん:02/10/11 23:50
うーん、過去の資産はレガシーシステムに比べたらないのは当然だな。けど、Web 系の非常に単純なシステムでのみ使われてい
る分けじゃない。290の意図はWeb系のシステムは全て単純と言っているのか、Web 系のシステムのうちの単純なもののみUMLが使われて
いると認識しているのどっちだ?

294 :非決定性名無しさん:02/10/12 00:01
UMLが浸透していく過程として、Web系小規模システムがターゲットに選ばれることが
多いという、結果論ではないでしょうか。
確かに適用しやすいです。
メリットも画面などがある方がユーザにわかりやすいです。
それに、UMLだけを適用するシーンは希少で、RUPなどの手法とセットで適用すること
が多いでしょ??
大規模システムに適用した場合のRUPは熟練工でないとプロ管で手間取ることが多くて
効率的でないと聞くし・・・
それがUMLの現状の評価として流布しているのでは?

295 :非決定性名無しさん:02/10/12 00:02
書いてるよ。
システムが完成した後に。

296 :非決定性名無しさん:02/10/12 00:07
それはここでの議論に入る前の問題です。分かって言ってんでしょ。

297 :288:02/10/12 00:13
>>290
その認識は変えたほうが良いですよ。
自動車業界なんかUMLできなきゃ下請けメーカーは
搭載する機器作れないし、通信機器もそう。
ビジネス系でいえばいくつかの業界で基幹業務で数百〜数千人月の
プロジェクトもちらほらあるよ。
進行中なんでこれ以上言えないけどね。マジです。

298 :288:02/10/12 00:31
>>294
RUPは誤った知識のまま実践してしまっているケース実に多し。
現状は教える側も教え方に問題アリです。
ちなみに本なんか読んだぐらいじゃだめだよ。
PMは紙にして数千ページぐらいある製品版を読破したことない人だめ。

299 :出張32 ◆Rb.XJ8VXow :02/10/12 02:30
>>295,297
そうなん?
実は、某大手SIの要請で現在緊急にクローザーとしてWeb&バッチ型の基幹システムを手掛けています。
そりゃもうド素人ばかりでお話になりません(笑
口は立っても所詮経験も浅くて思考はもっと浅いという状況の中、「お前ら黙って言うとおりにせい!」とか言ってなんとか
やってますわ。(ほんと疲れるよ)

300 :>>296:02/10/13 12:47
誰に対して言ってるの?

301 :出張32 ◆Rb.XJ8VXow :02/10/13 15:26
>>300
横槍だけど、多分「システムが完成した後」ってことに対するものでしょうね。
唯、現実を知ってる人からすれば「システムが完成した後に作成」ってのは凄く理解出来る。
ここらへんが、理論と現実の相違点なんだよね。
幾ら立派な理論であってもそれが実践出来なければ絵に書いた餅。
で、現実の状況をつぶさに見ていくと「不完全な展開」になってる場合が多く、
結果的に事後作成に終始しているんだよね。

これって、経験が浅い論理優先主義の人達が辿る道なんだよね。

302 :非決定性名無しさん:02/10/13 20:25
UML程度で理論と現実のギャップで実践できない状況なの?
だとすればDFDだろうがERだろうが後書きなんだろうね。
そのチームにはソフトウェア工学自体不在っぽいから。

303 :出張32 ◆Rb.XJ8VXow :02/10/13 20:34
>>302
うん、はっきり言うと出来ないね。
だって邪魔臭いだけで意味が無いもの。
はっきし言って、まともな設計出来る能力者ならば設計書は出来るだけ簡素なほうが
扱い易いしやり易い。

曖昧な状況をわざと残し全体像を先に読むケース等はUML使えない手法とも言える。
結局、アホで未熟な技術者に少しでも働いて貰う為の手法でしかない。
で、現実にはそんなレベルの奴に何を与えてもダメであり、指示通りに動いて貰うしか
道が無いと私は考える。
UMLで書かれた設計書だからと言って説明不要で正確な成果物が出来上がる等の考えは
妄想でしかないよ。(笑

304 :非決定性名無しさん:02/10/14 00:12
まぁまぁ、なんでも結論づけないで。
それもありですよ。うん、確かに悲しいけどそうでもあります。
でもまだ定説すら(あっても)認められていないのだから、皆で意見を出して収斂して
いけばいいのではないの?

305 :302:02/10/14 16:54
>>303
>UML使えない手法とも言える
出張さんはUMLという「表記」と手法や方法論を混同していますよ。
UMLは表記だけの仕様でしょ。OMGのUML仕様書見てね。
>設計書は出来るだけ簡素なほうが扱い易いしやり易い。
UML使っても簡素な設計書はできますよ。
あなたがUMLを使って書いたときの手法なり方法論なりがそう思えないもの
だっただけです。
>UMLで書かれた設計書だからと言って説明不要で正確な成果物が出来上がる
UMLを正しく理解した人は誰も「UMLだけ」で書かれた設計書なんかで開発しないよ。
それはERだろうがDFDだろうがダイアグラムには得意不得意があるのは同じこと。
定義は文字で書くし、必要ならばデシジョンテーブル書くし...
「UMLだけ」のポテンシャルで否定する必要はありませんよ。

で、あなたが書いている簡素な設計書というのはどんなんですか?
ダイアグラムは面倒だから全く無しですか?
まじめに興味あります。ご教授ください。

306 :出張32 ◆Rb.XJ8VXow :02/10/14 17:24
>>305
状況により変化するね。
まぁ、私の場合はコード設計書に関連性を持たせ意図用途を明確に定義することに拘ります。
後は、暴言を言うとテーブルレイアウトと機能定義の概略で足りますね。

307 :非決定性名無しさん:02/10/14 18:07
コード設計書って? 
機能定義って基本機能設計のことですか?




308 :出張32 ◆Rb.XJ8VXow :02/10/14 19:34
>>307
うい。
コード設計書とテーブルレイアウトによって、具体的にどのような種類のデータを扱うのかを規定します。
ここらが明確に規定されていない設計が多かったり、別紙が多数存在してたりして開発時のケアレスミスを
誘発する原因になってるケースが多い。
目的と用途それに他コードとの関連を具体的に記述しておればトラブルが防止できます。

ただ、そのような設計をしようと思えば開発すべきシステムを読みきっている必要があり
何方でも出来るわけじゃありません。


309 :302:02/10/14 21:01
コード設計書というのは内容的にJDKとかのjavadocのような記載内容を
イメージしてしまうのですがそんな感じかな。なるほど。
他コードとの関連というのが出てきましたが、javaなどOO言語だと
関連に種類があるので継承せよとかimportせよとか表記するということですね。

310 :出張32 ◆Rb.XJ8VXow :02/10/14 21:08
>>309
そういうことです。
コード表というのはテーブルレイアウトとともに扱う情報の性質や制御を受け持つ要素です。
その為、出来るだけ簡潔で尚且つ判り易い説明、用法が必要個所に記述されている必要があります。
表記法を一元化しても書類が乱雑になったりあちこちに分散されておれば気をつけるか馴れるかしない限り
情報収集に手間取り結果的に非効率となります。

311 :非決定性名無しさん:02/10/14 21:14
だみだこりゃ。

312 :出張32 ◆Rb.XJ8VXow :02/10/14 21:35
>>311
すまんね。
設計の経験が豊富な方でないと判らんお話をしてしまいました。

313 :非決定性名無しさん:02/10/14 22:44
307でコード設計書とは何かと聞かれて308でまともな回答をしていないように思えるが?
310の文章も、エンジニアとは思えない抽象的な言葉の羅列で、ソフトウェア工学
の理論のテキストに載っているような話だし、そもそも309の汎化になっていないが?

314 :出張32 ◆Rb.XJ8VXow :02/10/14 23:53
>>313
だから言ってる。
「設計の経験が豊富な方でないと判らんお話をしてしまいました。」とね♪

経験無いと理解出来ない範疇なんよ。
細かく説明するのはジャマイし君には理解不能だと思う。(持っている知識が乏しすぎるからね

315 :非決定性名無しさん:02/10/15 01:25
>>312
コード設計は、半導体製造プロセスを設計/保守してたころに
タプーリ横で見てました。 便宜上設計って呼んでるだけで、実際
は各部門が文句言わないように調整に入るだけです。

だって、コードの存在理由は作業者のミスを減らすことで、
端末の操作画面の設計の一部というのが正しい認識でしょう。
ビジネスアプリじゃ、コードなんて使わないのが昨今の正しい
設計だとおもうのだけど、強調して”コード設計書”とまで
書かれていたのでソースコードのコードと混同してるのかと
聞いてみただけです。 失礼。

316 :非決定性名無しさん:02/10/15 01:29
だみだこりゃ、ってのは、
大切な部分は触らせて貰ってないのね、って話しです。
♪が痛々しい…

317 :非決定性名無しさん:02/10/15 01:40
でも、くじけるなよ!
生きていれば明日がある!

318 :出張32 ◆Rb.XJ8VXow :02/10/15 02:56
>>315
例えば、性別を男、女って入力するのは邪魔臭いだけだよね。
ユーザーフレンドリであることを何処まで必要とするのかは、効率面と安易さの抱き合わせで
決定されるんですよ。
ですから、目的に応じた体系で対処せんといかんし、その過程でコード化は必須技術となります。(現状だとね)
まぁ、上記で私が述べてることはまた別の意味なんだけどね。(笑




319 :出張32 ◆Rb.XJ8VXow :02/10/15 03:03
>>315
あーそうそう、言い忘れていたわ。

> ソースコードのコードと混同してるのかと聞いてみただけです。

えっとね、そのコードも同じ意味ですよ。(笑

# もっと勉強して基礎をしっかりとしてね。

320 :非決定性名無しさん:02/10/15 22:08
もうだめぽ

321 :非決定性名無しさん:02/10/26 17:16
某社の駄目駄目くん、
嬉々として某OO紺猿&某UML企業の鴨になって大金差し出す計画立ててるんですけど、
晒しあげてもいいですか?


322 :非決定性名無しさん:02/10/26 17:34
(・∀・)イイカモ!

323 :非決定性名無しさん:02/10/27 00:30
OO紺猿&某UML企業って???
オブジェクト指向だけのコンサルなんて本当にいるんですね。

324 :非決定性名無しさん:02/11/03 04:50
>>323
頭が悪そうなレスですね

325 :非決定性名無しさん:02/11/18 02:32
MSのvisioとか
Rationalのroseとか、、、

326 :非決定性名無しさん:02/11/18 10:49
>325
その2つは比較するに当たって
コードジェネレータとか大きく機能が違うと思うな。
もちろん価格も機能と同じくかけ離れてるよね。
純粋にUMLを書くだけなら機能的に変わらないかもしれないけど。
俺が使い方知らないだけかな?

327 :非決定性名無しさん:02/11/21 00:47
Together Softだろ。

roseなんかより数倍いいよ。


328 :非決定性名無しさん:02/12/06 00:25
RoseもTCCも高すぎるよ・・・。
100万はだせん。

329 :米IBMが米Rationalを買収:02/12/17 00:47
http://itpro.nikkeibp.co.jp/free/NSW/NEWS/20021209/1/

330 :山崎渉:03/01/11 11:58
(^^)

331 :非決定性名無しさん:03/02/04 23:41
保守age

332 :非決定性名無しさん:03/02/05 00:09
UMLってさ、ホワイトボード前にしてテキトーにどんどん描くのがいいんでさ、
最近の「言語の仕様を何でも図に記述できます」という方向の拡張は、
モデル言語本来の役割からずれてるように思える。

そのままビルドできるコード吐く機能なんてどうでもいい。

333 :非決定性名無しさん:03/02/05 01:01
>>332
>UMLってさ、ホワイトボード前にしてテキトーにどんどん描くのがいいんでさ、
私もそう思う。裏紙とかにテキトーに書いていくと、なんとなく、
概念レベルのものが出来上がり、整理できてしまっています。
とりあえず、多重度は、気にしています。継承もかな?。

ただ、コード(設計クラス?)に落とすところで、悩み中です。
この辺りのことが書かれている、なんかいい書籍ないですかね?。

入門レベルのものばかりしかないし。洋書でもOKです。

334 :非決定性名無しさん:03/02/05 01:06
>>332
アイデア段階ならそれでいいけど、
まとまってきたらそれなりにしっかりかかないと設計できないじゃん。
まあ、設計が固まったあとで、コードに合わせて
図を保守していくのはいやだが。

335 :非決定性名無しさん:03/02/05 01:16
>>333
概念モデル->設計モデルの落とし方っていう意味?
その2つは全く別の目的でつくるものだから、
あんまり無理に落とそうとしない方がいいと思うんだけどな。

336 :非決定性名無しさん:03/02/07 01:36
>>335
やっぱりそう思います。そんな感じがするようになってきました。
PMという立場で、要件定義から入っていくので、業務理解のため、
システム化の対象となりそうな範囲を理解するのに、概念モデルを
書くと、非常に理解しやすいなーと最近感じています。

337 :非決定性名無しさん:03/02/07 11:30
要件定義ではなく、要求管理ではないか?
といってみるテスト。

小手先の知識で模範回答書いても、実践していないのがバレバレな罠

338 :非決定性名無しさん:03/02/07 11:32
つーか、>>336 は、>>333,>>335 に繋がっていない頓珍漢

339 :非決定性名無しさん:03/02/07 21:01
336は、別に何も間違ったことを言っているようには
思えないのだが・・・
要件定義をする前に、対象の業務を概念モデル使って理解しようと
していて、それがうまくいきそうだっていうことでしょ。
まさに概念モデルの目的そのものじゃないの?
要件定義=システムが満たすべき機能や品質を決定すること
要求管理=システムが満たすべき機能や品質を漏らさないよう体系的に管理すること
分かっていないのは337だと思われ。

340 :出張32 ◆Rb.XJ8VXow :03/02/17 19:04
>>336
概念モデルはシステムの幹に焦点合わせたもの。
細か過ぎるとそれこそ意味がないっす。(判り易くが基本。
だけども、概念モデルを書くに当たって綿密な思考が必要なんだよね。
結局、詳細部分も含めて思考されていないと絵に描いた餅になってしまうんだよね。(全く同じものでもね

そこらが判っていない人多いよね。


341 :非決定性名無しさん:03/02/19 02:21
>>340
言っていることがよくわかんねえっす。
詳細部分を含めて思考するってことは、
結局詳細部分も(頭の中で)モデリングしているってことなの?
でも、細かすぎると意味がない??
矛盾していないですか。


342 :出張32 ◆Rb.XJ8VXow :03/02/24 19:04
>>341
全然矛盾していません。
結局のところ細部に渡って思考されてることが重要なんよ。(コストを低減する為に詳細に書き出さないだけっす。
大雑把ならばそれこそ誰にでも出来ちゃうよ。

見た目のモデリングなんてものは所詮パンフレットでしかない。
整理し易い!、覚え易い!ってのは入口が通り易い程度のこと(重要ではあるけどね。


343 :山崎渉:03/03/13 13:51
(^^)

344 :非決定性名無しさん:03/03/30 23:42
皆さんのお力でぜひぬるぽをageて下ちい。
  ∧_∧
 ( ´∀`)< ぬるぽ は伊達じゃないっぽ

ぬるぽ 投票ヨロシク
http://pumpkinnet.to/ranking/words/


345 :非決定性名無しさん:03/03/31 00:29
>344
氏ね

346 :非決定性名無しさん:03/03/31 01:10
UMLわからん。やばい

347 :山崎渉:03/04/17 09:28
(^^)

348 :山崎渉:03/04/20 04:24
   ∧_∧
  (  ^^ )< ぬるぽ(^^)

349 :非決定性名無しさん:03/05/06 19:22
ステイトチャート図→主に要件定義で使う
アクティビティ図→主に設計で使う

と説明する資料を見つけたんだけど、普通逆だよなぁ?どうなのよ。


350 :非決定性名無しさん:03/05/07 23:51
>>349
普通がなんだかわかんが
RUPでは逆だ


351 :非決定性名無しさん:03/05/14 01:11
私の経験から、顧客の主要な業務(例えば基幹系)などの開発にUMLを適応しようとすると、
まず営業活動をおこなっている時点でお客様にアレルギーを生じさせてします。

お客様曰く。
「それがいいと思うんだったらUMLを使ってもいいですよ。」
「提出していただくドキュメントは、UMLを知らない我々(=顧客)でも理解できるものにしてください」
「ちゃんと動くシステムを作ってくださいね。」
「それと開発費用は安く上げてくださいね。」

----

こう言われるととUMLを使うのは上流工程ではなく、DOAで言うところの内部設計(詳細設計)
しておくのがいいのかな、と思ってしまいます。
ある開発の現場に居合わせましたが、上流工程でのクラス設計などは、一つの業務をいろんな角度から
あーでもない、こーでもないといじりまわしているだけで、作業が遅々として進まないという印象がありました。

----

ところで某社が主催しているUML技術者認定試験って、無料とはいえ、ひどすぎません?
何人かで相談しながら受験しましたが、あれは出題者の意向に沿う回答をしないと点数を
稼ぐことができないようです。この時は、全員が「完璧!」と信じていましたが、全員不
合格。オイ!いいかげんにしろ!と叫びたくなりました。

UMLって定着するようには思えないんですけどね。
皆さんどう思います?

352 :出張 ◆Rb.XJ8VXow :03/05/14 01:27
>>351
勘違い君が多いだけです。
君もその一人らしいけど、気付かないのは仕方ないってとこかなぁ?

353 :非決定性名無しさん:03/05/14 03:23
>>351
UMLという「共通言語」で書かれた図は、納品先の顧客にとって財産になるんです。
そのことを顧客に対して説得しなきゃだめだよ。

たとえば、システム構築の依頼先を今のベンダ(つまり>>351のことね)から他のベンダに変えても、
UMLで書いてあれば理解のギャップが少なくなる。
そんな財産になるというのは、お客にとってすごく有用なことなんだ。

354 :非決定性名無しさん:03/05/14 09:06
>>351

>何人かで相談しながら受験しましたが

不正受験者ハケーン。

355 :非決定性名無しさん:03/05/14 20:06
>>352
勘違い君の代表がそんなこと言うなよ…

356 :非決定性名無しさん:03/05/14 22:39
>>353
>納品先の顧客にとって財産になる

俺にとっては必要ないと思っていたが、
ちょと学んでみようという気になったよ
さんくす

357 :SP:03/05/15 01:08
>>353
> UMLという「共通言語」で書かれた図は、納品先の顧客にとって財産になるんです。

おっしゃることは非常に筋がとおっていると思います。が、営業の立場としては、
お客様にUMLを売り込むのは困難ですね。今まで何度もトライしましたが、ウチの
会社ではお客様様が指定しない限り積極的に売り込むことはやめました。
お客様の望むことは開発手法やドキュメントではなくシステムなんですよね。この
あたりにおける見解の相違がが「一途なUMLのSE」と「お客様に接する営業マン」
とで対立してしまうところ。

個人的にはUMLっていいと思うんですが、まだまだ市場が成熟していないという
ことを実感しています。

358 :353:03/05/16 00:51
というか、顧客の側から「財産だからきちんとUMLで書いてね」と言われて気付いた視点なんだが。

それまでは目の前のお客が好みそうなやり方、書き方を探しつつやっていた。
でも上述のようなことを言われてから、自信を持ってUMLを提示するようになれたよ。
いわばプロジェクト(の顧客側担当者)の視点から、顧客(のビジネス、コスト)の視点への変換です。

顧客を啓蒙するくらいの勢いでやってみようよ。

359 :開発としては:03/05/16 00:56
>>357
・実際の分析→設計はUMLで行っています。
・お客さまの分かる書き方(or御社指定の書き方
            ;古くから情報システムを入れているところに多い)
 で納品すると、書き換えコストをいただきます。
・お客さまの分かる書き方では、良い設計はできません。

という方向で営業してほしい。
(そのメインフレームに偏った指定書式はやめんか! とは客に言えない私。)



360 :出張32 ◆Rb.XJ8VXow :03/05/16 05:25
まともな分析すら出来ない者が幾らUMLで行っても下らんものしか出来ない。
そもそも、要求されている意図が読めずに用途すら理解せず、どんなものを作ってるのさえ
判っていない。
結局、当初の分析が滅茶苦茶で終盤になり仕様変更の憂き目に遭いその場しのぎの対策で
誤魔化し納品しているのが実情だろう。
そんなシステムを幾らUMLでドキュメント化したところで笑うしかない。

もっと技量を磨きなはれ!

361 :非決定性名無しさん:03/05/16 08:06
>>360
何に怒っているのか、まじでわからんのだが。

362 :出張32 ◆Rb.XJ8VXow :03/05/16 08:14
>>361
本物の技量があれば、ほんの短時間で顧客を魅了するぐらい容易い。
>>351からの流れを読むに小手先論ばかりで情けなく思い>>360
投稿をしてみたんだけどやっぱ判らんのだろうな。(視点が全く異なる)

363 :非決定性名無しさん:03/05/16 08:27
>>359
レガシーシステムにはUMLは逆に向かないんじゃない?
分析や設計に「オブジェクト」の概念が持ち込めないシステムにUML
使ったら、かえって混乱するっしょ。

364 :非決定性名無しさん:03/05/16 17:06
何をレガシーと呼んでるの? RDBをレガシーと呼んじゃうコンテキストもあるから、 暗黙では話せんキーワードだ。

365 :非決定性名無しさん:03/05/16 18:01
UMLって本で読んでも全然理解できなかった。
ある機能をプログラミングしてそれを人に見てもらうときに、
試しに使ってみたらいい感じだったので、それ以来多用するようになった。
UMLが単なる表記法だってのはこういうことかとやっと分かった。
実装サイドの低レベルな話ですんません

366 :非決定性名無しさん:03/05/16 22:55
>出張32 そんな内容量ゼロの書き込みをするような方でしたっけ? 本当にくだらないと思いました。 罵倒するなら、その理由・背景はぼかさず書くのが当たり前でしょ

367 :出張32 ◆Rb.XJ8VXow :03/05/17 00:15
>>366
なるほどもう少し詳しく書いてみよう。
設計をUMLで行うのはユーザー指定で無ければ開発側の勝手な作業と考えるべしって
言ったつもりなんだけどね。
つまり受託業務であるのだからドキュメントや打ち合わせでの資料等は全て合意の上で
作成されなければならないってことだ。
勿論、ユーザーに提出しない資料としてUMLドキュメントが存在してても構わない。
但し、>>359さんのように「最後にユーザーに判るように」ってのは頂けない。
つまり分析や打ち合わせ過程で十分な合意形成の為のドキュメントが作成されていないからだ。
ユーザーが理解できないUMLで設計するのは結構だが、ユーザーに理解出来る資料も同時に作成されなければ
何を持って設計の正しさをお客に伝えるのであろうか?
全て口頭?
それとも整合性の乏しいその場凌ぎのメモ書き?
設計書は必要なときに必要なものが作成され双方で確認されなければ死亡通知書になる危険すらある。
そんな認識でUMLの良さを訴えるのは止めて欲しい。


368 :非決定性名無しさん:03/05/17 00:18
ユーザーSEでUMLをつかってる(というか要求している)人キボンヌ。

369 :非決定性名無しさん:03/05/17 01:05
>>367
あのー....
UMLって設計モデルだけだと思っています?
実務では、お客様と一緒にUMLによるビジネスモデリングで
業務仕様を確認していますが。

370 :非決定性名無しさん:03/05/17 01:27
>>369
前提を無視して突っ込まれても困るのだが...
「ユーザー指定で無ければ」と断っているし、スレの流れも同じ。

ユーザー合意の下での話は全く別ですな。

371 :非決定性名無しさん:03/05/17 01:31
>>368
俺の客はそうだ。
大手ユーザー系企業。UMLでのドキュメント作成を規定している。
標準化作業はスケールが大きいところこそ効果が高いから、
大手ならUML導入のインセンティブは高いだろう。

372 :非決定性名無しさん:03/05/17 11:52
>ゆうべ熱かったやつら
なんかお前らと酒のみながら話をしたいんだが。
みんなそれぞれこうあるべきってのが頭にありそうで、面白い話をできそうだ。

373 :359:03/05/17 15:37
>>分析や打ち合わせ過程で十分な合意形成の為のドキュメントが作成されていないからだ。
こう読めるのかな? >>ALL

(メーカー内部でどういう書式を使っているかは置いといて)
主要内容の打ち合わせ

主要内容が書かれた「納品書式ではない客が読める」資料をコミット

主要内容+枝葉の内容を「納品書式で書いてある」資料をコミット
(この資料はそのまま納品)

実装
が作業の流れ。

374 :非決定性名無しさん:03/05/17 17:06
良スレぽ。だがUML使ってないので意味がわからんこと多々鬱死

375 :非決定性名無しさん:03/05/18 01:56
上流部分に限って話をするけど、
UMLって納品資料として使用する必要はないと思うんだけどね。
お客が求めているのは、きちんと体系だって整理された、
分かりやすい仕様書だと思う。
それを書くためには、まず業務をうまく整理する必要があって、
そのためのツールとしてUMLを使えばいいんじゃないかと思う。
実際UMLって結構良くできていて、業務の大部分を
モデル化できるような仕様になっている。
開発側は、UMLをうまく使って業務をうまく整理し、
日本語と直感的な図を使ってお客さんが分かるような仕様書を書けばよい。
UMLの部分を外に見せる必要はない。なんて思うんだけど。





376 :出張32 ◆Rb.XJ8VXow :03/05/18 07:36
>>375
そのようになるのが自然だわな。

「UMLを認めないアフォな客なんて!!!」などのフィルタを持ってたら
まともな設計が出来るはずもなし!ってことだな。

377 :非決定性名無しさん:03/05/18 10:46
>>375,376

賛成。上流工程ではUMLの効果は限定的だと思う。

素人にわかるように仕様をまとめるための過程でUMLを使っても
いいだろうとは思う。けれど、最終的な提出資料にまで使って意味
があるとはどうも思えない。それに、「UMLが技術者の世界での
標準図面だから(そうは思わないけど)、それで素人への検収資料も
まとめるべきだし、ユーザーもそれを理解して当然」ってのは無理
ありすぎ。

もちろん、ユーザーのほうからUMLでいいよっていうならOKだ
けど、そんなのは恵まれた例で一般化できない。(ユーザーである
パートのおばちゃんがコラボレーション図を理解してくれるなんて
企業があるらしい。うらやましいことだ)

まあ結局のところ、ユーザーが内容を理解して、実装工程でも「あ
のときはいいと思ったけど、できあがってみたらやっぱりこうじゃ
ない...」と言い出さないのであれば、UMLでもXYZでも
イタズラ書きでもなんだっていい。(でもイタズラ書きじゃ困るん
だけどね。それぞれの都合のいいように解釈できてしまうから)

378 :非決定性名無しさん:03/05/18 12:05
>>375-377
おもいっきり勘違いをしていると思うのだが。
従来、業務要件(ちなみに、俺、上流って言い方が嫌い)を記述する
モデリング手法って、ARIS、産能大方式、フローチャート、IDEF0、
その他(俺様流)等と、UMLでのビジネスモデリング(ビジネスユースケース、
ビジネスオブジェクト図)を比較して、ユーザーにわかりやすいか
どうかは決定的な差はないでしょ。
業務要件から、分析/設計、製造まで一貫性のあるモデリング手法だから
UML使ったらということであって、保守する必要のない説明資料だったら
別にUML以外の手書き資料だろうが、ポンチ絵,プロトタイプ等を
自由に使えばいい。
>パートのおばちゃんがコラボレーション図を理解してくれるなんて
あのな?何で業務要件を確認するのにコラボレーション図書く必要あるのか?
何でもいいが、ちゃんとUML&RUP正確に覚えてから物事言ってくれ。

379 :非決定性名無しさん:03/05/18 12:29
上流部分の提出ドキュメントとしてUMLを押しつけるのは
開発側の間違いだと思う。
ただ、逆に>>351の下の部分

>ある開発の現場に居合わせましたが、上流工程でのクラス設計などは、一つの業務をいろんな角度から
>あーでもない、こーでもないといじりまわしているだけで、作業が遅々として進まないという印象がありました。

ここの部分は顧客に工数を是が非でも認めて貰わなければならないと
思っている。業務分析をやるには当然試行錯誤が必要で、それは
それなりの時間がかかる。これはUML(っていうか、オブジェクト指向分析)を
使ってやろうと、構造化分析だろうと同じことだ。
成果物がなかなか出来てこないのは
顧客にとって不安だろうけど、良い仕様書を書くためには必要な時間だ。
開発側の立場に立つ351が上のようなことを言うのは
システム開発の本質を理解できていないんじゃないかと思う。
(煽りじゃなくて議論をしたいのよ、念のため)


380 :非決定性名無しさん:03/05/18 12:40
>>378
勘違いしているのはあなたの方ではないですか?
業務要件のモデリング手法と、業務要件について
合意を得るための文書は本来別物でしょう。
業務のモデル化は開発側の思考の過程であって、
必ずしもお客に見せるものではないし、後の工程との一貫性は、
あくまで開発側の利便性の話。今話している問題とは違う。



381 :非決定性名無しさん:03/05/18 13:17
>>380

>業務要件のモデリング手法と、業務要件について
>合意を得るための文書は本来別物でしょう。
別である必然性はないでしょう。
実際、うちの案件では、半分くらいはユーザー側が積極的に
UMLで業務要件を確認し、合意の手段に使っているし、
残りの案件では、内部的にUMLで要件の整理に使い、
顧客には別途、文書やポンチ絵での説明を提出している。
無理に、顧客に押し付ける必要はないが、開発側の標準的なスキル
として、UML使って業務要件をまとめられればいいんじゃない?

382 :非決定性名無しさん:03/05/18 13:25
>>381
うん、わかりました。そもそも議論の前提が違う。
顧客合意の元でUMLを使うことには誰も反対していませんよ。
>>370を読んで下さい。


383 :非決定性名無しさん:03/05/18 13:39
>>382
そうか?そもそも業務要件にUMLを使うことに否定的な
発言が続いていたと思うが。
>上流部分に限って話をするけど、
>UMLって納品資料として使用する必要はないと思うんだけどね。
>賛成。上流工程ではUMLの効果は限定的だと思う。


384 :非決定性名無しさん:03/05/18 14:00
>>383
えーと、375は俺なんだけど、あの発言は>>351を受けてのものです。
351は、お客への納品物としてUMLが使えない=上流部分ではUMLは
使えない。という発言だと考えたので、
要件の記述としてのUMLだけに目を向けるんじゃなくて、
業務分析のツールとしてUMLを使えばいいんじゃない?と言いたかったのです。
(俺は、要件の記述と業務分析は別物だと考えています。)
で、要件の記述としてのUMLが顧客に認められているならば、
それを使うのは別に問題なしと考えています。



385 :非決定性名無しさん:03/05/18 14:13
>>384
了解。
悪かったね。


386 :出張32 ◆Rb.XJ8VXow :03/05/18 18:46
>>379
その通り!
一番重要な時間と言える。
そこで多様な視点から論議することは大事である。
それによる成果物がほんの僅かであっても議論に参加した人達の認識は高まり
どの人がどれ位の理解であるのかも判るようになるだろう。
もちろん、整理しないままで悪戯に議論を繰り返すのは良くない。
必ず、論点と論拠を明確にした進行は必要だと考える。
それと、そこで出された案の全てが採用される訳ではないから、不採用になったもの
もしっかりと不採用理由を付けて管理するべきである。

387 :非決定性名無しさん:03/05/18 20:41
>>379,386

上流工程での試行錯誤が重要だというのは全面的に賛成。多くのプロジェクトで
「まあ、こんな感じでいいか」って感じで見切り発車的に先に進む例が多すぎると
ワシも感じている。何枚も何枚も図面を描きたおすとか、検討結果のダメ出しを
仲間うちで徹底するとかいった工夫がどうも足りなすぎる。

とはいうものの、試行錯誤が大事ってのは、使っている図法が適切ならばっての
が前提。351でのクラス図での検討の例は、試行錯誤を重ねているというよりは、
もしかしたら図法として適切でないゆえに検討が散漫になってモタモタしている
ってだけの目撃報告のような気がしてならない。

よい図法ってのは「何が正しいかはさておき、少なくともこれはおかしい」こと
がわかるような表現力がないといけないと思うんだけど、クラス図ってどうなん
だろ。クラス図で描かれた図面の正しさの根拠って「XXXXのパターンにXX
XXの要素を加味した。ものいずれのパターンもオーソドックスであるゆえにこれ
は正しいだろう」くらいしか評価できないのではないかという印象があるけどどう
なんだろ。

388 :非決定性名無しさん:03/05/18 20:49
単に習熟度の問題だと思うんだけど・・・
慣れればクラス図でもどこがおかしいって勘が働くようになるでしょ。
別にUMLに限らん話だけど

389 :出張32 ◆Rb.XJ8VXow :03/05/18 21:52
>>387,388
もちろん、習熟度の問題はあるだろう。
しかし一番多いのがハッキリしない要件が数件程度残ることだ。
必ずしも、要件定義で全てが決定されるわけではない。(理想は別だ)
ここで重要なのが「ハッキリしない要件」を如何扱うかで下流に大きな問題を
残すこととなる。
一番不味いのが「曖昧なまま宙ぶらりん」にするってことで、これをする設計者が結構いる。
次に不味いのが、「ハッキリしない要件を排除」することで、後工程で復活する。
最善なのが、「間違っていても要件を決め付ける」ってところか?

ともかく、設計にメリハリを付けガラス張りにすることこそ一番大事だと言える。

390 :非決定性名無しさん:03/05/18 22:31
>>389
主張したいことはわかったが、
それは開発プロセスの話であり、激しくスレ違いだろ。

UMLは表記法であり、開発プロセスとは関係ない。
(もっとも多くのケースでは開発プロセスと"誤って"関連付けられることが多いが)
じゃあ表記法としてUMLは適しているかというと、
適用範囲に漏れはあるが漏れない範囲においては抜群のパフォーマンスを示すと考えている。

他人に図表を提示するときには、その意図と見方を最初にざっと説明すると思う。
UMLで全然分からないと言われたことはほとんどないよ。
言われたときも、UML覚えたての頃に書いた「いろんなものを一度に詰め込んだ図」の時だ。
UMLとして文法化されているおかげで、図の表現内容も一定レベルを維持できる。

回数を重ねるごとに客も慣れてくるから、説明も省略可能で効率的になる。
恣意的なアイコン、恣意的な矢印を使い続けるのは、慣れによるメリットを捨てていると思う。


> ともかく、設計にメリハリをつけてガラス張りにすることこそ一番大事だと言える。
「メリハリをつけ」るとは何を指すのかまったく分からんが、はっきりさせておくことは大事だな。
いま必死でやっているよ。自分で成功させないことには胸を張って主張できない。

RUPやXPはその辺りを強調している。
つーか要求定義の方法論はすべて、昔のやつもそれをやるべきと提唱している。
(この業界7年目のまだまだひよっこなんで、昔のことは不勉強だが)



391 :出張32 ◆Rb.XJ8VXow :03/05/19 00:02
>>390
すまん、ちと横道にそれ過ぎたようだ。
頑張って良いシステムを開発してください。

392 :非決定性名無しさん:03/05/19 00:17
>>390
経験談を語れない、出張にそんな長いレスをつけるのは時間のムダだよ。
他の自分の意見を書いてる人にレスつけた方がいいよ。
「未経験者」とか1行レスで十分。
この発言でも相手をしてやってることになるから、良くないんだけど。

>>ALL
要件定義,仕様確定はひとまず置いておいて・・・
「開発後メーカーを変えてもいいように」という意味合いで、実装に近い
内容を書いたドキュメントを納品するよね。
これは、なるべくUMLで納品できるよう、顧客を説得した方が良いよね。


393 :非決定性名無しさん:03/05/19 00:39
>>392
>「開発後メーカーを変えてもいいように」という意味合いで、実装に近い
>内容を書いたドキュメントを納品するよね。
>これは、なるべくUMLで納品できるよう、顧客を説得した方が良いよね。
そのとおりだと思いますが、大規模システムになると
設計ドキュメント量は半端じゃないボリュームになりませんか。

394 :非決定性名無しさん:03/05/19 00:51
>>393
半端じゃないボリュームであればこそ、「書き直し」をしたくないわけですよ。


395 :出張32 ◆Rb.XJ8VXow :03/05/19 00:58
>>394
ダンボール箱で50箱位になるか?
先月終わったとこで45箱あったが...

396 :非決定性名無しさん:03/05/19 01:26
>>395
ダンボール箱っていってもいろいろある。
中サイズのKING GIMに換算すると、どのぐらい?

397 :出張32 ◆Rb.XJ8VXow :03/05/19 02:16
>>396
すまんすまん、A4コピー用紙箱ですわ。(2500毎入りのやつ)
そのドキュメントが一語一句添削されて返って来たからねぇ。
検査する側も半端じゃねぇ!

まぁ、カキコしてたの寄せ集め集団だったが...(笑
後で苦しんだのはクローザーであった!(ゴミに埋れて...

398 :sage:03/05/19 23:44
>>387
クラス図があいまいというのは同意です
正規化理論もキー項目に関する考慮もなく、ただなんとなく線を引ける世界なので…
クラス図は概念モデル作成と、詳細設計以降に利用すると割り切ったほうがいいと思うです

>>393-395
そこまで行ったら、実装しちまったほうが早いんじゃないっすか?
#そんな設計資料みて実装する方が地獄のような気が……

399 :398:03/05/19 23:45
しまった、失敗…sage

400 :出張32 ◆Rb.XJ8VXow :03/05/20 00:13
>>398
> クラス図があいまいというのは同意です
> 正規化理論もキー項目に関する考慮もなく、ただなんとなく線を引ける世界なので…
> クラス図は概念モデル作成と、詳細設計以降に利用すると割り切ったほうがいいと思うです

切り口が間違ってる(視点が不適切)ともう使えねぇ。
モデル化する以前に問題があることを認識する必要がある。
中途半端にモデル化するより、素材をそのまま読むほうがミスリードは少ない。
もちろん、最終的にモデル化する必要があることは当然だが技量が未熟だと
モデル化を急ぐ傾向があり不適切にモデル化された虚像に最後まで引きずられて
しまう傾向が強い。

> そこまで行ったら、実装しちまったほうが早いんじゃないっすか?
当然そうなる。
実装のほうが遥かに早い。
しかし、実際の実装作業もこれまた寄せ集め集団が実施、意味不明なコーディングと
無意味なテストの繰り返しで時間と予算だけが使われていく...

結局、少数のクローザーがエンティティ頼りにソースコードを全面的に書き直し
終焉となる。
勿論、書かれた仕様書の改定は必要最小限度に留まる。
こんなんでほんとに良いのか疑問ではあるが現実でもある。

401 :出張が:03/05/20 02:02

>>397でみごとに誘導尋問にはまっています。
引渡し前のドキュメントがどういう状態た見たことがないのでしょう。

このような、現場を知らない人の書きこみだと思いましょう。

402 :出張32 ◆Rb.XJ8VXow :03/05/20 02:43
>>401
A4コピー用紙箱に積み上げてあるぞ?
何か不満でもあるのか?

403 :非決定性名無しさん:03/05/20 04:50
漏れの読解力がないのかもしれんが
>>401が何を言ってるのかさっぱり分からん

404 :非決定性名無しさん:03/05/20 09:13
ちょっと話がずれてしまうけど、上流工程ではUMLのどれを使うこと
になってるんだろ。(自分でRUP読んで調べろといわれそうだけど)

なにやらクラス図もコラボレーション図も使えないみたいで、あとは
ユースケース図くらい?そうだとしたら、上流工程でユースケース図
を使うだけで「UMLは上流工程でも便利に使える」ってことになるの?

だいたい、UMLに含まれる雑多な図法のうちのどれかでも使えば
「UMLを使った」ってことになるとしたら、話は簡単でUMLは
上流でも下流でも非常に有用だってことになるなあ。

405 :非決定性名無しさん:03/05/20 09:20
まさにRUPに回答があるよ。 あとはアナリシスパターンとかビジネスモデリングとか

406 :非決定性名無しさん:03/05/20 20:55
>>404 上流工程ではUMLのどれを使うことになってるんだろ
それはUMLの仕様の範囲外だから、どれを使うか自分で決めれば
何をつかってもいいんだYO!
RUPには上流でのUC図、クラス図、シーケンス図、コラボレーション図、
ステートチャート図、アクティビティ図の使い方が書いてあるYO!

407 :非決定性名無しさん:03/05/20 23:09
>>406
ネタで煽ってます?
それとも単に知らないだけ?

408 :非決定性名無しさん:03/05/21 00:10
俺には出張32氏の意見はすごくまっとうなように思われるのだが・・・
何で叩かれてるの?

それはともかく、

>>398
> クラス図があいまいというのは同意です
> 正規化理論もキー項目に関する考慮もなく、ただなんとなく線を引ける世界なので…
> クラス図は概念モデル作成と、詳細設計以降に利用すると割り切ったほうがいいと思うです

UMLは汎用モデリング言語だから、応用範囲が広い分
あいまいな部分が残ってしまうのはあたりまえないんじゃないかな、
と俺は思っています。
例えば、関連一つ取っても分析のモデルと設計のモデルでは、
線の意味が違う。
それぞれの工程での図の目的と意味づけは開発プロセスの領分だから、
開発プロセス抜きにUMLのあいまいさを指摘しても仕方がないと
思います。
>>387氏のいう図の正しさの評価方法は経験則に基づくもので、
それはそれで必要なのですが、それに加えて
プロセスで定義された目的に適っているか?という評価軸を
加えれば、それなりに正しさを評価することは出来ると思っています。

409 :非決定性名無しさん:03/05/21 00:22
ちなみに、RUPはプロジェクト単位でのカスタマイズを前提とした
汎用プロセスだからなのか、図の目的、意味づけはかなりあいまいに
してあるように思われます。
RUPを導入する時には、やっぱりプロジェクト毎に図の正確な意味づけと
評価方法を定義してやる必要があるのではないでしょうか。
実際にRUPでやったことないので分からないけど。
だれか経験者がいたら、その辺の事情を教えて欲しいです。


410 :出張32 ◆Rb.XJ8VXow :03/05/21 01:23
モデル化は必要だしUMLが良く出来ていることを否定する人は少ないとおもう。
モデリングが整合性を確保し整理されたものであるならば、ケアレスミスは防げるし
何よりも同じ視点に沿った見方が確保されるから重宝することは事実だと思う。

しかし、このことが逆に作用してしまう工程の存在が問題を難しくしていると考える。
それは、モデル化する切り口を決める工程だ。
切り口が適切化であるか不適切であるかは重要である。
不適切な切り口であってもモデル化は可能だし、作り出された資料からその不適切さを
読み取るのははっきり言って難しい。
しかし、不適切な切り口だと後工程で必ず問題が発生する。
つまり不適切な切り口で目的を読み取ることとなり、結果的に間違った解釈に統一されて
しまうってことだ。
「それ意味が違う!」「今更、仕様変更を言われても..」

しかし、モデル化された資料に基き協議はして来たし確認も取って来た筈だ!
今頃何を...
.......
切り口が根本的に違うなんて....

少し過信し過ぎて居たようだ....

411 :非決定性名無しさん:03/05/21 02:25
>>408
>>俺には出張32氏の意見はすごくまっとうなように思われるのだが・・・
>>何で叩かれてるの?

他の人は「自分の職場でこんなことがあった」という経験談、およびそれに基づく
意見を載せているのに対し、出張はそれをしない。

「未経験者」が知ったかぶりをしているだけ。

412 :出張32 ◆Rb.XJ8VXow :03/05/21 03:01
>>411
残念だが私は本職だよ。
唯、君達とは全く違う立場に立っているから「自分の職場でこんなことがあった」等の
発言を控えているだけだ。

413 :出張に:03/05/21 21:33
「量的にA4コピー用紙箱45箱分と言っただけ」
と逃げられるかと思ったけど、墓穴を掘ったようです。
>>397
>>402
「顧客引渡し(検収)前後」において、2500×45枚のドキュメントが
「A4コピー用紙箱」に保存してあると言っています。

>>みなさん
何がいけないかを出張に教えるような書きこみはしないでください。
そして、他スレで出張に丁寧なレスをつけている経験者がいたら
この一連の流れを貼ってやってください。

(未経験者が出張を経験者だと思うことや、出張が書きこみをすることは止められないけど)

414 :非決定性名無しさん:03/05/21 21:42
>>407
> ネタで煽ってます?
> それとも単に知らないだけ?
チミのRUP良く見てみ
RUP2001A日本語版であれば
インストール先\RationalUnifiedProcess.ja_jp\process\workflow\busmodel\mdov_bm.htm
・ビジネス ユースケース モデルにおけるアクティビティ図
・ビジネス オブジェクト モデルのステートチャート図
・ビジネス オブジェクト モデルのシーケンス図
・ビジネス オブジェクト モデルにおけるコラボレーション図
インストール先\RationalUnifiedProcess.ja_jp\process\workflow\requirem\mdov_req.htm
・ユースケース モデルにおけるアクティビティ図

415 :あぼーん:あぼーん
あぼーん

416 :非決定性名無しさん:03/05/21 21:58
413が何を言ってるのかさっぱり分からん

417 :非決定性名無しさん:03/05/21 22:09
>>409
それを人は、テーラリングとよぶ。

必須。

418 :あぼーん:あぼーん
あぼーん

419 :あぼーん:あぼーん
あぼーん

420 :非決定性名無しさん:03/05/21 23:32
>>414
で、実際には、なに使ってるの?
まさか全部使っているわけじゃ(藁

421 :非決定性名無しさん:03/05/22 01:51
>>413って何?新手の粘着か?出張もストーカーが多いからな。

422 :非決定性名無しさん:03/05/22 07:52
>>414

なんだ、やっぱりシーケンス図だのコラボレーション図だの
ひととおりの図面が上流で使われる可能性はあるということね。
しかし、それらの図面を了解できるパートのオバちゃん揃いの
企業が多いとは思えないなあ。

423 :非決定性名無しさん:03/05/22 16:44
パートのおばちゃんが読むのは操作マニュアル。そこはテクニカルライティングの守備範囲。 上流行程を担当するのがパートのおばちゃんならば、おばちゃんが研鑽するべし。

424 :非決定性名無しさん:03/05/22 22:50
>>423

そりゃあデザイン検討に関わるのなら、メンバーにはある程度の
理解力が必要ってのは同意だけど、「上流工程での相手はど素人」
っていう前提を忘れちゃいけない。わかってもらうための努力を
こちらが惜しんじゃいけなくて、わかりやすい図面を使わなきゃ
ならないし、わかりやすいコンテンツを生み出す努力も必要だし、
わかったかどうかをこれでもかと確認するしつこさも必要。
素人にも納得できるような上流成果物を生み出すためにケンサン
を積まなきゃならないのはどっちかというと設計者の方なんじゃ
ないかな。

で、UMLはそれに応えられるのかな?せいぜいユースケース図
を書いてお茶を濁すくらいしかできないような気がするんだけど。

425 :414:03/05/22 23:22
>>420
どれか1つなんてことは無いYO!
相互作用に関してはシーケンス図かコラボレーション図
まぁ相互に変換可能だから実質全部使っているようなもんだし、それがRUPなんす。
詳しくは「ビジネスユースケースの実現」と「ユースケースの実現」を勉強してね。
ビジネスユースケースの実現でのアクティビティ図は、業務フローって
言った方がイメージしやすいかな。
ちなみに書籍にはここまで書いていないのでRUPの現物見てね。

426 :出張32 ◆Rb.XJ8VXow :03/05/23 04:34
>>424
そう、お互いに専門分野以外は「ド素人」であるとの認識は必要だと思う。
そりゃ、我々の商売は「多くの有能な人から有益な思考を学べる」ってことは言えるが
それでもユーザーサイドの実務経験を習得している訳じゃない。
つまりは「ド素人」であり切り口も下手をすると固定観念に縛れた陳腐なものに
なっていてその危うさに恐れを懐くことすらある。
しかし、人はほんの少しの配慮によりお互いを補完出来る。
そのことに気付けば「自専門分野だけに特化した視野で専門分野外の人を対象に嘲る」
ような愚かさは無くなるだろう。


427 :非決定性名無しさん:03/05/23 05:18
>>426
なんか、最近、出張はわりと常識的な発言しかしなくて
つまらないな。
もっとネタに徹してくだされ。

428 :非決定性名無しさん:03/05/23 16:37
>427
常識的なことというか、
あたりまえのことをただえらそうに並べてるだけでは?

429 :出張32 ◆Rb.XJ8VXow :03/05/23 21:07
>>428
その「常識で当たり前」のことが全く出来ていない奴が沢山いるから、
言わなくて良いことまで発言せにゃ〜ならんのよ。

特に「そんなん常識じゃん!」とかを直ぐに言う軽い奴は「頭のみで理解」している
奴が多くて始末におえない。
ほんとにほんと理解しているのかと、小一時間問い詰めたい...(笑


430 :非決定性名無しさん:03/05/23 21:45
>>429
> 特に「そんなん常識じゃん!」とかを直ぐに言う軽い奴は「頭のみで理解」している
> 奴が多くて始末におえない。

経験的に同意・・・・・・せざるをえない(TT)

431 :非決定性名無しさん:03/05/23 23:16
ソフトウエア開発における上流(分析/設計)工程のモデリング技術者の育成と,
モデル情報の共有を狙って5月19日,特定非営利活動法人「UMLモデリング推進協議会
UMTP/Japan(consortium for UML based Modeling Promotion)」が発足した。
ttp://itpro.nikkeibp.co.jp/free/NSW/NEWS/20030519/2/

432 :非決定性名無しさん:03/05/23 23:25
>>411
一般論として見れば出張32氏の見識にはそれなりに説得力が
あるように思うがね。

こういう見識眼というのは、実務でのスキルとは必ずしも一致
せず、氏のカキコは評論家の域を出ていない故に反発もあるの
だろうけど、漏れ的にはおもろいな。


433 :非決定性名無しさん:03/05/24 02:12
>>評論家の域を出ていない
評論家にもなっていないと思うが。
評論家は自分の意見を言う。教科書に載ってることを踏まえた上で。
(昨今の経済・金融政策の議論とか)

基礎を踏まえた上で一歩踏み込んでる書きこみに対して、
基礎のみでレスをつけるのが出張。
基礎のみなのに偉そうに言うから反発がある。

434 :出張32 ◆Rb.XJ8VXow :03/05/24 04:10
>>433
その考え方がそもそも間違っている。
基礎に始まり基礎に戻る。
新たな発想や思考は、基礎に戻ってこそ生まれる。
君らがより「高度」を欲し目標としているのは良くわかるが所詮マヤカシに過ぎん。
「基礎を踏まえた上で一歩踏み込んだ云々」は嘘の塊であることに気付けるのも、
基礎を大事にすればこそなせる技である。
君らが言う基礎のなんと脆いことか?

知っていることだけなら下らぬ。
基礎を磨き上げる行為すらせず小手先の論を持って「一歩踏み出す」とは笑止なり。


435 :非決定性名無しさん:03/05/24 17:29
>>431
これってヤバイんじゃないか?
なんせ、H内はCBOPでさんざん好きなことやって、
挙句の果てに国からもらった金を使い果たしたからね。
おまけに、H内はDOAだから、もともとオブジェクト
指向全然わかっていないときている。

436 :非決定性名無しさん:03/05/25 21:01
みなさん普段からOO開発なさっているわけですよね。
やっぱりソフトウェア業界では一般的になりつつあるんでしょうか。
今の会社ではOO開発、もちろんUMLを使ったことないのですが、
将来転職考えるならUML習得しといたほうがいいんですかね?

437 :非決定性名無しさん:03/05/25 21:14
>>436
一般的というかあたりまえの存在だよ。
書籍売場でソフトウェア開発の書籍を手にとってみれば、UMLの載っていないものを探すのが大変なくらい。

「転職するしない」がUML学習に対する条件分岐にはならないよ。
習得自体は簡単だから、がんがれえ。

438 :436:03/05/25 21:42
>>437
そうですか。UMLのUの字もでてこないような職場なんです。
このままだとオブジェクト指向開発なんて一生することないだろうな。

やっぱりこれからのことを考えるとOO開発の技術も習得するべきですよね。
ちなみにUMLってオブジェクト指向でしか使えないのですか?

439 :出張 ◆Rb.XJ8VXow :03/05/25 22:33
>>438
心配しなくても問題ないのとちゃうか?
今のとこブームではあるが技術的に難しいものはなく、それらを力説しているのは
まだまだ幼稚なクラスでもちっと静観しててもよさげっぽいっす。
ただ、ここ1−2年は結構成長してるからほんとに使えるツールが出現する時期に
なりつつあるのも事実で後2年位でjavaも完成の域に達すると思う。
もちろん、oo自体概念レベルでは完成されてる訳だが...


440 :山崎渉:03/05/28 14:29
     ∧_∧
ピュ.ー (  ^^ ) <これからも僕を応援して下さいね(^^)。
  =〔~∪ ̄ ̄〕
  = ◎――◎                      山崎渉

441 :非決定性名無しさん:03/06/28 09:40
めんどくさいよ。とりあえずUMLシルバー取ったけど、
自分が中心になって広める気が起きない。

442 :山崎 渉:03/07/12 12:50

 __∧_∧_
 |(  ^^ )| <寝るぽ(^^)
 |\⌒⌒⌒\
 \ |⌒⌒⌒~|         山崎渉
   ~ ̄ ̄ ̄ ̄

443 :非決定性名無しさん:03/07/18 13:17
保守

444 :非決定性名無しさん:03/07/18 19:59
うちの会社、UMLを使わないことに決まった。
Roseが泣いてるよ。

まあ、オブジェクト指向設計できるやつが、俺以外
いないという低レベルな会社だし。

445 :非決定性名無しさん:03/07/19 01:01
転職したほうがいいYO!

446 :あぼーん:あぼーん
あぼーん

447 :非決定性名無しさん:03/07/19 10:27
>>444
いま議論して、なんで「使わない」方向に決まるんだ?

448 :非決定性名無しさん:03/07/19 10:59
>>447
普通、そう思うのが普通だよな。

ほんと、一気にやる気なくした...。

449 :非決定性名無しさん:03/07/19 11:03
経営層が2ch好きで
>>439の発言を信じて2年静観することにしたとか

450 :非決定性名無しさん:03/07/19 11:13
>>448
「エッヘン。わが社の独自性をまもるべく〜」とか言ってたりして

451 :非決定性名無しさん:03/07/19 12:03
>>448

1)プロジェクトマネージャたちが、現場がなにをやっているのかわからなくて
指示も管理もできなくなるから。
2)現場が生兵法で大怪我するが目に見えてるから。



452 :あぼーん:あぼーん
あぼーん

453 :非決定性名無しさん:03/07/19 12:19
>>451
人は、決定権を与えられると、
あえてよの潮流に逆らって独自の判断をする事が、とてもすばらしい事に思えるから。
ホントは決定権持ってる奴が、充分な判断材料持ってる事が前提なんだけどね。

454 :山崎 渉:03/08/15 19:15
    (⌒V⌒)
   │ ^ ^ │<これからも僕を応援して下さいね(^^)。
  ⊂|    |つ
   (_)(_)                      山崎パン

455 :非決定性名無しさん:03/08/18 19:31
板違いを覚悟で御伺い致します。ご無礼をお許し下さい。
CPU1個、アセンブラのみの組込機器開発でUMLを適用するメリットはありますか?

私はソフトウェア開発に関して体系的な学習をした事が無く、今まで場当たり的な
開発作業を行っていました。が、年の離れた唯一人の先輩も定年を迎え、今後一人
で開発作業を行う事になりそうです。しかし、いつかは後輩が入社したり、外注先
と協力しながら作業を進める事が予想され、今から自分が関わる案件に関しては
とにかく他人様が理解できる資料を残す必要があると感じています。

皆様大規模なコンピュータシステム開発に精通されているご様子ですが、小規模な
組込機器開発にはあまり関係がない技術なのでしょうか?

456 :非決定性名無しさん:03/09/02 04:15
ネタで煽ってます?
それとも単に知らないだけ?


457 :非決定性名無しさん:03/09/19 16:23
OOやってなきゃクラス図は必要ないけど、ユースケースとか
ステートチャート図とかアクティビティ図とかは使えないこともない。

シンボルテーブル表とフローチャートで足りてるなら、無理して
つかわんでいいがな


458 :あぼーん:あぼーん
あぼーん

459 :非決定性名無しさん:03/09/23 04:10
euml


460 :非決定性名無しさん:03/09/26 01:33
やっぱLanguageってのは腑に落ちない。
Unified Modeling Representationぐらいじゃねーの?

461 :特進クラス:03/09/26 01:42
大手のプロマネの方々の知識って半端ないんですね。

462 :非決定性名無しさん:03/09/27 02:35
>>458
オマエモナー

463 :非決定性名無しさん:03/09/27 03:22
UMLは基本的に書式のはずだった。
最近統一プロセスとかいってるけど…。
アレは食えんな。

大事なのは書式じゃなくて中身なんだけど、訳もわからずUMLを謳う
にわかOO設計者が多くてウザイねぇ。
UMLは馬鹿でも使えるけど、しっかりしたOOとしてのデザインは別だね。

464 :非決定性名無しさん:03/10/20 00:12
元請けのSEやってますけど、UMLで設計書を書くどころか、DFDで設計書を書いたこともありません。
データ定義と機能はそれぞれEXCELで表にして書きます、もちろん普通の平易な日本語で。
ER図は提出ドキュメントに書きますけどね。

今までこれが普通だと思ってましたけど、おかしいですか?
ちなみにスパイラルモデルで開発など、うちの会社ではやってみようという気配もありません。
どんな小規模案件でもウォータフォールです。
そのくせPMBOKだけはやたらにお偉いさんが乗り気になって騒いでいます。

465 :非決定性名無しさん:03/10/20 11:02
とりあえず富士ソフトABCではOO開発など全くやる気配すらも見えませんので、
少なくともクラス図は目にすることはありませんな。

466 :非決定性名無しさん:03/10/20 14:00
>>464

提出用としてER図を描くってのはどういう
ことなんだろ。設計標準かなにかで提出が義務
づけられているから作っているってことかな。

クラス図もER図も設計のまっさいちゅうに使って
こそ意味があると思うのだが、標準だってんで
あらためて作るって、それってまるで意味ないよなあ。

467 :非決定性名無しさん:03/10/20 14:10
元請けだったらドキュメント成果物を分厚く水増しさせるために
とりあえずぶち込むってことはあるんじゃないの?
設計標準というより、後の案件、フェーズ2等で使うのではないかな。
うちもER図はたいてい提出してるよ。

468 :非決定性名無しさん:03/10/20 21:43
つーか、成果物にER図もないプロジェクトなんて、
保守できないよ。

469 :非決定性名無しさん:03/10/21 00:35
>>464
UMLはしょっちゅう目にしてるけど、DFDは就職して以来、一度も目にしてないな。
大手の大規模案件なんかだとDFD使って仕事してたりするのかな?
それからスパイラルモデルが可能なプロジェクトはかなり限られるよ。
それくらいならフェーズを分けることを提案する。

470 :非決定性名無しさん:03/10/23 14:43
UML2.0を見てC言語がC++に逝っちゃったのと同じ
匂いを感じるのは漏れだけ?

あんなの使えねーよと思っているんだが。


471 :非決定性名無しさん:03/10/23 22:42
UML2.0 は、CASEの夢再びって感じだよな。
MDAのためにはあそこまで仕様化しないといかんのだろうが、
とても一般人(顧客とか)に見せられたもんじゃない。

省略した概要図みたいなものを自動的に生成できないと、
あいかわらずドキュメントと実物の乖離が起きまくる。

472 :非決定性名無しさん:03/11/02 23:58
http://www.google.com/search?q=%E5%A4%A2%E7%B2%BE%E3%81%97%E3%81%A6%E3%81%9F%E3%82%89%E3%81%84%E3%81%91%E3%81%AA%E3%81%84%E3%81%AA%E3%81%A8%E6%80%9D%E3%81%A3%E3%81%9F&sourceid=mozilla-search&start=0&start=0&ie=utf-8&oe=utf-8

473 :非決定性名無しさん:03/11/24 03:54
出張が戯言を書き連ねるスレ

474 :非決定性名無しさん:04/01/03 22:36
出張いねーじゃん

475 :非決定性名無しさん:04/02/03 01:24
a

476 :非決定性名無しさん:04/02/22 01:57
OMG認定UML技術者資格試験というものがある。
http://www.umlcert.org

477 :非決定性名無しさん:04/02/23 20:04
UMLあげ

478 :赤シャカ ◆3GguJeKwzU :04/02/27 23:22

へー、このスレ、ためになるね。


479 :青シャカ ◆FAdyGXfXPk :04/02/27 23:41
青シャコも参考にしています

480 :非決定性名無しさん:04/03/05 22:32
UMLの入門書がイパーイあるんで日本人の書いたのだけでランキングしてください。

481 :非決定性名無しさん:04/03/14 21:23
VDM/SL で書いてますが何か?

482 :赤シャカ ◆3GguJeKwzU :04/03/17 23:58

最近、書店に増えたよな。
EUCでも、使えないかな。
ツールとして、使えそうな。。


483 :http://bulkfeeds.net/app/search2?q=UML:04/03/30 23:59
UML・仕様書・設計書関連2chスレッドのまとめ (siyousyo - wikich)

http://pwiki.chbox.com/pukiwiki.php?siyousyo


http://bulkfeeds.net/app/search2?q=UML

484 :非決定性名無しさん:04/03/31 02:01
・DOAの概念ER図
・OOの概念クラス図
って似たようなもの?

概念ER図から概念クラス図を起こしてみようとしているんだけど
概念クラス図がどうなるべきかよくわからなくて起こせない・・・

DOAとOOを両方とも理解しているスペシャリストが
周りにいればいいのにと思う今日この頃。
ここの人で両方スペシャルな人いますか?

485 :非決定性名無しさん:04/04/14 23:08
UMLフォーラムage

486 :非決定性名無しさん:04/04/14 23:13
手間ばっかり掛かって誰も見ないドキュメント作りかよ

487 :非決定性名無しさん:04/04/15 01:14
開発者は見るよ。

488 :非決定性名無しさん:04/04/21 11:53
最近 録音=◆Rb.XJ8VXow も新しい攻撃方法を憶えてきたからな。。
録音を攻撃すると「それじゃ、録音と変わりないなw」とか
「録音なみだな、お前」とかいう反撃は
みんな録音の自演。自分の自演とばれないように録音自身をバカにしたような論調で
実は録音がむかついたヤツを攻撃してる。
最初は別人かと思ったけど録音がいるところで必ず
同じパターンが続くんでわかってきた。

489 :非決定性名無しさん:04/04/29 20:05
んー。必要に応じて従来のDFDみたいな図とUMLとを使い分けてるヒトって、
フツーな気もするんですが。

「状態とメッセージ」な切り口と、「機能とデータ」な切り口の図が
必要なら両方用意しますね。「UMLを知ってる」かどうかは別の問題で、
システム化すべきポイントを捉えたユーザさんなら、よほどハズした図を
使わない限り、ちゃんと図を見てくれてます。実装考えても、RDBを意識
しなきゃいけない以上、Javaでの開発であってもDFDとかERDはあった方が便利。
てか作っとかないと実装者が気の毒。

(あ、むろん打ち合わせの相手をしてくれるユーザさんは、エンドユーザとは
違います。ひょっとしたら偶々非常勤の女性が担当なのかも知れませんが。)

OOと構造化分析とでは、思想がちがうけど、図面の書き方に関しては
開発しやすいように柔軟に使い回うのは「あり」だと思うです。

だから、要は確実に「使ってもらえる」設計を行うべきなんであって、
それをどこかに置き忘れたような「開拓者」じゃしょうがない、と
主張する出張さんの意見も感覚的にわかるような気がするんですよね。
当たり前の基本のキ、なんですが、案外、「わかってない」開発者大杉。

出張さん、未経験どころかマジ、すげー経験積んでるSEさんなんじゃないかと。
むしろマネージャさんかな。

490 :非決定性名無しさん:04/05/14 03:26
ノーテーションにとらわれ杉age


491 :非決定性名無しさん:04/05/16 02:08
うちはwordです。

156 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)