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

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

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

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

(過去ログ 23 を表示中)

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

■10052 / inTopicNo.41)

　Re[19]: オブジェクト指向熱イベントパネルディスカッシ

▼■

□投稿者/ がる (5回)-(2007/11/10(Sat) 09:49:17)

2007/11/10(Sat) 09:50:30 編集(投稿者)
2007/11/10(Sat) 09:50:21 編集(投稿者)

がるです。
当日前に燃えすぎると(…ど～でもいいけどATOK、もえすぎるで一発目萌えすぎるださないで orz)燃え尽きちゃうので(笑

多分ひどりさんの
> もう既に別投稿で書いたことですが、理論としてはＹＥＳです。
> ですが、実装としてそれが望ましいかどうか、はまた別な話だと思います。
このへんが私に一番近い感覚かなぁと。で、なのであえて「オブジェクト指向<STRONG>設計</STRONG>はのるのかなぁ」という風に書いてました。
# 過去の少ない記憶のかぎりだと…設計はともかく、実装的には、OOPは「ちょいと重すぎる」記憶があります(苦笑

あ。
「オブジェクト指向設計」から「非オブジェクト指向プログラミング」で書く手法っての、どこかで話してみると面白そうな。
…ってのも今ふと思ってみました。

あと、れいさんの
> 普通に設計した時、並列化しやすい問題になることは稀で、そこが問題なのです。
> 並列化しにくい問題を如何に並列化しやすい問題に変えるか、
> どうしても並列化しにくい問題なら、それをいかに高速化するか、
> この2者にうまい回答がないので、
> > 単に並列処理に対するうまい方法論が存在していないという…
> となるのだと思います。
このあたり。別タイミングででも、なんか別に切り出して「並列処理をごにょごにょする勉強会」とかすごく興味があります＾＾

ちょいと淡泊なレスですが。

引用返信 編集キー/

■10054 / inTopicNo.42)

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

▲▼■

□投稿者/ 渋木宏明(ひどり) (528回)-(2007/11/10(Sat) 13:14:12)

2007/11/10(Sat) 14:37:41 編集(投稿者)

> これはタスクがかなりの作業量であって、他と明確に分離されてないと効果がありません。
> つまり「並列化しやすい問題」の場合です。
> (それならGridコンピューティングに移行するのも楽ですね)

現状は、そういった問題を「並列化するため」だけでも多くのコードを記述しなければならなくて、下手をすると「本来解決するべき問題」が「並列化するため」のコードに埋もれてしまう、というまだまだ低いレベルで頭を悩ませなければならない状況なんですよねー

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

御意。

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

んーと、僕はそもそも「並列化」はモデリングの対象なの？という疑問が根底にあります。

例えば、とりあえず「並列化」は置いておいて、「高速化」について考えた場合、モデリングの段階で「高速化」を強く意識していたとして、それがどれだけ最終的なモデル図類から読み取れるでしょうか？

「高速なモデル」と「高速でないモデル」は異なるものになると思いますが、「高速であるかどうか」はモデルの表記ではなくて、全体の構成・構造によって達成されていると思うんです。

「並列化」についても同じなんじゃないかなーと。

引用返信 編集キー/

■10064 / inTopicNo.43)

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

▲▼■

□投稿者/ れい (182回)-(2007/11/10(Sat) 23:08:35)

■No10054 (渋木宏明(ひどり) さん) に返信
> 現状は、そういった問題を「並列化するため」だけでも多くのコードを記述しなければならなくて、下手をすると「本来解決するべき問題」が「並列化するため」のコードに埋もれてしまう、というまだまだ低いレベルで頭を悩ませなければならない状況なんですよねー

そうですね。
昔、言語でオブジェクト指向がサポートされてなかったころ、
オブジェクト指向なプログラミングをするために、たくさんコードが必要でした。
それと似た状況ですね。

