C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[43]: オブジェクト指向熱イベントパネルディスカッション検討スレッド [1]


(過去ログ 23 を表示中)

[トピック内 82 記事 (21 - 40 表示)]  << 0 | 1 | 2 | 3 | 4 >>

■9954 / inTopicNo.21)  Re[16]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
  
□投稿者/ ひろえむ (46回)-(2007/11/07(Wed) 23:46:42)
ひろえむ さんの Web サイト
2007/11/07(Wed) 23:47:57 編集(投稿者)

#nagiseさん

>1. パネラーにオブジェクト指向の説明を試みてもらう
>2. リスナーにどの説明のしかたが分かりやすかったか、挙手してもらう。
>3. そして、どういう点が分かりやすかった/分かりにくかった、どう説明したらよいのかを議論する

んー、むしろライトニングトークの形式でオブジェクト指向について話してもらうっていうのもおもしろいかもですねー。
これはこれでもおもしろい気がしますねー。

ただ、パネルディスカッションをするのであれば、どちらかというと、あるテーマについてディスカッションするという形態になるかなーと思っています(^^;

まぁ、どちらをやってもおもしろそうな気がしますo(^^)o

#がるさん

> がると申します。お初の方、はじめまして。
>今回、勉強会にうかがえそうなのでちと書き込みなど。

こちらこそ、当日よろしくお願いしますー(^^)

>OOについて、最近(…でもないのですが割合昔からなので)よく見るのが

貴重なご意見ありがとうございます。 そうですねー。 できるだけこのあたりについて触れることができるように頑張ります(^^)

#片桐さん

>ばりばりのCOBOLERでANSI-C派C++ぎりぎり擁護であり、どちらかといえばアンチC#(あえて書きますけど)な私としては(笑)

ほう。
このあたりの理由をちょっとお聞かせいただきたいですねー。 非常に興味あります(^o^)

#R・田中一郎 さん

> こういう欠点があるじゃないかと誰かが言ったら、それはこうすればいいんだよ、と誰かが返す。
> そんなやり取りもありがたいです(ありがたいってどういう意味だ?w)

んー、というか私がイメージしているのは、きちんと欠点を押さえて適用のしどころを判断できるようにするっていう感じじゃないのかなーと(^^;

いろいろとおもしろい意見も出てきていますので、週末あたりちょっと1度とりまとめてエントリにあげてみますね。

もちろん、引き続きご意見や前に出て話すぞー!って方も募集中ですのでよろしくお願いしますーm(__)m
引用返信 編集キー/
■9959 / inTopicNo.22)  Re[14]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ 渋木宏明(ひどり) (518回)-(2007/11/08(Thu) 02:24:30)
渋木宏明(ひどり) さんの Web サイト
> ・「オブジェクト指向プログラミング」と「オブジェクト指向設計」、好きな書籍の言葉を借りるなら「オブジェクト指向ソフトウェア工学」あたりの区別がついていない。
>  もっと具体的には「プログラミングレベル」と「設計レベル」の話の分離がしにくい。

ですねぇ。

クラスなんて、「プログラミング言語でオブジェクト指向を実践するための方法の一つ」でしかないはずなのに、「クラス=オブジェクト指向」みたいな説明が氾濫していて、どこからが「オブジェクト指向」でどこまでが「プログラミング言語の機能」なのかが非常に分かりづらくなっていると思います。

引用返信 編集キー/
■9960 / inTopicNo.23)  Re[16]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ 渋木宏明(ひどり) (519回)-(2007/11/08(Thu) 02:26:14)
渋木宏明(ひどり) さんの Web サイト
> こういう欠点があるじゃないかと誰かが言ったら、それはこうすればいいんだよ、と誰かが返す。
> そんなやり取りもありがたいです(ありがたいってどういう意味だ?w)

僕が「欠点」と思ってるコトには、明確な解決策がないはずなんですよね (^^;

引用返信 編集キー/
■9968 / inTopicNo.24)  Re[15]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ えムナウ (93回)-(2007/11/08(Thu) 10:35:47)
とりあえず挙手。

