@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- @IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
オブジェクト指向でオブジェクトの細分を表す言葉ありませんか
1
投稿者 | 投稿内容 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2006-03-19 17:51
みなさん,こんにちは.
早速ですが,言葉の定義についてご存じであれば教えてください. オブジェクト指向関連では,コンポーネント,サブシステム,クラス,オブジェクト,インスタンス,パッケージなどいくつもオブジェクトのまとまりを表す言葉がありますが,これをうまく体系立てて整理している定義をご存じありませんか. 設計はソフトウェアを分割してクラスにする作業と見た場合,
と細分にあった言葉を誰か定義してくれていないかなと期待しています. 設計をいくつかのステップに分ける場合,このような言葉があると考えやすいのになと思っています. | ||||||||||||
|
投稿日時: 2006-03-19 22:12
「コンポーネント」「パッケージ」はオブジェクト指向と無関係です。 (どちらかというと相反する概念だと思いますが。言いすぎ?) 「パッケージ」というのはJavaの言語仕様の一部に出てくるだけで、 オブジェクト指向とは関係ないと思います。 サブシステムはオブジェクト指向とは、あまり関連しない気がします。
ということで、そもそも相反してたり関係ない概念なので、体系化できないと思いますが。
「分ける」ということ自体が「設計」ですからねぃ。。なにをもって 「一まとまり」と呼ぶかは、どうしても何らかの意味合いが入ってしまうのでは。 ということでそれらはドメインとして定義するしかないのかもしれない、と思って ますが。。。 そもそも「オブジェクト分析」ですら、真っ当にやったことがない私が言うのも なんですが。。 | ||||||||||||
|
投稿日時: 2006-03-20 00:53
だったら、「メンバ」という実装レベルの単位しか思い浮かびません。 データではなく振る舞いであれば、さらにローカルな部位があると... ただ、
インスタンスとオブジェクトは良いですが、(でも、何でここに「オブジェクト」が?) 他の説明になり得ないので、「メンバ」はありえないですね。 _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||||||
|
投稿日時: 2007-01-23 16:29
個人的には、「オブジェクト」と「クラス」は粒度が同じで、これが最小単位だと思いますね(「メンバ」まで細分化すると、また観点が違ってくる)。
「オブジェクト」と「インスタンス」は同じものなので、これも同じ粒度。 一番粗いのがシステムで、その下がサブシステム。 ここまでは手法がオブジェクト指向だろうがそうでなかろうが一緒だと思います。 コンポーネントというのも、場合によっていろいろな意味に解釈できる言葉でしょうが、俺はサブシステムを構成するのがコンポーネントだと思っています。 セットで使うことを前提に設計されているオブジェクトを集めたものがコンポーネントという認識です。 Javaやったことないので、パッケージという言葉は使いません(Delphiもパッケージって言うんだっけ?)。 もう少し大きい単位になると、アセンブリとかアプリケーションとかいう言葉も使えるかもしれませんね。 #アセンブリはコンポーネントより細かいかなぁ。 例えば、市販製品である「FlexGrid」とか「TabPlus」とかは、「アプリケーション」と呼ぶのが適当だと思います。 | ||||||||||||
|
投稿日時: 2007-01-23 16:45
るぱんです。
→UMLで出てきた用語って事でいいですか? http://www.ogis-ri.co.jp/otc/hiroba/technical/JavaWorld_UML/chap2/index.html 大分類の10番目に 10. パッケージ って項目があります たたき台
[ メッセージ編集済み 編集者: るぱん 編集日時 2007-01-23 16:49 ] | ||||||||||||
|
投稿日時: 2007-01-23 19:25
Javaのパッケージに相当する概念を言うとすれば
「ネームスペース」日本語だと「名前空間」でしょうか。 C系とかXMLとかでは「ネームスペース」を使っていますよね。 こっちが多数派だと思っています。 「クラス」は型で「インスタンス」はその実態ですが、 「オブジェクト」と言った場合は曖昧に両方の意味で使われますね。 コンポーネントは部品のイメージ。 機能でのまとまりなので、実装のまとまりであるクラスが 複数集まって成している場合が多いのではないでしょうか。 クラスが実装のための単位なのに対して、コンポーネントは 機能を成す部品の単位と捕らえています。 (加納正和さんと認識が違うのが気になるところですが…) サブシステムという場合、アプリケーションの一つの機能を指します。 この用語はオブジェクト指向用語ではなく、もっと汎用な用語ですよね。
この認識が私とは違いますね。 設計は機能を実現するための方法論を決定する過程のように思っています。 データフローを中心に据えることが多いかな。 クラスがどうこう、なんてのは実装の際の方法論ですから いちいち設計しないですね。コードに書く際にその場で作ってます。 実装方法が悪ければリファクタリングしたりしますから、 コードのロジックを修正するのと同じような感覚でクラスを 作ったり消したりしていますね。 クラスの設計ってプログラムを組む前にフローチャートを 書くようなイメージだなぁ。納品物になってないなら書かないですね。 クラスの機能性はソース中にコメントで記述してツールでドキュメント生成だし。 | ||||||||||||
|
投稿日時: 2007-01-24 17:44
この部分に関しては大筋でシャノンさんやるぱんさんの意見辺りを参考にオブジェクト指向本やアーキテクチャ関連本を読まれると良いと思いますが
ユースケースやクラス図みたいなダイアグラム(UMLを使用しているといっている訳ではない。あくまで私のイメージ)を使用して、まずは大雑把な機能を洗い出し、更にそれぞれの機能を同じフォーマットのダイアグラムで詳細化していくようなことを言ってます?そこでそれぞれの粒度に名称が無いかと? だとすれば、無いと思いますよ。というか、粒度自体は最初のアーキテクチャ設計の段階で決めてしまうと思うので、各粒度の名称もひとえにアーキテクトのセンス次第かと… # ネーミングセンスが無いのなら、似たような規模のプロジェクトを参考にするとか。 | ||||||||||||
|
投稿日時: 2007-01-24 23:32
るぱんです。
どのシチュエーションで、どの単語を意図的に使えるかどうかだと思います。 粒度の大きな枠組みは、要件に近いところで使う言葉です。 粒度の細かい言葉は、細かい設計をする際に使う言葉です。 要件定義でインスタンスが・・・とか言われても、 「はぁ?」 ってなるでしょう? 単語を知るのは良いことですが、 当初の設問では、システム開発の流れを意識できていないと思いました。 個人的には、この「流れ」(my単語で失礼)こそが大事で、 そこを抑えない限り、どんな単語も有機的につながらないと思います。 システム開発の全体像の方が大事だと思います。 ご参考までに。 |
1