Assembly project/jp

開発ロードマップの一部にあるアセンブリモジュールのプロジェクト計画です.

目的と原則
これはアセンブリモジュールと製品作成機能の実装を目標としたソフトウェア開発計画です. FreeCADのCADモジュールであるパートとアセンブリに対するいくつかのコア機能の実装が関係します.

開発ステップはここで計画され、適切な形式の変更ログを作成するために課題追跡システムでトラッキングされます： 課題トラッカー

成果物
このプロジェクトの目標はFreeCADで次に示すような設計作業を行えるようにすることです：



これはモデルのやり取りを簡単に行えるようにできるだけISO10303仕様に近づけた拘束を伴う様々な種類のパートの統合を行うアセンブリの使用によって可能になる予定です.

もう一つの目標は運動学用のODEを利用できるようにすることです.

マルチモデル


現実世界での設計の重要な特徴は設計を取り扱い可能な断片に分割するということです. 設計上の全ての側面を一度に取り扱うのは不可能です. これは形状についても、FEMやCAMといったエンジニアリング的な作業についても当てはまることです. そこでFreeCADでモデルを分割できるようにする必要があります. これによっていくつかのことが可能なります：
 * 遅延読み込み - グラフィックスや作業をしている部分のメインメモリといったリソース以外は不必要になります
 * コンカレントエンジニアリング - 大人数で同じ設計に対して作業できるようになります
 * Fine grained バージョン管理 - 設計の様々な側面に対してより適切な管理を行えるようになります
 * その他にもあります....

マルチモデルの設計は次のようになります：

プロジェクトマネージメント
マルチモデルでは一つのプロジェクトに対して多くのファイルが存在し、そのほとんどが共有ディレクトリに置かれます. プロジェクトファイルとプロジェクトブラウザによってファイルは構造化されます. またプロジェクトに関する追加情報やプロジェクトのウェブサイトを保存することもできます.

1. "シンプル"モードと"プロジェクト"モードの二つのモード. シンプルではドキュメントが一つだけ存在し、全てのアセンブリとパーツはそのドキュメントの中にあります. プロジェクトが開かれたり作成されたりするとFreeCADはプロジェクトモードに移行します.

2. プロジェクト. ドライブ上のFCPrjファイルの位置がルートディレクトリを定義します. このディレクトリの下のファイルは全てそのルートディレクトリに対する相対パスで定義されます. 左側の追加ビューには扱っているファイルに対するディレクトリツリーを表示するProjectExplorerが存在するようになります. このルートディレクトリはSVNサンドボックスのルートとしても使用され、これによって作業後の共有やバージョン管理が容易になります. （ロート外やサーバー共有、ウェブ上のソースに対する）外部参照は分離可能な形でProjectExplorer内に表示されます（各ファイルサーバーやウェブサーバーを擬似的なディレクトリとする）. これによって外部参照の高速な閲覧や再ルーティングが可能になります.

著作権
3Dモデルの著作権は興味深い分野です. 3Dモデルは著作権保護の対象になりません. モデルの作成者は著作権を持ちますが、そのモデルによって表現される形状は特許や意匠特許によってしか保護されません（アメリカの場合）. しかも特許によって保護されるのは利益の発生する物理的な作成物だけなのです. その一例がMicrosoft製マウスの意匠特許です.

作成者（著作権保有者）と設計のモデル/製品/ファイルに対する全種類のライセンスについては記憶しておく必要があります. ライセンスに関しては私はCCライセンスをよく使います. http://creativecommons.org/

CCライセンスの略称キー:
 * BY = 表示のみ
 * BY-ND = 表示-改変禁止
 * BY-NC-ND = 表示-非営利- 改変禁止
 * BY-NC = 表示-非営利
 * BY-NC-SA = 表示-非営利- 継承
 * BY-SA = 表示-継承
 * PD = パブリックドメインなツールあるいは他のパブリックドメインな作品の一つを経由しパブリックドメインとして表示あるいは献呈；パブリックドメインな作品からの派生物は希望する任意のライセンス条項の下で作成者によって作成、ライセンスされる.

さらにURLのリンク先には（カスタムライセンス用に）全てのライセンスのドキュメントがあります.

ISO10303
ISO10303（STEP）はこの分野では非常に重要です. これは私が知る限りでは唯一の広く議論され認められた適切な標準化済み製品構造定義です.

以下に情報があるリンクをいくつか紹介します：
 * WikipediaのISO10303の項目
 * WikiStep.org ほとんどはSTEP-NCについてですが多くの基礎情報があります
 * STEPでの製品構造
 * 複数のSTEPの例
 * ISO10303-11 モデル化言語（EXPRESS）について
 * 製品モデリングについてのWikipediaの項目
 * パート41の概要 -- 製品概要とサポートの基礎
 * パート41（第2版）の概要 -- 製品構造の構成
 * 小規模なAP214ファイルの例