欠点:
ハードウェアやファームウェアの設計に使えない。
同様にマルチコア・マルチスレッドの時代に対応できない。
http://blogs.wankuma.com/mnow/archive/2007/11/01/105312.aspx

引用返信 編集キー/
■10001 / inTopicNo.25)  Re[15]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ がる (2回)-(2007/11/09(Fri) 00:31:30)
がるです。

To ひどりさん
> クラスなんて、「プログラミング言語でオブジェクト指向を実践するための方法の一つ」でしかないはずなのに、「クラス=オブジェクト指向」みたいな説明が氾濫していて、どこからが「オブジェクト指向」でどこまでが「プログラミング言語の機能」なのかが非常に分かりづらくなっていると思います。
同意します。
しかも「クラス=オブジェクト指向」な割に「メッセージパッシングがOOの基本」みたいな、それはそれは「ずれた」話が多いので。初心者ならずとも混乱すること頻り、です(苦笑
挙げ句、プログラムとは関係ない、車クラスは四輪と二輪があってほ乳類クラスの継承で犬インスタンスはワンとかネコインスタンスはニャーとか。
…どーやってプログラムにするんだろう、と、ずいぶん疑問に思ったモノです。
# …でまぁ「オブジェクト指向実用講座」とかいう駄文を書くに至ったわけなのですが(苦笑

あと、欠点で、おいらも挙手。
・メモリ食い過ぎ
・動的に処理するから処理重すぎ
比較対象:カリッカリにチューニングした、Cで書いたソース(苦笑
# まじめな話。組み込み系だと割合に切実だと耳にします。

雑談混じりで恐縮ですが。
引用返信 編集キー/
■10008 / inTopicNo.26)  Re[16]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ 渋木宏明(ひどり) (521回)-(2007/11/09(Fri) 09:19:44)
渋木宏明(ひどり) さんの Web サイト
2007/11/09(Fri) 09:43:19 編集(投稿者)

> しかも「クラス=オブジェクト指向」な割に「メッセージパッシングがOOの基本」みたいな、それはそれは「ずれた」話が多いので。初心者ならずとも混乱すること頻り、です(苦笑

「方法論」と「実現・実装手法」を同等レベルで語っちゃってるパターンですね。

まぁ、処理系が決まれば「実現・実装手法」の大枠も決まるわけで、方向的にはそれほど間違ってないと思いますけど、「どこからどこまでがナニ」なのかをきちんと説明しておかないと、その後の学習や別の処理系を使う時なんかに大きな混乱を生じてしまいますね。

> 挙げ句、プログラムとは関係ない、車クラスは四輪と二輪があってほ乳類クラスの継承で犬インスタンスはワンとかネコインスタンスはニャーとか。
> …どーやってプログラムにするんだろう、と、ずいぶん疑問に思ったモノです。

よくあるパターンですが、「雰囲気をつかむため」程度にしか使えない例え話だと思います。

日曜大工的なプログラミングにはそれで足りることもあるかもしれませんが、そこから「業務システム(≠プログラム)を構築する場合の工学的な手法」に至るまでには大きな隔たりがあると思います。

で、この「大きな隔たり」を埋めるための具体的な手法や方法論について言及してないところが「オブジェクト指向」の欠点というか弱点だと思うんですよね。

「オブジェクト指向」の適用や運用の成果が、あまりにも「オブジェクト指向」を実践する個人のスキルに左右されすぎてしまうのがマズいと思います。

> あと、欠点で、おいらも挙手。
> ・メモリ食い過ぎ
> ・動的に処理するから処理重すぎ

ここいら辺はトレードオフの領域じゃないすかね。

> 比較対象:カリッカリにチューニングした、Cで書いたソース(苦笑
> # まじめな話。組み込み系だと割合に切実だと耳にします。

切実ではありますが、いわゆる「組み込み」でもカーナビやケータイの世界はそうも言ってられなくなってきてますね。
引用返信 編集キー/
■10009 / inTopicNo.27)  Re[16]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ 渋木宏明(ひどり) (522回)-(2007/11/09(Fri) 09:37:50)
渋木宏明(ひどり) さんの Web サイト
> ハードウェアやファームウェアの設計に使えない。

ハードウェアはもともと「現実のオブジェクト」を相手に設計するもんだと思うので、オブジェクト指向が「使える」「使えない」以前の問題かと。

「目に見えないもの=ソフトウェア」を「「現実にそこにあるモノ」と同様のくくりで捉える」のがオブジェクト指向の本質なんじゃないスカ?

あと、ファームウェアに「使えない」ことはないと思います。

「使える」なら、一定の効果は出ると思いますよ。

ただし、別の投稿でも書いていますが、オブジェクト指向を実践するためには比較的大量の資源が必要です。

ファーム系はPCと比較して利用可能な資源が比較的少ないため、オブジェクト指向を実践するのが難しい状況にある、とみるべきでしょう。

> 同様にマルチコア・マルチスレッドの時代に対応できない。
> http://blogs.wankuma.com/mnow/archive/2007/11/01/105312.aspx

これも、オブジェクト指向「が」どうこう言う問題ではないと思います。

オブジェクト指向という「方法論」と、クラスやら文法どうこう言う「実装・実現手法」をごっちゃに捉えるからそういう見方になるんじゃないでしょうか。

個人的には、単純に、オブジェクト指向的な設計をマルチコアやマルチスレッドという実行環境を活かした実装にマッピングするための手法やツールがまだ未発達なだけ、だと思います。

さらに言えば、マルチコアやらマルチスレッドなんてのは所詮「実行環境」の話であって、設計時にそんなことまで意識しないで設計できるのが理想的だと思います。

ブログや VSUG news letter なんかでも取りあげましたが、TPL (Task Pallale Library) なんかは、その基盤を目指してるんじゃないかなーと。

引用返信 編集キー/
■10010 / inTopicNo.28)  Re[17]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ 凪瀬 (1回)-(2007/11/09(Fri) 10:21:35)
凪瀬 さんの Web サイト
並列処理は別次元のパラダイムですよねぇ。

ジェネリクス指向でもアスペクト指向でも並列処理には対処できない。
オブジェクト指向だけが対処できない弱点というわけでなく、
単に並列処理に対するうまい方法論が存在していないという…
引用返信 編集キー/
■10018 / inTopicNo.29)  Re[17]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ がる (3回)-(2007/11/09(Fri) 12:37:32)
がる さんの Web サイト
がるです。
…すみません当日になる前にいい感じで食いついてます(笑
# だって面白いんですものw

> 「どこからどこまでがナニ」なのかをきちんと説明しておかないと、その後の学習や別の処理系を使う時なんかに大きな混乱を生じてしまいますね。
ですねぇ。この辺をあいまいにするから、他プラットフォーム、他言語とかに行ったときにつぶしが利きにくくなるんですよね。



トレードオフについては私もそう思うです。より厳密には「オブジェクト指向プログラミングにするかしないかのトレードオフ」で。
実際、ゲーム屋さんと話しをして思うのが「ああこの人たち肌でオブジェクト指向な設計してるんだなぁ」って思うです。で、設計はOOだけど、実装はメモリ効率重視のベタ、って感じで。
…その辺をうまく取り上げられると「オブジェクト指向 〜設計と実装の違い〜」が表現できるのかなぁ? と今思ってみました。

> 切実ではありますが、いわゆる「組み込み」でもカーナビやケータイの世界はそうも言ってられなくなってきてますね。
みたいですねぇ。あまりその辺の現場は詳しくないのですが…まぁいわゆる「悲鳴」を聞くだに「OOにすれば…」とか思ってしまいます。
あと、耳にするのが「オンラインゲーム」。今までと違って「保守メンテ」が発生するので、オブジェクトだったり保守性考えたり、という「従来の或いは旧来のゲーム屋さんの作り方」とはずいぶん違ってるとか。

………というこゆい話が当日できるのを楽しみにしております ^^
引用返信 編集キー/
■10019 / inTopicNo.30)  Re[18]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ 渋木宏明(ひどり) (523回)-(2007/11/09(Fri) 13:33:58)
渋木宏明(ひどり) さんの Web サイト
> 実際、ゲーム屋さんと話しをして思うのが「ああこの人たち肌でオブジェクト指向な設計してるんだなぁ」って思うです。で、設計はOOだけど、実装はメモリ効率重視のベタ、って感じで。

