Menguerti Diagram Alur Data: Hierarki, Niat, dan Aturan Keseimbangan

Pendahuluan

1. Blok Bangunan Inti: Kosakata DFD

Sebelum masuk ke tingkat dan jenis, Anda memerlukan empat simbol fundamental yang menyusun setiap DFD. Simbol-simbol ini konsisten di semua notasi (Yourdon/DeMarco, Gane & Sarson, SSADM) — mereka hanya berbeda dalam bentuk.

Konvensi penamaan (krusial untuk kejelasan):

• Proses: nomor + frasa kata kerja → 1.0 Validasi Pesanan, 2.0 Periksa Stok. Angkapenomoran adalah yang memungkinkan dekomposisi (proses 2.0 dipecah menjadi 2.1, 2.2, 2.3…).

• Penyimpanan Data: nomor + frasa kata benda → D1 Pelanggan, D2 Stok.

• Aliran data: deskriptor singkat dari konten data → Permintaan Pesanan, Verifikasi Pembayaran, Penghitungan Stok.

2. Hierarki Tingkat (Abstraksi melalui Dekomposisi)

Ide inti dari DFD bertingkat adalah dekomposisi dari atas ke bawah: Anda mulai dengan satu gelembung buram dan secara rekursif mengungkap bagian dalamnya hingga setiap proses menjadi sangat sederhana.

2.1 Diagram Konteks (Tingkat 0)

• Abstraksi: Tingkat tertinggi yang mungkin — seluruh sistem adalah satu proses.

• Apa yang ditampilkan: Entitas eksternal, dan aliran data yang menghubungkannya dengan gelembung sistem tunggal. Hanya itu.

• Apa yang sengaja disembunyikan: Setiap proses internal, setiap penyimpanan data, dan semua aliran data di dalam sistem.

• Tujuan: Mendefinisikan batas sistem — garis tegas antara “apa yang ada di dalam” dan “apa yang ada di luar.”

Di bawah ini adalah Diagram Konteks untuk sebuah Sistem Pemrosesan Pesanan. Perhatikan bagaimana seluruh sistem muncul sebagai proses 0, dan semua detail didorong ke dunia eksternal:

digraph DFD_Context {
    graph [
        rankdir = LR
        splines = true
        overlap = false
        nodesep = 0.5
        ranksep = 1.2
        fontname = "Helvetica,Arial,sans-serif"
        fontsize = 12
        label = "Sistem Pemrosesan Pesanan — Diagram Konteks (Level 0)"
        labelloc = t
    ]

    node [
        fontname = "Helvetica,Arial,sans-serif"
        fontsize = 11
        penwidth = 1.5
    ]

    node [shape = box, style = "filled", fillcolor = "#E1F5FE", color = "#0288D1"]
    Customer; Supplier; Bank;

    subgraph cluster_SystemBoundary {
        label = "Sistem Pemrosesan Pesanan";
        fontname = "Helvetica,Arial,sans-serif; bold"
        fontsize = 14
        color = "#757575"
        style = "dashed,rounded"
        bgcolor = "#FAFAFA"
        margin = 20

        node [shape = circle, style = "filled", fillcolor = "#E8F5E9", color = "#388E3C", fixedsize = true, width = 1.6]
        SYS [label="0nPemrosesannPesanannSistem"];
    }

    edge [
        fontname = "Helvetica,Arial,sans-serif"
        fontsize = 9
        color = "#555555"
        arrowsize = 0.8
    ]

    Customer -> SYS [label="PermintaannPesanan"];
    SYS -> Customer [label="Konfirmasi &nStatusnPesanan"];
    Supplier -> SYS [label="KetersediaannPersediaan"];
    SYS -> Supplier [label="PermintaannStok"];
    Bank -> SYS [label="VerifikasinPembayaran"];
    SYS -> Bank [label="PermintaannPembayaran &nPembayaran"];
}

Baca batasnya: Dalam Diagram Konteks ini, sistem tidak melakukan apa pun yang terlihat — tetapi setiap interaksi eksternal didaftarkan. Artefak ini adalah kontrak yang Anda tandatangani dengan para pemangku kepentingan: ini menangkap ruang lingkup dan mencegah pergeseran ruang lingkup karena apa pun yang tidak ada pada diagram ini berada di luar ruang lingkup.

