部品表のデザインパターンは一見シンプルですが、信じられないほど強力です。この記事では、ITプロフェッショナルに馴染みのある、BOMパターンに適合するとは思わなかったかもしれない例を紹介します。また、BOM構造をより柔軟で管理しやすくする方法を示す概念も紹介します。
BOMの簡単な要約
部品表 製造業にルーツがあります。これは、原材料、サブアセンブリ、中間アセンブリ、サブコンポーネント、部品、および最終製品の製造に必要なそれぞれの数量のリストです。
最も単純な形式では、従来のBOM構造は次のようになります。
ただし、同じ種類の構造をさまざまなさまざまな目的に使用できます。 、厳密に階層的で緊密に結合されたものから、かなり平坦で緩く結合されたものまでさまざまです。 BOM構造の詳細については、この記事を参照してください。
スキーマ–日常の例
信じられないかもしれませんが、class-attribute-typeトリプレットとtable-column-typeトリプレットもBOMパターンに従います。以下の物理データモデルには、データディクショナリのコアテーブルが含まれています。
| Table | 説明 |
|---|---|
| dd_attribute | 実装に依存しない一意の属性。 |
| dd_attr_instance | 属性のインスタンス。インスタンスには、次の2つの特徴的な関係があります。 1）インスタンスが属するクラス。これは、論理オブジェクトまたは物理オブジェクトの場合があります。インスタンスはこのクラスに固有です。 2）データ型。ネイティブ型または別のクラス型のいずれかです。 |
| dd_class | 一般的な意味でのクラスまたはオブジェクト–実際の実装はclass_typeによって与えられます –一連の属性があります。 |
データディクショナリ、またはメタデータリポジトリは、IBM Dictionary of Computingで、「意味、他のデータとの関係、出所、使用法、形式などのデータに関する情報の集中リポジトリ」として定義されています。
ここで、Javaアプリケーションの次のXMLスキーマ定義（XSD）について考えてみます。
いずれかのネイティブXMLタイプの属性を持つXSD複合タイプを定義します。 文字列 、 NMTOKEN 、 anySimpleType –またはその他の複雑なタイプ。
上記のXSDのデータディクショナリへの入力を開始するには、最初にXMLネイティブデータ型をクラスとして入力する必要があります。 ：
| class_name | ステレオタイプ |
|---|---|
| ブール値 | ネイティブ |
| 日付 | ネイティブ |
| dateTime | ネイティブ |
| 文字列 | ネイティブ |
| バージョン | ネイティブ |
| NMTOKEN | ネイティブ |
| anySimpleType | ネイティブ |
これで、データディクショナリの入力を開始するために必要なものがすべて揃いました。以下の例では、 ConnectionConfigTypeを完全に定義するのに十分なものが示されています。 複合型。
| dd_attribute | of_class（dd_attr_instance経由） | type_class（dd_attr_instance経由） | ||
|---|---|---|---|---|
| attr_name | class_name | ステレオタイプ | class_name | ステレオタイプ |
| キー | PropertyType | XSDcomplexType | 文字列 | ネイティブ |
| 値 | PropertyType | XSDcomplexType | 文字列 | ネイティブ |
| プロパティ | ConnectionConfigType | XSDcomplexType | PropertyType | XSDcomplexType |
| driverClassName | ConnectionConfigType | XSDcomplexType | 文字列 | ネイティブ |
| ユーザー | ConnectionConfigType | XSDcomplexType | 文字列 | ネイティブ |
| パスワード | ConnectionConfigType | XSDcomplexType | 文字列 | ネイティブ |
| poolName | ConnectionConfigType | XSDcomplexType | 文字列 | ネイティブ |
ConnectionConfigType.Propertyのデータ型に注意してください 属性は別の複合型、PropertyType 。 XMLでは、複合型は他の複合型で構成できます。 XMLドキュメント、特にWSDLでネストされた複合型を見つけることは珍しくありません。
だから何？ あなたが尋ねる。 XMLは構造が階層的であり、複雑な型を再利用できることを考えると、XMLは当然BOMパターンに従います 。
そして、この現象はXMLに限定されません。 JSONやオブジェクトリレーショナルデータベースのスキーマなど、他のスキーマもBOMパターンに従います 。
BOMに柔軟性を組み込む
従来の製品のBOM構造では、現実の世界で何が起こるかをモデル化するために、3つのよりきめ細かい概念が関係しています。これらは代替案です 、バリアント 、および改訂 。
代替 特定のアイテムの代替品です。たとえば、自動車メーカーは、特定のアイテムに対して異なるサプライヤーを持っている場合があります。実際には、これはメーカーが複数の供給元から同等の燃料ポンプを入手できることを意味します。通常、顧客にはこのオプションは提供されませんが、メーカーに柔軟性を提供します。
以下の例の表の項目として燃料ポンプを使用し、代わりにボッシュとルーカスを使用しました。燃料ポンプの代替品があるということは、たった1つということです。 アセンブリの内、エンジン製造時に選択されます。
| アイテム | 代替 | |
|---|---|---|
| 親 | 子 | 数量 |
| V6（アセンブリ） | 燃料ポンプ（代替） | 1 |
| 燃料ポンプ（代替） | ボッシュポンプ（アセンブリ） | |
| 燃料ポンプ（代替） | ルーカスポンプ（アセンブリ） | |
バリアント 別の種類のアイテムですが、今回はお客様が選択します。車の購入者は、3ドア、5ドア、またはエステート（ステーションワゴンまたはワゴン）のさまざまなボディスタイルを選択できます。また、V6またはV8の2種類のエンジンから選択することもできます。この例では、購入者はバリアントの下にあるアセンブリの1つだけを選択する必要があります。
| アイテム | |||
|---|---|---|---|
| 親 | 子 | 最小選択 | 最大の選択 |
| 車（アセンブリ） | ボディ（バリアント） | 1 | 1 |
| ボディ（バリアント） | 3ドア（アセンブリ） | ||
| ボディ（バリアント） | 5ドア（アセンブリ） | ||
| ボディ（バリアント） | エステート（アセンブリ） | ||
| 車（アセンブリ） | エンジン（バリアント） | 1 | 1 |
| エンジン（バリアント） | V6（アセンブリ） | ||
| エンジン（バリアント） | V8（アセンブリ） | ||
他のドメインでは、選択肢の数はさらに多様です。例として教育を取り上げます。特定の資格を取得するには、学生は一定数のグループを完了する必要があります。グループごとに、いくつかのモジュールから選択できます。
たとえば、学生が卒業証書を取得するために2つのグループを完了する必要があるとします。 6つのリストから2つのモジュールを選択して、最初のグループを完成させることができます。次に、2番目のグループを完了するために、5つから3つのモジュールを選択する必要があります。 （これがより詳細に確認したいセクターである場合は、柔軟な設計が英国の情報標準委員会によって公開されています。）
上記の例は両方とも、以下に示す単純なパターンに従います。このパターンは、かなり静的な構造に適しています。バリアントと代替は階層に挿入され、それらのすぐ下のアイテムから何らかの選択を行う必要があることを示します。
時間の経過とともに状況が変化する傾向がある場合は、次のパターンの方が柔軟性が高く、保守が容易です。欠点は、トラバース（またはナビゲート）するのが少し扱いにくいことです。
上記の論理モデルを物理モデルに変換すると、次のようになります。
このモデルでは、アイテムは分割できないパーツまたはアセンブリのいずれかです。パーツとアセンブリは階層に編成されています。ただし、代替案 、バリアント および改訂 時間の経過とともにかなり変化する傾向があるため、独自の明確な関係があります。これにより、階層の再編成が最小限に抑えられます。
たとえば、自動車メーカーは継続的に自動車を開発しています。その結果、顧客が利用できるようになったバリアントと同様に、パーツの選択肢は時間の経過とともに変化します。アセンブリに変更が発生すると、アセンブリが改訂されます。 改訂 アイテムの変更履歴を示します。この例を考えてみましょう：
| 部品番号 | バージョン | 前へ | 後続 |
|---|---|---|---|
| 123456-1 | 1 | 123456-1 | 123456-1 |
| 123456-2 | 2 | 123456-1 | 123456-2 |
| 123456-3 | 3 | 123456-2 | 123456-3 |
| 123456-4 | 4 | 123456-1 | 123456-4 |
| 123456-5 | 5 | 123456-2、123456-3 | 123456-5 |
上記の表の説明は次のようになります。アイテムには少なくとも1つのリビジョン（元のバージョン）があります。製品の元のバージョンは、2番目のバージョンを作成するために使用されます。 2つ目は、バージョン3を作成するためにさらに開発されましたが、うまくいきませんでした。そのため、エンジニアは元のバージョンを改訂して、バージョン4を作成しました。徹底的なテストの結果、これも理想的とは言えないことがわかりました。そのため、エンジニアは2番目と3番目のバージョンの側面を取り入れて、最終製品であるバージョン5を作成することにしました。
前後のキーを見ると、変更履歴に多対多が必要な理由がわかります。 アイテムとリビジョンの関係。同じ原則がアイテム、代替品、バリアントに適用されます。
部品表パターンについての最後の言葉
この一連の記事が、BOMパターンの認識に役立つことを願っています。プロジェクトに表示されると、特定のドメインでモデル化するのに最適な方法がわかります。
ただし、厳密な部品表構造には長所と短所があることに注意してください。長所：階層は再利用可能です。短所：階層は再利用可能です。これはあなたの場合は悪いことかもしれませんし、悪いことではないかもしれませんが、それは確かに知っておくべきことです。
良い点は、階層を石に設定する必要がないことです。代替案、バリアント、およびリビジョンを使用して、オプションが存在するドメイン、履歴の位置を保持する必要があるドメイン、および最終的に唯一の定数が変更されるドメインをモデル化できます。