Pola desain bill of material tampak sederhana, namun sangat kuat. Artikel ini akan memperkenalkan sebuah contoh, yang akrab bagi para profesional TI, yang mungkin menurut Anda tidak sesuai dengan pola BOM. Ini juga akan memperkenalkan konsep untuk menunjukkan kepada Anda bagaimana membuat struktur BOM Anda lebih fleksibel dan lebih mudah untuk dikelola.
Rekap Singkat BOM
tagihan bahan berakar pada manufaktur. Ini adalah daftar bahan mentah, sub-rakitan, rakitan antara, sub-komponen, suku cadang, dan jumlah masing-masing yang dibutuhkan untuk memproduksi produk akhir.
Dalam bentuknya yang paling sederhana, struktur BOM klasik terlihat seperti ini:
Namun, jenis struktur yang sama dapat digunakan untuk banyak tujuan berbeda , yang berkisar dari sesuatu yang sangat hierarkis dan digabungkan dengan erat hingga sesuatu yang cukup datar dan digabungkan secara longgar. Untuk informasi lebih lanjut tentang struktur BOM, lihat artikel ini.
Skema – Contoh Sehari-hari
Percaya atau tidak, triplet tipe-kelas-atribut dan triplet tipe-tabel juga mengikuti pola BOM. Model data fisik di bawah ini berisi tabel inti dari kamus data.
| Tabel | Deskripsi |
|---|---|
| dd_attribute | Atribut unik, tidak bergantung pada implementasi apa pun. |
| dd_attr_instance | Sebuah instance dari sebuah atribut. Instance memiliki dua hubungan yang berbeda: 1) Kelas yang dimilikinya, yang dapat berupa objek logis atau fisik. Instance unik untuk kelas ini. 2) Tipe data, yang dapat berupa tipe asli atau tipe kelas lainnya. |
| dd_class | Kelas atau objek dalam pengertian umum – implementasi aktual diberikan oleh class_type – yang memiliki sekumpulan atribut. |
Kamus data, atau repositori metadata, didefinisikan dalam IBM Dictionary of Computing sebagai "penyimpanan informasi terpusat tentang data seperti makna, hubungan dengan data lain, asal, penggunaan, dan format".
Sekarang perhatikan Definisi Skema XML (XSD) berikut untuk aplikasi Java:
Ini mendefinisikan tipe kompleks XSD yang memiliki atribut baik tipe XML asli – mis. string , NMTOKEN , anySimpleType – atau tipe kompleks lainnya.
Untuk mulai mengisi kamus data untuk XSD di atas, pertama-tama kita harus memasukkan tipe data asli sebagai kelas XML :
| nama_kelas | stereotipe |
|---|---|
| boolean | Asli |
| tanggal | Asli |
| tanggalWaktu | Asli |
| string | Asli |
| versi | Asli |
| NMTOKEN | Asli |
| anySimpleType | Asli |
Kami sekarang memiliki semua yang kami butuhkan untuk mulai mengisi kamus data kami. Pada contoh di bawah ini, cukup ditunjukkan untuk mendefinisikan ConnectionConfigType . secara lengkap tipe kompleks.
| dd_attribute | of_class (melalui dd_attr_instance) | type_class (melalui dd_attr_instance) | ||
|---|---|---|---|---|
| attr_name | nama_kelas | stereotipe | nama_kelas | stereotipe |
| kunci | Tipe Properti | XSDcomplexType | string | Asli |
| nilai | Tipe Properti | XSDcomplexType | string | Asli |
| Properti | ConnectionConfigType | XSDcomplexType | Tipe Properti | XSDcomplexType |
| driverClassName | ConnectionConfigType | XSDcomplexType | string | Asli |
| pengguna | ConnectionConfigType | XSDcomplexType | string | Asli |
| sandi | ConnectionConfigType | XSDcomplexType | string | Asli |
| poolName | ConnectionConfigType | XSDcomplexType | string | Asli |
Perhatikan bagaimana tipe data dari ConnectionConfigType.Property atribut adalah tipe kompleks lainnya, PropertyType . Dalam XML, tipe kompleks dapat dibuat dari tipe kompleks lainnya. Tidak jarang menemukan tipe kompleks bersarang dalam dokumen XML, terutama di WSDL.
Jadi apa? Anda bertanya. Nah, mengingat XML adalah hierarki dalam struktur dan tipe kompleks dapat digunakan kembali, XML secara alami mengikuti pola BOM .
Dan fenomena ini tidak terbatas pada XML. Skema lain, seperti skema untuk JSON dan database relasional objek, ikuti pola BOM juga .
Menggabungkan Fleksibilitas dalam BOM
Dalam struktur BOM produk klasik, tiga konsep yang lebih halus terlibat dalam pemodelan apa yang terjadi di dunia nyata. Ini adalah alternatif , varian , dan revisi .
Sebuah alternatif adalah pengganti barang tertentu. Misalnya, produsen mobil mungkin memiliki pemasok yang berbeda untuk barang-barang tertentu. Secara praktis, ini berarti pabrikan dapat memperoleh pompa bahan bakar yang setara dari berbagai sumber. Biasanya, pelanggan tidak diberikan opsi ini, tetapi memberikan fleksibilitas kepada produsen.
Kami telah menggunakan pompa bahan bakar sebagai item dalam tabel contoh di bawah ini, dengan Bosch dan Lucas sebagai alternatifnya. Memiliki alternatif pompa bahan bakar berarti satu-satunya rakitan akan dipilih pada saat pembuatan mesin.
| Item | Alternatif | |
|---|---|---|
| Induk | Anak | Kuantitas |
| V6 (Perakitan) | Pompa Bahan Bakar (Alternatif) | 1 |
| Pompa Bahan Bakar (Alternatif) | Pompa Bosch (Perakitan) | |
| Pompa Bahan Bakar (Alternatif) | Pompa Lucas (Perakitan) | |
Sebuah varian adalah jenis barang lain, tetapi kali ini pelangganlah yang menentukan pilihan. Pembeli mobil dapat memilih gaya bodi yang berbeda – 3 pintu, 5 pintu, atau estate (station wagon atau wagon). Mereka juga dapat memilih dari dua jenis mesin yang berbeda – V6 atau V8. Dalam contoh kita, pembeli harus memilih satu dan hanya satu rakitan di bawah varian.
| Item | Variasi | ||
|---|---|---|---|
| Induk | Anak | Pilihan Minimal | Pilihan Maks |
| Mobil (Perakitan) | Body (Varian) | 1 | 1 |
| Body (Varian) | 3 Pintu (Perakitan) | ||
| Body (Varian) | 5 Pintu (Perakitan) | ||
| Body (Varian) | Estate (Perakitan) | ||
| Mobil (Perakitan) | Mesin (Varian) | 1 | 1 |
| Mesin (Varian) | V6 (Perakitan) | ||
| Mesin (Varian) | V8 (Perakitan) | ||
Di domain lain, jumlah pilihannya lebih bervariasi. Ambillah pendidikan sebagai contoh. Untuk mendapatkan kualifikasi tertentu, seorang siswa harus menyelesaikan sejumlah kelompok. Untuk setiap kelompok, mereka dapat memilih dari beberapa modul.
Misalnya, seorang siswa perlu menyelesaikan dua kelompok untuk mendapatkan ijazah. Mereka dapat memilih dua modul dari daftar enam untuk menyelesaikan kelompok pertama. Kemudian, mereka harus memilih tiga modul dari lima untuk menyelesaikan kelompok kedua. (Jika ini adalah sektor yang ingin Anda lihat lebih detail, desain yang fleksibel telah diterbitkan oleh Dewan Standar Informasi Inggris.)
Kedua contoh di atas mengikuti pola sederhana yang ditunjukkan di bawah ini. Pola ini cocok untuk struktur yang cukup statis. Varian dan alternatif dimasukkan ke dalam hierarki untuk menunjukkan bahwa semacam pilihan harus dibuat dari item tepat di bawahnya.
Di mana hal-hal cenderung berubah dari waktu ke waktu, maka pola berikut lebih fleksibel dan lebih mudah untuk dipertahankan. Sisi negatifnya, ini sedikit lebih berat untuk dilintasi (atau dinavigasi).
Dengan mengubah model logika di atas menjadi model fisik, hal-hal mulai terlihat seperti ini:
Dalam model ini, item adalah bagian yang tidak dapat dibagi atau rakitan. Bagian dan rakitan diatur ke dalam hierarki. Namun, alternatif , varian dan revisi memiliki hubungan mereka sendiri yang berbeda karena mereka cenderung berubah sedikit dari waktu ke waktu. Ini meminimalkan reorganisasi hierarki.
Misalnya, produsen mobil terus mengembangkan mobilnya. Oleh karena itu, alternatif suku cadang berubah dari waktu ke waktu, seperti halnya varian yang tersedia bagi pelanggan. Ketika perubahan terjadi dalam perakitan, perakitan akan direvisi. Sebuah revisi menunjukkan riwayat perubahan item. Perhatikan contoh ini:
| Nomor Bagian | Versi | Sebelumnya | Selanjutnya |
|---|---|---|---|
| 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 |
Narasi untuk tabel di atas berjalan seperti ini:item memiliki setidaknya satu revisi – versi aslinya. Versi asli produk digunakan untuk membuat versi kedua. Yang kedua dikembangkan lebih lanjut untuk membuat versi tiga, yang tidak berhasil. Jadi para insinyur merevisi versi aslinya, membuat versi empat. Setelah pengujian ekstensif, ini juga ditemukan kurang ideal. Jadi para insinyur memutuskan untuk mengambil aspek dari versi kedua dan ketiga dan membuat versi lima, produk akhir.
Jika Anda melihat kunci sebelumnya dan berikutnya, Anda akan melihat mengapa riwayat perubahan memerlukan banyak-ke-banyak hubungan antara item dan revisi. Prinsip yang sama berlaku antara item, alternatif, dan varian.
Kata Terakhir Tentang Pola Bill of Materials
Harapan saya adalah rangkaian artikel ini telah membantu Anda mengenali pola BOM. Saat muncul di proyek Anda, Anda akan memahami cara terbaik untuk memodelkannya di domain spesifik Anda.
Harap dicatat, bahwa struktur bill of material yang ketat memiliki pro dan kontra. Pro:hierarki dapat digunakan kembali. Con:hierarki dapat digunakan kembali. Ini mungkin atau mungkin bukan hal yang buruk dalam kasus Anda, tetapi ini pasti sesuatu yang harus diperhatikan.
Hal baiknya adalah hierarki tidak perlu dibuat kaku. Dengan menggunakan alternatif, varian, dan revisi, Anda dapat memodelkan domain di mana opsi ada, di mana posisi historis harus dipertahankan, dan akhirnya di mana satu-satunya konstanta adalah perubahan.