2.2 DFD Level 1

• Abstraksi: Memecah satu 0 proses menjadi sub-proses utamanya.

• Apa yang ditunjukkannya: Area fungsional utama, penyimpanan data kunci, dan bagaimana data bergerak di antara mereka, penyimpanan, dan entitas eksternal.

• Tujuan: Memberikan pandangan pertama yang nyata tentang struktur sistem. Fungsi utama sekarang terlihat.

Untuk contoh Pesanan, proses 0 diuraikan menjadi empat fungsi utama: Validasi Pesanan, Periksa Stok, Proses Pembayaran, dan Buat Pengiriman. Perhatikan bahwa penyimpanan data muncul di sini untuk pertama kali:

digraph DFD_Level1 {
    graph [
        rankdir = LR
        splines = true
        overlap = false
        nodesep = 0.5
        ranksep = 0.8
        fontname = "Helvetica,Arial,sans-serif"
        fontsize = 12
        label = "Sistem Pemrosesan Pesanan — DFD Level 1"
        labelloc = t
    ]

    node [
        fontname = "Helvetica,Arial,sans-serif"
        fontsize = 11
        penwidth = 1.5
    ]

    node [shape = box, style = "filled", fillcolor = "#E1F5FE", color = "#0288D1"]
    Customer; Supplier; Bank;

    subgraph cluster_SystemBoundary {
        label = "Sistem Pemrosesan Pesanan";
        fontname = "Helvetica,Arial,sans-serif; bold"
        fontsize = 14
        color = "#757575"
        style = "dashed,rounded"
        bgcolor = "#FAFAFA"
        margin = 20

        node [shape = circle, style = "filled", fillcolor = "#E8F5E9", color = "#388E3C", fixedsize = true, width = 1.4]
        P1 [label="1.0nValidasinPesanan"];
        P2 [label="2.0nPeriksanStok"];
        P3 [label="3.0nProsesnPembayaran"];
        P4 [label="4.0nBuatnPengiriman"];

        node [shape = record, style = "filled", fillcolor = "#FFF9C4", color = "#FBC02D", fixedsize = false]
        CustomerDS [label="{ <id> D1 | Pelanggan }"];
        InventoryDS [label="{ <id> D2 | Stok }"];
        OrderDS [label="{ <id> D3 | Pesanan }"];
        PaymentDS [label="{ <id> D4 | Pembayaran }"];
    }

    edge [
        fontname = "Helvetica,Arial,sans-serif"
        fontsize = 9
        color = "#555555"
        arrowsize = 0.8
    ]

    Customer -> P1 [label="PermintaannPesanan"];
    Bank -> P3 [label="VerifikasinPembayaran"];
    Supplier -> P2 [label="KetersediaannStok"];
    P1 -> P2 [label="PesanannValid"];
    P3 -> P4 [label="PembayarannDikonfirmasi"];
    P1 -> CustomerDS [label="Validasi & PerbaruinPelanggan", dir=both];
    P2 -> InventoryDS [label="Perbarui &nCek Stok", dir=both];
    P1 -> OrderDS [label="CatatnPesanan"];
    P3 -> PaymentDS [label="Catat & VerifikasinPembayaran", dir=both];
    P4 -> OrderDS [label="PerbaruinStatus"];
    P2 -> Supplier [label="PermintaannStok"];
    P4 -> Customer [label="RinciannPengiriman"];
}

Hal-hal penting yang terjadi di sini yang harus selalu Anda periksa:

• Penomoran konsisten (1.0…4.0) yang cocok dengan induknya 0.

• Keseimbangan (dijelaskan di bawah) — aliran masuk dan keluar dari proses 0 dalam Diagram Konteks harus sama dengan aliran masuk dan keluar dari diagram Level 1 secara keseluruhan.

• Akses penyimpanan dua arah (misalnya P1 -> CustomerDS [dir=both]) digambar sebagai satu sisi yang digabungkan, bukan sebagai dua panah yang berantakan.

2.3 DFD Level 2 (dan Selanjutnya)

• Abstraksi: Dekomposisi lebih lanjut dari sebuah tunggal proses Level 1.

• Apa yang ditampilkan: Detail granular untuk proses kompleks. Setiap sub-proses mendapatkan fungsi atomik.