逆に言うと、今は並列化されてるだけで価値があるということですね。
今、「オブジェクト指向でプログラムしてます」では宣伝になりませんが、
並列化も同じ状態になってくれると世界はもっと幸せになれると思います。

#でもきっと「並列化って何？」っていう人が増えるんでしょうね。

>>並列処理に対するうまい方法論がないというのは、
>>並列処理に対するうまいモデリング技法がない、と言い換えてもいいと思います。
>
> んーと、僕はそもそも「並列化」はモデリングの対象なの？という疑問が根底にあります。
> 例えば、とりあえず「並列化」は置いておいて、「高速化」について考えた場合、モデリングの段階で「高速化」を強く意識していたとして、それがどれだけ最終的なモデル図類から読み取れるでしょうか？
>
> 「高速なモデル」と「高速でないモデル」は異なるものになると思いますが、「高速であるかどうか」はモデルの表記ではなくて、全体の構成・構造によって達成されていると思うんです。

モデリングは仕様の決定でもなく、詳細の決定でもないですよね。
全体の構成・構造を決定する手法がモデリングではないのですか？

現状、モデリングといえばオブジェクトの設計でしょうが、
ソフトウェアの構成を決定するための手法は全てモデリングでしょう。

> 「並列化」についても同じなんじゃないかなーと。

ひどりさんは並列化と高速化を比較するのですね。
確かに、通常のソフトウェア開発では、並列化する最終的理由は高速化ですね。

私は、並列化設計とオブジェクト指向設計を対比していました。
オブジェクト指向をきちんと学んでから設計を行えば、
自然と保守性・再利用性の高いコードがかけます。
同様に、ある設計技法を学んでから設計を行うと、
自然と並列処理されやすいコードが書けるようになるのではないかと。

並列化が、オブジェクト指向の上に乗っかって欲しいという前提がありますね。

オブジェクト指向は処理の高速化を目指した設計技法ではないですよね。
オブジェクト指向設計したら、一般には遅くなります。
同様に、並列化設計したら、多少(CPUの命令数的な)コストはかかるかもしれないけど
並列化されやすいコードが書ける、と。

んー。こうして考えると、
私の発想はただのマルチスレッドプログラミングですね。
いわゆるPCで、高級言語を扱う範囲内では、
マルチスレッドをもって並列化としていいでしょうが、
並列化ってそれだけじゃないですよね。

ひどりさんは何かもっと壮大なことを考えてるのでしょうか。

引用返信 編集キー/

■10076 / inTopicNo.44)

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

▲▼■

□投稿者/ えムナウ (95回)-(2007/11/11(Sun) 03:51:36)

> 現状は、そういった問題を「並列化するため」だけでも多くのコードを記述しなければならなくて、下手をすると「本来解決するべき問題」が「並列化するため」のコードに埋もれてしまう、というまだまだ低いレベルで頭を悩ませなければならない状況なんですよねー

現在はインテルでコンパイラを出しているしマイクロソフトもアクションを起こし始めています。
こういうタイミングだからこそオブジェクト指向のモデリングにも並列化設計が必要と考えています。

>んーと、僕はそもそも「並列化」はモデリングの対象なの？という疑問が根底にあります。

私は現実に数プロジェクトのファームウェアで書いています。
私の書いたUMLは並列化のためのコメントで、あるページは本体よりも面積が多いくらいあふれかえりました。
ハード屋さんにも相談されたことがあります。否定的な回答をしました。

>並列化が、オブジェクト指向の上に乗っかって欲しいという前提がありますね。
私もそう思っています。
というか体系的なオブジェクト指向設計ができるならUMLの拡張でもいいと思っています。
れいさんも、パネラーで出席されて私と一緒に並列化をオブジェクト指向設計に加えることの賛成派に回りませんか？

引用返信 編集キー/

■10079 / inTopicNo.45)

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

▲▼■

□投稿者/ れい (186回)-(2007/11/11(Sun) 05:57:06)

