O padrão de design da lista de materiais é enganosamente simples, mas incrivelmente poderoso. Este artigo apresentará um exemplo, familiar aos profissionais de TI, que você pode não ter pensado que se encaixa no padrão BOM. Ele também apresentará conceitos para mostrar como tornar suas estruturas de BOM mais flexíveis e muito mais fáceis de gerenciar.
Uma breve recapitulação do BOM
Uma lista de materiais tem suas raízes na fabricação. É uma lista das matérias-primas, subconjuntos, conjuntos intermediários, subcomponentes, peças e as quantidades de cada um necessário para fabricar um produto final.
Em sua forma mais simples, a estrutura clássica da BOM se parece com isso:
No entanto, o mesmo tipo de estrutura pode ser usado para vários fins diferentes , que variam de algo estritamente hierárquico e fortemente acoplado a algo bastante plano e fracamente acoplado. Para obter mais informações sobre a estrutura da BOM, consulte este artigo.
Esquemas – um exemplo diário
Acredite ou não, o trio do tipo atributo de classe e o trio do tipo coluna de tabela também seguem o padrão BOM. O modelo de dados físicos abaixo contém as tabelas principais de um dicionário de dados.
| Tabela | Descrição |
|---|---|
| dd_attribute | Um atributo único, independente de qualquer implementação. |
| dd_attr_instance | Uma instância de um atributo. A instância possui dois relacionamentos distintos: 1) A classe à qual ela pertence, que pode ser um objeto lógico ou físico. A instância é exclusiva para esta classe. 2) O tipo de dados, que pode ser um tipo nativo ou outro tipo de classe. |
| dd_class | Uma classe ou objeto no sentido genérico – a implementação real sendo dada por class_type – que tem um conjunto de atributos. |
Um dicionário de dados, ou repositório de metadados, é definido no IBM Dictionary of Computing como um "repositório centralizado de informações sobre dados, como significado, relacionamentos com outros dados, origem, uso e formato".
Agora considere a seguinte XML Schema Definition (XSD) para um aplicativo Java:
Ele define tipos complexos XSD que possuem os atributos de qualquer tipo XML nativo – por exemplo, cadeia , NMTOKEN , qualquerSimpleType – ou outros tipos complexos.
Para começar a preencher o dicionário de dados para o XSD acima, primeiro precisamos inserir o XML tipos de dados nativos como classes :
| class_name | estereótipo |
|---|---|
| booleano | Nativo |
| data | Nativo |
| dataHora | Nativo |
| cadeia | Nativo |
| versão | Nativo |
| NMTOKEN | Nativo |
| anySimpleType | Nativo |
Agora temos tudo o que precisamos para começar a preencher nosso dicionário de dados. No exemplo abaixo, apenas o suficiente é mostrado para definir completamente o ConnectionConfigType tipo complexo.
| dd_attribute | of_class (via dd_attr_instance) | type_class (via dd_attr_instance) | ||
|---|---|---|---|---|
| attr_name | class_name | estereótipo | class_name | estereótipo |
| chave | Tipo de propriedade | XSDcomplexType | cadeia | Nativo |
| valor | Tipo de propriedade | XSDcomplexType | cadeia | Nativo |
| Propriedade | ConnectionConfigType | XSDcomplexType | Tipo de propriedade | XSDcomplexType |
| driverClassName | ConnectionConfigType | XSDcomplexType | cadeia | Nativo |
| usuário | ConnectionConfigType | XSDcomplexType | cadeia | Nativo |
| senha | ConnectionConfigType | XSDcomplexType | cadeia | Nativo |
| Nome do pool | ConnectionConfigType | XSDcomplexType | cadeia | Nativo |
Observe como o tipo de dados do
ConnectionConfigType.Property atributo é outro tipo complexo, PropertyType . Em XML, tipos complexos podem ser compostos de outros tipos complexos. Não é incomum encontrar tipos complexos aninhados em documentos XML, especialmente em WSDL. E daí? você pergunta. Bem, dado que XML é hierárquico em estrutura e tipos complexos podem ser reutilizados, XML segue naturalmente o padrão BOM .
E esse fenômeno não se limita ao XML. Outros esquemas, como os de bancos de dados JSON e relacionais de objeto, também seguem o padrão BOM .
Incorporando flexibilidade em um BOM
Na estrutura clássica da BOM do produto, três conceitos mais refinados estão envolvidos na modelagem do que acontece no mundo real. Estas são alternativas , variantes e revisões .
Uma alternativa é um substituto para um item específico. Por exemplo, um fabricante de automóveis pode ter fornecedores diferentes para determinados itens. Praticamente, isso significa que o fabricante pode obter bombas de combustível equivalentes de várias fontes. Normalmente, o cliente não tem essa opção, mas dá flexibilidade ao fabricante.
Usamos bombas de combustível como itens na tabela de exemplo abaixo, com Bosch e Lucas como alternativas. Ter uma alternativa de bomba de combustível significa que uma e apenas uma dos conjuntos serão selecionados no momento da fabricação do motor.
| Item | Alternativa | |
|---|---|---|
| Pai | Filho | Quantidade |
| V6 (Montagem) | Bomba de combustível (alternativa) | 1 |
| Bomba de combustível (alternativa) | Bomba Bosch (Montagem) | |
| Bomba de combustível (alternativa) | Bomba Lucas (Montagem) | |
Uma variante é outro tipo de item, mas desta vez o cliente faz a escolha. Um comprador de carro pode escolher diferentes estilos de carroceria – 3 portas, 5 portas ou uma perua (perua ou perua). Eles também podem selecionar entre dois tipos diferentes de motor – um V6 ou um V8. Em nosso exemplo, o comprador deve escolher um e apenas um dos conjuntos abaixo da variante.
| Item | Variante | ||
|---|---|---|---|
| Pai | Filho | Escolha mínima | Escolha máxima |
| Carro (Montagem) | Corpo (Variante) | 1 | 1 |
| Corpo (Variante) | 3 Portas (Montagem) | ||
| Corpo (Variante) | 5 Portas (Montagem) | ||
| Corpo (Variante) | Propriedade (Montagem) | ||
| Carro (Montagem) | Motor (Variante) | 1 | 1 |
| Motor (Variante) | V6 (Montagem) | ||
| Motor (Variante) | V8 (Montagem) | ||
Em outros domínios, o número de escolhas é mais variado. Tome a educação como exemplo. Para obter uma qualificação específica, o aluno deve concluir um determinado número de grupos. Para cada grupo, eles podem escolher entre vários módulos.
Por exemplo, suponha que um aluno precise completar dois grupos para obter um diploma. Eles podem escolher dois módulos de uma lista de seis para completar o primeiro grupo. Em seguida, eles devem escolher três módulos de cinco para completar o segundo grupo. (Se este for um setor que você gostaria de ver com mais detalhes, um design flexível foi publicado pelo Conselho de Padrões de Informação do Reino Unido.)
Ambos os exemplos acima seguem o padrão simples mostrado abaixo. Esse padrão se presta a estruturas bastante estáticas. Variantes e alternativas são inseridas na hierarquia para indicar que algum tipo de escolha deve ser feita a partir dos itens imediatamente abaixo deles.
Onde as coisas tendem a mudar com o tempo, o padrão a seguir é mais flexível e mais fácil de manter. No lado negativo, é um pouco mais difícil de percorrer (ou navegar).
Ao transformar o modelo lógico acima em um modelo físico, as coisas começam a ficar assim:
Neste modelo, um item é uma peça indivisível ou uma montagem. As peças e montagens são organizadas em hierarquias. No entanto, alternativas , variantes e revisões têm seus próprios relacionamentos distintos, porque eles tendem a mudar um pouco ao longo do tempo. Isso minimiza a reorganização da hierarquia.
Por exemplo, os fabricantes de automóveis desenvolvem continuamente seus carros. Segue-se que as alternativas de peças mudam ao longo do tempo, assim como as variantes disponibilizadas ao cliente. Quando ocorre uma alteração em uma montagem, a montagem é revisada. Uma revisão indica o histórico de alterações do item. Considere este exemplo:
| Número da peça | Versão | Antecedentes | Seguinte |
|---|---|---|---|
| 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 |
A narrativa para a tabela acima é assim:um item tem pelo menos uma revisão – sua versão original. A versão original do produto é usada para criar a segunda versão. O segundo foi desenvolvido para criar a versão três, que não deu certo. Assim, os engenheiros revisaram a versão original, criando a versão quatro. Após testes extensivos, isso também foi considerado abaixo do ideal. Então os engenheiros decidiram pegar aspectos da segunda e terceira versões e criar a versão cinco, o produto final.
Se você observar as chaves anteriores e subsequentes, verá por que o histórico de alterações precisa de um muitos-para-muitos relação entre itens e revisões. O mesmo princípio se aplica entre itens, alternativas e variantes.
Uma palavra final sobre o padrão da lista de materiais
Minha esperança é que esta série de artigos tenha ajudado você a reconhecer o padrão BOM. Quando ele aparecer em seus projetos, você entenderá a melhor forma de modelá-lo em seu domínio específico.
Observe, porém, que a estrutura rígida da lista de materiais tem prós e contras. Pró:as hierarquias são reutilizáveis. Contra:as hierarquias são reutilizáveis. Isso pode ou não ser uma coisa ruim no seu caso, mas certamente é algo que você deve estar ciente.
O bom é que as hierarquias não precisam ser imutáveis. Usando alternativas, variantes e revisões, você pode modelar domínios onde existem opções, onde a posição histórica deve ser mantida e, finalmente, onde a única constante é a mudança.