• Tujuan: Anda terus membuat Level 3, Level 4, dan seterusnya hingga setiap proses daun cukup sederhana untuk dijelaskan dalam narasi singkat atau pseudocode — proses terminal tersebut disebut sebagai Primitif Fungsional (sebuah proses primitif).

Di sini kita memperbesar ke proses 2.0 Periksa Persediaan dari DFD Level 1, memecahnya menjadi 2.1 Tanya Stok, 2.2 Periksa Ketersediaan, dan 2.3 Cadangkan Stok:

digraph DFD_Level2 {
    graph [
        rankdir = LR
        splines = true
        overlap = false
        nodesep = 0.4
        ranksep = 0.8
        fontname = "Helvetica,Arial,sans-serif"
        fontsize = 12
        label = "Sistem Pemrosesan Pesanan — DFD Level 2 (dekomposisi 2.0 Cek Stok)"
        labelloc = t
    ]

    node [
        fontname = "Helvetica,Arial,sans-serif"
        fontsize = 11
        penwidth = 1.5
    ]

    node [shape = box, style = "filled", fillcolor = "#E1F5FE", color = "#0288D1"]
    P1_Parent [label="1.0 / 3.0n(tetangga)"];
    Supplier;

    subgraph cluster_SystemBoundary {
        label = "2.0 Cek Stok (terdekomposisi)";
        fontname = "Helvetica,Arial,sans-serif; bold"
        fontsize = 14
        color = "#757575"
        style = "dashed,rounded"
        bgcolor = "#FAFAFA"
        margin = 20

        node [shape = circle, style = "filled", fillcolor = "#E8F5E9", color = "#388E3C", fixedsize = true, width = 1.4]
        P21 [label="2.1nQuerynStok"];
        P22 [label="2.2nCeknKetersediaan"];
        P23 [label="2.3nReservasinStok"];

        node [shape = record, style = "filled", fillcolor = "#FFF9C4", color = "#FBC02D", fixedsize = false]
        InventoryDS [label="{ <id> D2 | Stok }"];
        OrderDS [label="{ <id> D3 | Pesanan }"];
    }

    edge [
        fontname = "Helvetica,Arial,sans-serif"
        fontsize = 9
        color = "#555555"
        arrowsize = 0.8
    ]

    P1_Parent -> P21 [label="PesanannValid"];
    P22 -> P1_Parent [label="StoknDikonfirmasi & Status"];
    Supplier -> P22 [label="ResponsnKetersediaan"];
    P21 -> P22 [label="JumlahnStok"];
    P22 -> P23 [label="KetersediaannDikonfirmasi"];
    P23 -> P1_Parent [label="StoknDireservasi"];
    P21 -> InventoryDS [label="Query", dir=both];
    P23 -> InventoryDS [label="PengurangannDireservasi", dir=both];
    P23 -> OrderDS [label="PerbaruinStatus"];
    P22 -> OrderDS [label="BacanPesanan"];
}

Kapan Anda berhenti? Aturan praktisnya: terus lakukan dekomposisi hingga setiap proses daun adalah sebuah Primitif Fungsional — sebuah proses yang cukup sederhana untuk sepenuhnya ditentukan oleh beberapa baris pseudocode atau sebuah cerita pengguna yang singkat. Tidak ada tingkat target yang tetap; kompleksitaslah yang menentukan kedalaman. Sebuah proses kecil mungkin sudah primitif pada Level 1, sedangkan proses yang besar mungkin memerlukan Level 3 atau 4.

3. DFD Logis vs. DFD Fisik — Dimensi NiatDimensi

Ini adalah sumbu yang Anda tandai dengan benar sebagai yang sering disamakan dengan terminologi Diagram Kelas. Mari kita lebih tepat:

• Diagram Kelas menggunakan Konseptual/Logis/Fisik untuk mengekspresikan tingkat abstraksi dari sebuah model data.

• DFD menggunakan Logis/Fisik untuk mengekspresikan niat desain — apa vs. bagaimana — dan ini adalah ortogonal terhadap hierarki Level.

Artinya setiap level (Konteks, Level 1, Level 2) dapat digambar sebagai DFD Logis atau DFD Fisik. Mereka adalah sumbu yang independen, bukan tangga.

3.1 DFD Logis — Apayang Dilakukan Sistem

