日記/20070429 の変更点

|[[''前の日記''>日記/20070428]]|[[''次の日記''>日記/20070502]]|
~
昨日までは実機を使った走行実験や、各種計測などを行ってきました。~
今日からはソフトウェアの設計作業にはいっていきたいと思います。~
ゴールデンウィークにもなったことですし、まとまった時間がとれそうです(^o^)/~

今日からはソフトウェアの設計作業はじめます。~
ゴールデンウィークにもなったので一挙にすすめてしまおう!~
~
早速、今日丸一日使って考えたことをまとめておきます。~
今日考えたことをまとめておきます。~
~
*20070429 シミュレータ構想 [#x39712cb]
~
**設計の構想 [#c8724faa]
設計を始めたい気持ちを抑えつつ、まずはやりたいことを整理していきたいと思います。~
構想が長くなりすぎるとやる気がなくなりそうなので、lightweightにしておきます。~

構想が長くなりすぎるとやる気がなくなりそうなので、lightweightに。~
ここでは設計指針、機能要求、非機能要求、を''要求''と呼ぶことにして、やりたいことをまとめました。~

***ポイントとなる要望・要求 [#pcf10447]
以下のような感じで行きたいと思います。（[[日記/20070421]]で考えた要望に少し追加してみました）~
以下のような感じで。（[[日記/20070421]]で考えた要望に少し追加）~

~
''1.Windowsプラットフォームで動作すること''~
とりあえず、身近なOSで動かしたいな〜~
~
''2.今後のSTEP2,STEP3への物理計算拡張を考慮した設計とすること''~
物理計算処理も階層化したほうがよさそうです。ソルバー単位になるかな。。~

~
''3.物理計算エンジン部分を取替え可能に設計すること''~
物理計算と描画の境界線は意識しましょう。学生の頃、物理計算用のPG組んだとき、これを混ぜて痛い目を見ました。後から描画処理を追加するときに、計算処理に手をいれたくなるんです。その頃はASPECT指向なんて知りませんでした。~

~
''4.パスファインダーをパーツのアセンブリとして表現すること''~
将来パスファインダーを構成する部品が変わってもいいように。~

~
''5.3Dグラフィックスへの対応を考慮した設計とすること''~
やはり見た目的に3Dにも対応させたいので、スケール感をもって、2Dの計算をさせたほうが良いでしょう。~
でしょう。~
~
''6.複数台のパスファインダーの同時シミュレーションに対応すること''~
複数でアルゴリズム対決みたいなのをシミュレータ上でできたら楽しそうです。~

~
''7.C++で記述されたパスファインダー制御コードと連携できること''~
パスファインダーの制御コードはC++なので、Fortranでシミュレータを作ってはいけないということです。Windowsに依存しすぎてもいけないのでInterfaceを定義して、薄いWrapperをかませるような使い方を想定します。~
~
''8.新しい技術ネタを取り入れること''~
やるからには単なるソフトの設計作業でなくて、何か新しいことSomething Newが欲しいです。~
やるからには単なるソフトの設計作業でなくて、何か新しいことSomething Newが欲しい。~
''9.とにかく動くこと''~
ゴールデンウィーク内で動くものを作ることにします。~
ゴールデンウィーク内で動くものを作る~
''10.見た目重視''~
シミュレータでインパクトを与えるのも目的かと思うので、見た目もダサくならないように注意します。~
で、ここから、アーキテクチャを考えてみたいと思います。~
シミュレータでインパクトを与えるのも目的。見た目もダサくならないように注意。~


**アーキテクチャを考える [#f89c3d30]
私は''アーキテクチャ''とは''ソフトウェア構造のラフスケッチ''と考えていますので、要求からラフスケッチをおこしたいと思います。~

***スケッチの修正 [#cab30727]
まずは[[日記/20070421]]のスケッチをベースベースにすこし修正をかけてみました。~
まずは[[日記/20070421]]のスケッチをベースにすこし修正をかけてみました。~
#ref(archchange2.png,nolink);

-マスの責務
--''Algorithm''~
パスファインダーのアルゴリズムを担当します。シミュレータとは物理的にも完全に分離したほうがいいでしょう。シミュレータに対するクライアントになります。シミュレータをCOMで作ってしまうのもありですね。~
パスファインダーのアルゴリズムを担当します。シミュレータとは物理的にも完全に分離したほうがいいでしょう。シミュレータに対するクライアントになります。シミュレータをCOMで作ってしまうのもあり。~
--''Wrapper''~
ラッパーといっていますが、''Adapter''という意味はほとんどありません。スクラッチで作るので、実質''インタフェース((C++だと純粋仮想関数だけでできたクラスといったほうがわかりやすいでしょうか。C#とかJavaならInterfaceクラスがあって便利ですね。^O^))''を定義して、''インタフェースに対して実装しようね''と言っていることと変わりないかと思います。~
ラッパーといっていますが、''Adapter''という意味はほとんどありません。スクラッチで作るので、実質''インタフェース((C++だと純粋仮想関数だけでできたクラスといったほうがわかりやすいでしょうか。C#とかJavaならInterfaceクラスがあって便利ですね。))''を定義して、''インタフェースに対して実装しようね''と言っていることと変わりないかと思います。~
~
--''Simulator''~
シミュレータ本体です。Windowsで動くようにしましょうという気持ちを込めて(Windows)としてしまいました。~
やっぱり''COM''ではなくて、''.NETライブラリ''で実装しようと思います。覚えた知識があっというまに使えなくなります。時代の流れは早いです。~
''COM''ではなくて、''.NETライブラリ''で実装しようと思います。実装レイヤーに近いほど覚えた知識があっというまに使えなくなる、時代の流れは早いです。~
~
---''RCX Simulator''~
パスファインダーと、パスファインダーの外的環境、その２者の相互作用など。~
[[日記/20070421]]では外的環境の存在を認識していませんでした。~
~
---''Kinetics''~
動力学です。学生のときには「ｘｘｘにおける動力学」みたいなレポート書を良くかされていました。今回はおそらく実装できないです。時間的に。~
動力学です。学生のときには「ｘｘｘにおける動力学」みたいなレポートをよく作っていたなぁ。今回はおそらく実装できないです。時間的に。~
~
---''Kinematics''~
運動学です。こちらは、最低限実装します。実装しないと静止画を表示するソフトになってしまいます。~
運動学です。こちらは、最低限実装します。~

--''Draw''~
画面への描画を担当します。RCX Simulatorと密接に関わります。~
***要求に答える [#c35599d9]
**要求とアーキテクチャ [#p9193d65]
要求から、アーキテクチャをすこし詳細化してみました。明日からは実装に入りたいので、もう''パッケージ''を意識しています。~
~
#ref(arch1.png,nolink);
~
□内の数字はアーキテクチャに対応する、要求番号です。~
~
~
-''2.今後のSTEP2,STEP3への物理計算拡張を考慮した設計とすること''
-''3.物理計算エンジン部分を取替え可能に設計すること''~
2と3は''パスファインダーと物理計算の分離''および、''物理計算と外部環境（たとえばコースとのインタファクション）との分離''を意識して設計せよ、ということになります。~
~
~
-''4.パスファインダーをパーツのアセンブリとして表現すること''~
パスファインダーの形状は来年変わるかもしれないので、パーツ（たとえば１つのLEGOブロック）を組んでパスファインダーの形状を再現できるように設計しておく必要があるということです。違う形状のパスファインダーを同時に走らせるなんてこともやりたいです。~
パスファインダーの形状は来年変わるかもしれないので、パーツ（たとえば１つのLEGOブロック）を組んでパスファインダーの形状を再現できるように設計しておく必要があるということです。ルールが変わってもいいように、違う形状のパスファインダーを同時に走らせるなんてこともやりたいです。~
~
~
-''5.3Dグラフィックスへの対応を考慮した設計とすること''~
パスファインダーを描画するグラフィックはとりあえず2Dで作りますが、今後のことも考えて3Dでも使えるように設計しておきます。つまり2Dでも3Dでも同じ操作体系で使えるように設計せよ、との方針になります。''Factory Method''とか''Template Method''とか「サブクラスさんおまかせ」系のデザインパターンが使えそうです。~
パスファインダーを描画するグラフィックはとりあえず2Dで作りますが、今後のことも考えて3Dでも使えるように設計しておきます。つまり2Dでも3Dでも同じ操作体系で使えるように設計せよ、との方針になります。''Factory Method''とか''Template Method''とか「サブクラスさんおまかせ」系のデザパタを採用予定。~
~
~
-''6.複数台のパスファインダーの同時シミュレーションに対応すること''~
''PathFinder''クラスを''new''して''add''して大量生産できるよに設計しておきましょう、ということです。最初に考えておかないと意外に苦労しそうなポイントです。''robo-one''用のシミュレータを作ったときは、ここで泣きました。~
''PathFinder''クラスを''new''して''add''して大量生産できるよに設計しておきましょう、ということです。OOP的にはあたりまえかもしれないが、最初に考えておかないと意外に苦労しそうなポイントです。''robo-one''用のシミュレータを作ったときは、ここで泣きました。~

~
**要求と開発環境 [#x56dba95]
開発環境はほぼ頭で固まっていましたが、一応考えを整理してみました。~
~
||Algorithm|Wrapper|Simulator|
|プラットフォーム|>|>|Windows .NET Framework2.0|
|(理由)|>|>|MFCがタダで使える環境が無いので。|
|開発環境|>|VC++ 2005 Express|VC# 2005 Express|
|（理由）|>|ロジックはパスファインダー側と同じにしたいのでC++。C++/CLIを覚えたい。無料だから。|VC#のりファクタリング機能が使いたい(VC++には無いです）＆新しいことを覚えたい。無料だから。|
|（理由）|>|ロジックはパスファインダー側と同じにしたいのでC++。C++/CLIをさわってみたい。|VC#のりファクタリング機能が使いたい(VC++には無いの）＆新しいことを覚えたい。|
|構成管理|>|>|SubVersion|
|（理由）|>|>|VSSが有料でSubVersionもTortoiseSVNも無料だから|
|C++とC#の連携|>|>|.NETのコンポーネントにするので問題無いはず。Event/Delegateまわりには注意。|

~
~
-要求の整理
--''1.Windowsプラットフォームで動作すること''~
--''7.C++で記述されたパスファインダー制御コードと連携できること''~
Windowsプラットフォームの選択肢を考えます。パスファインダー用のマイコン(H8)コードはC言語 or C++言語を使うので、そっちと連携するにはWindowsでもC++を使うのがよさげです。~
Windowsプラットフォームの選択肢を考えます。パスファインダー用のマイコン(H8)コードはC言語 or C++言語を使うので、そっちと連携するにはWinでもC++を使うのがよさげです。~
~
~
--''8.新しい技術ネタを取り入れること''~
こんなネタを仕入れたいな。~
(1).NET Framework 2.0の技術の習得~
(2)C++/CLIの習得~
(3)C#の新しい仕様（パーシャルクラスとか）~
(4)新しい開発環境~
~
--''9.とにかく動くこと''~
RADをします。それを行う為には、強力なIDEが欲しいです。こんな機能があると助かります。~
・インテリセンス（コード補完）~
・リファクタリング機能~
・ワンタッチビルド~
・構成管理~
RADをします。
~
~
--''10.見た目重視''~
多少アーキテクチャ原則に違反しても見た目がよくなる工夫を、ということでしょうか。~
~

~
|[[''前の日記''>日記/20070428]]|[[''次の日記''>日記/20070502]]|
~