インチ パート1 この3のポストシリーズの(OK、私はそれが2つの部分になると言ったが、これは私が予想していたよりも長くなった)私は基本的な設計プロセスの現実と、ソフトウェアツールがそのプロセスを容易にするのにどのように役立つかについて少し話しました。 SSIが哲学的に「変化」にどのようにアプローチするかについて(プロセスの特定の段階に関係なく)、そしてクライアントが設計プロセスの早い段階で変更の管理を容易にするために理想的なShipConstructor製品モデルの作成にどのように取り組むかについて、第2部で話すことを約束しました。 私の次の 2つの 記事では、私はそれらの両方を行うように努力します。
変革の哲学
変化は、船の設計と建設において対処するより一般的で困難なことの1つです。 個別生産(機器、消費者製品、小規模アセンブリを考える)などの他の業界では、製品の規模と範囲は、変更が製品モデル全体に伝播する際に高い予測可能性を可能にします。 複雑度が比較的低いため、ルール(パラメトリック、トポロジ、または連想)をモデルに組み込むのが簡単なだけでなく、結果として生じる変更の検証が容易になります。 しかし、モデルが複雑になるにつれてこれらの業界でも、多くの設計者が作成したモデル内で作業することは非常に困難です(モデルの作成が不十分な場合、別のユーザーがモデルに組み込んだルールを理解するのが難しい、またはその両方)。
造船は、私たちのプロジェクトの範囲と規模が他のほとんどの業界の規模を上回るため、この課題を何度も悪化させます。 また、プロジェクトの巨大さによって、変更を自動化および管理 できる ツールもさらに価値のあるものになります。 聞き覚えがありますか?
私たちの哲学は、常に自動化された変更を許可し、奨励することでしたが、ユーザーが変更の結果を表示、制御、および理解できるように、それが起こる前に。 この最初の例は、当社の製品の一部で13年以上前にさかのぼって、モデルの変更に合わせた自動更新が可能な連想DWGの生産図面でした。 現在のバージョンの ShipConstructor を使用すると、モデルの変更に応じて すべての 図面を自動的に更新できます。 どの図面を更新する必要があるか、更新が行われる時期を制御し、図面内で何が変更されるか、誰が変更を加えたのか、いつ発生したのかを完全に知らされると、ユーザーに「自動的に更新される」のではなく、「自動的に更新される」ような言語を使用します。 図面が変更される前に。
この同じ哲学は、数年前にShipConstructorのモデリング部分が書き換えられたときに適用されました。 新しいバージョンの ShipConstructor (ShipConstructor 2008 以降) には、製品モデル内の多くの品目間に関連付けとパラメトリックの関係があります。 このシリーズの第 3 部では、これらの関係の性質について詳しく説明します。
このようなシステムで作成できる潜在的な関係の深さにより、SSIは、変更を行うユーザーのインフォームド・コンセント と 、変更が発生する前に変更の影響を制御する機能なしに自動的に変更が発生することが重要であると考えています。 これに対して、他のツールでは、これらの変更を自動的に行い、変更された内容に関する情報が存在しない場合にユーザーを残します。 ShipConstructor は、製品モデル全体にわたる変更が製品モデル全体に及ぼす影響を表示し、ユーザーが選択した品目または領域に対してのみ変更の影響を制限できるようにします。
次の記事では、このシリーズの 最後の記事 で、製品モデルに存在する関連機能と、ユーザーがそれらの機能をどのように使用しているかを詳しく見ていきます。