アセンブリ拘束
大規模なモデルと製品を組みあげる上で重要な役割を果すのがアセンブリ拘束です. これはパーツをどのように製品にアセンブルするかを表す固有のルールを定式化したもので、固定、面対面、角度、オフセットなどの主要なものを始めとしていくつかのパターンがあります. パーツが変更された場合にもこれらの拘束が維持できるようにするには特殊なソルバーが必要になります. このソルバーはスケッチャーのソルバーとは根本的に異なるものです. おそらくこれにはグラフベースのアプローチを使う必要があると思うのですが...

運動学
さらに高度な手段としてはODEかそれに類したライブラリの使用があるでしょう. これを使って機械的運動学シミュレーションを満たすようにパーツやアセンブリを統合するのです. これを使えば衝突判定や機械システムの状態の調査が可能になります.

バージョン管理
バージョン管理と分散開発は重要な点です. マルチモデルの設計では設計を小さな断片に分解してチーム内で分散して作業することが可能です. ソフトウェア開発者にとっては"分散"と"バージョン"は聞き慣れた言葉です. ぜひDVCSを使いましょう. よい比較検討記事がここにあります.

私たちが扱うのは膨大なデータであり、簡単に差分を取ることができないようなものです. 従って使えるものはスナップショット永続的なモデルを使用しているものだけです. たんに差分を蓄積するだけのシステムでは私たちのデータの場合、深刻な問題が起きるでしょう（個人的にMercurialとCatiaのファイルで試したことがあります）. 商用と非フリーなものを除くと基本的にはGitとSVNしかありません.

この作業でのGitの使用は二つの大きな課題があります：
 * Gitは非常に複雑です. 　リモートのリポジトリへのマージ（プッシュ、プル）はもちろん、非線形な開発パスに沿ったブランチ、マージ、タグ付けは問題を多いに複雑にしています. それをユーザーから隠蔽するのは非常に難しい作業になるでしょう.
 * Gitでは特定のファイルタイプに対してマージと差分を行うハンドラを使用することができます. 私たちの場合、.fcstdのためのハンドラが必要になるでしょう. このハンドラでFreeCADドキュメントを調べ、オブジェクトやフィーチャー、パラメータの変更点表示とマージを行うことができなければなりません. これも簡単なことではありません.

しかしGitを使えば高級なPLMシステムでさえ夢に見るような多くの可能性が開けるでしょう...

Organizing
以下に優れたアセンブリ/製品設計に必要となる開発項目を挙げておきます：

インフラストラクチャ
アセンブリではFreeCADの基盤システムとインフラストラクチャ層への変更が必要になるでしょう.

マルチモデル
マルチモデルはFreeCADの設計当初から念頭にあったことです. そのために私たちはマルチドキュメントインターフェイスを採用し、無制限の数のドキュメントを読み込めるようにしました. しかし私たちは複数のドキュメントをビュー（パートツリー）に表示できるように3Dビューを中心に改善する必要があります.

パートツリー
アセンブリではパーツやサブアセンブリによる複合物がメインワークフローとなるのでツリーの中でパーツをまとめる（グループ化する）ツールを実装する必要があります. DocumentObjectGroupとは異なり、アセンブリのグループは子グループの表示と配置を扱えなければなりません. もっとも良いのはそれぞれにViewProviderを取り付けることです. そのためにはViewProviderがClaimChildrenインターフェイスのようなものもつ必要があります.

ドラッグ/ドロップ/コピー/ペーストのインターフェイスの統合
ツリーまたは3DビューでViewProviderとWorkbencheがドラッグ/ドロップ/コピー/ペーストの操作を完全に制御できるようなインターフェイス.

外部リソース
（内部または外部のブラウザからの）ドープリンクの制御. つまり（潜在的に）低速な接続（http）経由でのリソースの読み込み.

オブジェクトモデル
必要な概念を取り扱うクラスツリー. 参照、インターフェイス、ドキュメントリンク、ビュー、複合物、拘束、設定など他にも多くのものがあります...

アセンブリ拘束ソルバー
スケッチャーソルバーのインターフェイスと非常に似通ったアセンブリ拘束ソルバーとのインターフェイスを定義しなければなりません.

物理シミュレーションインターフェイス
アセンブリのパーツの位置を制御する外部の（マルチ）フィジックスシミュレーションソフトウェアとのインターフェイス. 運動学テストとDMUを行うために"bullet"または"ODE"を使えるようにしなければならないでしょう.

次のアクション

 * オブジェクトモデル
 * 0.12のリリースブランチができるまで待機