御意。

> …その辺をうまく取り上げられると「オブジェクト指向 〜設計と実装の違い〜」が表現できるのかなぁ? と今思ってみました。

アリですね。

> あと、耳にするのが「オンラインゲーム」。今までと違って「保守メンテ」が発生するので、オブジェクトだったり保守性考えたり、という「従来の或いは旧来のゲーム屋さんの作り方」とはずいぶん違ってるとか。

苦労してますね>知り合いのゲーム屋さんがw

某韓国系のベンダが自社ゲームから再利用可能なブツを抜き出して、フレームワークとして再販してたりもするらしいですけど、買ってきた「まんま」だと大したことは出来ないみたいです。

> ………というこゆい話が当日できるのを楽しみにしております ^^

来週末なんですよねぇ>熱
都合が微妙なんだけど、一応申し込んでおこうかなぁ。

欠席になってしまったらごめんなさい m(_ _)m>開催の人

引用返信 編集キー/
■10023 / inTopicNo.31)  Re[18]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ 渋木宏明(ひどり) (524回)-(2007/11/09(Fri) 16:07:21)
渋木宏明(ひどり) さんの Web サイト
> 単に並列処理に対するうまい方法論が存在していないという…

そうですね。

並列化を活用した実装を得るためには、まだまだ古典的なC標準ライブラリを扱うようなレベルでコードを記述しないと駄目なのが実情ですからねぇ。