■No10076 (えムナウさん) に返信
> >んーと、僕はそもそも「並列化」はモデリングの対象なの？という疑問が根底にあります。
> 私は現実に数プロジェクトのファームウェアで書いています。
> 私の書いたUMLは並列化のためのコメントで、あるページは本体よりも面積が多いくらいあふれかえりました。
> ハード屋さんにも相談されたことがあります。否定的な回答をしました。

FirmやASICの場合、最適化のレベルが通常のソフトの比じゃないでしょうから、
並列化はすごく難しい問題ですよねぇ。
現状のUMLでは無理、UMLの拡張程度でなんとかできるものか…。
いわゆる職人芸が必要で、そう考えると、

>「並列化」はモデリングの対象なの？

というひどりさんも言も理解できます。
「ちょwwUMLじゃ無理ww」っていう感じですね。

> >並列化が、オブジェクト指向の上に乗っかって欲しいという前提がありますね。
> 私もそう思っています。
> というか体系的なオブジェクト指向設計ができるならUMLの拡張でもいいと思っています。

こういったものは言葉よりも実装が先行するはずです。

並列化やマルチスレッド、非同期処理に関しては、すでにかなりの知識・経験を蓄積し、
並列化の方針もだいぶ固まってきてるように見えます。
.Netも、ThreadPoolやBackgroundWorker等、有用な概念・クラスがあります。
(ThreadPoolは、がるさんの「タスク」とほぼ同じ概念ですよね)
.Net 3.5のTPL(だっけ？)やIntelのTBB(だっけ？)などでどのような概念が出るのか、気になります。

オブジェクト志向がそうであったように、本当に全く新しい概念が突然できることはないですから、
こういった指針・概念をまとめたような、うまく使えるような、
そういった体系的技法ができるのできて欲しいですし、
もうすぐできると思っています。それがUMLの拡張で済むならベストですね。

ただ、私のこの発想はパフォーマンスを犠牲にする発想です。前の投稿で述べたように、
オブジェクト志向がパフォーマンスを犠牲にして開発効率・保守性・再利用性を上げたのと同様に
並列化が誰でも楽にできるようになる代わりに、パフォーマンスは犠牲になるでしょう。

ですから、FirmやASICの開発で使うのは難しそうですね。
低レベルなものほど、新しい概念の恩恵を受けるのは遅くなりますから、
新しい並列化パラダイムができても、それがFirmやASICに応用可能になるまで、
えむナウさんが幸せになれるまでは、だいぶかかりそうに思います。

(というか、もしかすると今UMLを使ってFirm作ってるの自体、先行しすぎなのでは？)

>れいさんも、パネラーで出席されて私と一緒に並列化をオブジェクト指向設計に加えることの賛成派に回りませんか？

■No10052 (がるさん) に返信
> このあたり。別タイミングででも、なんか別に切り出して「並列処理をごにょごにょする勉強会」とかすごく興味があります＾＾

門外漢ですし。
いつかいいタイミングがあったら、ですね。

引用返信 編集キー/

■10080 / inTopicNo.46)

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

▲▼■

□投稿者/ 渋木宏明(ひどり) (529回)-(2007/11/11(Sun) 06:58:16)

> モデリングは仕様の決定でもなく、詳細の決定でもないですよね。
> 全体の構成・構造を決定する手法がモデリングではないのですか？

と思います。

で、高速化や並列化は、もっと下のレベルの話なんじゃないかなーと。

> ひどりさんは並列化と高速化を比較するのですね。
> 確かに、通常のソフトウェア開発では、並列化する最終的理由は高速化ですね。

現状はそれが一番大きな理由ですが、将来的には「グリッドに流したいから」とか「それが当たり前だから」というのが主な理由になってしまうような気がします。

> オブジェクト指向は処理の高速化を目指した設計技法ではないですよね。
> オブジェクト指向設計したら、一般には遅くなります。
> 同様に、並列化設計したら、多少(CPUの命令数的な)コストはかかるかもしれないけど
> 並列化されやすいコードが書ける、と。

