KATA PENGANTAR
Dengan menyebut nama Tuhan yang Maha Pengasih penulis panjatkan puji
syukur atas kehadirat-Nya yang telah melimpahkan rahmat, hidayah, dan
karunia-Nya kepada penulis, sehingga penulis dapat menyelesaikan makalah tentang
Pengiriman Crude Palm Oil ke Banjarmasin dalam waktu yang telah
ditentukan.
Laporan ini merupakan salah satu kewajiban yang harus dipenuhi guna
menyelesaikan tugas besar mata kuliah Rekayasa Perangkat Lunak pada Politeknik
Negeri Tanah Laut. Terima kasih banyak penulis ucapkan kepada semua pihak yang
telah membantu untuk menyelesaikan makalah ini.
Terlepas dari semua itu, penulis menyadari sepenuhnya bahwa masih ada
kekurangan baik dari penyusunan format makalah, susunan kalimat maupun isi yang
terdapat pada dalam makalah ini. Oleh karena itu dengan tangan terbuka penulis
menerima segala kritik dan saran dari pembaca agar penulis dapat memperbaharui makalah
tentang Pengiriman Crude Palm Oil ke Banjarmasin ini.
Pelaihari,
Juni 2019
Penulis
1.1 Latar Belakang
CPO (Clude Palm Oil) adalah produk utama dalam pengolahan minyak sawit
disamping minyak inti sawit. Dalam proses selanjutnya CPO diolah melalui tahap
pemucatan untuk menurunkan Kadar karoten agar warnanya kelihatan lebih menarik.
Pada proses pemucatan biasanya
digunakan adsorben. Pada proses pemucatan selama ini digunakan bentonit alam
yang sudah diubah ukuran partikelnya sebagai adsorben. Penggunaan bentonit alam
sebagai pemucat selama ini kurang memberikan hasil yang maksimal.
Menurut beberapa literatur, setelah pemakaian adsorben tertinggal
sejumlah minyak sawit di dalamnya. Karena itu dicoba menggunakan zeolit alam
menggantikan bentonit alam yang digunakan selama ini. Zeolit alam banyak
didapat di tanah air, salah satunya di Sarulla, Kabupaten Tapanuli Utara, Sumatera
Utara.
Zeolit alam dapat dirubah ukuran
partikelnya terlebih dahulu jika ingin digunakan. Variasi ukuran partikel yang
dilakukan adalah merubah partikel menjadi 80, 100, dan 120 mesh. Setelah
dirubah ukuran partikelny dilakukan aktivasi. Proses aktivasi yang dikenal
selama ini ada dua Cara yaitu proses kimia dan fisika.
Proses kimia yang dilakukan adalah dengan pengasaman, yaitu dengan
menggunakan asam klorida atau asam sulfat. Sedangkan proses fisika dilakukan
dengan pemanasan, yaitu dengan memanaskannya pada suhu 200, 300, 400 o C pada
grafit furnace, (Rosita, N, 2004).
1.2 Rumusan Masalah
1.
Bagaimana membangun aplikasi pengelolaan Pengiriman
Crude Palm Oil ke Banjarmasin yang
aman dan efisien?
2.
Bagaimana mencapai tujuan dari fungsi aplikasi
yang telah dibuat?
1.3 Batasan Masalah
1.
Aplikasi yang dibuat hanya membatasi pengelolaan
Pengiriman Crude Palm Oil ke
Banjarmasin.
2.
Berupa rancangan yang berdasarkan DFD (data Flow Diagram).
1.4 Tujuan dan Manfaat
1.
Membuat DFD (Data
Flow Diagram) metode Yourdon dan Tom DeMarco dengan studi kasus Pengiriman Crude Palm Oil ke Banjarmasin.
2.
Membuat UML (Unified
Modeling Language) dengan studi kasus Pengiriman Crude Palm Oil ke Banjarmasin.
3.
Memahami aliran informasi dan tranformasi
informasi yang diaplikasikan sebagai data yang mengalir dari masukan dan
keluaran.
4.
Mengetahui spesifikasi, gambaran dan dokumentasi
dari rsncangan sisitem perangkat lunak.
2.1 Data Flow Diagram
(DFD)
Data Flow Diagram (DFD) awalnya dikembangkan oleh Chris Gane dan Trish
Sarson pada tahun 1979 yang termasuk dalam Structured System Analysis and
Design Methodology (SSADM) yang ditulis oleh Crish Gane dan Trish Sarson.
Sistem yang dikembangkan ini berbasis pada dekomposisi fungsional dari sebuah
sistem. Tahun 1980-an Edward Yourdon dan Tom DeMarco memperkenalkan metode yang
lain, dimana mengubah persegi dengan sudut lengkung (pada DFD Crish Gane dan
Trish Sarson) dengan lingkaran untuk menotasikan. DFD Edward Yourdon dan Tom
DeMarco popular digunakan sebagai model analisis sistem perangkat lunak untuk
sistem perangkat lunak yang akan diimplementasikan dengan pemprograman
tersetruktur.
Informasi yang ada didalam perangkat lunak dimodifikasi deengan beberapa transformasi
yang dibutuhkan. Data Flow Diagram (DFD) atau dalam bahasa Indonesia menjadi
Diagram Air Data (DAD) adalah representasi grafik yang menggambarkan
aliran informasi dan transformasi
informasi yang diaplikasikan sebagai data yang mengalir dari masukan (input)
dan keluaran (output).
DFD dapat digunakan
untuk merepresentasikan sebuah sistem atau perangkat lunak pada beberapa level
abstrak. DFD dapat dibagi menjadi beberapa level yang lebih detail untuk
merepresentasikan aliran informasi atau fungsi yang lebih detail. DFD
menyediakan mekanisme untuk pemodelan fungsional ataupun pemodelan aliran
informasi. Notasi-notasi pada DFD (Edward Yourdon dan Tom DeMarco) adalah
sebagai berikut.
Berikut ini
adalah tahapan-tahapan perancangan dengan menggunakan
DFD.
1.
Membuat DFD Level 0 atau sering disebut juga
Context Diagram, DFD Level 0 menggambarkan sistem yang akan dibuat sebagai
suatu entitas tunggal yang berinteraksi dengan orang maupun sistem lain. DFD
Level 0 digunakan untuk menggambarkan interaksi antara sistem yang akan
dikembangkan dengan entitas luar. Aliran data berupa data masukan (input) dan
keluaran (output) kedalam proses perangkat lunak yang dirancang.
2.
DFD Level 1, digunakan untuk menggambarkan
modul-modul yang ada dalam sistem yang akan dikembangkan. DFD Level 1 merupakan
hasil breakdown DFD Level 0 yang sebelumnya sudah dibuat.
3.
Membuat DFD Level 2, modul-modul pada DFD Level1
dapat dibreakdown lebih detail tergantung pada tingkat kedetailan modul
tersebut. Apabila modul tersebut sudah cukup detail dan rinci maka modul
tersebut sudah tidak perlu untuk di-breakdown lagi. Untuk sebuah sistem, jumlah
DFD Level 2 sama dengan jumlah modul pada DFD Level 1 yang di-breakdown.
4.
Membuat DFD Level 3 dan seterusnya, merupakan
breakdown dari modul pada DFD Level diatasnya. Breakdown pada level 3 dan
seterusnya sama persis dengan DFD Level 1 atau Level 2.
2.2 Kamus Data
Kamus data dipergunakan untuk memperjelas aliran data yang digambarkan
pada DFD. Kamus data adalah kumpulan daftar elemen data yang mengalir pada
sistem perangkat lunak sehingga masukan (input) dan keluaran (output) dapat
dipahami secara umum (memiliki standar Cara penulisan). Kamus data dalam
implementasi program dapat menjadi parameter masukkan atau keluaran dari sebuah
fungsi atau prosedur. Kamus data biasanya berisi:
Nama, merupakan Nama dari data
·
Digunakan di, merupakan proses-proses yang
terkait data
·
Deskripsi, merupakan deskripsi data
·
Informasi tambahan, seperti tipe data, nilai
data, batas nilai data, dan komponen yang membentuk data.
|
Simbol
|
Keterangan
|
|
=
|
Disusun atau terdiri dari
|
|
+
|
Dan
|
|
[ | ]
|
Baik… atau…
|
|
{ }n
|
n Kali diulang/bernilai banyak
|
|
( )
|
Data opsional
|
|
*…*
|
Batas komentar
|
2.3 Unified Modeling Language (UML)
UML merupakan teknik pemrograman berorientasi objek yang merupakan bahasa
visual untuk pemodelan dan komunikasi mengenai sebuah sistem dengan
menggabungkan diagram dan teks-teks pendukung, yang muncul karena adanya
kebutuhan pemodelan visual untuk menspesifikasi, menggambarkan, membangun, dan
dokumentasi dari sistem perangkat lunak.
1.
Use Case Diagram
Use case diagram
merupakan pemodelan untuk kelakuan (behevior) sistem informasi yang akan
dibuat. Use case mendeskripsikan sebuah interaksi antara satu atau lebih actor
dengan sistem informasi yang akan dibuat. Secara kasar, use case digunakan
untuk mengetahui fungsi apa saja yang ada didalam sebuah sistem informasi dan
siapa saja yang berhak menggunakan fungsi-fungsi itu. Syarat penamaan pada use case adalah Nama didefinisikan
sesimpel mungkin dan dapat dipahami.
|
Simbol
|
Deskripsi
|
|
Use Case
|
Funsional yang disediakan sistem sebagai unit-unit
yang saling bertukar pesan antar unit atau aktor, biasanya dinyatakan dengan
menggunakan kata kerja di awal frase nama use case
|
|
Actor
|
Orang, proses, atau sistem lain yang berinteraksi
dengan sistem informasi yang akan dibuat di luar sistem informasi yang akan
di buat itu sendiri, jadi walaupun simbol dari aktor adalah gambar orang,
tapi aktor belum tentu merupakan orang, biasanya dinyatakan menggunakan kata
benda di awal frase nama aktor.
|
|
Asosiasi (Association)
|
Komuikasi antara aktor dan use case yang
berpartisipasi pada use case atau use case memiliki interaksi dengan aktor
|
|
Menggunakan /include/uses
<<Extend>>
|
Relasi use case tambahan ke sebuah use case dimana
use case yang ditambahkan dapat berdiri sendiri walau tanpa use case tambahan
itu, mirip dengan prinsip inheritance pada pemograma
|
|
Generalisasi(Generalization)
|
Hubungan generalisasi davn spesialisasi
(umum-khusus) antara dua bah use case dimana fungsi yang satu adalah fungsi yang
lebih umum dari lainnya.
|
|
Menggunakan /include/uses
<<include>>
|
Relasi use case tambahan ke
sebuah use case dimana use case yang ditambahkan memerlukan use case ini
untuk menjalankan fungsinya atau sebagai syarat dijalankannya use case ini.
|
Diagram kelas menggambarkan struktur sistem dari segi
pendefinisian kelas-kelas yang akan dibuat untuk membangun sistem. Kelas
memiliki apa yang disebut atribut dan metode atau proses.
·
Atribut merupakan variable-variabel yang
dimiliki oleh suatu kelas
·
Operasi atau metode adalah fungsi-fungsi yang
dimiliki oleh suatu kelas
Kelas-kelas yang ada pada struktur sistem harus dapat melakukan
fungsifungsi sesuai dengan kebutuhan sistem sehingga pembuat perangkat lunak
atau programmer dapat membuat kelas-kelas didalam program perangkat lunak
sesuai dengan perancangan diagram kelas. Susunan struktur kelas yang baik pada
diagram kelas sebaiknya memiliki jenis-jenis kelas berikut.
·
Kelas main, merupakan kelas yang memiliki fungsi
awal dieksekusi ketika sistem dijalankan.
·
Kelas yang menangani tampilan sistem (view),
merupakan kelas yang mendefinikan dan mengatur tampilan ke pemakai.
·
Kelas yang diambil dari pendefinisian use case
(controller), kelas yang menangani fungsi-fungsi yang harus ada diambil dari
pendefinisian use case, kelas ini biasanya disebut dengan kelas proses yang
menangani proses bisnis pada perangkat lunak
·
Kelas yang diambil dari pendefinisian data
(model), merupakan kelas yang digunakan untuk memegang atau membungkus data
menjadi sebuah
·
kesatuan yang diambil maupun akan disimpan ke
basis data. Semua tabel yang dibuat di basis data dapat dijalankan kelas, namun
untuk tabel dari hasil relasi atau atribut multivalue pada ERD dapat dijadikan
kelas tersendiri dapat juga tidak asalkan pengaksesannya dapat
dipertanggungjawabkan atau tetap ada di dalam perancangan kelas.
3. Diagram Status
Diagram Status
menggambarkan transisi dan perubahan keadaan (dari satu state ke state lainnya)
suatu objek pada sistem sebagai akibat dari stimuli yang diterima. Pada umumnya
statechart diagram menggambarkan class tertentu (satu class dapat memiliki
lebih dari satu statechart diagram).
Dalam UML, state digambarkan berbentuk segiempat
dengan sudut membulat dan memiliki nama sesuai kondisinya saat itu. Transisi
antar state umumnya memiliki kondisi guard yang merupakan syarat terjadinya
transisi yang bersangkutan, dituliskan dalam kurung siku. Action yang dilakukan
sebagai akibat dari event tertentu dituliskan dengan diawali garis miring.
Titik awal dan akhhir
digambarkan berbentuk lingkaranberwarna penuh dan berwarna setengah.
4. Diagram
Aktivitas
Activity diagram
menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang,
bagaimana masing-masing alir berawal, decision yang mungkin terjadi, dan
bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses
paralel yang mungkin terjadi pada beberapa eksekusi.
Activity diagram
merupakan state diagram khusus, di mana sebagian besar state adalah action dan
sebagian besar transisi di-trigger oleh selesainya state sebelumnya (internal
processing). Oleh karena itu activity diagram tidak menggambarkan behaviour
internal sebuah sistem (dan interaksi antar subsistem) secara eksak, tetapi
lebih menggambarkan proses-proses dan jalur-jalur aktivitas dari level atas
secara umum.
Sebuah aktivitas dapat
direalisasikan oleh satu use case atau lebih. Aktivitas menggambarkan proses
yang berjalan, sementara use case menggambarkan bagaimana aktor menggunakan
sistem untuk melakukan aktivitas.
Sama seperti state,
standar UML menggunakan segiempat dengan sudut membulat untuk menggambarkan
aktivitas. Decision digunakan untuk menggambarkan behaviour pada kondisi
tertentu. Untuk mengilustrasikan proses-proses paralel (fork dan join)
digunakan titik sinkronisasi yang dapat berupa titik, garis horizontal atau
vertikal. Activity diagram dapat dibagi menjadi beberapa object swimlane untuk
menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu.
Contoh Activity Diagram:
5. Diagram
Sekuen
Sequence diagram
menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk
pengguna, display, dan sebagainya) berupa message yang digambarkan terhadap
waktu. Sequence diagram terdiri atar dimensi vertikal (waktu) dan dimensi
horizontal (objek-objek yang terkait).
Sequence diagram biasa
digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah yang
dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu.
Diawali dari apa yang men-trigger aktivitas tersebut, proses dan perubahan apa
saja yang terjadi secara internal dan output apa yang dihasilkan.
Masing-masing objek,
termasuk aktor, memiliki lifeline vertikal.
Message digambarkan sebagai garis berpanah dari satu objek ke objek
lainnya. Pada fase desain berikutnya, message akan dipetakan menjadi
operasi/metoda dari class. Activation
bar menunjukkan lamanya eksekusi sebuah proses, biasanya diawali dengan
diterimanya sebuah message.
Untuk objek-objek yang
memiliki sifat khusus, standar UML mendefinisikan icon khusus untuk objek
boundary, controller dan persistent entity.
Contoh Sequence Diagram:
6. Diagram Kolaborasi
Collaboration diagram
juga menggambarkan interaksi antar objek seperti sequence diagram, tetapi lebih
menekankan pada peran masing-masing objek dan bukan pada waktu penyampaian
message. Setiap message memiliki sequence
number, di mana message dari level tertinggi memiliki nomor 1. Messages dari
level yang sama memiliki prefiks yang sama.
Contoh Collaboration Diagram:
7. Diagram
Komponen
Component diagram menggambarkan struktur
dan hubungan antar komponen piranti lunak, termasuk ketergantungan (dependency)
di antaranya.
Komponen piranti lunak adalah modul berisi code, baik
berisi source code maupun binary code, baik library maupun executable, baik
yang muncul pada compile time, link time, maupun run time. Umumnya komponen
terbentuk dari beberapa class dan/atau package, tapi dapat juga dari
komponen-komponen yang lebih kecil. Komponen dapat juga berupa interface, yaitu
kumpulan layanan yang disediakan sebuah komponen untuk komponen lain.
Contoh gambar Komponen:
8. Diagram
Deployment
Deployment diagram menggambarkan
detail bagaimana komponen di deploy dalam infrastruktur sistem, dimana komponen
akan terletak (pada mesin, server atau piranti keras apa), bagaimana kemampuan
jaringan pada lokasi tersebut, spesifikasi server, dan hal lain-lain ynag
bersifat fisikal.
Sebuah node server, workstation,
atau piranti keras lain yang digunakan untuk men-deploy komponen dalam
lingkungan sebenarnya. Hubungan antar node (misalnya TCP/IP) dan requirement
dapat juga didefinisikan dalam diagram ini.
Contoh gambar diagram deployment:
9. Diagram Komunikasi
Diagram komunikasi menggambarkan
interaksi antar objek/bagian dalam bentuk urutan pengiriman pesan. Diagram
komunikasi merepresentasikan informasi yang diperoleh dari diagram kelas,
diagram sekuen, dan diagram use case untuk mendeskripsikan gabungan antara
struktur statis dan tingkah laku dinamis dari suatu sistem. Diagram komunikasi
mengelompokkan message pada kumpulan diagram sekuen menjadi sebuah diagram
dalam diagram komunikasi yang dituliskan adalah operasi/metode yang dijalankan
antara objek yang satu dan objek lainnya secara keseluruhan, oleh karena itu
dapat diambil dari jalannya interaksi pada semua diagram sekuen. Penomoran
metode dapat dilakukan berdasarkan urutan
Dijalankannya metode/proses diantara objek yang satu dengan objek lainnya
atau objek itu sendiri.
Diagram konteks tersebut juga
terdiri dari dua entitas luar (terminator) sebagai berikut:
|
Entitas
Luar (terminator)
|
Keterangan
|
|
Admin
Kantor
|
Admin
kantor dapat melakukan login dan bisa melihat data pengirim CPO, maka dari
aliran data yang masuk (input)
adalah:
·
Data untuk login
·
Data pengiriman CPO
Aliran
data keluaran (output) adalah
sebagai berikut:
·
Informasi login
·
Melihat data pengiriman
|
|
Petugas
|
Petugas
dapat melakukan login, dapat memasukkan (input)
beberapa jumlah inputan data, maka
dari itu terminator ini akan mengirimkan masukan (input) berupa:
·
Login
·
Data mobil pengiriman
·
Data timbangan minyak
·
Data jadwal pengiriman
lalu aliran terminatornya yaitu:
·
Informasi login
·
Laporan data mobil pengiriman
·
Laporan data timbangan minyak
·
Laporan data jadwal pengiriman
|
2. Diagram Dekomposisi
3. DFD Level 1
Tempat penyimpanan (storage) yang digunakan pada perancangan
DFD level 1 adalah:
|
Nama penyimpana
|
Keterangan
|
|
Data
mobil pengiriman
|
Sebuah
tabel didalam basis data untuk menyimpan data mobil pengiriman.
|
|
Data
timbangan minyak
|
Sebuah
tabel didalam basis data untuk menyimpan data timbangan minyak.
|
|
Data
jadwal pengiriman
|
Sebuah
tabel didalam basis data untuk menyimpan data jadwal pengiriman.
|
|
Data
laporan
|
Sebuah tabel didalam basis data untuk
menyimpan data laporan.
|
Proses-proses yang
terlibat pada DFD level 1 adalah:
|
Nama Proses
|
Aliran data masuk (input)
|
Aliran data keluar (output)
|
Keterangan
|
|
login
|
login
|
informasi
login
|
Petugas
login untuk melakukan penginputan dari hasil pendataan yang telah dilakukan,
dari pendataan mobil pengiriman, pendataan timbangan minyak dan pendataan
jadwal pengiriman.
|
|
Mobil
pengiriman
|
petugas
|
informasi
petugas, informasi mobil pengiriman
|
Petugas
input kedalam proses data mobil pengiriman untuk melakukan pendataan yang
akan di proses nantinya. Kemudian proses dari data mobil pengiriman akan
diinputkan data mobil pengiriman tersebut ke dala tabel data mobil
pengiriman, dan mengouputkan hasil informasinya.
|
|
Timbangan
minyak
|
Petugas
|
Informasi
petugas, informasi timbangan minyak
|
Petugas
dapat melakukan penginputan data timbangan minyak ke dalam proses lalu di
akan diinputkan lagi ke tabel data timbangan minyak.
|
|
Jadwal
pengiriman
|
Petugas
|
Informasi
petugas, informasi jadwal pengiriman
|
Petugas
dapat melakukan penginputan data jadwal pengiriman ke dalam proses lalu di
akan diinputkan lagi ke tabel data timbangan minyak.
|
|
Laporan
|
|
Laporan
data mobil pengiriman, laporan data timbangan minyak, laporan data jadwal
pengiriman
|
Admin
kantor hanya dapat melihat dari hasil pendataan yang telah diinputkan oleh
petugas.
|
|
Log
out
|
|
Informasi
log out
|
Admin kantor dan petugas melakukan log out
untuk keluar dari akun aplikasi.
|
4. Level 2 proses 2
DFD level 2 proses 2 dari proses
Data mobil pengiriman ini terdapat 2 terminator yang dapat mengakses proses
tersebut, akan tetapi terminator admin kantor hanya bisa melihat hasil
penginputan sedangkan terminator petugas yang melakukan penginputan data-data
tersebut. Pertama, petugas dapat menginputkan data mobil pengiriman, mengedit
data mobil pengiriman, menghapus data mobil pengiriman, dan menyimpan data
mobil pengiriman.
5. Level 2 proses 3
DFD
level 2 proses 3 dari proses Data timbangan minyak ini terdapat 2 terminator
yang dapat mengakses proses tersebut, akan tetapi terminator admin kantor hanya
bisa melihat hasil penginputan sedangkan terminator petugas yang melakukan
penginputan data-data tersebut. Pertama, petugas dapat menginputkan data
timbangan minyak, mengedit data timbangan minyak, menghapus data timbangan
minyak, dan menyimpan data timbangan minyak.
6. Level 2 proses 4
DFD level 2 proses 4 dari proses
Data jadwal pengiriman ini terdapat 2 terminator yang dapat mengakses proses
tersebut, akan tetapi terminator admin kantor hanya bisa melihat hasil
penginputan sedangkan terminator petugas yang melakukan penginputan data-data
tersebut. Pertama, petugas dapat menginputkan data jadwal pengiriman, mengedit
data jadwal pengiriman, menghapus data jadwal pengiriman, dan menyimpan data
jadwal pengiriman.
7. Level 2 prose 5
DFD level 2 proses 5 dari proses Data laporan ini terdapat 1 terminator
yang dapat mengakses proses tersebut yaitu admin kantor. Admin Kantor dapat
menerima laporan data mobil pengiriman, laporan data timbangan minyak, laporan
data jadwal pengiriman.
3.2 Unified Modeling
Language (UML)
1. Definisi Aktor
Berikut adalah deskripsi
pendefinisian actor pada pengaplikasian pengiriman CPO ke Banjarmasin:
|
No
|
Aktor
|
Deskripsi
|
|
1.
|
Petugas
|
Orang yang bertugas dan memiliki hak akses untuk
melakukan operasi pengololaan data mobil pengiriman, data Jadwal pengiriman,
data Timbangan minyak. .Petugas juga memiliki hak akses untuk :
·
Mencari informasi mobil pengiriman, melihat
informasi mobil pengiriman, dan mencetak informasi mobil pengiriman.
·
Mencari informasi timbangan minyak, melihat
informasi timbangan minyak, dan mencetak informasi timbangan minyak.
·
Mencari informasi jadwal pengiriman, melihat
informasi jadwal pengiriman, dan mencetak informasi jadwal pengiriman.
|
|
2.
|
Admin
|
Admin adalah orang yang memiliki hak akses untuk:
·
Mencari informasi mobil pengiriman, melihat
informasi mobil pengiriman, dan mencetak informasi mobil pengiriman.
·
Mencari informasi timbangan minyak, melihat
informasi timbangan minyak, dan mencetak informasi timbangan minyak.
·
Mencari informasi jadwal pengiriman, melihat
informasi jadwal pengiriman, dan mencetal jadwal pengiriman.
|
2. Definisi Use Case
|
No
|
Use
Case
|
Deskripsi
|
|
1.
|
Validasi
|
Merupakan proses pengecekan hak akses siapa yang
berhak mengakses proses pengelolaan data jadwal pengiriman, timbangan minyak,
jadwal pengiriman.
Login wajib untuk fungsi-fungsi yang berkaitan
dengan akses pengubahan ke basis data, oleh karena itu fungsi-fungsi yang
melakukan perubahan basis data harus mengecek validasi user yang mengakses
fungsi-fungsi ini.
Validasi merupakan generalisasi dari proses login,
logout, dan memeriksa status login.
|
|
2.
|
Login
|
Merupakan proses untuk melakukan login petugas dan
admin.
|
|
3.
|
Logout
|
Merupakan proses untuk melakukan logout petugas dan
admin.
|
|
4.
|
Memeriksa
Status Login
|
Merupakan proses untuk memeriksa apakah pengguna
aplikasi sudah melakukan login atau belum.
|
|
5.
|
Memeriksa
Mobil Pengiriman
|
Mengelola mobil pengiriman merupakan proses
generalisasi yang meliputi empat buah proses pengelolaan data mobil
pengiriman yaitu menginputkan mobil pengiriman, mengedit mobil pengiriman,
menghapus mobil pengiriman, dan menyimpan mobil pengiriman.
|
|
6.
|
Menginputkan Mobil Pengiriman
|
Merupakan proses memasukkan data mobil pengiriman
ke dalam basis data.
|
|
7.
|
Mengedit Mobil Pengiriman
|
Merupakan prose mengedit data mobil pengiriman yang
ada pada basis data.
|
|
8.
|
Menghapus Mobil Pengiriman
|
Merupakan proses menghapus data mobil pengiriman
yang ada pada basis data.
|
|
9.
|
Menyimpan Mobil Pengiriman
|
Merupakan proses menyimpan data mobil pengiriman ke
dalam basis data.
|
|
10.
|
Mengelola
Timbangan Minyak
|
Mengelola timbangan minyak merupakan proses
generalisasi yang meliputi empat buah proses pengelolaan data timbangan
minyak yaitu menginputkan timbangan minyak, mengedit timbangan minyak,
menghapus timbangan minyak, dan menyimpan timbangan minyak.
|
|
11.
|
Menginputkan Timbangan Minyak
|
Merupakan proses menginputkan data timbangan minyak
ke dalam basis data.
|
|
12.
|
Mengedit Timbangan Minyak
|
Merupakan proses mengedit data timbangan minyak
yang ada pada basis data.
|
|
13.
|
Menghapus Timbangan Minyak
|
Merupakan proses menghapus data timbangan minyak
yang ada pada basis data.
|
|
14.
|
Menyimpan Timbangan Minyak
|
Merupakan prose menyimpan data timbangan minyak
pada basis data.
|
|
15.
|
Mengelola
Jadwal Pengiriman
|
Mengelola Jadwal pengiriman merupakan prose
generalisasi yang meliputi empat proses pengelolaan data jadwal pengiriman
yaitu menginputkan jadwal pengiriman, mengedit jadwal pengiriman, menghapus
jadwal pengiriman, dan menyimpan jadwal pengiriman.
|
|
16.
|
Menginputkan Jadwal Pengiriman
|
Merupakan proses memasukkan data jadwal pengiriman
ke dalam basis data.
|
|
17.
|
Mengedit Jadwal Pengiriman
|
Merupakan proses mengedit data jadwal pengiriman
yang ada pada basis data.
|
|
18.
|
Menghapus Jadwal Pengiriman
|
Merupakan proses menghapus data jadwal pengiriman
pada basis data.
|
|
19.
|
Menyimpan Jadwal Pengiriman
|
Merupakan proses menyimpan
data jadwal pengiriman ke basis data.
|
3. Skenario Use Case
Berikut adalah
scenario jalannya masing-masing use case
yang telah didefinisikan sebelumnya:
Nama Use Case: Login
Skenario:
|
Aksi
Aktor
|
Reaksi
Sistem
|
|
Skenario
Normal
|
|
|
1.
Memasukkan username dan password
|
|
|
|
2.
Memeriksa valid tidaknya daa masukkan dengan
memeriksa ke tabel user.
|
|
|
3.
Masuk ke aplikasi pengelolaan pengiriman CPO
ke Banjarmasin
|
|
Skenario
Alternif
|
|
|
1.
Memasukkan username
dan password
|
2.
Memeriksa valid tidaknya data masukkan
|
|
|
3.
Menampilkan pesan login tidak valid
|
|
4.
Memasukkan username
dan password yang valid
|
5.
Memeriksa valid tidaknya data masukkan
|
|
|
6.
Masukkan ke aplikasi pengelolaan pengiriman
CPO ke Banjarmasin
|
Nama Use Case: Logout
Skenario:
|
Aksi
Aktor
|
Reaksi
Sistem
|
|
Skenario
Normal
|
|
|
1. Memilih
menu logout
|
|
|
|
2.
Melakukan logout
|
Nama Use Case: Memeriksa status login
Skenario:
|
Aksi
Aktor
|
Reaksi
Sistem
|
|
Skenario
Normal
|
|
|
|
1.
Memeriksa ke variabel session sebagai penanda login apakah pengguna aplikasi sudah
login
|
|
|
1.
Mengembalikan status login, sudah login atau
belum
|
Nama Use Case: Menginputkan Mobil Pengiriman
Skenario:
|
Aksi
Aktor
|
Reaksi
Sistem
|
|
Skenario
Normal
|
|
|
|
1.
Memeriksa status login
|
|
2.
Memasukkan data sesuai kolom yang ada
|
.
|
|
|
3.
Memeriksa valid tidaknya data masukkan
|
|
|
4.
Menyimpan data ke basis data
|
|
|
5.
Menampilkan pesan sukses simpan
|
|
Skenario
Alternatif
|
|
|
|
1.
Memeriksa status login
|
|
2.
Menginputkan data sesuai kolom yang ada
|
|
|
|
3.
Memeriksa valid tidaknya data inputan
|
|
|
4.
Mengeluarkan pesan bahwa data inputan tidak
valid
|
|
5.
Memperbaiki data inputan yang tidak valid
|
|
|
|
6.
Memeriksa valid tidkanya data inputan
|
|
|
7.
Menyimpan data ke basis data
|
|
|
8.
Menampilkan pesan sukses simpan
|
Nama Use Case: Mengedit Mobil Pengiriman
Skenario:
|
Aksi
Aktor
|
Reaksi
Sistem
|
|
Skenario
Normal
|
|
|
|
1.
Memeriksa status login
|
|
2.
Memasukkan kata kunci dan kategori pencarian
|
|
|
|
3.
Mencari data yang akan diubah
|
|
|
4.
Menampilkan data yang dicari (belum semua
kolom data ditampilkan dan bisa banyak data yang memenuhi data pencarian)
|
|
5.
Memilih data yang akan diubah
|
|
|
|
6.
Menampilkan semua kolom data yang akan diubah
|
|
7.
Mengubah data
|
|
|
|
8.
Memeriksa valid tidaknya data masukan
|
|
|
9.
Menyimpan data yang telah diubah ke basis data
|
|
|
10.
Menampilkan pesan bahwa data sukses disimpan
|
|
Skenario
Alternif
|
|
|
|
1.
Memeriksa status login
|
|
2.
Memasukkan kata kunci dan kategori pencarian
|
|
|
|
3.
Mencari data yang akan diubah
|
|
|
4.
Menampilkan data yang dicari (belum semua
kolom data ditampilkan dan bisa banyak data yang memenuhi data pencarian)
|
|
5.
Memilih data yang akan diubah
|
|
|
|
6.
Menampilkan semua kolom data yang akan diubah
|
|
7.
Mengubah data
|
|
|
|
8.
Memeriksa valid tidaknya data masukan
|
|
|
9.
Menampilkan pesan bahwa data masukan tidak
valid
|
|
10.
Memperbaiki data inputan yang diubah dan tidak
valid
|
|
|
|
11.
Memeriksa valid tidaknya data masukan
|
|
|
12.
Menyimpan data yang telah diubah ke basis data
|
|
|
13.
Menampilkan pesan bahwa data sukses disimpan
|
Nama Use Case: Menghapus Mobil Pengiriman
Skenario:
|
Aksi
Aktor
|
Reaksi
Sistem
|
|
Skenario
Normal
|
|
|
|
1.
Memeriksa status login
|
|
2.
Memasukkan kata kunci dan kategori pencarian
|
|
|
|
3.
Mencari data yang akan dihapus
|
|
|
4.
Menampilkan data yang dicari (belum semua
kolom data ditampilkan dan bisa banyak data yang memenuhi data pencarian)
|
|
5.
Memilih data yang akan dihapus
|
|
|
|
6.
Menampilkan pesan konfirmasi apakah data akan
benar-benar dihapus
|
|
7.
Mengeklik pilihan setuju data dihapus
|
|
|
|
8.
Menghapus data dari basis data
|
|
|
9.
Menampilkan pesan bahwa data sukses dihapus
|
|
Skenario
Alternif
|
|
|
|
1.
Memeriksa status login
|
|
2.
Memasukkan kata kunci dan kategori pencarian
|
|
|
|
3.
Mencari data yang akan dihapus
|
|
|
4.
Menampilkan data yang dicari (belum semua
kolom data ditampilkan dan bisa banyak data yang memenuhi data pencarian)
|
|
5.
Memilih data yang akan dihapus
|
|
|
|
6.
Menampilkan pesan konfirmasi apakah data akan
benar-benar dihapus
|
|
7.
Mengeklik pilihan tidak setuju data dihapus
|
|
|
|
8.
Kembali ke form pencarian sebelumnya.
|
Nama Use Case: Menginputkan Timbangan Minyak
Skenario:
|
Aksi
Aktor
|
Reaksi
Sistem
|
|
Skenario
Normal
|
|
|
|
1.
Memeriksa status login
|
|
2.
Memasukkan data sesuai kolom yang ada
|
.
|
|
|
3.
Memeriksa valid tidaknya data masukkan
|
|
|
4.
Menyimpan data ke basis data
|
|
|
5.
Menampilkan pesan sukses simpan
|
|
Skenario
Alternatif
|
|
|
|
1.
Memeriksa status login
|
|
2.
Menginputkan data sesuai kolom yang ada
|
|
|
|
3.
Memeriksa valid tidaknya data inputan
|
|
|
4.
Mengeluarkan pesan bahwa data inputan tidak
valid
|
|
5.
Memperbaiki data inputan yang tidak valid
|
|
|
|
6.
Memeriksa valid tidkanya data inputan
|
|
|
7.
Menyimpan data ke basis data
|
|
|
8.
Menampilkan pesan sukses simpan
|
Nama Use Case: Menginputkan Timbangan Minyak
Skenario:
|
Aksi
Aktor
|
Reaksi
Sistem
|
|
Skenario
Normal
|
|
|
|
1.
Memeriksa status login
|
|
2.
Memasukkan data sesuai kolom yang ada
|
.
|
|
|
3.
Memeriksa valid tidaknya data masukkan
|
|
|
4.
Menyimpan data ke basis data
|
|
|
5.
Menampilkan pesan sukses simpan
|
|
Skenario
Alternatif
|
|
|
|
1.
Memeriksa status login
|
|
2.
Menginputkan data sesuai kolom yang ada
|
|
|
|
3.
Memeriksa valid tidaknya data inputan
|
|
|
4.
Mengeluarkan pesan bahwa data inputan tidak
valid
|
|
5.
Memperbaiki data inputan yang tidak valid
|
|
|
|
6.
Memeriksa valid tidkanya data inputan
|
|
|
7.
Menyimpan data ke basis data
|
|
|
8.
Menampilkan pesan sukses simpan
|
Nama Use Case: Mengedit Timbangan Minyak
Skenario:
|
Aksi
Aktor
|
Reaksi
Sistem
|
|
Skenario
Normal
|
|
|
|
1.
Memeriksa status login
|
|
2.
Memasukkan kata kunci dan kategori pencarian
|
|
|
|
3.
Mencari data yang akan diubah
|
|
|
4.
Menampilkan data yang dicari (belum semua
kolom data ditampilkan dan bisa banyak data yang memenuhi data pencarian)
|
|
5.
Memilih data yang akan diubah
|
|
|
|
6.
Menampilkan semua kolom data yang akan diubah
|
|
7.
Mengubah data
|
|
|
|
8.
Memeriksa valid tidaknya data masukan
|
|
|
9.
Menyimpan data yang telah diubah ke basis data
|
|
|
10.
Menampilkan pesan bahwa data sukses disimpan
|
|
Skenario
Alternif
|
|
|
|
1.
Memeriksa status login
|
|
2.
Memasukkan kata kunci dan kategori pencarian
|
|
|
|
3.
Mencari data yang akan diubah
|
|
|
4.
Menampilkan data yang dicari (belum semua
kolom data ditampilkan dan bisa banyak data yang memenuhi data pencarian)
|
|
5.
Memilih data yang akan diubah
|
|
|
|
6.
Menampilkan semua kolom data yang akan diubah
|
|
7.
Mengubah data
|
|
|
|
8.
Memeriksa valid tidaknya data masukan
|
|
|
9.
Menampilkan pesan bahwa data masukan tidak
valid
|
|
10.
Memperbaiki data inputan yang diubah dan tidak
valid
|
|
|
|
11.
Memeriksa valid tidaknya data masukan
|
|
|
12.
Menyimpan data yang telah diubah ke basis data
|
|
|
13.
Menampilkan pesan bahwa data sukses disimpan
|
Nama Use Case: Menghapus Timbangan Minyak
Skenario:
|
Aksi
Aktor
|
Reaksi
Sistem
|
|
Skenario
Normal
|
|
|
|
1.
Memeriksa status login
|
|
2.
Memasukkan kata kunci dan kategori pencarian
|
|
|
|
3.
Mencari data yang akan dihapus
|
|
|
4.
Menampilkan data yang dicari (belum semua
kolom data ditampilkan dan bisa banyak data yang memenuhi data pencarian)
|
|
5.
Memilih data yang akan dihapus
|
|
|
|
6.
Menampilkan pesan konfirmasi apakah data akan
benar-benar dihapus
|
|
7.
Mengeklik pilihan setuju data dihapus
|
|
|
|
8.
Menghapus data dari basis data
|
|
|
9.
Menampilkan pesan bahwa data sukses dihapus
|
|
Skenario
Alternif
|
|
|
|
1.
Memeriksa status login
|
|
2.
Memasukkan kata kunci dan kategori pencarian
|
|
|
|
3.
Mencari data yang akan dihapus
|
|
|
4.
Menampilkan data yang dicari (belum semua
kolom data ditampilkan dan bisa banyak data yang memenuhi data pencarian)
|
|
5.
Memilih data yang akan dihapus
|
|
|
|
6.
Menampilkan pesan konfirmasi apakah data akan
benar-benar dihapus
|
|
7.
Mengeklik pilihan tidak setuju data dihapus
|
|
|
|
8.
Kembali ke form pencarian sebelumnya.
|
Nama Use Case: Mengiputkan jadwal Pengiriman
Skenario:
|
Aksi
Aktor
|
Reaksi
Sistem
|
|
Skenario
Normal
|
|
|
|
1.
Memeriksa status login
|
|
2.
Memasukkan data sesuai kolom yang ada
|
.
|
|
|
3.
Memeriksa valid tidaknya data masukkan
|
|
|
4.
Menyimpan data ke basis data
|
|
|
5.
Menampilkan pesan sukses simpan
|
|
Skenario
Alternatif
|
|
|
|
1.
Memeriksa status login
|
|
2.
Menginputkan data sesuai kolom yang ada
|
|
|
|
3.
Memeriksa valid tidaknya data inputan
|
|
|
4.
Mengeluarkan pesan bahwa data inputan tidak
valid
|
|
5.
Memperbaiki data inputan yang tidak valid
|
|
|
|
6.
Memeriksa valid tidkanya data inputan
|
|
|
7.
Menyimpan data ke basis data
|
|
|
8.
Menampilkan pesan sukses simpan
|
Nama Use Case: Mengedit Jadwal Pengiriman
Skenario:
|
Aksi
Aktor
|
Reaksi
Sistem
|
|
Skenario
Normal
|
|
|
|
1.
Memeriksa status login
|
|
2.
Memasukkan kata kunci dan kategori pencarian
|
|
|
|
3.
Mencari data yang akan diubah
|
|
|
4.
Menampilkan data yang dicari (belum semua
kolom data ditampilkan dan bisa banyak data yang memenuhi data pencarian)
|
|
5.
Memilih data yang akan diubah
|
|
|
|
6.
Menampilkan semua kolom data yang akan diubah
|
|
7.
Mengubah data
|
|
|
|
8.
Memeriksa valid tidaknya data masukan
|
|
|
9.
Menyimpan data yang telah diubah ke basis data
|
|
|
10.
Menampilkan pesan bahwa data sukses disimpan
|
|
Skenario
Alternif
|
|
|
|
1.
Memeriksa status login
|
|
2.
Memasukkan kata kunci dan kategori pencarian
|
|
|
|
3.
Mencari data yang akan diubah
|
|
|
4.
Menampilkan data yang dicari (belum semua
kolom data ditampilkan dan bisa banyak data yang memenuhi data pencarian)
|
|
5.
Memilih data yang akan diubah
|
|
|
|
6.
Menampilkan semua kolom data yang akan diubah
|
|
7.
Mengubah data
|
|
|
|
8.
Memeriksa valid tidaknya data masukan
|
|
|
9.
Menampilkan pesan bahwa data masukan tidak
valid
|
|
10.
Memperbaiki data inputan yang diubah dan tidak
valid
|
|
|
|
11.
Memeriksa valid tidaknya data masukan
|
|
|
12.
Menyimpan data yang telah diubah ke basis data
|
|
|
13.
Menampilkan pesan bahwa data sukses disimpan
|
Nama Use Case: Menghapus Jadwal Pengiriman
Skenario:
|
Aksi
Aktor
|
Reaksi
Sistem
|
|
Skenario
Normal
|
|
|
|
1.
Memeriksa status login
|
|
2.
Memasukkan kata kunci dan kategori pencarian
|
|
|
|
3.
Mencari data yang akan dihapus
|
|
|
4.
Menampilkan data yang dicari (belum semua
kolom data ditampilkan dan bisa banyak data yang memenuhi data pencarian)
|
|
5.
Memilih data yang akan dihapus
|
|
|
|
6.
Menampilkan pesan konfirmasi apakah data akan
benar-benar dihapus
|
|
7.
Mengeklik pilihan setuju data dihapus
|
|
|
|
8.
Menghapus data dari basis data
|
|
|
9.
Menampilkan pesan bahwa data sukses dihapus
|
|
Skenario
Alternif
|
|
|
|
1.
Memeriksa status login
|
|
2.
Memasukkan kata kunci dan kategori pencarian
|
|
|
|
3.
Mencari data yang akan dihapus
|
|
|
4.
Menampilkan data yang dicari (belum semua
kolom data ditampilkan dan bisa banyak data yang memenuhi data pencarian)
|
|
5.
Memilih data yang akan dihapus
|
|
|
|
6.
Menampilkan pesan konfirmasi apakah data akan
benar-benar dihapus
|
|
7.
Mengeklik pilihan tidak setuju data dihapus
|
|
|
|
8.
Kembali ke form pencarian sebelumnya.
|
1. Diagram Use Case
2. Diagram Kelas
Keterangan
Diagram Kelas Studi Kasus Pengiriman
CPO ke Banjarmasin:
|
Nama
Kelas
|
Keterangan
|
|
Main
|
Merupakan kelas main
|
|
Antarmuka
|
Merupakan kelas yang menangani tampilan
|
|
Validasi
|
Merupakan kelas proses yang diambil dari
pendefinisian use case validasi
|
|
Mengelola_petugas
|
Merupakan kelas proses yang diambil dari
pendefinisian use case mengelola petugas yang didalamnya harus menangani
proses menginputkan petugas, mengedit petugas, menghapus petugas, dan
menyimpan petugas.
|
|
Mengelola_Mobil_pengiriman
|
Merupakan kelas proses yang diambil dari
pendefinisian use case mengelola mobil pengiriman yang didalamnya harus
menangani proses menginputkan mobil pengiriman, mengedit mobil pengiriman,
menghapus mobil pengiriman, dan menyimpan mobil pengiriman.
|
|
Mengelola_Timbangan_minyak
|
Merupakan kelas proses yang diambil dari
pendefinisian use case mengelola timbangan minyak yang didalamnya harus
menangani proses menginputkan timbangan minyak, mengedit timbangan minyak,
menghapus timbangan minyak, dan menyimpan timbangan minyak.
|
|
Mengelola_Jadwal_pengiriman
|
Merupakan kelas proses yang diambil dari
pendefinisian use case mengelola jadwal pengiriman yang didalamnya harus
menangani proses menginputkan jadwal pengiriman, mengedit jadwal pengiriman,
menghapus jadwal pengiriman, dan menyimpan jadwal pengiriman.
|
|
Mengelola_Admin_Kantor
|
Merupakan kelas proses yang diambil dari
pendefinisian use case mengelola admin kantor yang didalamnya harus menangani
proses menginputkan admin kantor, mengedit admin antor, menghapus admin
kantor, dan menyimpan admin kantor.
|
|
KoneksiBasisData
|
Merupakan kelas utilitas
untuk koneksi ke basisi data dan melakukan query
|
3. Diagram Objek
4. Diagram Sekuen
a. Use Case: Login
b. Use Case: Logout
c. Use Case: Memeriksa Status Login
Proses memeriksa status login berisi
untuk memeriksa apakah pengguna perangkat lunak sudah melakukan login. Proses
ini digunakan oleh use case lain sehingga akan menjadi bagian diagram sekuen
dari use case lain yang menggunakannya.
d. Use Case: Menginputkan Mobil
Pengiriman
e. Use Case: Mengedit Mobil
Pengiriman
f. Use Case: Menghapus Mobil
Pengiriman
g. Use Case: Menyimpan Mobil
Pengiriman
h. Use Case: Menginputkan Timbangan
Minyak
i. Use Case: Mengedit Timbangan
Minyak
j. Use Case: Menghapus Timbangan
Minyak
k. Use Case: Menyimpan Timbangan Minyak
l. Use Case: Menginputkan Jadwal
Pengiriman
m. Use Case: Mengedit Jadwal Pengiriman
n. Use Case: Menghapus Jadwal
Pengiriman
o. Use Case: Menyimpan Jadwal
Pengiriman
5. Diagram Komunikasi
a. Use Case: Login
b. Use Case: Logout
c. Use Case: Memeriksa Status Login
Proses memeriksa status login berisi untuk memeriksa apakah pengguna
perangkat lunak sudah melakukan login. Proses ini digunakan oleh use case lain
sehingga akan menjadi bagian diagram komunikasi dari use case lain yang
menggunakannya.
d. Use Case: Menginputkan Mobil
Pengiriman
e. Use Case: Mengedit Mobil
Pengiriman
f. Use Case: Menghapus Mobil
Pengiriman
g. Use Case: Menyimpan Mobil
Pengiriman
h. Use Case: Menginputkan Timbangan
Minyak
j. Use Case: Mengedit Timbangan
Minyak
k. Use Case: Menghapus Timbangan
Minyak
l. Use Case: Menyimpan Timbangan
Minyak
m. Use Case: Menginputkan Jadwal
Pengiriman
n. Use Case: Mengedit Jadwal
Pengiriman
o. Use Case: Menghapus Jadwal
Pengiriman
p. Use Case: Menyimpan Jadwal
Pengiriman
6. Diagram Kolaborasi
Diagram kolaborasi merupakan gabungan diagram komunikasi dari aplikasi
kearsipan tvri stasiun Kalimantan selatan berbasis web (dipisah-pisah agar
lebih jelas).
a. Antarmuka Aplikasi
b. Mengelola Petugas
c. Mengelola Mobil Pengiriman
d. Mengelola Timbangan Minyak
e. Mengelola Jadwal Pengiriman
f. Mengelola Admin Kantor
7. Diagram Status
Berikut
adalah status dari setiap objek pada diagram objek aplikasi Pengiriman CPO ke
Banjarmasin.
a. Objek: m dari kelas Main
Metode main membawa transisi dari
status awal ke status akhir.
b. Objek: an
dari kelas Antarmuka
Beberapa metode di dalam kelas Antarmuka ketika dijalankan akan membawa
dari status awal ke status akhir. Namun ada beberapa metode yang dijalankan
sebagai bagian dari proses yang lain, misalkan untuk proses menginputkan, mengedit,
menghapus dan menyimpan data, maka pada awalnya akan dijalankan proses
pencarian untuk menemukan data yang akan dibuah, dihapus, atau dicetak.
c. Objek: v dari kelas Validasi
Metode
login mengisi variabel SESSION sebagai penanda bahwa status telah login.
d. Objek: k dari
kelas KoneksiBasisData
e. Objek: mmp
dari kelas MengelolaMobilPengiriman
Proses mencari mobil pengiriman merupakan proses yang dapat berdiri
sendiri maupun sebagai bagian dari proses menginputkan, mengedit, menghapus
atau menyimpan data mobil pengiriman untuk menemukan mobil pengiriman mana yang
akan diinputkan, diedit, dihapus atau disimpan.
f. Objek: mtm
dari kelas Mengelola Timbangan Minyak
Proses mencari timbangan minyak merupakan proses yang dapat berdiri
sendiri maupun sebagai bagian dari proses menginputkan, mengedit, menghapus
atau menyimpan data timbangan minyak untuk menemukan timbangan minyak mana yang
akan diinputkan, diedit, dihapus atau disimpan.
g. Objek: mjp
dari kelas Mengelola Jadwal Pengiriman
Proses mencari Jadwal pengiriman merupakan proses yang dapat berdiri
sendiri maupun sebagai bagian dari proses menginputkan, mengedit, menghapus
atau menyimpan data Jadwal pengiriman untuk menemukan Jadwal pengiriman mana yang
akan diinputkan, diedit, dihapus atau disimpan.
8. Diagram
Aktivitas
9. Diagram
Komponen
Berikut ini adalah contoh diagram komponen.
10. Diagram Deployment
Berikut adalah contoh diagram deployment.
4.1 Kesimpulan
Perancangan pembuatan aplikasi
merupakan tahapan yang harus dilakukan agar pembuatan aplikasi nantinya tidak
berubah dari apa yang telah disetujui/ditetapkan sebelumnya. Dalam hal ini
penulis membuat rancangan tersebut menggunakan metode DFD (Data Flow Diagram) menurut Edward
Yourdon and Tom DeMarco yang merupakan representasi grafik yang
menggambarkan aliran informasi dan transformasi informasi yang diaplikasikan
sebagai data yang mengalir dari masukan dan keluaran. Selain DFD, penulis juga
menggunakan metode UML (Unified Modeling
Language) yang merupakan teknik pemrograman berorientasi objek yang
merupakan bahasa visual untuk pemodelan dan komunikasi mengenai sebuah sistem
dengan menggabungkan diagram dan teks-teks pendukung, yang muncul karena adanya
kebutuhan pemodelan visual untuk menspesifikasi, menggambarkan, membangun, dan
dokumentasi dari sistem perangkat lunak
Tidak ada komentar:
Posting Komentar