Bandingkan iniLogisDFD keanggotaan Logis dengan yang Fisik yang langsung berada di bawahnya. Sistem yang sama, level yang sama — tetapi yang Logis tidak menyebutkan teknologi apa pun dan departemen spesifik, hanyabisniskegiatan dankonseptualpenyimpanan data:

digraph DFD_Logical {
    graph [
        rankdir = LR
        splines = true
        overlap = false
        nodesep = 0.5
        ranksep = 0.8
        fontname = "Helvetica,Arial,sans-serif"
        fontsize = 12
        label = "DFD Logis — Apa yang dilakukan sistem (tanpa bias implementasi)"
        labelloc = t
    ]

    node [
        fontname = "Helvetica,Arial,sans-serif"
        fontsize = 11
        penwidth = 1.5
    ]

    node [shape = box, style = "filled", fillcolor = "#E1F5FE", color = "#0288D1"]
    Customer; Staff;

    subgraph cluster_SystemBoundary {
        label = "Sistem Keanggotaan (Logis)";
        fontname = "Helvetica,Arial,sans-serif; bold"
        fontsize = 14
        color = "#757575"
        style = "dashed,rounded"
        bgcolor = "#FAFAFA"
        margin = 20

        node [shape = circle, style = "filled", fillcolor = "#E8F5E9", color = "#388E3C", fixedsize = true, width = 1.4]
        P1 [label="1.0nDaftarnAnggota"];
        P2 [label="2.0nTerbitkannPerpanjangan"];

        node [shape = record, style = "filled", fillcolor = "#FFF9C4", color = "#FBC02D", fixedsize = false]
        MemberDS [label="{ <id> D1 | Catatan Anggota }"];
    }

    edge [
        fontname = "Helvetica,Arial,sans-serif"
        fontsize = 9
        color = "#555555"
        arrowsize = 0.8
    ]

    Customer -> P1 [label="AplikasinKeanggotaan"];
    Staff -> P2 [label="PermintaannPerpanjangan"];
    P1 -> MemberDS [label="TambahnAnggota"];
    P2 -> MemberDS [label="Perbarui &nBaca Catatan", dir=both];
    P2 -> Customer [label="PemberitahuannPerpanjangan"];
}

3.2 DFD Fisik —BagaimanaSistem Diimplementasikan

Sistem yang sama keanggotaan, sekarang sebagai DFD Fisik — perhatikan proses 1.0 berubah menjadi Layanan Pendaftaran (Server), penyimpanan data berubah menjadi MySQL members_db, sebuah Antrian Email muncul, dan aliran diberi label dengan protokol konkret:

digraph DFD_Physical {
    graph [
        rankdir = LR
        splines = true
        overlap = false
        nodesep = 0.5
        ranksep = 0.8
        fontname = "Helvetica,Arial,sans-serif"
        fontsize = 12
        label = "DFD Fisik — Bagaimana sistem diimplementasikan (teknologi & departemen)"
        labelloc = t
    ]

    node [
        fontname = "Helvetica,Arial,sans-serif"
        fontsize = 11
        penwidth = 1.5
    ]

    node [shape = box, style = "filled", fillcolor = "#E1F5FE", color = "#0288D1"]
    CustomerWeb [label="PelanggannPortal Web"];
    FrontOffice [label="KantornDepan"];

    subgraph cluster_SystemBoundary {
        label = "Sistem Keanggotaan (Fisik)";
        fontname = "Helvetica,Arial,sans-serif; bold"
        fontsize = 14
        color = "#757575"
        style = "dashed,rounded"
        bgcolor = "#FAFAFA"
        margin = 20

        node [shape = circle, style = "filled", fillcolor = "#E8F5E9", color = "#388E3C", fixedsize = true, width = 1.5]
        SRV [label="LayanannPendaftarann(Server)"];

        node [shape = record, style = "filled", fillcolor = "#FFF9C4", color = "#FBC02D", fixedsize = false]
        MySQLDS [label="{ <id> D1 | MySQLnmembers_db }"];
        QueueDS [label="{ <id> D2 | AntriannEmail }"];
    }

    edge [
        fontname = "Helvetica,Arial,sans-serif"
        fontsize = 9
        color = "#555555"
        arrowsize = 0.8
    ]

    CustomerWeb -> SRV [label="HTTPS POSTn/registern(JSON)"];
    FrontOffice -> SRV [label="Aplikasi DesktopnLogin API"];
    SRV -> MySQLDS [label="JDBC Insertn& Select Txn", dir=both];
    SRV -> QueueDS [label="JMSnPesan"];
    SRV -> CustomerWeb [label="HTTP 200nemail selamat datang"];
}