高速化すること≒並列化することとして例示したわけじゃないです。

高速化はモデリングの対象じゃないですよね？
それと同じように、並列化もモデリングで記述する問題じゃないんじゃね？と思うわけデス。

> 並列化ってそれだけじゃないですよね。

厳密にはそうですね。
でも、プログラム１本とかのスコープではそう考えてもそれほど問題はないはずです。

僕のアタマはまだグリッドには対応していないので、「並列化」に関してはせいぜい「１台のＰＣの中」レベルでしか考えられません (^^;

> ひどりさんは何かもっと壮大なことを考えてるのでしょうか。

基本的な主張は「並列化はモデリングの対象ではないんじゃね？」とゆーことデス。
モデリングと並列化では問題分野が違うと思うんですよ。

「並列化」は、モデリングよりも下層である「実装を得るための層＝コンパイラやランタイムなど」で解決するべきなんじゃないかなと。

引用返信 編集キー/

■10081 / inTopicNo.47)

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

▲▼■

□投稿者/ 渋木宏明(ひどり) (530回)-(2007/11/11(Sun) 07:26:42)

> こういうタイミングだからこそオブジェクト指向のモデリングにも並列化設計が必要と考えています。

否（笑）

「並列化された実装を得るためのうまい仕組み」は必要だと思いますが、それが現時点でオブジェクト指向に統合されるべきである、とは今のところ思えません。

「楽だから」って言われたら「そうかもね」と応えますが、「それが最善である」とする根拠が僕には思い浮かびません。

> 現在はインテルでコンパイラを出しているしマイクロソフトもアクションを起こし始めています。

どうして、それらの会社はコンパイラやランタイムから手をつけたんでしょうね？

「まず設計技法を改善するべきだ」と考えたのなら、UML の拡張提案したり圧力をかけたり (^^; できるはずです。

某Ｍ社に関して言えば、独自の記法を世に出すこともできるはずです。

> >んーと、僕はそもそも「並列化」はモデリングの対象なの？という疑問が根底にあります。
>
> 私は現実に数プロジェクトのファームウェアで書いています。
> 私の書いたUMLは並列化のためのコメントで、あるページは本体よりも面積が多いくらいあふれかえりました。
> ハード屋さんにも相談されたことがあります。否定的な回答をしました。

モデリングが実装の詳細を記述するための技術ではない以上、実装の詳細に記述しようとして苦労するのは当たり前じゃないですか？

その場面で UML を使う旨味は、記法や記号が標準化されたものである、というとこくらいな気が。

> >並列化が、オブジェクト指向の上に乗っかって欲しいという前提がありますね。
> 私もそう思っています。

僕は上下逆ね ;-)

並列化は、「オブジェクト指向による設計」よりも下位の「よりより実装を得るための技術」だと考えます。

すんごく省略して言うと、コンパイラの最適化みたいなもんだと。

引用返信 編集キー/

■10082 / inTopicNo.48)

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

▲▼■

□投稿者/ 渋木宏明(ひどり) (531回)-(2007/11/11(Sun) 08:07:43)

2007/11/11(Sun) 08:10:00 編集(投稿者)

# 同じ内容を再投稿してしまったので削除しますた。

引用返信 編集キー/

■10086 / inTopicNo.49)

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

▲▼■

□投稿者/ れい (187回)-(2007/11/11(Sun) 12:15:12)

スーパースケーラやパイプラインも一種の「並列化」ですが、
これは隠蔽されて見えませんよね。
このレベルの並列化はコンパイラとCPUで自動的にやってくれます。

並列化した際、通信コストが小さい順に書くと、
core内の並列化＝スーパースケーラ、パイプライン
CPU内core間の並列化≒マルチスレッド
PC内CPU間の並列化≒マルチスレッド
ネット内PC間の並列化≒Grid
となるわけで、
通信のコストが高ければ高いほど一つのタスクが大きい必要があります。

コードを小さいタスクに分割するのは楽なので、
スーパースケーラやパイプラインは十分にうまく動いてるわけですね。

