Il modello di progettazione della distinta base è ingannevolmente semplice, ma incredibilmente potente. Questo articolo introdurrà un esempio, familiare ai professionisti IT, che potresti non aver ritenuto adatto al modello della distinta base. Introdurrà anche concetti per mostrarti come rendere le tue strutture BOM più flessibili e molto più facili da gestire.
Un breve riepilogo della distinta base
Una distinta materiali ha le sue radici nella produzione. È un elenco di materie prime, sottoassiemi, assiemi intermedi, sottocomponenti, parti e le quantità di ciascuno necessarie per fabbricare un prodotto finale.
Nella sua forma più semplice, la classica struttura della distinta base si presenta così:
Tuttavia, lo stesso tipo di struttura può essere utilizzato per una moltitudine di scopi diversi , che vanno da qualcosa di strettamente gerarchico e strettamente accoppiato a qualcosa di abbastanza piatto e di accoppiamento lasco. Per ulteriori informazioni sulla struttura della distinta base, consulta questo articolo.
Schemi:un esempio quotidiano
Che ci crediate o no, anche la tripletta di tipo attributo classe e la tripletta di tipo colonna tabella seguono lo schema della distinta base. Il modello di dati fisici riportato di seguito contiene le tabelle principali di un dizionario di dati.
| Tabella | Descrizione |
|---|---|
| attributo_dd | Un attributo univoco, indipendente da qualsiasi implementazione. |
| dd_attr_istanza | Un'istanza di un attributo. L'istanza ha due relazioni distintive: 1) La classe a cui appartiene, che può essere un oggetto logico o fisico. L'istanza è univoca per questa classe. 2) Il tipo di dati, che può essere un tipo nativo o un altro tipo di classe. |
| dd_class | Una classe o un oggetto in senso generico:l'effettiva implementazione è data da class_type – che ha una serie di attributi. |
Un dizionario di dati, o repository di metadati, è definito in IBM Dictionary of Computing come un "repository centralizzato di informazioni sui dati come significato, relazioni con altri dati, origine, utilizzo e formato".
Consideriamo ora la seguente XML Schema Definition (XSD) per un'applicazione Java:
Definisce tipi complessi XSD che hanno gli attributi di entrambi i tipi XML nativi, ad es. stringa , NMTOKEN , qualsiasiTipoSimple – o altri tipi complessi.
Per iniziare a popolare il dizionario dei dati per l'XSD sopra, dobbiamo prima inserire i tipi di dati nativi come classi XML :
| class_name | stereotipo |
|---|---|
| booleano | Nativo |
| data | Nativo |
| dateTime | Nativo |
| stringa | Nativo |
| versione | Nativo |
| NMTOKEN | Nativo |
| qualsiasiTipoSimple | Nativo |
Ora abbiamo tutto ciò di cui abbiamo bisogno per iniziare a popolare il nostro dizionario di dati. Nell'esempio seguente, viene mostrato quanto basta per definire completamente il ConnectionConfigType tipo complesso.
| dd_attribute | of_class (tramite dd_attr_instance) | type_class (tramite dd_attr_instance) | ||
|---|---|---|---|---|
| attr_name | nome_classe | stereotipo | nome_classe | stereotipo |
| chiave | Tipo proprietà | Tipo complesso XSD | stringa | Nativo |
| valore | Tipo proprietà | Tipo complesso XSD | stringa | Nativo |
| Proprietà | TipoConfigConnessione | Tipo complesso XSD | Tipo proprietà | Tipo complesso XSD |
| driverClassName | TipoConfigConnessione | Tipo complesso XSD | stringa | Nativo |
| utente | TipoConfigConnessione | Tipo complesso XSD | stringa | Nativo |
| password | TipoConfigConnessione | Tipo complesso XSD | stringa | Nativo |
| nomepiscina | TipoConfigConnessione | Tipo complesso XSD | stringa | Nativo |
Nota come il tipo di dati di ConnectionConfigType.Property l'attributo è un altro tipo complesso, PropertyType . In XML, i tipi complessi possono essere costituiti da altri tipi complessi. Non è raro trovare tipi complessi nidificati nei documenti XML, specialmente in WSDL.
E allora? tu chiedi. Bene, dato che XML ha una struttura gerarchica e tipi complessi possono essere riutilizzati, XML segue naturalmente il modello BOM .
E questo fenomeno non si limita all'XML. Anche altri schemi, come quelli per JSON e database relazionali a oggetti, seguono il modello BOM .
Incorporare la flessibilità in una distinta base
Nella classica struttura della distinta base del prodotto, tre concetti a grana più fine sono coinvolti nella modellazione di ciò che accade nel mondo reale. Queste sono alternative , varianti e revisioni .
Un'alternativa è un sostituto di un particolare articolo. Ad esempio, una casa automobilistica può avere fornitori diversi per determinati articoli. In pratica, ciò significa che il produttore può ottenere pompe del carburante equivalenti da più fonti. Di solito, al cliente non viene offerta questa opzione, ma offre flessibilità al produttore.
Abbiamo utilizzato le pompe del carburante come elementi nella tabella di esempio seguente, con Bosch e Lucas come alternative. Avere un'alternativa alla pompa del carburante significa quella una e una sola degli assiemi saranno selezionati al momento della fabbricazione del motore.
| Articolo | Alternativa | |
|---|---|---|
| Genitore | Bambino | Quantità |
| V6 (Assemblaggio) | Pompa carburante (alternativa) | 1 |
| Pompa carburante (alternativa) | Pompa Bosch (montaggio) | |
| Pompa carburante (alternativa) | Pompa Lucas (montaggio) | |
Una variante è un altro tipo di articolo, ma questa volta è il cliente a scegliere. Un acquirente di auto può scegliere diversi stili di carrozzeria:3 porte, 5 porte o station wagon (station wagon o station wagon). Possono anche scegliere tra due diversi tipi di motore:un V6 o un V8. Nel nostro esempio, l'acquirente deve scegliere uno e solo uno degli assiemi sotto la variante.
| Articolo | Variante | ||
|---|---|---|---|
| Genitore | Bambino | Scelta minima | Scelta massima |
| Auto (montaggio) | Corpo (Variante) | 1 | 1 |
| Corpo (Variante) | 3 porte (montaggio) | ||
| Corpo (Variante) | 5 porte (montaggio) | ||
| Corpo (Variante) | Proprietà (Assemblea) | ||
| Auto (montaggio) | Motore (Variante) | 1 | 1 |
| Motore (Variante) | V6 (Assemblaggio) | ||
| Motore (Variante) | V8 (Assemblaggio) | ||
In altri domini, il numero di scelte è più vario. Prendi l'istruzione come esempio. Per ottenere una qualifica particolare, uno studente deve completare un determinato numero di gruppi. Per ogni gruppo, possono scegliere tra diversi moduli.
Ad esempio, supponiamo che uno studente debba completare due gruppi per ottenere un diploma. Possono scegliere due moduli da un elenco di sei per completare il primo gruppo. Quindi, devono scegliere tre moduli tra cinque per completare il secondo gruppo. (Se questo è un settore che vorresti vedere più in dettaglio, un design flessibile è stato pubblicato dall'Information Standard Board del Regno Unito.)
Entrambi gli esempi sopra seguono lo schema semplice mostrato di seguito. Questo modello si presta a strutture abbastanza statiche. Varianti e alternative vengono inserite nella gerarchia per indicare che è necessario effettuare una sorta di scelta dagli elementi immediatamente sottostanti.
Laddove le cose tendono a cambiare nel tempo, lo schema seguente è più flessibile e più facile da mantenere. Il lato negativo è che è un po' più ingombrante da attraversare (o navigare).
Trasformando il modello logico sopra in un modello fisico, le cose iniziano ad apparire così:
In questo modello, un articolo è una parte indivisibile o un assieme. Le parti e gli assiemi sono organizzati in gerarchie. Tuttavia, alternative , varianti e revisioni hanno le loro relazioni distinte perché tendono a cambiare un po' nel tempo. Ciò riduce al minimo la riorganizzazione della gerarchia.
Ad esempio, le case automobilistiche sviluppano continuamente le loro auto. Ne consegue che le alternative dei pezzi cambiano nel tempo, così come le varianti messe a disposizione del cliente. Quando si verifica una modifica in un assieme, l'assieme viene rivisto. Una revisione indica la cronologia delle modifiche dell'articolo. Considera questo esempio:
| Numero parte | Versione | Precedenti | Successivo |
|---|---|---|---|
| 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 |
La narrazione per la tabella sopra è questa:un articolo ha almeno una revisione:la sua versione originale. La versione originale del prodotto viene utilizzata per creare la seconda versione. Il secondo è stato ulteriormente sviluppato per creare la versione tre, che non ha funzionato. Quindi gli ingegneri hanno rivisto la versione originale, creando la versione quattro. Dopo numerosi test, anche questo è risultato essere tutt'altro che ideale. Quindi gli ingegneri hanno deciso di prendere aspetti della seconda e della terza versione e creare la versione cinque, il prodotto finale.
Se guardi le chiavi precedenti e successive, vedrai perché la cronologia delle modifiche ha bisogno di un molti-a-molti rapporto tra voci e revisioni. Lo stesso principio si applica tra articoli, alternative e varianti.
Un'ultima parola sul modello della distinta base
La mia speranza è che questa serie di articoli ti abbia aiutato a riconoscere il modello della distinta base. Quando apparirà nei tuoi progetti, capirai come modellarlo al meglio nel tuo dominio specifico.
Tieni presente, tuttavia, che la rigida struttura della distinta base presenta pro e contro. Pro:le gerarchie sono riutilizzabili. Contro:le gerarchie sono riutilizzabili. Questo potrebbe essere o meno un aspetto negativo nel tuo caso, ma è sicuramente qualcosa di cui essere consapevoli.
La cosa buona è che le gerarchie non hanno bisogno di essere scolpite nella pietra. Utilizzando alternative, varianti e revisioni, puoi modellare domini dove esistono opzioni, dove è necessario mantenere la posizione storica e, infine, dove l'unica costante è il cambiamento.
