- ベストアンサー
クラスの動的な関係を表すのはシーケンス図ですか？
オブジェクト指向実装において、クラス間の静的な関係を表現するにはクラス図を用いて 動的な関係を表現するにはシーケンス図を用いるのでしょうか？ 下記例のような内容をドキュメントで表現したいのですが何を用いればよいのか分かりません。 どうぞご意見ください。 【例】 あるイベントが発生した時に、クラスＡのメソッドＡ１からクラスＢのメソッドＢ１を呼び出し Ｂ１である処理をした結果をメソッドＡ１が受け取り、Ａ１がその結果に応じた処理を行う。 などを図として表現したいです。 以上、よろしくお願いします。
- regarega
- お礼率50% (31/62)
- その他（プログラミング・開発）
- 回答数1
- ありがとう数0
- みんなの回答 （1）
- 専門家の回答
質問者が選んだベストアンサー
特集：前編 モデリング言語「UML」を学ぼう (1/2) http://www.itmedia.co.jp/enterprise/0402/16/epn01.html [相互作用図] - [シーケンス図] - [コミュニケーション図] なるほどね、勉強になった！ クラス図はアレルギー反応だけど、この辺りなら少しはなじめそう。 トランザクションを記述するなら、シーケンス図で、 オブジェクトの相互作用を記述すなら、コミュニケション図かぁ。 コミュニケーション図は分散オブジェクトの相互作用を表現するのによさそう。 質問の記述ならシーケンス図かな？ 処理の流れを表現したいんだから。 「クラスの動的な関係」っていうと何だか、クラスの関係がダイナミックに変形するみたいできもちわるいね。
関連するQ&A
- サーブレットのクラス図について。
サーブレットを勉強しています。同時にモデリングも勉強したいと思っています。 サーブレットで、例えば、 login1.jsp（htmlのログインのフォーム） login2.jsp（IDとパスワード送信後のページ。ログイン成功、失敗を表示する） ConnectionManager.java（DBとの接続を担当） user.java（ユーザオブジェクト。オブジェクトをセッションにおく） というファイルたちで、ログインの処理を実装したのですが、これらをクラス図で表現するとどんな感じになるのでしょうか？ そもそもこういった処理はクラス図にはしないものなのでしょうか？（user.javaだけクラス図に書くとか…。よく分かりませんが。） 参考文献や参考URLだけでも結構です。 よろしくお願いします。
- 締切済み
- Java
- 【C#】フォームクラスと他クラスとの連携について
C#を勉強し始めたばかりの者です。 オブジェクト指向言語が初めてなので、オブジェクト指向的考え方が出来てないゆえの質問だとは思うのですが・・・。 質問内容ですが、フォームクラスと他のクラスとの連携方法がわかりません。 具体的に言いますと、フォームクラスで別のAというクラスを宣言し、そのクラスのB()メソッドを実行したときに中で発生した例外メッセージをフォームのコントロールで表示したい、という場合、どうすればよいのでしょうか？ Doメソッドで例外メッセージをstringとして返し、それをフォームクラスの方で処理するしかないのでしょうか？ お知恵を貸してください。よろしくお願いします。
- ベストアンサー
- C・C++・C#
- UML(シーケンス図)の質問
お世話になっていますm(__m) シーケンス図の勉強をしていてどうにも納得がいかない点を質問させてください。 いろいろ調べてみたのですが納得がいかず・・・ 処理フロー：メインから、時計クラスの時間を取得 例えば上記のような処理フローの場合、 添付ファイルの左枠（当方のシーケンス図）のようになると思っています。 ですが、教本やネットで検索すると、 生成を行わず、クラスのライフラインに直接関数を呼び出ししています。 添付ファイルの右枠（ネットのシーケンス図） staticクラスでない限り、 呼出し元でオブジェクトの生成をしてから、関数を実行すると思っているのですが、 「：時計クラス」のライフラインはどういう意味合いなのでしょうか。 おバカですみません、、、 どうかご解答よろしくお願いいたします。
- 締切済み
- Java
- JAVAのクラスの考え方は・・？
JAVAの勉強をしていている学生です。 常々思っていたのですが、クラスの考え方がしっくりきてませんヽ(~-~ よく参考書などで書かれていることで 「クラスは設計図のようなもの、オブジェクトはそこから作成した実体」 「鋳型がクラスでどんどん作れるのがインスタンス」 といった話が疑問でならないのです。 というのも・・クラスの設計って、自分自身をフィールドに宣言したりできますよね。。 でそこから生成して、また自分自身のフィールドに生成して・・とか。 インターフェースを実装したクラスで、、、内部クラスを持ったクラスで、、、ジェネリッククラス、、。 となってくると、最初の考え方では、論理的に無理？私の脳内では変換しきれないです(´；ω；) 多分前提となる考え方が間違っていたり、私の想像力が乏しいだけだと思います。 どなたか、「クラスってこう考えればオブジェクト指向が見えてくる」と表現している本やサイトなどご存じないでしょうか。 一朝一夕で理解しようとは思っていませんので、きちんと参考にして理解しようと頑張ります！ 「私的には・・」や「あなたが勘違いしている箇所は・・」といったご意見もぜひお聞きしたいです！ クラスかオブジェクト指向かどっちかというより、クラスありきでJAVAのオブジェクト指向が本当に理解できると考えています。参考書やWEBを探してみた限りではやっぱり理解できないです(´；ω；) ちなみにC言語を中学生で始め、プログラミングに触れました。
- 締切済み
- Java
- クラス図→ソース
くだらない質問かもしれませんが・・・ まず特急列車などの指定席の予約などを行う簡易プログラムを作りたい時に、 例えば、 ◇-- は集約の関連 を表すとして、 受付 ◇-- 時刻表 ◇-- 列車 という部分を持つクラス図を作ったとします。時刻表は列車の発車時刻などが書かれています。（例えばなので、これは集約にすべきじゃない！とかは無しの方向で） これをソースに書き出してやる際に、 受付クラスは フィールドとして時刻表への参照配列をもち、時刻表クラスはフィールドとして列車への参照配列をもつとします。 時刻表 timetable[]; 列車 train[] それで、列車にあるメソッド(hogehoge())を受付のあるメソッドで使いたいというときに、おそらく、 this.timetable[x].train[y].hogehoge(); としますよね。 でも、複雑なクラス図になっていくにつれてもし使いたい場所とメソッドとの間が激しく離れている場合は、 aaa.bbb.ccc.ddd.eee.….zzz(); とかなっちゃいますよね。そうならないように設計しろと言われればそれまでなのですが、実際にクラス図→ソースの段階でこういうこと（設計ミス？）が起きてしまうことってよくあるのでしょうか？ また、この例であれば時刻表クラスに列車オブジェクトを取り出すような Train getTrain() とかいうメソッドを用意し、受付クラス中のメソッドで、 Train t = timetable.getTrain(); t.hogehoge(); 等する方が一般的でしょうか？なにやらうまく説明できないですが、不明な点があればご指摘ください。
- ベストアンサー
- Java
- オブジェクト指向とUMLについて
「オブジェクト指向」と「UML」の勉強をしようと思っているのですが、お勧めの参考書またはWebサイトをお教えていただきたいです。 ※オブジェクト指向については、JavaやC++のような言語についてではなく、オブジェクト指向についてです。 ちなみに私はJavaは経験したことがありますが、正直"オブジェクト指向がなんたるか"はわかっていないです… 現在業務でJavaに携わっていてるので、オブジェクト指向という考え方をこの機にしっかりと学べればと思っています。 UMLはまったく無知です； クラス図やシーケンス図など中身にナニがあるか微妙に知っているだけです…； どちらか片方でも良いので何かございましたら、お教え願います。 …参考書だと電車で読めるので、ちょっとだけ喜びます(笑
- ベストアンサー
- その他([技術者向] コンピューター)
- 使えるメソッドはクラスで予め指定されている？
javaを始めたばかりでまだ右も左も分からないのですが、 (オブジェクトは作成してみましたが、クラス自体は作ったことがありません。) 例えば、Aというオブジェクトを作る為に、Bというクラスを使ったとします。 この際、使用できるメソッドというのは、クラスで予め定義されているものが使えるのでしょうか？ それとも、クラスとオブジェクトというのは、全く切り離されたもので、 メソッドはjavaの世界で予め用意され、どんなオブジェクトを作成する時にも全て使用出来るものなのでしょうか？ 教えてください！！
- ベストアンサー
- Java
- オブジェクト指向に関して。
Javaの解説本を読んでオブジェクト指向プログラミングという物があることをしりました。その本には「オブジェクトはデータとそのデータを扱うための機能を持っている。この機能はメソッドと呼ぶ。クラスは設計図のような物で変数とメソッドから構成されている。設計図を実際に形にした物がインスタンスである。」と書いてありました。私はオブジェクト＝クラスのような感じがしたのですが、実際のところオブジェクト＝クラスでいいのでしょうか？ また、友人に話したところ、オブジェクト指向はサブルーチンに似ているといっていました。私はプログラミングの知識が全くないのでサブルーチンという物が何なのかわからないのですが、サブルーチンとオブジェクト指向の考え方は違うような気がするのです。友人に説明して納得させるにはどうしたら良いのでしょうか? ぜひ、力を課してください。
- 締切済み
- その他（プログラミング・開発）
- 継承・実装の関係で悩んでいます。
継承・実装の関係について悩んでいます。 ここでは、アクセス制御を考えずに、インスタンスかstaticかabstract(ここではabstract final staticやabstract classのこと)の違いで、どう継承するのか考えています。 // 継承 はメソッドのオーバーライドのことを考えます。(オーバーロードは考えない) クラスAからクラスBでオーバーライドしたメソッドは、 クラスCでさらにオーバーライドできるのでしょうか？ クラスCが クラスBのクラスAからオーバーライドしたメソッド をクラスBのメソッドとして見たときに、オーバーライドすることは可能なのでしょうか？ クラスA │ インスタンスフィールドA │ staticフィールドA │ │ クラスA() { } │ │ インスタンスメソッドA () { } │ staticメソッドB() { } ↓ クラスB extends クラスA │ インスタンスフィールドA // 継承 │ インスタンスフィールドB │ staticフィールドB │ │ サブクラス1() { } // コンストラクタは継承しない、super()で呼び出す │ │ インスタンスメソッドA () { } // 継承 │ │ インスタンスメソッドB () { } │ staticメソッドB () { } ↓ クラスC extends クラスB implements インタフェースD, ... ↑ インスタンスフィールドA // クラスBのフィールドを継承 │ インスタンスフィールドB // クラスBのフィールドを継承 │ インスタンスフィールドC │ staticフィールドC │ │ サブクラス2() { } │ │ インスタンスメソッドA () ｛ ｝ // クラスBのメソッドを継承 │ インスタンスメソッドB () { } // クラスBのメソッドを継承 │ インスタンスメソッドD () { } // インタフェースDのメソッドを実装 │ インスタンスメソッドE () { } // インタフェースDのメソッドを実装 │ │ │ インスタンスメソッドC () { } │ staticメソッドC() { } │ interface インタフェースD extends インタフェースE ↑ │ staticフィールドD // public static final │ │ インスタンスメソッドD() { } // public abstract │ インスタンスメソッドE() { } // 継承 │ interface インタフェースE staticフィールドE // public static final インスタンスメソッドE() { } // public abstract
- ベストアンサー
- Java
- オブジェクト指向の間違いと改善案について
オブジェクト指向というより オブジェクト指向プログラミングについての間違いと改善案をブログに書いてみました。 http://chaosblogchaos.blog.fc2.com/?no=2 この考え方に間違いがあるでしょうか？ 説明不足の点はないでしょうか？ よろしくお願いします。 以下ブログの内容 ---------- ■カオス指向（仮） カオス指向（仮）とは、オブジェクトに処理を追加・削除することでオブジェクトの振る舞いに無限性を持たせる試みです。 カオス指向（仮）ではデータが主体となり、木構造で保持します。 （ファイルフォルダで例えると、フォルダがオブジェクト、ファイルがプロパティに当たるイメージです） 処理を追加・削除が可能なことからプロトタイプベースがもっとも近いですが、 オブジェクトが親子関係を持つことと オブジェクトの親子関係から処理が影響を受ける事が異なります。 ●オブジェクトの内容 ・配列か連想配列で子オブジェクトを保持できます。 オブジェクトどうしの強い関係を意味し、親が削除される場合、子も削除される関係にあります。 オブジェクトはルートからの木構造の中に必ず存在する事になります。 ・別途、変数領域を確保する。 処理で使用する値を保持します。 オブジェクトどうしの弱い関係を保持できます。 ・処理を持つ。 オブジェクトに処理を持たせることができるます。 プロトタイプベースと異なる点は、 オブジェクトが処理を持っていても、オブジェクトがその処理をするわけでは無く、自身と子オブジェクトに対して適用され、”認識タイプ”を持つ場合に処理します。 ・”認識タイプ”を持つ。 処理の実行を制御します。認識タイプを含むかどうかで処理を行うかどうかを決定します。 オブジェクトのクラスは”認識タイプ”で実現可能と考えて問題ありません。 ●”認識タイプ” オブジェクト指向なら、 人は歩く、話す、・・・。Aさんは人。Aさんは話す。 カオス指向なら、 歩けるなら歩く、話せるなら話す、・・・。Aさんは歩ける、話せる、・・・。Aさんは話す。（歩ける・話せるを認識するようにした場合） 人は歩く、人は話す、・・・。Aさんは人。Aさんは話す。（人を認識するようにした場合） のどちらでも作成が可能で、 話せるなら話す、・・・。の場合、ウサギAの”認識タイプ”に話せるを追加することで、ウサギAは話せるようになります。 話せるウサギは実用的ではありませんが、 特定ユーザーのアクセスログだけ出力したい場合は、 処理を用意し、対象ユーザーに”認識タイプ”を追加することでログ出力処理を追加することが出来ます。 ●木構造と処理 ユーザー 日本 Aさん Bさん アメリカ Cさん とある場合、 全ユーザーの処理をユーザーに保持 日本用の処理がある場合、日本に アメリカ用の処理がある場合、アメリカに処理を追加します。 そうすることでAさんは日本の処理、Cさんはアメリカの処理が行われます。 ●同一処理による関係 処理には優先順位が存在し、その順番で処理します。 処理A、処理Bとある場合、処理Aの中で元処理として実行します。 処理Aの中で元処理を行わない場合、処理Bは行われません。 ■カオス指向（仮）でどうなるか？ ・幾つかのデザインパターンが不要になります。 デコレータ・コンポジット・ステートパターン等 ・多重継承らしきものが出来るようになります。 ※根本から違うので、多重継承らしきものとします。 ・循環問題が発生しませんない ファイルフォルダのような木構造では循環は起こりえない。 ■オブジェクト指向プログラミングの問題点 オブジェクトにつき１クラスという決め付けが オブジェクト指向プログラミングにはあったのではないかと考えております。 オブジェクト指向では、 オブジェクト：クラス：継承クラスは1:1:1で、1:1:*は条件により可能ですが原則不可能。 カオス指向では、 オブジェクト：クラスは1:*と頭からクラスを複数持たせることで多重継承らしき形が実現可能ということです。 クラスの継承がなくなっていますが、クラスを複数持たせる事とクラスに順番を持たせることで継承が可能です。 オブジェクト指向プログラミングでは、オブジェクトにつき１クラスという決め付けが継承というシステムを作り 多重継承を難しくしたのではないかと考えております。
- 締切済み
- その他([技術者向] コンピューター)