もっと「並列化を活用するための環境」が整備されてくれば、他の手法やツールなんかとの連携もおのずと進歩してくるはずですが、まだ数年はかかるのかなぁ。


引用返信 編集キー/
■10029 / inTopicNo.32)  Re[18]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ がる (4回)-(2007/11/09(Fri) 17:18:49)
がる さんの Web サイト
がると申します。

> 並列処理は別次元のパラダイムですよねぇ。
んと…
http://ja.wikipedia.org/wiki/%E4%B8%A6%E5%88%97%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0
「コンピュータにおいて複数のプロセッサで1つのタスクを動作させること。問題を解く過程はより小さなタスクに分割できることが多い、という事実を利用して処理効率の向上を図る手法である。」
の並列処理、でOKでせうか?

上述条件がtrueと仮定して。
何に重点を置くかにもよると思うのですが、「1タスクを1インスタンス」とみなして、やり取りを「インタフェース」とみなすとすると、案外にオブジェクト指向設計はのるのかなぁと思ってるのですがどうでしょうか?

並列処理(…っていうかどうしてもあたまん中でgridコンピューティングになるのですが)って、少なくとも発想はものすごくおぶじぇくち〜な気が、個人的にはしてるです。
…でまぁいろいろ妄想を考えてたりするのですがw
ちと文章で書くの大変なんで、よかったら当日、直接「メッセージパッシング」してくださいw
九分九厘着物着てるので割合に見つけやすいほうかと思いますw
引用返信 編集キー/
■10030 / inTopicNo.33)  Re[19]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ 渋木宏明(ひどり) (525回)-(2007/11/09(Fri) 18:08:46)
渋木宏明(ひどり) さんの Web サイト
> 何に重点を置くかにもよると思うのですが、「1タスクを1インスタンス」とみなして、やり取りを「インタフェース」とみなすとすると、案外にオブジェクト指向設計はのるのかなぁと思ってるのですがどうでしょうか?