マルチスレッドレベルだと、タスクがある程度大きくないと意味がありません。
いままでは大きなタスクに分ける方法はプログラマがそれを意識して書くしか無かったわけです。
これをコンパイラなりランタイムなりが自動でやってくれればよい、
というのがひどりさんの立場ですよね。

100％自動でタスク分割は難しいでしょうが、
少しの労力で簡単にタスク分割できるよう、
言語にサポートをいれたり、ライブラリ追加したり、頑張ったコンパイラを作ったり、
というのが最近の傾向ですよね。

コンパイラの技術が向上して
ようやくマルチスレッドレベルで分割できるようになってきたのと、
マルチコアのてこ入れのおかげでしょうね。
このまま進めば、ちょっとの労力でグリッドに流せる日が来るかもしれません。

そういった日になっても、並列化しやすいモデリング技法があったとしたら、
それには価値があると思いますし、
コンパイラや言語の進化に応じて、
設計技法にも並列化に関して新しい方法論ができると思います。

並列化はずいぶん前から言われてますが、未だに広範に使える方法論はありません。
コンパイラも、言語も、設計技法も、全部がもう少し進歩すると思ってます。

> 高速化はモデリングの対象じゃないですよね？
> それと同じように、並列化もモデリングで記述する問題じゃないんじゃね？と思うわけデス。

もちろん設計で考慮するのは速度より保守性、再利用性などですが、
ダメな設計ですと、実装レベルの改良ではどうにもならないような場合もあります。
高速化しやすい設計もありますから、モデリングで速度を考慮する場合も少なくありません。
ですので、そういった意味では高速化もモデリングの対象であると思います。

同様に、並列化しやすい設計もあるはずです。
コンパイラや言語が並列化サポートを強化するなら、
それに対応した設計もあるはずだと思います。

そしてそういった設計技法は、グリッド時代も対応しやすくするでしょうし、
並列化の理解をより深めるものであろうと思います。

引用返信 編集キー/

■10089 / inTopicNo.50)

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

▲▼■

□投稿者/ えムナウ (96回)-(2007/11/11(Sun) 15:08:06)

>「並列化された実装を得るためのうまい仕組み」は必要だと思いますが、それが現時点でオブジェクト指向に統合されるべきである、とは今のところ思えません。

言い換えれば大丈夫なわけね。
「並列化された実装を得るためのうまい仕組み」をオブジェクト指向設計の、
モデリングに組み込んでくれれば便利なのに・・・と。
別のものが作られてもいいですけどね・・・とか？

>「まず設計技法を改善するべきだ」と考えたのなら、UML の拡張提案したり圧力をかけたり (^^; できるはずです。
>某Ｍ社に関して言えば、独自の記法を世に出すこともできるはずです。
ニーズが集約されればやるでしょ？

>並列化は、「オブジェクト指向による設計」よりも下位の「よりより実装を得るための技術」だと考えます。
>すんごく省略して言うと、コンパイラの最適化みたいなもんだと。
Lockやvolatileがある時点で違うでしょ。

引用返信 編集キー/

■10090 / inTopicNo.51)

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

▲▼■

□投稿者/ えムナウ (97回)-(2007/11/11(Sun) 15:24:16)

>(というか、もしかすると今UMLを使ってFirm作ってるの自体、先行しすぎなのでは？)
ファームウェアだってドキュメントを通じて発注者と確認をとります。
昔はフローチャートを使っていましたがUMLにしたっていいでしょう。
UMLでもフォークとジョインがあります。

>門外漢ですし。
>いつかいいタイミングがあったら、ですね。
わんくまの辞書には「門外漢」という単語はありません。
いいタイミングは白熱した今です。

引用返信 編集キー/

■10091 / inTopicNo.52)

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

▲▼■

□投稿者/ 渋木宏明(ひどり) (532回)-(2007/11/11(Sun) 15:27:49)