Poin Penting: Proyek yang matang menghasilkan DFD Logis terlebih dahulu (Konteks hingga Level 2) selama pengumpulan persyaratan agar pemangku kepentingan dapat memverifikasi kebenaran perilaku tanpa gangguan teknis, kemudian menurunkan DFD Fisik darinya selama perancangan — ketika “apa” telah disepakati, “bagaimana” dapat ditambahkan. Tingkatan tetap sejajar: Level 1 Fisik Anda mencerminkan Level 1 Logis Anda, diperkaya dengan detail implementasi.

4. Memetakan Tingkatan DFD ke Abstraksi Diagram Kelas

Jika Anda sudah berpikir dalam istilah abstraksi Diagram Kelas, berikut ini adalah perkiraan (dan berguna tetapi tidak sempurna) jembatan:

Peringatan: Pemetaan ini adalah kemudahan model mental, bukan kesetaraan formal. Seperti yang Anda catat, otoritatif terminologi dalam literatur analisis sistem (DeMarco, Gane & Sarson, Yourdon) secara ketat Konteks, Tingkat 1, Tingkat 2… bersama dengan Logis/Fisik perbedaan.

5. Aturan Kualitas Kritis DFD

Ini adalah invarian yang memisahkan DFD profesional yang seimbang dari yang sembarangan:

1. Disiplin penamaan. Setiap proses memiliki kata kerja + kata benda, diberi nomor, dan penomorannya membentuk pohon yang ketat (0 → 1.0…4.0 → 2.1…2.3). Setiap penyimpanan data diberi nomor D1, D2, … Setiap aliran memiliki label deskriptif.

2. Penyeimbangan (konsistensi di seluruh tingkat). Input dan output dari proses induk harus sama persis dengan gabungan input dan output dari proses anaknya. Jika proses 2.0 menerima Pesanan Valid dan mengembalikan Stok Dikonfirmasi, maka diagram Tingkat 2 yang menguraikan 2.0 harus menerima Pesanan Valid dan harus menghasilkan Stok Dikonfirmasi — tidak lebih, tidak kurang. Ini adalah satu-satunya aturan paling penting saat penguraian.

3. Tidak ada aliran langsung dari entitas ke entitas.Data selalu mengalir melalui sebuah proses. Entitas eksternal tidak pernah terhubung langsung satu sama lain atau ke penyimpanan data.

4. Tidak ada aliran langsung dari entitas ke penyimpanan. Entitas eksternal berinteraksi dengan penyimpanan hanya melalui sebuah proses (dalam konvensi DeMarco/Yourdon, ini adalah ketat aturan).

