- - PR -
UMLを用いた開発について
| 投稿者 | 投稿内容 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2002-06-02 08:44
まず、始めに、このスレッドは今までの中でも特に勉強になりますね。
簡潔で分かりやすいです。 基本的に、一言で言ってしまえば、自分の置かれている位置と、 顧客の要望と、作る商品（ソフト）の分野や、顧客の企業の社会的位置や 現状の顧客の状態把握などをして、話し合いや交渉をしながら、 お互いの共通点を見つけながら、どのモデルでどういう方法論を取ったらいいか？ ただ、単に流行ってるとか、最新だとかにとらわれず、 今まで行われてきた色々な手法の中から、その場その場で柔軟に選択しながら 設計段階に入るまでに情報を把握して、設計段階に入るときまでに決めて そこから、作りこんでいくってのが、結果的に現実的なんではないでしょうか？ 理論と現実が必ずしも100%一致するとも、思えないので。。。 幅が広すぎてすいません。 でも、過去に遡って全部書くわけにもいかないので、お許しを。 どうでしょうか？ これも、やはり無理があるかな？ | ||||||||||||||||
|
投稿日時: 2002-06-02 13:45
ふうすけさんの書かれた内容が余りにも多いので、取り敢えずこの点に関して 私もふうすけさんが言われる通りだと思います。 でも、最低限クラス図を捨てる様な事が起きるのでは、駄目だと思います。 先ず、UMLは、インターフェース（広い意味）と別管理する事無く、インターフェースと一体のものとしてインプリメントされるべきです！ その重要性が理解出来てない所が、いまのUMLツールの一番の問題点ですね。 UML上の変更は、インターフェースへ反映されるべきですし、インターフェースの変更がUMLに反映されるべきです。 今のコンポーネントベースのＲＡＤツールなら、これも可能だと思うのですが…。 （それから、全てがインライン形式でしか書けない、JAVA方式が最近多いですが、これも問題ですよね。私は嫌です。） クラスが設計時インターフェースとしてUMLに対応出来る事、そしてそれが実装される事が一番大切なんだと思います。 UMLに関しては、実際にコンポーネントクラスライブラリを持ってる所が、もっと主導権を発揮すべきだと思っています。 私は、Delphiの場合、ボーランドにこれを期待したんですが、ボーランドもラショナルという感じですね。 「．ＮＥＴ」は、期待出来るんじゃないでしょうか？う〜ん、期待したいな！ （私が思っている事を十分には表現出来てませんが、取り敢えずレスします。） | ||||||||||||||||
|
投稿日時: 2002-06-02 14:47
うーん…
レイヤの問題だと思うんですけどねぇ。> クラス図云々 理想/妄想は、「要求仕様書からプログラムが自動生成されること」ですよね。 で、UML で業務分析をもげもげ、で、RAD にかけて、ってのはまぁ、わかるんです。 なんですが、プログラムが自動生成されるほどの要求仕様書って…とか、絶対に業務に直接は関係しない中間データは使われるはず、とかとか、いろいろ問題がありそうな気がします。 UML って、幸運なことに業務分析にも使える。いままでは勘と経験で文書化してたのに。かといって、それをそのままプログラムに適用するのは危険でしょう。 プログラムの設計図としての UML はまた別に起こすべきじゃないですかね。こっちは純粋に RAD ツールとして。 業務そのものがプログラムと一対一対応できるぐらいに単純化/システム化されてるならそのまま適用してもよいと思うのですが、そういう業務はそもそもすでにパッケージ化されているのではないでしょうか。 | ||||||||||||||||
|
投稿日時: 2002-06-02 15:19
UMLに限らないんですが、UMLのスレッドなのでUMLで書きますが、
ちょっと、現実世界で疑問に思うところがあるのですが。。。 実際に、病院のシステムなどを年単位で再構築しているところなどを見ていると、 まず、最小限のイントラネットを作り直す。 そして、テストをし、結果を待つ。 で、最初に戻って改良する。 それから、別の部署のシステムを分析し、テストの終わったイントラネットに 合わせる形で、再構築する。 で、テストして結果を待つ。 問題が無ければそのまま次へ進む。 改良した方がいいところが見つかると、 その部署内のみの問題か？ 最初の段階の設計に問題が無かったか？ 見直す。 この段階で全体像を考える。 それから、最初に戻って、０から再テスト、再構築する。 それで、上記２つのテストがほぼ大丈夫となった時点で、 次の部署に移る。 今度は、そこの部署で問題が無いか？ テストする。 問題が無ければ他の部署へ。 問題があったら、段階を追って、２番目の部署、最初の構築、 全体構造の把握、 これを繰り返し繰り返し、最終構築をする。 何度も何度も、テストにテストの繰り返しで、全体像が決まっていても、 要求仕様が変化していく、 この期間が長くなればなるほど、技術も進歩するので、 繰り返し作業になる。 最終目的が途中で変わったりする。 全体像も当初とは全く違った物になったりする。 この繰り返しで、1年から2年単位で、完成を目指す。 これ、現実の病院で行われているようなんですが？ 通常の企業の業務とかなり違うところがあるのは分かっています。 １つの間違えが、人間の生死に関わるか関わらないか？ この時点で、通常の企業の業務とは分かれるとは思うんですが、 ただ、１つ、可能な限り完全性を求める。 これは、予算や期間の問題もありますが、 変わらないと思うんです。 UMLの段階からいきなり落とした場合、どの程度の完全性がテスト段階で 期待出来るんでしょう？ こういう観点から見ると、objectさんの書かれた内容とふうすけさんの書かれた 内容をある程度、型に当てはめないで、両方の考え方を、ある程度 融合することは、不可能なんでしょうか？ UMLを無視するのは今の時代、後戻りでおかしいですし、 かといって、UMLに全てを求めるのは、人間が完成物を使う限り、 問題が起きる可能性もあると思うんですが？ なので、UMLと、ソースの間に、ワンクッション何かが必要なんじゃないでしょうか？ この何かが、私の勉強不足で考え付かないんですが。。。 | ||||||||||||||||
|
投稿日時: 2002-06-02 15:22
言葉を誤解してるかも知れませんが、私は実装レベルの問題ではなくて、ＵＭＬ中のクラス図と、今の言語で記述出来るクラス定義間の「１ｔｏ１マッピング」のレベルで話しました。
今のUMLツールも、理想はそうだと思います。 でも、ツールが実用される上で大切なのは、先ず実際に使ってる人の邪魔にならない事だと思います。 だから、私は現在の言語のレベルでクラスを完全にサポートし、その他コラボレーションは、あくまで図としてサポートするのが実際的だと思っています。
これは、幸運じゃなくて、出来るべくして、出来てると私は思います。 「UML はまた別に起こすべき」というのは、恐らく見解の相違で、絶対にどちらかでなければならないという事ではないと思います。 それに、別のRADツールとして実現するにしても、クラス・コンポーネント間で、UMLレベルの対話が必要になると私は思っています。
この、一対一対応は、本来一番大切なものじゃないでしょうか？ ドメインとコドメインがある種の同型関係を持つ事は、最も大切だと思います。 だからこそ、実際に使えるという事になると思いますよ。 現在あるパッケージが完全だと思いませんし、少しでも良くしたいという気持ちが大切なんだと思います。 それに、私はＵＭＬをインフラとして考えたいですね。 だから、当然出来る限り、開発者全員が使える、それを目指すべきだと思っています。 （特に価格的に！） | ||||||||||||||||
|
投稿日時: 2002-06-02 23:44
日曜日です。 
例の本を第２章まで読んでの今の考えですが、 （※他に体系立った本は一切読んでない状態ですが．．．）
このかえるさんの書き込みが「ビンゴ！」ですね。 勿論UMLを使うとしたら仕事で使うことになるので、一人では決められませんが、 ・今は一切使ってない −−＞ 使うと良い図を使う。 ・使うリスクがあるなら無理してまでは使わない。 ・当面ツールはVisioレベルでOK？ ・勉強会なり討論会を開く。 最初のステップはこんな感じですかね。 | ||||||||||||||||
|
投稿日時: 2002-06-03 10:29
ふうすけさんの書き込みでヘッダファイルへのドキュメンテーションについて触れられていますが、こんなことを考えています（ものになるかどうは不明です）．
どんなものでしょうか？ （現実的か、意味なさそうか、などのご意見があれば、お願いします） JavaやC#であれば、ドキュメンテーションコメントが作成できますから、 1.クラスの抽出が終了したら、設計の舞台はソースファイルへ移行する。 2.ひたすら、ドキュメンテーションを入れながらソースを作成する。 3.この時のメソッドの戻り値は、nullや0。というか、それ以外は記述しない。 4.もちろん、この時点で記述するのは、インターフェイスそのものであるpublicなものだけです。 5.UnitTestを作る。当然、すべてアサーションフェイルになるはず（0が返るべきならサクセスするけど） 6.で、ここまでのソースとUniteTestのソースを実装者に渡す。（第一次ドキュメント出力後） （実装詳細のドキュメンテーションが必要ならば、実装者がドキュメンテーションコメントに追加する：第二次ドキュメント出力） 7.したがって、UMLのクラス図には詳細は記述しない。 （継承関係については、UMLのクラス図がないとちょっと辛いので、必要だとは思います） 8.以降、すべてソースファイル（継承関係やクラスの追加、削除はUMLにも反映させる）で2.から7.でスパイラルさせます（7.の時点で、CVSやvssへコミットが1度入る） Visioだとメソッドの詳細にコードが記述できますが、エディターが使いにくいし、やはりソースはソースファイルに記述しないと、cvsやvssと適合しない気がします。というのもあって、UMLからのコード生成はあまり現時点では考慮せずに、ソース主義でいくのが良いかなと思っているわけですが。 | ||||||||||||||||
|
投稿日時: 2002-06-03 16:05
可能であればですけど、パッケージ作る時にはカスタマイズが楽でいいかもしれせんね。 | ||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。