2007/11/11(Sun) 15:30:34 編集(投稿者)

> 言い換えれば大丈夫なわけね。
> 「並列化された実装を得るためのうまい仕組み」をオブジェクト指向設計の、
> モデリングに組み込んでくれれば便利なのに・・・と。
> 別のものが作られてもいいですけどね・・・とか？

結果としてそうなる可能性は否定してません。
「汎用コメントよりましな何か」が追加されるくらいの可能性はあると思います。（すごく低いと思うけど）

でも、途中の議論を全部省略してイキナリ「メンドクセーからモデリング技法を拡張しようぜ」って言われても手放しで賛成することはできません。
結局、具体的な拡張案みたいなものは出てきてもいないし。

> >「まず設計技法を改善するべきだ」と考えたのなら、UML の拡張提案したり圧力をかけたり (^^; できるはずです。
> >某Ｍ社に関して言えば、独自の記法を世に出すこともできるはずです。
> ニーズが集約されればやるでしょ？

えムナウさんがそんなに熱心に「必要だ」と主張しているくらいなのに、まだ「ニーズが集約されていない」ってのは変じゃないですか？

> >並列化は、「オブジェクト指向による設計」よりも下位の「よりより実装を得るための技術」だと考えます。
> >すんごく省略して言うと、コンパイラの最適化みたいなもんだと。
> Lockやvolatileがある時点で違うでしょ。

それは実装の詳細なんで、本来の意味におけるモデリングで扱う問題領域ではありません。
モデルから実装を起こす際に解決されるべき問題です。

引用返信 編集キー/

■10092 / inTopicNo.53)

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

▲▼■

□投稿者/ カンタービレ (36回)-(2007/11/11(Sun) 15:59:29)

白熱中に水を差してスミマセン。

オブジェクト指向がどうとか並列処理がとか、ムズカシイ言葉にいまいちついていけないんデス・・。
（じゃ発言するな、でしたらしないようにシマス。）

基本的にオブジェクトは処理やデータの固まりという考え方で合ってマス？
OOによる設計（モデリング）はそうした固まりをどう作ってどうつなげるかを決めていく手法のことで、
その表現としてUMLなどのツールが存在する。という解釈で合ってマス？

並列処理って時間軸が主観点デスよね？
並列化設計という言葉をこのスレで初めて見たくらいのレベルの頭しか持ち合わせてないんですが、
オブジェクトは時間軸の断面をベースに表現しているとして、並列化設計って何かと何かを「同時に」実行して
っていうのを体系的に表現することになるのでしょうか？
オブジェクトと時間でどっちが上・下とかって感覚があまり実感できなくて、つい発言しちゃいました。

時間軸を体系的に表現するための手法を並列化設計というならば、例えば２次元表記のUMLに時間という
ベクトルを加えた３次元表記で表すべき時代がきた、いやそうじゃない、とかそういう議論でしょうか。
（ナンカ飛躍シスギ・・タカモ）

なんか設計技法とプログラミング技法が混合して飛び交っているように見えて発言しにくいんデスが
解釈に間違いがあるようでしたらスルーして下さい。。

引用返信 編集キー/

■10093 / inTopicNo.54)

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

▲▼■

□投稿者/ 渋木宏明(ひどり) (533回)-(2007/11/11(Sun) 16:05:44)

> スーパースケーラやパイプラインも一種の「並列化」ですが、
（略）
> マルチコアのてこ入れのおかげでしょうね。

現在やごく近い将来の状況はそーであると思います。

> このまま進めば、ちょっとの労力でグリッドに流せる日が来るかもしれません。

は、いつごろ来るんでしょうねぇ。

> そういった日になっても、並列化しやすいモデリング技法があったとしたら、
> それには価値があると思いますし、

モデリングと直結するかなー？
具体案も出なかったので、実物が登場してからのお楽しみですな。

> 並列化はずいぶん前から言われてますが、未だに広範に使える方法論はありません。
> コンパイラも、言語も、設計技法も、全部がもう少し進歩すると思ってます。

