Designmönstret för materialförteckningen är bedrägligt enkelt, men ändå otroligt kraftfullt. Den här artikeln kommer att introducera ett exempel, bekant för IT-proffs, som du kanske inte trodde passade stycklistmönstret. Den kommer också att introducera koncept för att visa dig hur du gör dina stycklistor mer flexibla och mycket lättare att hantera.
En kort sammanfattning av BOM
En materiallista har sina rötter i tillverkningen. Det är en lista över råvaror, underenheter, mellanenheter, underkomponenter, delar och de kvantiteter av varje som behövs för att tillverka en slutprodukt.
I sin enklaste form, den klassiska BOM-strukturen, ser den ut så här:
Men samma typ av struktur kan användas för en mängd olika ändamål , som sträcker sig från något strikt hierarkiskt och tätt kopplat till något ganska platt och löst kopplat. Se den här artikeln för mer information om BOM-strukturen.
Schema – ett vardagsexempel
Tro det eller ej, tripletten av klassattributtyp och tripletten av tabellkolumntyp följer också BOM-mönstret. Den fysiska datamodellen nedan innehåller kärntabellerna i en dataordbok.
| Tabell | Beskrivning |
|---|---|
| dd_attribute | Ett unikt attribut, oberoende av eventuell implementering. |
| dd_attr_instance | En instans av ett attribut. Instansen har två distinkta relationer: 1) Klassen den tillhör, som kan vara ett logiskt eller fysiskt objekt. Förekomsten är unik för den här klassen. 2) Datatypen, som antingen kan vara en inbyggd typ eller en annan klasstyp. |
| dd_klass | En klass eller objekt i generisk mening – den faktiska implementeringen ges av class_type – som har en uppsättning attribut. |
En datadictionary, eller metadatarepository, definieras i IBM Dictionary of Computing som ett "centraliserat arkiv med information om data såsom betydelse, relationer till andra data, ursprung, användning och format".
Tänk nu på följande XML Schema Definition (XSD) för en Java-applikation:
Den definierar XSD-komplexa typer som har attributen för antingen infödda XML-typer – t.ex. sträng , NMTOKEN , anySimpleType – eller andra komplexa typer.
För att börja fylla i datalexikonet för ovanstående XSD måste vi först ange XML infödda datatyper som klasser :
| klassnamn | stereotyp |
|---|---|
| boolesk | Native |
| datum | Native |
| dateTime | Native |
| sträng | Native |
| version | Native |
| NMTOKEN | Native |
| anySimpleType | Native |
Vi har nu allt vi behöver för att börja fylla i vår dataordbok. I exemplet nedan visas precis tillräckligt för att helt definiera ConnectionConfigType komplex typ.
| dd_attribute | of_class (via dd_attr_instance) | type_class (via dd_attr_instance) | ||
|---|---|---|---|---|
| attr_name | klassnamn | stereotyp | klassnamn | stereotyp |
| nyckel | PropertyType | XSDcomplexType | sträng | Native |
| värde | PropertyType | XSDcomplexType | sträng | Native |
| Egendom | ConnectionConfigType | XSDcomplexType | PropertyType | XSDcomplexType |
| förarklassnamn | ConnectionConfigType | XSDcomplexType | sträng | Native |
| användare | ConnectionConfigType | XSDcomplexType | sträng | Native |
| lösenord | ConnectionConfigType | XSDcomplexType | sträng | Native |
| poolnamn | ConnectionConfigType | XSDcomplexType | sträng | Native |
Notera hur datatypen för ConnectionConfigType.Property attribut är en annan komplex typ, PropertyType . I XML kan komplexa typer bestå av andra komplexa typer. Det är inte ovanligt att hitta kapslade komplexa typer i XML-dokument, särskilt i WSDL.
Vad då? du frågar. Tja, med tanke på att XML har en hierarkisk struktur och komplexa typer kan återanvändas, XML följer naturligt stycklistmönstret .
Och detta fenomen är inte begränsat till XML. Andra scheman, som de för JSON och objektrelationella databaser, följer också BOM-mönstret .
Inkludera flexibilitet i en stycklista
I den klassiska produktstyckliststrukturen är tre finare koncept involverade i att modellera vad som händer i den verkliga världen. Dessa är alternativ , varianter och revisioner .
Ett alternativ är ett substitut för ett visst föremål. Till exempel kan en biltillverkare ha olika leverantörer för vissa varor. I praktiken betyder detta att tillverkaren kan få likvärdiga bränslepumpar från flera källor. Vanligtvis ges inte kunden det här alternativet, men det ger tillverkaren flexibilitet.
Vi har använt bränslepumpar som objekt i exempeltabellen nedan, med Bosch och Lucas som alternativ. Att ha ett bränslepumpalternativ innebär att en och bara en av enheterna kommer att väljas vid tidpunkten för motortillverkning.
| Artikel | Alternativ | |
|---|---|---|
| Förälder | Barn | Mängd |
| V6 (montering) | Bränslepump (alternativ) | 1 |
| Bränslepump (alternativ) | Bosch-pump (montering) | |
| Bränslepump (alternativ) | Lucas Pump (montering) | |
En variant är en annan typ av föremål, men den här gången gör kunden valet. En bilköpare kan välja olika karosstyper – 3-dörrars, 5-dörrars eller en herrgård (kombi eller vagn). De kan också välja mellan två olika typer av motorer – en V6 eller en V8. I vårt exempel måste köparen göra ett val av en och endast en av sammansättningarna under varianten.
| Artikel | Variant | ||
|---|---|---|---|
| Förälder | Barn | Minst val | Max valmöjlighet |
| Bil (montering) | Kropp (variant) | 1 | 1 |
| Kropp (variant) | 3-dörr (montering) | ||
| Kropp (variant) | 5-dörr (montering) | ||
| Kropp (variant) | Ejendom (montering) | ||
| Bil (montering) | Motor (variant) | 1 | 1 |
| Motor (variant) | V6 (montering) | ||
| Motor (variant) | V8 (montering) | ||
Inom andra domäner är antalet val mer varierat. Ta utbildning som exempel. För att få en viss kvalifikation måste en student slutföra ett visst antal grupper. För varje grupp kan de välja mellan flera moduler.
Anta till exempel att en elev måste slutföra två grupper för att få ett diplom. De kan välja två moduler från en lista med sex för att slutföra den första gruppen. Sedan måste de välja tre moduler från fem för att slutföra den andra gruppen. (Om det här är en sektor du skulle vilja se mer detaljerat har en flexibel design publicerats av Storbritanniens Information Standard Board.)
Båda exemplen ovan följer det enkla mönstret som visas nedan. Detta mönster lämpar sig för strukturer som är ganska statiska. Varianter och alternativ infogas i hierarkin för att indikera att någon form av val måste göras bland objekten omedelbart under dem.
Där saker och ting tenderar att förändras över tid, är följande mönster mer flexibelt och lättare att underhålla. På minussidan är det lite mer otympligt att korsa (eller navigera).
Genom att omvandla ovanstående logiska modell till en fysisk modell börjar saker och ting se ut så här:
I denna modell är ett föremål antingen en odelbar del eller en sammansättning. Delar och sammansättningar är organiserade i hierarkier. Men alternativ , varianter och revisioner har sina egna distinkta relationer eftersom de tenderar att förändras ganska mycket med tiden. Detta minimerar omorganisering av hierarkin.
Till exempel utvecklar biltillverkarna kontinuerligt sina bilar. Av detta följer att delalternativen förändras över tiden, liksom de varianter som görs tillgängliga för kunden. När en förändring sker i en sammanställning, revideras sammansättningen. En revision anger objektets ändringshistorik. Tänk på det här exemplet:
| Artikelnummer | Version | Föregående | Efterföljande |
|---|---|---|---|
| 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 |
Berättelsen för ovanstående tabell ser ut så här:ett objekt har minst en version – dess ursprungliga version. Den ursprungliga versionen av produkten används för att skapa den andra versionen. Den andra utvecklades vidare för att skapa version tre, vilket inte fungerade. Så ingenjörerna reviderade den ursprungliga versionen och skapade version fyra. Efter omfattande tester visade sig detta också vara mindre än idealiskt. Så ingenjörerna bestämde sig för att ta aspekter av den andra och tredje versionen och skapa version fem, slutprodukten.
Om du tittar på de föregående och efterföljande nycklarna kommer du att se varför förändringshistoriken behöver en många-till-många förhållandet mellan poster och revisioner. Samma princip gäller mellan artiklar, alternativ och varianter.
Ett sista ord om styckmönstret
Min förhoppning är att den här artikelserien har hjälpt dig att känna igen BOM-mönstret. När det dyker upp i dina projekt kommer du att förstå hur du bäst modellerar det i din specifika domän.
Observera dock att den strikta styckstrukturen har för- och nackdelar. Fördel:hierarkier är återanvändbara. Nackdel:hierarkier är återanvändbara. Detta kan vara dåligt i ditt fall eller inte, men det är verkligen något att vara medveten om.
Det som är bra är att hierarkier inte behöver vara huggna i sten. Med hjälp av alternativ, varianter och revisioner kan du modellera domäner där alternativ finns, där den historiska positionen måste behållas och i slutändan där den enda konstanten är förändring.