El patrón de diseño de la lista de materiales es engañosamente simple, pero increíblemente poderoso. Este artículo presentará un ejemplo, familiar para los profesionales de TI, que quizás no haya pensado que se ajusta al patrón de BOM. También presentará conceptos para mostrarle cómo hacer que sus estructuras de listas de materiales sean más flexibles y mucho más fáciles de administrar.
Un breve resumen de la lista de materiales
Una lista de materiales tiene sus raíces en la fabricación. Es una lista de las materias primas, los subensamblajes, los ensamblajes intermedios, los subcomponentes, las piezas y las cantidades de cada uno necesarias para fabricar un producto final.
En su forma más simple, la estructura BOM clásica se ve así:
Sin embargo, el mismo tipo de estructura se puede utilizar para una multitud de propósitos diferentes. , que van desde algo estrictamente jerárquico y fuertemente acoplado hasta algo bastante plano y débilmente acoplado. Para obtener más información sobre la estructura de la lista de materiales, consulte este artículo.
Esquemas:un ejemplo cotidiano
Lo crea o no, el triplete de clase-atributo-tipo y el triplete de tipo tabla-columna también siguen el patrón BOM. El siguiente modelo de datos físicos contiene las tablas principales de un diccionario de datos.
| Tabla | Descripción |
|---|---|
| dd_atributo | Un atributo único, independiente de cualquier implementación. |
| dd_attr_instancia | Una instancia de un atributo. La instancia tiene dos relaciones distintivas: 1) La clase a la que pertenece, que puede ser un objeto lógico o físico. La instancia es única para esta clase. 2) El tipo de datos, que puede ser un tipo nativo u otro tipo de clase. |
| dd_clase | Una clase u objeto en el sentido genérico:la implementación real está dada por class_type – que tiene un conjunto de atributos. |
Un diccionario de datos, o repositorio de metadatos, se define en el IBM Dictionary of Computing como un "repositorio centralizado de información sobre datos como el significado, las relaciones con otros datos, el origen, el uso y el formato".
Ahora considere la siguiente definición de esquema XML (XSD) para una aplicación Java:
Define tipos complejos XSD que tienen los atributos de tipos XML nativos, p. cadena , NMTOKEN , cualquierTipoSimple – u otros tipos complejos.
Para comenzar a completar el diccionario de datos para el XSD anterior, primero debemos ingresar los tipos de datos nativos XML como clases :
| nombre_de_clase | estereotipo |
|---|---|
| booleano | Nativo |
| fecha | Nativo |
| fechaHora | Nativo |
| cadena | Nativo |
| versión | Nativo |
| NMTOKEN | Nativo |
| cualquierTipoSimple | Nativo |
Ahora tenemos todo lo que necesitamos para comenzar a completar nuestro diccionario de datos. En el siguiente ejemplo, se muestra lo suficiente para definir completamente el ConnectionConfigType tipo complejo.
| dd_atributo | of_class (a través de dd_attr_instance) | type_class (a través de dd_attr_instance) | ||
|---|---|---|---|---|
| attr_name | nombre_clase | estereotipo | nombre_clase | estereotipo |
| clave | Tipo de propiedad | XSDcomplexType | cadena | Nativo |
| valor | Tipo de propiedad | XSDcomplexType | cadena | Nativo |
| Propiedad | Tipo de configuración de conexión | XSDcomplexType | Tipo de propiedad | XSDcomplexType |
| nombre de la clase del controlador | Tipo de configuración de conexión | XSDcomplexType | cadena | Nativo |
| usuario | Tipo de configuración de conexión | XSDcomplexType | cadena | Nativo |
| contraseña | Tipo de configuración de conexión | XSDcomplexType | cadena | Nativo |
| nombre del grupo | Tipo de configuración de conexión | XSDcomplexType | cadena | Nativo |
Observe cómo el tipo de datos de ConnectionConfigType.Property atributo es otro tipo complejo, PropertyType . En XML, los tipos complejos pueden estar formados por otros tipos complejos. No es raro encontrar tipos complejos anidados en documentos XML, especialmente en WSDL.
¿Y qué? usted pregunta. Bueno, dado que XML tiene una estructura jerárquica y los tipos complejos se pueden reutilizar, XML sigue naturalmente el patrón BOM .
Y este fenómeno no se limita a XML. Otros esquemas, como los de JSON y bases de datos relacionales de objetos, también siguen el patrón BOM .
Incorporar flexibilidad en una lista de materiales
En la estructura clásica de la lista de materiales del producto, tres conceptos más detallados están involucrados en el modelado de lo que sucede en el mundo real. Estas son alternativas , variantes y revisiones .
Una alternativa es un sustituto de un artículo en particular. Por ejemplo, un fabricante de automóviles puede tener diferentes proveedores para ciertos artículos. En la práctica, esto significa que el fabricante puede obtener bombas de combustible equivalentes de múltiples fuentes. Por lo general, al cliente no se le da esta opción, pero le da flexibilidad al fabricante.
Hemos usado bombas de combustible como elementos en la siguiente tabla de ejemplo, con Bosch y Lucas como alternativas. Tener una bomba de combustible alternativa significa que uno y solo uno de los conjuntos se seleccionarán en el momento de la fabricación del motor.
| Artículo | Alternativa | |
|---|---|---|
| Padre | Niño | Cantidad |
| V6 (ensamblaje) | Bomba de combustible (alternativa) | 1 |
| Bomba de combustible (alternativa) | Bomba Bosch (ensamblaje) | |
| Bomba de combustible (alternativa) | Bomba Lucas (ensamblaje) | |
Una variante es otro tipo de artículo, pero esta vez el cliente hace la elección. El comprador de un automóvil puede elegir diferentes estilos de carrocería:3 puertas, 5 puertas o familiar (camioneta o familiar). También pueden seleccionar entre dos tipos diferentes de motor:un V6 o un V8. En nuestro ejemplo, el comprador debe elegir uno y solo uno de los conjuntos debajo de la variante.
| Artículo | Variante | ||
|---|---|---|---|
| Padre | Niño | Elección mínima | Elección máxima |
| Coche (Montaje) | Cuerpo (variante) | 1 | 1 |
| Cuerpo (Variante) | 3 puertas (ensamblaje) | ||
| Cuerpo (Variante) | 5 puertas (ensamblaje) | ||
| Cuerpo (Variante) | Patrimonio (Asamblea) | ||
| Coche (Montaje) | Motor (Variante) | 1 | 1 |
| Motor (Variante) | V6 (ensamblaje) | ||
| Motor (Variante) | V8 (ensamblaje) | ||
En otros dominios, el número de opciones es más variado. Tomemos como ejemplo la educación. Para obtener una calificación particular, un estudiante debe completar un número determinado de grupos. Para cada grupo, pueden elegir entre varios módulos.
Por ejemplo, suponga que un estudiante necesita completar dos grupos para obtener un diploma. Pueden elegir dos módulos de una lista de seis para completar el primer grupo. Luego, deben elegir tres módulos de cinco para completar el segundo grupo. (Si este es un sector que le gustaría ver con más detalle, la Junta de Normas de Información del Reino Unido ha publicado un diseño flexible).
Ambos ejemplos anteriores siguen el patrón simple que se muestra a continuación. Este patrón se presta a estructuras que son bastante estáticas. Las variantes y alternativas se insertan en la jerarquía para indicar que se debe hacer algún tipo de elección entre los elementos inmediatamente debajo de ellas.
Cuando las cosas tienden a cambiar con el tiempo, el siguiente patrón es más flexible y más fácil de mantener. En el lado negativo, es un poco más difícil de manejar (o navegar).
Al transformar el modelo lógico anterior en un modelo físico, las cosas comienzan a verse así:
En este modelo, un elemento es una pieza indivisible o un conjunto. Las piezas y los ensamblajes se organizan en jerarquías. Sin embargo, alternativas , variantes y revisiones tienen sus propias relaciones distintas porque tienden a cambiar bastante con el tiempo. Esto minimiza la reorganización de la jerarquía.
Por ejemplo, los fabricantes de automóviles desarrollan continuamente sus automóviles. De ello se deduce que las alternativas de piezas cambian con el tiempo, al igual que las variantes que se ponen a disposición del cliente. Cuando se produce un cambio en un ensamblaje, el ensamblaje se revisa. Una revisión indica el historial de cambios del elemento. Considere este ejemplo:
| Número de pieza | Versión | Precedente | Subsiguiente |
|---|---|---|---|
| 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 narrativa de la tabla anterior es la siguiente:un elemento tiene al menos una revisión:su versión original. La versión original del producto se utiliza para crear la segunda versión. El segundo se desarrolló aún más para crear la versión tres, que no funcionó. Así que los ingenieros revisaron la versión original y crearon la versión cuatro. Después de extensas pruebas, también se encontró que esto era menos que ideal. Entonces, los ingenieros decidieron tomar aspectos de la segunda y tercera versión y crear la versión cinco, el producto final.
Si observa las claves anteriores y posteriores, verá por qué el historial de cambios necesita un muchos a muchos relación entre artículos y revisiones. El mismo principio se aplica entre artículos, alternativas y variantes.
Una palabra final sobre el patrón de lista de materiales
Espero que esta serie de artículos le haya ayudado a reconocer el patrón BOM. Cuando aparezca en sus proyectos, comprenderá la mejor manera de modelarlo en su dominio específico.
Sin embargo, tenga en cuenta que la estructura estricta de la lista de materiales tiene ventajas y desventajas. Pro:las jerarquías son reutilizables. Con:las jerarquías son reutilizables. Esto puede o no ser algo malo en su caso, pero sin duda es algo que debe tener en cuenta.
Lo bueno es que las jerarquías no necesitan ser grabadas en piedra. Usando alternativas, variantes y revisiones, puede modelar dominios donde existen opciones, donde se debe conservar la posición histórica y, en última instancia, donde la única constante es el cambio.