いやぁ、そう出来なくはないですが、「そうした方よい」理由はあまりないと思いますよ。
実行レベルでは実際には不利になってしまうパターンの方が多いんじゃないかと。

引用返信 編集キー/
■10035 / inTopicNo.34)  Re[19]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ 凪瀬 (2回)-(2007/11/09(Fri) 20:29:25)
1タスクってスレッドを意味していると思っていいのかな?
やりとりをインターフェースとしてくくりだしたところで同期できるわけでもないですし。

> 九分九厘着物着てるので
ほほう。私も対抗して和装していこうかな。
引用返信 編集キー/
■10036 / inTopicNo.35)  Re[20]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ Jitta on the way (34回)-(2007/11/09(Fri) 20:44:34)
いいなぁ
行きたいなぁ

来週末は息子の音楽会だわ(ノ_-;)
引用返信 編集キー/
■10039 / inTopicNo.36)  Re[21]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ ひろえむ (47回)-(2007/11/09(Fri) 21:30:36)
ひろえむ さんの Web サイト
あああ・・・もったいないもったいない

ここで議論しないでー。 オブ熱にもってきてー(^o^;;;
引用返信 編集キー/
■10043 / inTopicNo.37)  Re[22]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ えムナウ (94回)-(2007/11/10(Sat) 01:17:03)
>「並列化を活用するための環境」が整備されてくれば、他の手法やツールなんかとの連携もおのずと進歩してくるはず
ハードウェアに関してはASICとかでプログラム化されたものをよく目にします。
接点の動作とかステータスと置き換えてUML化するところも出てきているわけです。
ハードウェアは並列的に動作しますので並列化を活用するための環境が必須なわけです。
ファームウェアでも扱うのは対ハードウェアですので事情は同じです。

並列化を活用するための環境が整備されていないということは、
現在のUMLにおけるオブジェクト設計に環境面(図の拡張も含む)で不足している部分があるということでしょう。

>「1タスクを1インスタンス」とみなして、やり取りを「インタフェース」とみなすとすると、案外にオブジェクト指向設計はのるのかなぁと思ってるのですがどうでしょうか?
上記の話で納得いくでしょうか?
ハードウェア動作を記述するのに「インタフェース」とみなせるでしょうか?
マルチコアというのは別CPUですから複数のステータスが何の脈略もなく(規則はありますがあえてこう書きます)変更されるのですから、
ハードウェア動作と似た部分があると思いますがいかがでしょうか?

引用返信 編集キー/
■10046 / inTopicNo.38)  Re[23]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ 渋木宏明(ひどり) (526回)-(2007/11/10(Sat) 02:49:01)
渋木宏明(ひどり) さんの Web サイト
2007/11/10(Sat) 03:23:41 編集(投稿者)

> ハードウェアは並列的に動作しますので並列化を活用するための環境が必須なわけです。
> ファームウェアでも扱うのは対ハードウェアですので事情は同じです。

そうかな?

一般論として「並列的に動作するハードウェアを相手にするソフトウェアが並列化されていなければならない」とするのは、途中の議論を省きすぎだと思います。

結果的にそうなる or そうするのが適切な場合もあるでしょうし、そうしない方が適切、の両方があるはずです。

> 並列化を活用するための環境が整備されていないということは、
> 現在のUMLにおけるオブジェクト設計に環境面(図の拡張も含む)で不足している部分があるということでしょう。

UML = オブジェクト指向「ではない」し、UML は実装の詳細を記述するためのツールじゃないんで、そんなもんでしょう。

UML のレベルで「並列化」なんか意識した図を書かなくても、結果、目的の「処理」が並列実行さるような実装がどうにかして得られればオッケーってのが、元々の UML の立ち位置じゃないかと。

