Styklistens designmønster er vildledende enkelt, men alligevel utroligt kraftfuldt. Denne artikel vil introducere et eksempel, kendt for it-professionelle, som du måske ikke troede passer til styklistemønsteret. Det vil også introducere koncepter for at vise dig, hvordan du gør dine styklistestrukturer mere fleksible og meget nemmere at administrere.
En kort sammenfatning af styklisten
En materialeliste har sine rødder i fremstillingen. Det er en liste over de råmaterialer, underenheder, mellemkonstruktioner, underkomponenter, dele og mængden af hver, der er nødvendig for at fremstille et slutprodukt.
I sin enkleste form, den klassiske styklistestruktur, ser den sådan ud:
Den samme slags struktur kan dog bruges til en lang række forskellige formål , som spænder fra noget strengt hierarkisk og tæt koblet til noget ret fladt og løst koblet. For mere information om styklistestrukturen, se denne artikel.
Skemaer – et hverdagseksempel
Tro det eller ej, klasse-attribut-type-tripletten og tabel-kolonne-type-tripletten følger også styklistemønsteret. Den fysiske datamodel nedenfor indeholder kernetabellerne i en dataordbog.
| Tabel | Beskrivelse |
|---|---|
| dd_attribute | En unik egenskab, uafhængig af enhver implementering. |
| dd_attr_instance | En forekomst af en attribut. Forekomsten har to karakteristiske relationer: 1) Den klasse den tilhører, som kan være et logisk eller fysisk objekt. Forekomsten er unik for denne klasse. 2) Datatypen, som enten kan være en indbygget type eller en anden klassetype. |
| dd_klasse | En klasse eller et objekt i generisk forstand – den faktiske implementering er givet af class_type – der har et sæt attributter. |
En dataordbog eller metadatalager er defineret i IBM Dictionary of Computing som et "centraliseret lager af information om data såsom betydning, relationer til andre data, oprindelse, brug og format".
Overvej nu følgende XML Schema Definition (XSD) for en Java-applikation:
Den definerer XSD-komplekse typer, som har egenskaberne for enten native XML-typer – f.eks. streng , NMTOKEN , anySimpleType – eller andre komplekse typer.
For at begynde at udfylde dataordbogen for ovenstående XSD, skal vi først indtaste XML native datatyper som klasser :
| klassenavn | stereotype |
|---|---|
| boolesk | Native |
| dato | Native |
| datoTid | Native |
| streng | Native |
| version | Native |
| NMTOKEN | Native |
| anySimpleType | Native |
Vi har nu alt, hvad vi behøver for at begynde at udfylde vores dataordbog. I eksemplet nedenfor vises lige nok til fuldt ud at definere ConnectionConfigType kompleks type.
| dd_attribute | of_class (via dd_attr_instance) | type_class (via dd_attr_instance) | ||
|---|---|---|---|---|
| attr_name | klassenavn | stereotype | klassenavn | stereotype |
| tast | Ejendomstype | XSDcomplexType | streng | Native |
| værdi | Ejendomstype | XSDcomplexType | streng | Native |
| Ejendom | ConnectionConfigType | XSDcomplexType | Ejendomstype | XSDcomplexType |
| driverklassenavn | ConnectionConfigType | XSDcomplexType | streng | Native |
| bruger | ConnectionConfigType | XSDcomplexType | streng | Native |
| adgangskode | ConnectionConfigType | XSDcomplexType | streng | Native |
| poolnavn | ConnectionConfigType | XSDcomplexType | streng | Native |
Bemærk hvordan datatypen for ConnectionConfigType.Property attribut er en anden kompleks type, PropertyType . I XML kan komplekse typer bestå af andre komplekse typer. Det er ikke ualmindeligt at finde indlejrede komplekse typer i XML-dokumenter, især i WSDL.
Hvad så? du spørger. I betragtning af at XML er hierarkisk i struktur og komplekse typer kan genbruges, XML følger naturligvis styklistemønstret .
Og dette fænomen er ikke begrænset til XML. Andre skemaer, som dem for JSON og objektrelationelle databaser, følger også styklistemønsteret .
Integrering af fleksibilitet i en stykliste
I den klassiske produktstyklistestruktur er tre finere koncepter involveret i modelleringen af, hvad der sker i den virkelige verden. Disse er alternativer , varianter og revisioner .
Et alternativ er en erstatning for en bestemt vare. For eksempel kan en bilproducent have forskellige leverandører til visse varer. I praksis betyder det, at producenten kan få tilsvarende brændstofpumper fra flere kilder. Normalt får kunden ikke denne mulighed, men det giver producenten fleksibilitet.
Vi har brugt brændstofpumper som elementer i eksempeltabellen nedenfor, med Bosch og Lucas som alternativerne. At have et brændstofpumpealternativ betyder, at en og kun én af samlingerne vil blive udvalgt på tidspunktet for motorens fremstilling.
| Vare | Alternativ | |
|---|---|---|
| Forælder | Barn | Mængde |
| V6 (Samling) | Brændstofpumpe (alternativ) | 1 |
| Brændstofpumpe (alternativ) | Bosch Pumpe (Samling) | |
| Brændstofpumpe (alternativ) | Lucas Pump (Samling) | |
En variant er en anden type vare, men denne gang træffer kunden valget. En bilkøber kan vælge forskellige karrosserityper – 3-dørs, 5-dørs eller stationcar (stationcar eller vogn). De kan også vælge mellem to forskellige motortyper – en V6 eller en V8. I vores eksempel skal køberen vælge én og kun én af samlingerne under varianten.
| Vare | Variant | ||
|---|---|---|---|
| Forælder | Barn | Min. valg | Maksimalt valg |
| Bil (montage) | Krop (variant) | 1 | 1 |
| Krop (variant) | 3-dørs (samling) | ||
| Krop (variant) | 5 dør (samling) | ||
| Krop (variant) | Ejendom (forsamling) | ||
| Bil (montage) | Motor (variant) | 1 | 1 |
| Motor (variant) | V6 (Samling) | ||
| Motor (variant) | V8 (Samling) | ||
På andre domæner er antallet af valg mere varieret. Tag uddannelse som eksempel. For at opnå en bestemt kvalifikation skal en studerende gennemføre et bestemt antal grupper. For hver gruppe kan de vælge mellem flere moduler.
Antag for eksempel, at en studerende skal gennemføre to grupper for at få et eksamensbevis. De kan vælge to moduler fra en liste på seks for at fuldføre den første gruppe. Derefter skal de vælge tre moduler fra fem for at fuldføre den anden gruppe. (Hvis dette er en sektor, du gerne vil se mere detaljeret, er et fleksibelt design blevet offentliggjort af UK's Information Standard Board.)
Begge ovenstående eksempler følger det enkle mønster vist nedenfor. Dette mønster egner sig til strukturer, der er ret statiske. Varianter og alternativer er indsat i hierarkiet for at indikere, at der skal foretages en eller anden form for valg blandt emnerne umiddelbart under dem.
Hvor ting har en tendens til at ændre sig over tid, så er følgende mønster mere fleksibelt og lettere at vedligeholde. På den negative side er det lidt mere uhåndterligt at krydse (eller navigere).
Ved at transformere ovenstående logiske model til en fysisk model, begynder tingene at se sådan ud:
I denne model er en genstand enten en udelelig del eller en samling. Dele og samlinger er organiseret i hierarkier. Dog alternativer , varianter og revisioner har deres egne særskilte forhold, fordi de har tendens til at ændre sig en del over tid. Dette minimerer hierarki omorganisering.
For eksempel udvikler bilproducenter løbende deres biler. Det følger heraf, at delalternativer ændrer sig over tid, ligesom de varianter, der stilles til rådighed for kunden. Når der sker en ændring i en samling, bliver samlingen revideret. En revision angiver ændringshistorikken for elementet. Overvej dette eksempel:
| Artikelnummer | Version | Forudgående | Efterfølgende |
|---|---|---|---|
| 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 |
Fortællingen for ovenstående tabel lyder sådan her:et element har mindst én revision - dens originale version. Den originale version af produktet bruges til at skabe den anden version. Den anden blev videreudviklet til at skabe version tre, som ikke fungerede. Så ingeniørerne reviderede den originale version og skabte version fire. Efter omfattende test viste dette sig også at være mindre end ideelt. Så ingeniørerne besluttede at tage aspekter af den anden og tredje version og skabe version fem, det endelige produkt.
Hvis du ser på de foregående og efterfølgende nøgler, vil du se, hvorfor ændringshistorikken har brug for en mange-til-mange forhold mellem elementer og revisioner. Det samme princip gælder mellem varer, alternativer og varianter.
Et sidste ord om styklistemønstret
Mit håb er, at denne serie af artikler har hjulpet dig med at genkende styklistemønstret. Når det vises i dine projekter, vil du forstå, hvordan du bedst modellerer det i dit specifikke domæne.
Bemærk dog, at den strenge styklistestruktur har fordele og ulemper. Fordel:hierarkier kan genbruges. Ulemper:hierarkier kan genbruges. Dette er måske eller måske ikke en dårlig ting i dit tilfælde, men det er bestemt noget, du skal være opmærksom på.
Det gode er, at hierarkier ikke behøver at være hugget i sten. Ved at bruge alternativer, varianter og revisioner kan du modellere domæner, hvor der findes muligheder, hvor den historiske position skal bibeholdes, og i sidste ende hvor den eneste konstant er forandring.