のはずだけど、その過程で「並列化」というテーマそのものが少し変形されたり分割されたりする可能性もありそーな気がしています。

>>高速化はモデリングの対象じゃないですよね？
>>それと同じように、並列化もモデリングで記述する問題じゃないんじゃね？と思うわけデス。
>
> もちろん設計で考慮するのは速度より保守性、再利用性などですが、
> ダメな設計ですと、実装レベルの改良ではどうにもならないような場合もあります。
> 高速化しやすい設計もありますから、モデリングで速度を考慮する場合も少なくありません。
> ですので、そういった意味では高速化もモデリングの対象であると思います。

もちろん、「高速であること」が要件ならば、それは設計の段階で織り込んでおかなくてはならないです。
でもそれは「高速に問題を処理する（はず）の構造」を記述するのであって、「高速であること」を表す記法や記号があるわけじゃないでしょ？ってことです。

> 同様に、並列化しやすい設計もあるはずです。
> コンパイラや言語が並列化サポートを強化するなら、
> それに対応した設計もあるはずだと思います。

そう思いマス。
でもそれは UML に記法や記号の追加でどーこーなる問題なん？ホントにそんなんで大丈夫なん？と。

引用返信 編集キー/

■10094 / inTopicNo.55)

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

▲▼■

□投稿者/ 渋木宏明(ひどり) (534回)-(2007/11/11(Sun) 16:13:45)

2007/11/11(Sun) 16:22:37 編集(投稿者)

> ファームウェアだってドキュメントを通じて発注者と確認をとります。
> 昔はフローチャートを使っていましたがUMLにしたっていいでしょう。

現状、イチバン「マシ」ですね。
UML は標準化された手法なので「話を通しやすい」という点では間違いありません。

# フローチャートなんか書くくらいならコード書いた方が早いし ;-p

引用返信 編集キー/

■10095 / inTopicNo.56)

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

▲▼■

□投稿者/ 渋木宏明(ひどり) (535回)-(2007/11/11(Sun) 16:26:03)

>> >並列化は、「オブジェクト指向による設計」よりも下位の「よりより実装を得るための技術」だと考えます。
>> >すんごく省略して言うと、コンパイラの最適化みたいなもんだと。
>> Lockやvolatileがある時点で違うでしょ。
>
>それは実装の詳細なんで、本来の意味におけるモデリングで扱う問題領域ではありません。
>モデルから実装を起こす際に解決されるべき問題です。

> UMLでもフォークとジョインがあります。

UML のレベルではそれで十分だと思うんだけどなぁ。

設計段階で考慮するべきはせいぜい「同期すること」程度で、「どう同期するのか＝同期にどんな仕組みを使うのか」は実装の問題。

引用返信 編集キー/

■10096 / inTopicNo.57)

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

▲▼■

□投稿者/ えムナウ (98回)-(2007/11/11(Sun) 16:55:19)

>並列処理って時間軸が主観点デスよね？
>並列化設計という言葉をこのスレで初めて見たくらいのレベルの頭しか持ち合わせてないんですが、
>オブジェクトは時間軸の断面をベースに表現しているとして、並列化設計って何かと何かを「同時に」実行して
>っていうのを体系的に表現することになるのでしょうか？
UMLのシーケンス図やステート図を知っていますか？
時間軸や状態の移り変わりが主観点ですよね。

私のUMLの不満は、コメントでごまかさない設計がしたいということです。
アクティビティ図・シーケンス図・ステート図で並列化設計がしづらいというのが第1点。
クラス図でもなんかの工夫はいるんじゃないかと思っているのが2点目です。

引用返信 編集キー/

■10097 / inTopicNo.58)

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

▲▼■

□投稿者/ えムナウ (99回)-(2007/11/11(Sun) 17:25:19)

