Das Designmuster für die Stückliste ist täuschend einfach, aber unglaublich leistungsfähig. In diesem Artikel wird ein Beispiel vorgestellt, das IT-Experten bekannt ist und von dem Sie vielleicht dachten, dass es nicht zum BOM-Muster passt. Außerdem werden Konzepte vorgestellt, die Ihnen zeigen, wie Sie Ihre Stücklistenstrukturen flexibler und einfacher zu verwalten machen können.
Eine kurze Zusammenfassung der Stückliste
Eine Stückliste hat seine Wurzeln in der Fertigung. Es ist eine Liste der Rohmaterialien, Unterbaugruppen, Zwischenbaugruppen, Unterkomponenten, Teile und der jeweiligen Mengen, die zur Herstellung eines Endprodukts benötigt werden.
In seiner einfachsten Form, der klassischen Stücklistenstruktur sieht es so aus:
Die gleiche Art von Struktur kann jedoch für eine Vielzahl von verschiedenen Zwecken verwendet werden , die von streng hierarchisch und eng gekoppelt bis zu ziemlich flach und locker gekoppelt reichen. Weitere Informationen zur Stücklistenstruktur finden Sie in diesem Artikel.
Schemata – ein alltägliches Beispiel
Ob Sie es glauben oder nicht, das Klassenattribut-Typ-Triplet und das Tabellenspalten-Typ-Triplet folgen ebenfalls dem BOM-Muster. Das folgende physische Datenmodell enthält die Kerntabellen eines Datenwörterbuchs.
| Tabelle | Beschreibung |
|---|---|
| dd_attribute | Ein eindeutiges Attribut, unabhängig von einer Implementierung. |
| dd_attr_instance | Eine Instanz eines Attributs. Die Instanz hat zwei unterschiedliche Beziehungen: 1) Die Klasse, zu der sie gehört, die ein logisches oder physisches Objekt sein kann. Die Instanz ist für diese Klasse eindeutig. 2) Der Datentyp, der entweder ein nativer Typ oder ein anderer Klassentyp sein kann. |
| dd_class | Eine Klasse oder ein Objekt im allgemeinen Sinne – die eigentliche Implementierung wird durch class_type angegeben – die eine Reihe von Attributen hat. |
Ein Datenwörterbuch oder Metadaten-Repository wird im IBM Dictionary of Computing als „zentrales Repository von Informationen über Daten wie Bedeutung, Beziehungen zu anderen Daten, Herkunft, Verwendung und Format“ definiert.
Betrachten Sie nun die folgende XML Schema Definition (XSD) für eine Java-Anwendung:
Es definiert komplexe XSD-Typen, die die Attribute entweder nativer XML-Typen haben – z. Zeichenfolge , NMTOKEN , beliebiger Einfacher Typ – oder andere komplexe Typen.
Um mit dem Füllen des Datenwörterbuchs für die obige XSD zu beginnen, müssen wir zuerst die XML-nativen Datentypen als Klassen eingeben :
| class_name | Stereotyp |
|---|---|
| boolesch | Nativ |
| Datum | Nativ |
| dateTime | Nativ |
| Zeichenfolge | Nativ |
| Version | Nativ |
| NMTOKEN | Nativ |
| beliebiger Einfacher Typ | Nativ |
Wir haben jetzt alles, was wir brauchen, um mit der Befüllung unseres Datenwörterbuchs zu beginnen. Im Beispiel unten wird gerade genug angezeigt, um den ConnectionConfigType vollständig zu definieren komplexer Typ.
| dd_attribute | of_class (über dd_attr_instance) | type_class (über dd_attr_instance) | ||
|---|---|---|---|---|
| attr_name | Klassenname | Stereotyp | Klassenname | Stereotyp |
| Taste | PropertyType | XSDcomplexType | Zeichenfolge | Nativ |
| Wert | PropertyType | XSDcomplexType | Zeichenfolge | Nativ |
| Eigenschaft | Verbindungskonfigurationstyp | XSDcomplexType | PropertyType | XSDcomplexType |
| Treiberklassenname | Verbindungskonfigurationstyp | XSDcomplexType | Zeichenfolge | Nativ |
| Benutzer | Verbindungskonfigurationstyp | XSDcomplexType | Zeichenfolge | Nativ |
| Passwort | Verbindungskonfigurationstyp | XSDcomplexType | Zeichenfolge | Nativ |
| Poolname | Verbindungskonfigurationstyp | XSDcomplexType | Zeichenfolge | Nativ |
Beachten Sie den Datentyp von ConnectionConfigType.Property Das Attribut ist ein weiterer komplexer Typ, PropertyType . In XML können komplexe Typen aus anderen komplexen Typen bestehen. Es ist nicht ungewöhnlich, verschachtelte komplexe Typen in XML-Dokumenten zu finden, insbesondere in WSDL.
Na und? du fragst. Nun, da XML eine hierarchische Struktur hat und komplexe Typen wiederverwendet werden können, folgt XML natürlich dem BOM-Muster .
Und dieses Phänomen ist nicht auf XML beschränkt. Andere Schemas, wie die für JSON und objektrelationale Datenbanken, folgen ebenfalls dem BOM-Muster .
Flexibilität in eine Stückliste integrieren
In der klassischen Produktstücklistenstruktur sind drei feinkörnigere Konzepte beteiligt, um zu modellieren, was in der realen Welt passiert. Dies sind Alternativen , Varianten und Überarbeitungen .
Eine Alternative ist ein Ersatz für einen bestimmten Artikel. Beispielsweise kann ein Autohersteller für bestimmte Artikel unterschiedliche Lieferanten haben. Praktisch bedeutet dies, dass der Hersteller gleichwertige Kraftstoffpumpen von mehreren Quellen beziehen kann. Normalerweise wird dem Kunden diese Option nicht gegeben, aber es gibt dem Hersteller Flexibilität.
Wir haben Kraftstoffpumpen als Elemente in der Beispieltabelle unten verwendet, mit Bosch und Lucas als Alternativen. Eine Kraftstoffpumpen-Alternative zu haben bedeutet, dass einzig und allein der Baugruppen werden zum Zeitpunkt der Motorenherstellung ausgewählt.
| Element | Alternative | |
|---|---|---|
| Eltern | Kind | Menge |
| V6 (Montage) | Kraftstoffpumpe (Alternative) | 1 |
| Kraftstoffpumpe (Alternative) | Bosch-Pumpe (Montage) | |
| Kraftstoffpumpe (Alternative) | Lucas-Pumpe (Montage) | |
Eine Variante ist eine andere Art von Artikel, aber diesmal trifft der Kunde die Wahl. Ein Autokäufer kann zwischen verschiedenen Karosserievarianten wählen – 3-Türer, 5-Türer oder Kombi (Kombi oder Kombi). Sie können auch zwischen zwei verschiedenen Motortypen wählen – einem V6 oder einem V8. In unserem Beispiel muss der Käufer eine und nur eine der Baugruppen unterhalb der Variante auswählen.
| Element | Variante | ||
|---|---|---|---|
| Eltern | Kind | Mindestauswahl | Maximale Auswahl |
| Auto (Montage) | Körper (Variante) | 1 | 1 |
| Körper (Variante) | 3-Türer (Montage) | ||
| Körper (Variante) | 5-Türer (Montage) | ||
| Körper (Variante) | Nachlass (Versammlung) | ||
| Auto (Montage) | Engine (Variante) | 1 | 1 |
| Motor (Variante) | V6 (Montage) | ||
| Motor (Variante) | V8 (Montage) | ||
In anderen Bereichen ist die Anzahl der Auswahlmöglichkeiten vielfältiger. Nehmen wir das Beispiel Bildung. Um eine bestimmte Qualifikation zu erlangen, muss ein Student eine bestimmte Anzahl von Gruppen absolvieren. Für jede Gruppe können sie aus mehreren Modulen wählen.
Angenommen, ein Student muss zwei Gruppen absolvieren, um ein Diplom zu erhalten. Sie können zwei Module aus einer Liste von sechs auswählen, um die erste Gruppe zu vervollständigen. Dann müssen sie drei Module aus fünf auswählen, um die zweite Gruppe abzuschließen. (Wenn Sie sich diesen Sektor genauer ansehen möchten, hat das Information Standard Board des Vereinigten Königreichs ein flexibles Design veröffentlicht.)
Beide obigen Beispiele folgen dem unten gezeigten einfachen Muster. Dieses Muster eignet sich für Strukturen, die ziemlich statisch sind. Varianten und Alternativen werden in die Hierarchie eingefügt, um anzuzeigen, dass eine Auswahl aus den unmittelbar darunter liegenden Elementen getroffen werden muss.
Wenn sich die Dinge im Laufe der Zeit ändern, ist das folgende Muster flexibler und einfacher zu pflegen. Auf der anderen Seite ist es etwas unhandlicher zu durchqueren (oder zu navigieren).
Durch die Umwandlung des obigen logischen Modells in ein physikalisches Modell sehen die Dinge so aus:
In diesem Modell ist ein Artikel entweder ein unteilbares Teil oder eine Baugruppe. Teile und Baugruppen sind in Hierarchien organisiert. Allerdings Alternativen , Varianten und Überarbeitungen haben ihre eigenen unterschiedlichen Beziehungen, weil sie sich im Laufe der Zeit ziemlich ändern. Dies minimiert die Hierarchiereorganisation.
Beispielsweise entwickeln Autohersteller ihre Autos ständig weiter. Daraus folgt, dass sich die Teilealternativen im Laufe der Zeit ändern, ebenso wie die dem Kunden zur Verfügung gestellten Varianten. Wenn in einer Baugruppe eine Änderung auftritt, wird die Baugruppe überarbeitet. Eine Überarbeitung gibt den Änderungsverlauf des Artikels an. Betrachten Sie dieses Beispiel:
| Teilenummer | Version | Vorhergehend | Folgende |
|---|---|---|---|
| 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 |
Die Erzählung für die obige Tabelle lautet wie folgt:Ein Element hat mindestens eine Revision – seine ursprüngliche Version. Die ursprüngliche Version des Produkts wird verwendet, um die zweite Version zu erstellen. Die zweite wurde weiterentwickelt, um Version drei zu erstellen, die nicht funktionierte. Also überarbeiteten die Ingenieure die ursprüngliche Version und erstellten Version vier. Auch dies stellte sich nach ausgiebigen Tests als nicht optimal heraus. Also beschlossen die Ingenieure, Aspekte der zweiten und dritten Version zu übernehmen und Version fünf, das Endprodukt, zu erstellen.
Wenn Sie sich die vorhergehenden und nachfolgenden Schlüssel ansehen, werden Sie sehen, warum der Änderungsverlauf einen viele-zu-viele-Wert benötigt Beziehung zwischen Artikeln und Revisionen. Das gleiche Prinzip gilt zwischen Artikeln, Alternativen und Varianten.
Ein letztes Wort zum Stücklistenmuster
Ich hoffe, dass Ihnen diese Artikelserie geholfen hat, das BOM-Muster zu erkennen. Wenn es in Ihren Projekten erscheint, werden Sie verstehen, wie Sie es am besten in Ihrem spezifischen Bereich modellieren können.
Bitte beachten Sie jedoch, dass die strikte Stücklistenstruktur Vor- und Nachteile hat. Pro:Hierarchien sind wiederverwendbar. Nachteil:Hierarchien sind wiederverwendbar. Dies kann in Ihrem Fall eine schlechte Sache sein oder auch nicht, aber es ist sicherlich etwas, dessen Sie sich bewusst sein sollten.
Das Gute ist, dass Hierarchien nicht in Stein gemeißelt sein müssen. Mit Alternativen, Varianten und Überarbeitungen können Sie Bereiche modellieren, in denen Optionen bestehen, in denen die historische Position beibehalten werden muss und in denen letztendlich die einzige Konstante der Wandel ist.
