Het ontwerppatroon van de stuklijst is bedrieglijk eenvoudig, maar toch ongelooflijk krachtig. Dit artikel introduceert een voorbeeld, bekend bij IT-professionals, waarvan u misschien niet dacht dat het in het stuklijstpatroon past. Het introduceert ook concepten om u te laten zien hoe u uw stuklijststructuren flexibeler en veel gemakkelijker te beheren kunt maken.
Een korte samenvatting van de stuklijst
Een stuklijst heeft zijn wortels in de productie. Het is een lijst van de grondstoffen, subassemblages, tussenassemblages, subcomponenten, onderdelen en de hoeveelheden die nodig zijn om een eindproduct te vervaardigen.
In zijn eenvoudigste vorm, de klassieke stuklijststructuur, ziet het er als volgt uit:
Dezelfde soort structuur kan echter worden gebruikt voor een groot aantal verschillende doeleinden , die variëren van iets strikt hiërarchisch en strak gekoppeld tot iets redelijk plat en losjes gekoppeld. Zie dit artikel voor meer informatie over de stuklijststructuur.
Schema's – een alledaags voorbeeld
Geloof het of niet, het class-attribuut-type triplet en het table-column-type triplet volgen ook het stuklijstpatroon. Het onderstaande fysieke datamodel bevat de kerntabellen van een datadictionary.
| Tabel | Beschrijving |
|---|---|
| dd_attribuut | Een uniek kenmerk, onafhankelijk van enige implementatie. |
| dd_attr_instance | Een instantie van een attribuut. De instantie heeft twee onderscheidende relaties: 1) De klasse waartoe het behoort, wat een logisch of fysiek object kan zijn. De instantie is uniek voor deze klasse. 2) Het gegevenstype, dat een native type of een ander klassetype kan zijn. |
| dd_class | Een klasse of object in de generieke zin – de daadwerkelijke implementatie wordt gegeven door class_type – dat een set attributen heeft. |
Een datadictionary, of metadatarepository, wordt in de IBM Dictionary of Computing gedefinieerd als een "gecentraliseerde repository van informatie over gegevens zoals betekenis, relaties met andere gegevens, oorsprong, gebruik en formaat".
Overweeg nu de volgende XML Schema Definition (XSD) voor een Java-toepassing:
Het definieert complexe XSD-types die de attributen hebben van ofwel native XML-types - b.v. tekenreeks , NMTOKEN , anySimpleType – of andere complexe typen.
Om te beginnen met het vullen van de datadictionary voor de bovenstaande XSD, moeten we eerst de XML native datatypes als klassen invoeren :
| class_name | stereotype |
|---|---|
| booleaans | Native |
| datum | Native |
| dateTime | Native |
| tekenreeks | Native |
| versie | Native |
| NMTOKEN | Native |
| anySimpleType | Native |
We hebben nu alles wat we nodig hebben om ons datadictionary te vullen. In het onderstaande voorbeeld wordt net genoeg getoond om het ConnectionConfigType . volledig te definiëren complex type.
| dd_attribuut | of_class (via dd_attr_instance) | type_class (via dd_attr_instance) | ||
|---|---|---|---|---|
| attr_name | class_name | stereotype | class_name | stereotype |
| sleutel | PropertyType | XSDcomplexType | tekenreeks | Native |
| waarde | PropertyType | XSDcomplexType | tekenreeks | Native |
| Eigenschap | ConnectionConfigType | XSDcomplexType | PropertyType | XSDcomplexType |
| driverClassName | ConnectionConfigType | XSDcomplexType | tekenreeks | Native |
| gebruiker | ConnectionConfigType | XSDcomplexType | tekenreeks | Native |
| wachtwoord | ConnectionConfigType | XSDcomplexType | tekenreeks | Native |
| poolNaam | ConnectionConfigType | XSDcomplexType | tekenreeks | Native |
Merk op hoe het gegevenstype van de ConnectionConfigType.Property attribuut is een ander complex type, PropertyType . In XML kunnen complexe typen bestaan uit andere complexe typen. Het is niet ongebruikelijk om geneste complexe typen in XML-documenten te vinden, vooral in WSDL.
En? je vraagt. Welnu, aangezien XML hiërarchisch van structuur is en complexe typen hergebruikt kunnen worden, XML volgt natuurlijk het stuklijstpatroon .
En dit fenomeen is niet beperkt tot XML. Andere schema's, zoals die voor JSON en object-relationele databases, volgen ook het stuklijstpatroon .
Flexibiliteit opnemen in een stuklijst
In de klassieke productstuklijststructuur zijn drie fijnmazigere concepten betrokken bij het modelleren van wat er in de echte wereld gebeurt. Dit zijn alternatieven , varianten , en revisies .
Een alternatief is een vervanging voor een bepaald item. Zo kan een autofabrikant voor bepaalde artikelen verschillende leveranciers hebben. In de praktijk betekent dit dat de fabrikant gelijkwaardige brandstofpompen uit meerdere bronnen kan verkrijgen. Meestal krijgt de klant deze optie niet, maar het geeft de fabrikant flexibiliteit.
We hebben brandstofpompen gebruikt als items in de onderstaande voorbeeldtabel, met Bosch en Lucas als alternatieven. Een alternatief voor een brandstofpomp hebben betekent dat één en slechts één van de assemblages zal worden geselecteerd op het moment van fabricage van de motor.
| Artikel | Alternatief | |
|---|---|---|
| Ouder | Kind | Aantal |
| V6 (montage) | Brandstofpomp (alternatief) | 1 |
| Brandstofpomp (alternatief) | Bosch-pomp (montage) | |
| Brandstofpomp (alternatief) | Lucas-pomp (montage) | |
Een variant is een ander type artikel, maar deze keer maakt de klant de keuze. Een autokoper kan verschillende carrosserievarianten kiezen:3-deurs, 5-deurs of een stationwagen (stationwagen of wagon). Ze kunnen ook kiezen uit twee verschillende motortypes:een V6 of een V8. In ons voorbeeld moet de koper een keuze maken uit één en slechts één van de samenstellingen onder de variant.
| Artikel | Variant | ||
|---|---|---|---|
| Ouder | Kind | Min keuze | Maximale keuze |
| Auto (montage) | Lichaam (variant) | 1 | 1 |
| Lichaam (variant) | 3-deurs (montage) | ||
| Lichaam (variant) | 5-deurs (montage) | ||
| Lichaam (variant) | Landgoed (montage) | ||
| Auto (montage) | Motor (variant) | 1 | 1 |
| Motor (variant) | V6 (montage) | ||
| Motor (variant) | V8 (montage) | ||
In andere domeinen is het aantal keuzes gevarieerder. Neem als voorbeeld het onderwijs. Om een bepaalde kwalificatie te behalen, moet een student een bepaald aantal groepen voltooien. Per groep kunnen ze kiezen uit meerdere modules.
Stel bijvoorbeeld dat een student twee groepen moet voltooien om een diploma te behalen. Ze kunnen twee modules kiezen uit een lijst van zes om de eerste groep te voltooien. Vervolgens moeten ze drie modules van vijf kiezen om de tweede groep te voltooien. (Als dit een sector is die u in meer detail zou willen zien, is er een flexibel ontwerp gepubliceerd door de Britse Information Standard Board.)
Beide bovenstaande voorbeelden volgen het onderstaande eenvoudige patroon. Dit patroon leent zich voor constructies die vrij statisch zijn. Varianten en alternatieven worden in de hiërarchie ingevoegd om aan te geven dat er een keuze moet worden gemaakt uit de items die er direct onder staan.
Waar dingen de neiging hebben om in de loop van de tijd te veranderen, is het volgende patroon flexibeler en gemakkelijker te onderhouden. Aan de andere kant is het een beetje onpraktisch om te doorkruisen (of te navigeren).
Door het bovenstaande logische model om te zetten in een fysiek model, begint het er als volgt uit te zien:
In dit model is een artikel een ondeelbaar onderdeel of een samenstel. Onderdelen en samenstellingen zijn georganiseerd in hiërarchieën. Echter, alternatieven , varianten en revisies hebben hun eigen verschillende relaties omdat ze in de loop van de tijd nogal wat veranderen. Dit minimaliseert hiërarchie reorganisatie.
Zo blijven autofabrikanten hun auto's continu doorontwikkelen. Hieruit volgt dat onderdeelalternatieven in de loop van de tijd veranderen, evenals de varianten die aan de klant ter beschikking worden gesteld. Wanneer er een wijziging optreedt in een assembly, wordt de assembly herzien. Een revisie geeft de wijzigingsgeschiedenis van het item aan. Beschouw dit voorbeeld:
| Onderdeelnummer | Versie | Voorafgaand | Vervolg |
|---|---|---|---|
| 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 |
Het verhaal voor de bovenstaande tabel gaat als volgt:een item heeft ten minste één revisie - de originele versie. De originele versie van het product wordt gebruikt om de tweede versie te maken. De tweede werd verder ontwikkeld om versie drie te maken, wat niet lukte. Dus de ingenieurs hebben de originele versie herzien en versie vier gemaakt. Ook dit bleek na uitgebreid testen niet ideaal. Dus besloten de ingenieurs om aspecten van de tweede en derde versie te nemen en versie vijf te maken, het uiteindelijke product.
Als u naar de voorgaande en volgende toetsen kijkt, ziet u waarom de wijzigingsgeschiedenis een veel-op-veel nodig heeft relatie tussen items en revisies. Hetzelfde principe is van toepassing op artikelen, alternatieven en varianten.
Een laatste woord over het stuklijstpatroon
Ik hoop dat deze serie artikelen je heeft geholpen het stuklijstpatroon te herkennen. Wanneer het in uw projecten verschijnt, begrijpt u hoe u het het beste kunt modelleren in uw specifieke domein.
Houd er echter rekening mee dat de strikte materiaallijststructuur voor- en nadelen heeft. Pro:hiërarchieën zijn herbruikbaar. Nadeel:hiërarchieën zijn herbruikbaar. Dit kan in jouw geval al dan niet een slechte zaak zijn, maar het is zeker iets om rekening mee te houden.
Het goede is dat hiërarchieën niet in steen gebeiteld hoeven te worden. Met behulp van alternatieven, varianten en revisies kun je domeinen modelleren waar opties bestaan, waar de historische positie behouden moet blijven en uiteindelijk waar verandering de enige constante is.