> >「1タスクを1インスタンス」とみなして、やり取りを「インタフェース」とみなすとすると、案外にオブジェクト指向設計はのるのかなぁと思ってるのですがどうでしょうか?
> 上記の話で納得いくでしょうか?

もう既に別投稿で書いたことですが、理論としてはYESです。

ですが、実装としてそれが望ましいかどうか、はまた別な話だと思います。

> ハードウェア動作を記述するのに「インタフェース」とみなせるでしょうか?

どういうスコープの話でしょう?

例えば、PCI なんかのバスや SoC で使われる AMBA バスなんかは、立派に「インターフェース」と呼べるものだと思いケド。

> マルチコアというのは別CPUですから複数のステータスが何の脈略もなく(規則はありますがあえてこう書きます)変更されるのですから
> ハードウェア動作と似た部分があると思いますがいかがでしょうか?

あるとは思います。
が、それがアプリケーション設計にどう影響するのか分かりません。

現在でも、マルチコアやマルチスレッドに対応したOSが稼働している状況であれば、一般的なプログラマは「コアの数」や「各コアのステート」を強く意識してソフトウェア設計を行う必要はありません。

そういう状況では、一般的なプログラマが気にかけるべきは単位は「スレッド」です。
そして、主に意識するべきは利用可能なスレッド数程度です。

逆に、OSすら存在しないようなレベルのファームウェアでCPUの状態をプログラマが意識しなければいけない、というのは至極当たり前な話で、それがオブジェクト指向云々という話とどう絡んでくるのか、ちょっと分からないです。

引用返信 編集キー/
■10047 / inTopicNo.39)  Re[20]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
□投稿者/ 渋木宏明(ひどり) (527回)-(2007/11/10(Sat) 03:27:58)
渋木宏明(ひどり) さんの Web サイト
2007/11/10(Sat) 03:31:43 編集(投稿者)

> やりとりをインターフェースとしてくくりだしたところで同期できるわけでもないですし。

同期とか込みで「オブジェクト間のコミュニケーション手段」と捉えればオッケーじゃないですか?

例えば「オブジェクト=COM オブジェクト」の時、STA に配置された COM オブジェクトに対するメソッド呼び出しは COM ランタイムによって同期されます。

引用返信 編集キー/
■10049 / inTopicNo.40)  Re[21]: オブジェクト指向熱イベントパネルディスカッション検討スレッド
 
□投稿者/ れい (180回)-(2007/11/10(Sat) 05:55:06)
2007/11/10(Sat) 06:27:20 編集(投稿者)

並列処理のスレッドが始まってる…
なら私も混ぜてください。

No10010 (凪瀬 さん) に返信
> 単に並列処理に対するうまい方法論が存在していないという…

広範に利用できる一般的方法はないですよね。
いい方法がみつかったとしたら、
それはきっとオブジェクト指向の上にのると思いますし、
そうあって欲しいですが。

No10029 (がる さん) に返信
> 何に重点を置くかにもよると思うのですが、「1タスクを1インスタンス」とみなして、やり取りを「インタフェース」とみなすとすると、案外にオブジェクト指向設計はのるのかなぁと思ってるのですがどうでしょうか?

人間の想像できる全ての事象がオブジェクトですから、
そのようにのっけることも可能ですし、そういった実装も見ます。
GPUに命令を渡すときなどはそんな感じでやりますよね。
これはタスクがかなりの作業量であって、他と明確に分離されてないと効果がありません。
つまり「並列化しやすい問題」の場合です。
(それならGridコンピューティングに移行するのも楽ですね)

そんな問題だらけなら簡単で、なにも問題ありません。

普通に設計した時、並列化しやすい問題になることは稀で、そこが問題なのです。
並列化しにくい問題を如何に並列化しやすい問題に変えるか、
どうしても並列化しにくい問題なら、それをいかに高速化するか、
この2者にうまい回答がないので、
> 単に並列処理に対するうまい方法論が存在していないという…
となるのだと思います。