5. Akses dua arah adalah satu sisi. Ketika dua elemen saling bertukar data dua arah (umum pada penyimpanan data), gambarlah satu panah dengan dir=both dan label gabungan (“Perbarui & Query"), bukan dua panah satu arah terpisah — hal ini menjaga diagram tetap rapi dan mudah dibaca.

6. Berhenti pada primitif fungsional. Dekomposisi hanya sejauh yang diperlukan; proses terminal harus dapat dijelaskan dalam beberapa baris pseudocode.

6. Konvensi Visual yang Digunakan dalam Diagram-Diagram Ini

Semua contoh di atas mengikuti gaya DFD modern standar yang dirender dengan rapi di Graphviz:

• Entitas eksternal — kotak biru muda dengan batas biru (“#E1F5FE / #0288D1).

• Proses — lingkaran hijau dengan batas hijau (“#E8F5E9 / #388E3C), dinomori dan diberi nama dengan kata kerja.

• Penyimpanan data — batang kuning bergaya rekam (#FFF9C4 / #FBC02D) diberi label dengan ID + nama (D2 | Persediaan).

• Batas sistem — wadah (klaster) putus-putus dengan sudut melengkung dan latar belakang terang (#FAFAFA) dan batas berwarna abu-abu (#757575).

• Sisi — abu-abu sedang (#555555), kepala panah kecil, perutean sejajar sumbu melalui titik mesin.

7. Daftar Periksa Sebelum Menyajikan DFD

Gunakan ini sebagai gerbang tinjauan diri sebelum menganggap DFD apa pun sebagai selesai:

• Apakah tingkatnya dinyatakan dengan jelas (Konteks / Tingkat n)? Apakah pohon penomoran konsisten dengan induknya?

• Apakah keempat jenis simbol digunakan dengan benar, dengan pola penamaan yang tepat?

• Apakah diagram seimbang terhadap induknya (arus masuk/keluar cocok persis)?

• Apakah semua aliran diberi label dengan deskriptor data yang bermakna?

• Apakah aliran penyimpanan/vendor dua arah digabungkan menjadi satu dir=both sisi?

• Apakah entitas batas dan eksternal bebas dari aliran langsung entitas↔entitas / entitas↔penyimpanan?

• Apakah setiap proses daun memenuhi syarat sebagai primitif fungsional?

8. Ringkasan

• Hierarki = Tingkatan. Konteks (Tingkat 0) → Tingkat 1 → Tingkat 2 → … Setiap tingkat menguraikan satu proses menjadi sub-proses yang lebih halus hingga primitif fungsional tercapai.

• Niat = Logis vs Fisik. DFD Logis menjawab apa; DFD Fisik menjawab bagaimana. Kedua sumbu tersebut ortogonal — setiap tingkat dapat digambar dengan salah satu cara.

• Jangan sebut tingkat DFD sebagai “konseptual/logis/fisik.” Itu adalah istilah model kelas. Dalam analisis sistem formal (DeMarco, Gane & Sarson, Yourdon), kosakata yang benar adalah Konteks / Tingkat 1 / Tingkat 2 ditambah Logis/Fisik perbedaan.

• Praktik terbaik: bangun DFD Logis melalui Tingkat 0–2 selama analisis untuk mengunci persyaratan, lalu turunkankan DFD Fisikselama desain untuk merencanakan implementasi.

Empat diagram Graphviz di atas (“Konteks, Level 1, Level 2, dan pasangan Logis/Fisik) menunjukkan seluruh progresi. Setiap diagram dirender langsung dari blok kode — Anda dapat menyalin salah satunya ke Graphviz untuk melihat hasil rendernya.

Kesimpulan

Referensi

1. Menguasai Diagram Alur Data: Dari Menggambar Manual ke Pemodelan Berbantuan AI dengan Visual Paradigm: Panduan komprehensif yang mencakup dasar-dasar DFD, langkah-langkah pembuatan manual, dan alur kerja pemodelan berbantuan AI yang inovatif menggunakan VP AI Chatbot.
2. Menguasai Diagram Alur Data: Panduan Komprehensif untuk Dekomposisi Top-Down Berbantuan AI dengan Visual Paradigm: Postingan blog ini membahas secara mendalam penggunaan AI Visual Paradigm untuk dekomposisi top-down, mendemonstrasikan cara menghasilkan DFD Level 1, 2, dan 3 secara interaktif.
3. Menguasai Diagram Alur Data dengan Visual Paradigm: Panduan Langkah demi Langkah: Panduan resmi yang menyediakan tutorial praktis langkah demi langkah untuk membuat DFD, dimulai dengan templat dan menggunakan contoh dunia nyata seperti sistem belanja online.
4. Cara Membuat DFD dengan Visual Paradigm Desktop: Panduan praktis yang berfokus pada versi desktop, menjelaskan cara membuat proyek, menggambar diagram konteks dan level-1, serta menggunakan fitur dekomposisi.
5. Menguasai Tingkat Diagram Alur Data dan Keseimbangan: Sumber daya yang membahas konsep kritis menyeimbangkan diagram alur data di berbagai tingkat untuk memastikan konsistensi dan akurasi dalam analisis sistem.
6. Panduan Pemula untuk Diagram Alur Data (DFD) dengan Visual Paradigm Online: Panduan ramah pemula yang memperkenalkan konsep DFD dan menyediakan tutorial langkah demi langkah yang sederhana untuk membuat diagram menggunakan versi online Visual Paradigm.
7. Contoh Diagram Alur Data: Halaman sumber daya berharga yang menawarkan kumpulan contoh DFD untuk berbagai sistem seperti sistem pemesanan makanan, aplikasi supermarket, dan manajemen inventaris, yang dapat digunakan sebagai model referensi.