>具体案も出なかったので、実物が登場してからのお楽しみですな。
クラス図にはライフサイクルを書きたいな。
IOポートを集約してクラスみたいに書いてしまうこともあるのでプロパティ間に依存線を書きたいな。
とかとか、現実に書いていると思ってしまうので全部コメント。

アクティビティ図・シーケンス図・ステート図なんかは書いているときりがないので、
重要ではないけど必ずチェックしておかなきゃいけない信号とかも全部コメント。

>そう思いマス。
>でもそれは UML に記法や記号の追加でどーこーなる問題なん？ホントにそんなんで大丈夫なん？と。
じゃぁ、そういう議論をしましょうよ。
UML に記法や記号の追加というのはあくまでも例ですので、
本来はオブジェクト指向設計でもモデリングで並列化をキチンと表現したいということです。

引用返信 編集キー/

■10098 / inTopicNo.59)

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

▲▼■

□投稿者/ 渋木宏明(ひどり) (536回)-(2007/11/11(Sun) 17:28:21)

> 私のUMLの不満は、コメントでごまかさない設計がしたいということです。

要するに、不満の対象は UML の表現力なんですよね？

UML = オブジェクト指向ではないので。。。というのは前に述べた通りです。
細かい議論抜きに「UML の欠点＝オブジェクト指向の欠点だ」という方向で僕を説得しようとしても無駄な努力ですｗ

UML に何が足りないのか？という話題なら、それはそれで参加します。

>クラス図でもなんかの工夫はいるんじゃないかと思っているのが2点目です。

クラスとクラスメンバに対する「要同期呼び出し、を示すマークアップ」とか？

>アクティビティ図・シーケンス図・ステート図で並列化設計がしづらいというのが第1点。

設計のスコープによると思うけど、ひょっとして、巨大でコメントだらけなステート図を書いてたりします？
あるいは、やたらと小さなステート図を多量のアクティビティやシーケンスでつなぎ合わせるハメになるかのどっちかかな。

でもこれ、ちょっとやそっとの追加とかじゃどーにもならないと思うけど。。。
その理由として僕が挙げるのは「問題領域が違うから」デス。

図や記法・記号の追加でイケる、とするなら、たとえばどんな方向が考えられますか？

引用返信 編集キー/

■10099 / inTopicNo.60)

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

▲　■

□投稿者/ 渋木宏明(ひどり) (537回)-(2007/11/11(Sun) 17:38:14)

> クラス図にはライフサイクルを書きたいな。

「このクラスはこう使うべし」みたいなところを？
処理系や実行環境によってかなり変動することろだから、UML 的にはコメントでしか対応できなさそうな。。。

コメントかあるいは新設で、C/C++ の pragma みたいなノリで、モデルより下層のプログラミング言語なんかに対する指示が書けるといーんですかね？

> IOポートを集約してクラスみたいに書いてしまうこともあるのでプロパティ間に依存線を書きたいな。
> とかとか、現実に書いていると思ってしまうので全部コメント。

これもやっぱり実装の都合をモデル図にどー書くんさ？的な話ですよねぇ。
うまく切れればシーケンスで書いてしまえばいいと思うけど、切り口無い時もあるかなぁ。

> アクティビティ図・シーケンス図・ステート図なんかは書いているときりがないので、
> 重要ではないけど必ずチェックしておかなきゃいけない信号とかも全部コメント。

うっそーん、書いた方が楽なやつもあると思うけど (^^; > 図s

> >でもそれは UML に記法や記号の追加でどーこーなる問題なん？ホントにそんなんで大丈夫なん？と。
> じゃぁ、そういう議論をしましょうよ。
> UML に記法や記号の追加というのはあくまでも例ですので、
> 本来はオブジェクト指向設計でもモデリングで並列化をキチンと表現したいということです。

別投稿でも書いていますが、構造設計と並列化では問題領域が違うから、両者を同じ土俵で表現しようとしても難しいだけであまり成果が上がらないように思うんですよ。
可能だとして、具体的にどういう展開が考えられます？？？

引用返信 編集キー/

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

- Child Tree -