No10035 (凪瀬 さん) に返信
> 1タスクってスレッドを意味していると思っていいのかな?
> やりとりをインターフェースとしてくくりだしたところで同期できるわけでもないですし。

1タスク、というレベルまで分解できるならもう同期なんて些細な問題です。
というとおかしいですね。正確に言うなら。
タスクに分けるなら、同期しなくていいくらいまで細かく分けるべきで、
そこまで分けても、タスクに分けた際のコストを上回るほど、
1タスクが大きくなるようにうまく設計するための方法論がないのです。

No10043 (えムナウ さん) に返信
> >「並列化を活用するための環境」が整備されてくれば、他の手法やツールなんかとの連携もおのずと進歩してくるはず
> ハードウェアに関してはASICとかでプログラム化されたものをよく目にします。
> 接点の動作とかステータスと置き換えてUML化するところも出てきているわけです。

ASICの設計は真似事を1回しただけなのでよくわかりませんが、今はUMLなのですか…。

> 並列化を活用するための環境が整備されていないということは、
> 現在のUMLにおけるオブジェクト設計に環境面(図の拡張も含む)で不足している部分があるということでしょう。

UMLが環境の全てではないですが、今の環境に並列化のための手法が足りないのは
皆さんも認めるところでしょう。
もしかしたら、その穴を埋めるのが、UMLの拡張かもしれない、とは思います。
そうではない、全く新しいものかもしれません。
UMLの拡張程度なら覚えるのが楽でいいですね。

> >「1タスクを1インスタンス」とみなして、やり取りを「インタフェース」とみなすとすると、案外にオブジェクト指向設計はのるのかなぁと思ってるのですがどうでしょうか?
> 上記の話で納得いくでしょうか?

上記で説明したように、私は一概に納得してはいません。

> ハードウェア動作と似た部分があると思いますがいかがでしょうか?

ハードウェア・ファームウェア動作と似た部分があるというのは、ある程度理解できます。
がるさんの想定している状況より、
えむナウさんはより高い自由度(状態の数)、より高い並列度、の状態を想定しているのだと思います。

あらゆる入力が非同期で、状態がころころ変わる場合、
タスクに分けるのが非常に困難です。
それを如何にうまく処理するのか、その方法論が欲しいのであろうと思います。

私はローレベルなハードウェアの場合は、ソフトウェアの方法論と変わってくると思っています。
CPUのコア一個は、この先も逐次実行であるので、「如何にタスクに分けるか」というのを
突き詰めれば答えはでそうですが、
ASICなどの場合は全く逐次実行ではないですから、本質的にだめではないかと。

No10046 (渋木宏明(ひどり) さん) に返信
>>並列化を活用するための環境が整備されていないということは、
>>現在のUMLにおけるオブジェクト設計に環境面(図の拡張も含む)で不足している部分があるということでしょう。
> UML = オブジェクト指向「ではない」し、UML は実装の詳細を記述するためのツールじゃないんで、そんなもんでしょう。
> UML のレベルで「並列化」なんか意識した図を書かなくても、結果、目的の「処理」が並列実行さるような実装がどうにかして得られればオッケーってのが、元々の UML の立ち位置じゃないかと。

上に書いたことの言い換えになりますが。

並列処理に対するうまい方法論がないというのは、
並列処理に対するうまいモデリング技法がない、と言い換えてもいいと思います。

一方、UMLはモデリングのための言語です。

今はうまく並列化できないわけですから、
現状のUMLは不満足であるということになると思います。

UMLのレベルで、並列化した時に十分うまく動くような、
クラス設計なり何なりが、ある程度簡単にできる、っていうのが理想的なUMLではないかと。

UMLに求めず、他のモデリング方法でもうまく並列化できるなら問題ないのですが、
UMLに追加なり変更なりで、うまく並列処理のモデリングができるなら、いいですよね。
引用返信 編集キー/

<前の20件 | 次の20件>
トピック内ページ移動 / << 0 | 1 | 2 | 3 | 4 >>

管理者用

- Child Tree -