Modul RPL 2019
Modul RPL 2019
Disusun Oleh
Aris Diantoro, S.Kom.
Nama Lengkap :
Kelas :
Tgs Kls Tgs Kls Tgs Kls Tgs P1 P2 Kls Tgs Kls Tgs Kls P1 P2
Tgs Kls Tgs Kls Tgs Kls Tgs P1 P1 Kls Tgs Kls Tgs Kls P1 P2
Page 1 of 120
DAFTAR ISI
MODUL 6 UML.....................................................................................................................................
DAFTAR PUSTAKA
LAMPIRAN-LAMPIRAN
Page 2 of 120
BAB 1 PENGENALAN
REKAYASA PERANGKAT LUNAK
Page 3 of 120
• Pengembangan Perangkat Lunak : Perangkat lunak yang memenuhi spesifikasi
harus di produksi
Page 4 of 120
SOFTWARE ENGINEERING
Pendahuluan
Model proses canggih apa yang telah diusulkan untuk rekayasa perangkat lunak ?
Definisi
Suatu proses evolusi dan pemanfaatan alat dan teknik untuk pengembangan
software.
Page 5 of 120
- Terkandung komponen nilai dari SE yang berbentuk program dengan tugas -
tugas :
- Membuat suatu desain aplikasi yang ada dilingkungan tugas atau pekerjaan.
Page 6 of 120
Implementasi desain berupa program
Analisis
&
Desain
1/3
Page 7 of 120
VI. KINERJA PROGRAM
Dipengaruhi oleh :
VII. PORTABILITAS
- Kemampuan transfer perangkat lunak dari suatu jenis komputer ke lainnya dengan
biaya usaha minimum
VIII. PERAWATAN
Page 8 of 120
X. APLIKASI – APLIKASI SOFTWARE
1. Sistem Software.
o Compilers
o Editors
o Telecommunication Processors
3. Business Software
o Payroll (penggajian)
o Inventory (Persediaan)
o System Simulation
5. Embedded Software
o Fungsi – fungsi digital pada mobil : Fuel Control, Dashboard Displays, Breaking
Systems
Page 9 of 120
6. Personal Computer / PCI Software
o Word Processing
o Spread Sheets
o Computer Graphics
o Database Management
o Thasram Proving
o Game Playing
XI. METODE :
Metode adalah cara bagaimana kita secara teknis menyediakan pembangunan software,
yang terdiri dari :
4. Arsitektur program
5. Algoritma Prosedur
6. Pengkodean
7. Testing
8. Pemeliharaan
Page 10 of 120
XII. ALAT BANTU :
XIII. PROSEDUR :
Gambar the classic cycle (waterfall model) dapat dilihat pada halaman berikut :
Page 11 of 120
Sistem Feasibility (1)
Coding (5)
Integration (6)
Implementation (7)
2. SA dan Users
3. SA
4. SA
5. Programmers, Testers
8. Maintenance staf
Page 12 of 120
XVI. Aktivitas
1. Rekayasa sistem
3. Rancangan (design)
i. Struktur data
4. Pengkodean (coding)
5. Testing
6. Pemeliharaan (maintenance)
XVII. Prototyping
Page 13 of 120
XVIII. KESIMPULAN
a. Pengulangan pernyataan bahwa biaya perangkat lunak lebih mahal dari pada
perangkat keras.
Page 14 of 120
1. Tujuan Rekayasa Perangkat Lunak
A. Menghasilkan sebuah perangkat lunak yang berkualitas. Yang dimaksud dengan
berkualitas dapat dilihat dari tiga sisi, sisi sponsor (individu atau organisasi yang
telah mengeluarkan biaya dalam pembangunan perangkat lunak), sisi pemakai
(siapapun yang menggunakan perangkat lunak tersebut), sisi maintainer / modifier
(yang memelihara dan memodifikasi perangkat lunak tersebut). Untuk lebih
jelasnya lihat gambar 2.1.
Sisi Sponsor :
Tujuan utama sponsor adalah menghasilkan dan atau menghemat uang. Sponsor
ingin menggunakan perangkat lunak tersebut untuk meningkatkan produktivitas
organisasi. Sponsor mengharapkan untuk dapat menghasilkan sebuah layanan
dengan biaya yang rendah tetapi masuk akal. Karena itu sistem yang dibuat harus
handal, fleksibel dan efisien. Selain itu biaya dari pemeliharaan, modifikasi dan
peningkatan dari sistem tersebut harus serendah mungkin.
Sisi Pemakai :
Bagi pemakai perangkat lunak adalah alat untuk membantu menyelesaikan tugas-
tugasnya. Karena itu perangkat lunak harus menyediakan fungsi-fungsi yang
dibutuhkan oleh pemakai. Perangkat lunak juga harus handal dan efisien,
perangkat lunak harus dapat menghasilkan output yang konsisten. Selain itu
pemakai harus merasa perangkat lunak yang dibuat mudah untuk dipelajari, mudah
digunakan dan mudah untuk diingat.
Sisi Maintainer/modifier :
Yang diinginkan oleh maintainer/modifier adalah perangkat lunak tersebut memiliki
sangat sedikit error pada saat penginstallan pertama (catatan : sangat kecil
kemungkinannya untuk menghasilkan perangkat lunak yang 100 % bebas dari
bug). Selain itu perangkat lunak tersebut harus terdokumentasi dengan baik.
Source code juga harus mudah dibaca, terstruktur dan dirancang dengan baik dan
bersifat modular.
Page 15 of 120
2. Masalah-masalah RPL?
• Perangkat lunak telah diselesaikan dan diserahkan (delivered) tetapi tidak
pernah digunakan (47%).
• Pemakai (user) sudah membayar untuk perangkat lunak tetapi tidak pernah
jadi dan diserahkan (29,7%).
1980 an belum dikenal peranannya, bahkan menjadi bahan tertawaan. Hal ini
disebabkan karena pada awal diciptakan, kecepatan perangkat lunak masih sangat
lambat, sehingga masih “kalah” jika dibandingkan dengan kecepatan pengolahan
angka dengan menggunakan kalkulator ataupun sempoa.
Page 16 of 120
Sekarang menjadi mesin yang mengendalikan pengambilan keputusan dan sangat
erat kaitannya dengan berbagai bidang antara lain :
o Transportasi
o Medis
o Telekomunikasi
o Militer
o Proses industri
o Hiburan
Peran Perangkat Lunak computer mengalami perubahan penting dan dramatis selama
paruh abad ke 20 seperti unjuk kerja perangkat keras, perubahan-perubahan besar dalam
arsitektur computer, pertambahan yang pesat pada memori dan kapasitas penyimpanan,
serta variasi pilihan input dan output yang luas
Page 17 of 120
Era ketiga ditandai dengan munculnya :
Era ke empat :
User semakin jauh dari computer individual dan pemrograman
Menuju kepada pengaruh kolektif dari computer dan perangkat lunak
Mesin desktop yang kuat
Sistem operasi lebih canggih
Tersedianya jaringan local dan global
Arsitektur perhitungan berubah cepat dari lingkungan mainframe terpusat ke
lingkungan client/server yang desentralisasi
Rangkuman perkembangan yang terjadi, secara ringkas, terlihat dalam tabel sbb :
Tahun-tahun Awal Era Kedua Era Ketiga Era Keempat
Page 18 of 120
a. Embedded Software Dlm otomotif untuk kontrol bahan bakar, tampilan dashboard,
sistem rem, dll.
b. Perangkat Lunak Personal Komputer Worksheet, Simple Database, dll.
c. Perangkat Lunak Kecerdasan Buatan Game, pembuktian teorema
usang
Tingkat Kematian
Kegagalan segera
waktu
Tingkat
kegagalan Pada tingkat yang sama
sampai usang
waktu
Gambar 1.3. Kurva Kegagalan pada perangkat lunak
Page 19 of 120
BAB 2 METODE
PENGEMBANGAN PL
1. PANDANGAN UMUM TENTANG RPL
Rekayasa merupakan :
Analisis
Desain
Konstruksi
Verifikasi
Manajemen Kesatuan Teknik (atau sosial)
“Dari IEEE ( IEEE Std 1016 – 1998 Recommended Practice for Software Design
Description ) Dari standar IEEE 1016, ditekankan bahwa siklus hidup adalah segala
sesuatu yang lebih berdasar kepada urutan waktu dibandingkan proses yang terjadi.
Proses perangkat lunak ialah kegiatan yang tercakup dalam upaya memproduksi
dan mengembangkan sistem perangkat lunak. Proses disajikan dalam model proses
perangkat lunak. Kegiatannya secara umum terdiri dari penetapan spesifikasi, desain
dan implementasi, validasi dan evolusi. Rekayasa kebutuhan (requirement
engineering) adalah proses pengembangan spesifikasi perangkat lunak. Proses
disain dan implementasi mengubah spesifikasi untuk sebuah sistem Bahwa siklus
hidup perangkat lunak merupakan urutan hidup sebuah perangkat lunak berdasarkan
perkembangan perangkat lunak yang ditentukan oleh pengembang perangkat lunak
itu sendiri.
Page 20 of 120
Pengembangan perangkat lunak
Pasca produksi
Definisi Proses
Analisis dan defenisi persyaratan. Pelayanan, batasan, dan tujuan sistem ditentukan
melalui konsultasi dengan user sistem. Perancangan sistem dan perangkat lunak.
Proses perancangan sistem membagi persyaratan dalam sistem perangkat keras
atau perangkat lunak. Kegiatan ini menentukan arsitektur sistem secara keseluruhan.
Implementasi dan pengujian unit. Pada tahap ini, perancangan perangkat lunak
direalisasikan sebagai serangkaian program atau unit program.
Integrasi dan pengujian sistem. Unit program atau program individual diintegrasikan dan diuji
sebagai sistem yang lengkap untuk menjamin bahwa persyaratan sistem
Kesimpulannya:
Bahwa sebuah proses perangkat lunak merupakan sekumpulan aktifitas maupun
metode yang digunakan pengembang perangkat lunak.
Waterfall sendiri memiliki definisi bahwa sebuah proses hidup perangkat lunak memiliki
proses yang linier dan sequensial.
Page 21 of 120
2. Rapid Aplication Development ( RAD )
Merupakan metodelogi perancangan system dengan menggunakan frekwensi atau
rentang waktu yang ditetapkan jaraknya sesuai dengan perangkat lunak yang
dikembangkan
3. Prototype
Metodelogi perancangan system yang evolusioner dimana dalam proses
pengembangannya membutuhkan kemampuan tingkat mahir atau yang telah
memahami permasalahan dalam kegiatan perancangan system dengan pengalaman
dan keilmuan yang lebih baik.
4. Spiral
Metodelogi ini pun merupakan kategori evolusioner yang membutuhkan kemampuan
menganalisa permasalahan yang lebih komplek secara battom up.
Page 22 of 120
PROTOTYPING DAN PEMODELAN
PERANGKAT LUNAK
Dalam proses analisis proses pendekatan dilakukan, dan salah satunya adalah
prototyping. Prototyping adalah sebuah proses pengumpulan persyaratan, pengaplikasian
prinsip analisis, dan penyusunan model perangkat lunak yang akan dibangun untuk penilaian
dan pengembangan. Akhirnya ada lingkungan yang membutuhkan konstruksi prototipe pada
awal analisis, karena model adalah satu-satunya alat dimana persyaratan dapat ditarik secara
efektif. Model tersebut kemudian dikembangkan dalam perangkat lunak produksi.
Ada empat model prototype:
1. Prototype kertas, menggambarkan system dengan menggunakan media kertas.
Prototype kertas tidak bisa diuji coba dan diimplementasikan.
2. Prototype berbasis PC, memanfaatkan program aplikasi untuk menunjukkan
interaksi manusia dan komputer.
3. Prototype kerja, merupakan implementasi sebagian fungsi system yang ingin
dilihat unjuk kerjanya, dan diwujudkan dalam sebuah program.
4. Prototype program, program benar-benar dibuat dan dapat berfungsi dengan baik.
Selain itu, program juga terus menerus ditambah dan dilengkapi.
Paradigma prototyping dapat terbatas atau tidak terbatas. Pendekatan terbatas disebut
throaway prototyping. Dengan menggunakan pendekatan ini, prototipe sebagai sebuah
demonstrasi dari sebuah persyaratan. Sedangkan pendekatan tidak terbatas, yang disebut juga
evolutionary prototyping., menggunakan prototipe sebagai bagian pertama dari aktivitas
analisis yang akan diteruskan ke dalam desain dan konstruksi. Sebelum pendekatan terbatas
atau tidak terbatas dilaksanakan perlu dilakukan apakah sistem yang akan dibangun dapat
menerima protoyping atau tidak. Sejumlah faktor perlu diperhatikan, diantaranya: area
aplikasi, kompleksitas aplikasi, karakteristik pelanggan, dan karakteristik proyek.
Page 23 of 120
Beberapa kelebihan/manfaat yang bisa diambil bila kita menggunakan prototyping
antara lain :
1. Adanya komunikasi yang intensif antara pengembang dan user
2. Membantu dalam analisis, karena kebutuhan user telah dipahami dengan baik oleh
pengembang sehingga dapat meminimalkan salah persepsi antara kedua pihak.
3. Peran user meningkat, karena user dapat melakukan evaluasi dan masukan baru
setiap saat.
4. Pengembangan lebih cepat, karena program bisa langsung dibuat dan user dapat
melihat setiap tahap pembuatan program.
5. Mudah dalam implementasinya, karena user sudah sejak awal terlibat sehingga
sudah akrab dan tidak merasa asing terhadap program.
Sedangkan kelemahan memakai prototype adalah :
1. User sibuk, karena user dan pengembang harus sama-sama memiliki komitmen untuk
sering bertemu dan membahas kebutuhannya
2. User ingin program segera selesai sehingga pengembang sering mengabaikan
dokumentasi
3. User berharap terlalu banyak, seringnya evaluasi dan komunikasi membuat user sering
berubah fikiran dan tidak pasti akan kebutuhannya.
Di dalam suatu industri dikenal berbagai macam proses, demikian juga halnya dengan
industri perangkat lunak. Perbedaan proses yang digunakan akan menguraikan aktivitas-
aktivitas proses dalam cara-cara yang berlainan. Perusahaan yang berbeda menggunakan
proses yang berbeda untuk menghasilkan produk yang sama. Tipe produk yang berbeda
mungkin dihasilkan oleh sebuah perusahaan dengan menggunakan proses yang berbeda.
Namun beberapa proses lebih cocok dari lainnya untuk beberapa tipe aplikasi. Jika proses
yang salah digunakan akan mengurangi kualitas kegunaan produk yang dikembangkan.
Page 24 of 120
Karena banyaknya variasi dalam model proses yang digunakan maka tidak mungkin
menghasilkan gambaran-gambaran yang reliabel untuk alokasi biaya dalam aktivitas-aktivitas
ini.
Modifikasi perangkat lunak biasanya lebih dari 60 % dari total biaya pembuatan
perangkat lunak. Presentasi ini terus bertambah karena lebih banyak perangkat lunak
dihasilkan dan dipelihara. Pembuatan perangkat lunak untuk suatu perubahan adalah penting.
Proses perangkat lunak komplek dan melibatkan banyak aktivitas.
Understandability, yaitu sejauh mana proses secara eksplisit ditentukan dan bagaimana
kemudahan definisi proses itu dimengerti.
Visibility, apakah aktivitas-aktivitas proses mencapai titik akhir dalam hasil yang jelas
sehingga kemajuan dari proses tersebut dapat terlihat nyata/jelas
Supportability, yaitu sejauh mana aktivitas proses dapat didukung oleh CASE
Acceptability, apakah proses yang telah ditentukan oleh insinyur dapat diterima dan
digunakan dan mampu bertanggung jawab selama pembuatan produk perangkat lunak
Reliability, apakah proses didesain sedimikian rupa sehingga kesalahan proses dapat
dihindari sebelum terjadi kesalahan pada produk.
Robustness, dapatkah proses terus berjalan walaupun terjadi masalah yang tak diduga
Maintainability, dapatkah proses berkembang untuk mengikuti kebutuhan atau
perbaikan
Rapidity, bagaimana kecepatan proses pengiriman sistem dapat secara lengkap
memenuhi spesifikasi.
Page 25 of 120
Pemodelan dalam rekayasa perangkat lunak merupakan suatu hal yang dilakukan
ditahap awal dan akan mempengaruhi pekerjaan-pekerjaan selanjutnya dalam rekayasa
perangkat lunak tersebut.
1. Model Waterfall
Jasa, kendala dan tujuan dihasilkan dari konsultasi dengan pengguna sistem. Kemudian
semuanya itu dibuat dalam bentuk yang dapat dimengerti oleh user dan staf pengembang.
Proses desain sistem membagi kebutuhan-kebutuhan menjadi sistem perangkat lunak atau
perangkat keras. Proses tersebut menghasilkan sebuah arsitektur sistem keseluruhan.
Desain perangkat lunak termasuk menghasilkan fungsi sistem perangkat lunak dalam
bentuk yang mungkin ditransformasi ke dalam satu atau lebih program yang dapat
dijalankan.
Selama tahap ini desain perangkat lunak disadari sebagai sebuah program lengkap atau
unit program. Uji unit termasuk pengujian bahwa setiap unit sesuai spesifikasi.
Unit program diintegrasikan dan diuji menjadi sistem yang lengkap untuk menyakinkan
bahwa persyaratan perangkat lunak telah dipenuhi. Setelah ujicoba, sistem disampaikan ke
pelanggan.
Page 26 of 120
Normalnya, ini adalah phase yang terpanjang. Sistem dipasang dan digunakan.
Pemeliharaan termasuk pembetulan kesalahan yang tidak ditemukan pada langkah
sebelumnya. Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai
kebutuhan baru ditemukan.
Dalam prakteknya, setiap langkah sering tumpang tindih dan saling memberi
informasi satu sama lain. Proses perangkat lunak tidak linier dan sederhana tapi mengandung
urutan iterasi dari aktivitas pengembangan. Selama di langkah terakhir, perangkat lunak telah
digunakan. Kesalahan dan kelalaian dalam menentukan kebutuhan perangkat lunak original
dapat diatasi
Sayangnya, model ini banyak mengandung iterasi sehingga membuat sulit bagi pihak
manajemen untuk memeriksa seluruh rencana dan laporan. Maka dari itu, setelah sedikit
iterasi, biasanya bagian yang telah dikembangkan akan dihentikan dan dilanjutkan dengan
langkah pengembangan selanjutnya. Masalah-masalah selama resolusi selanjutnya, dibiarkan
atau diprogram. Pemberhentian yang prematur dari persyaratan akan berarti bahwa sistem
tidak akan sesuai dengan keinginan user. Mungkin juga sistem terstruktur secara jelek yang
Page 27 of 120
sebenarnya merupakan masalah desain akan dibiarkan karena terkalahkan oleh trik
implementasi.
2. Model Spiral
Model spiral dibagi menjadi sejumlah aktivitas kerangka kerja, disebut juga wilayah
tugas, antara tiga sampai 6 wilayah tugas :
Komunikasi pelanggan
Perencanaan
Analisis resiko
Perekayasaan
Page 28 of 120
Tugas-tugas yang dibutuhkan untuk membangun satu atau lebih representasi aplikasi.
Evaluasi pelanggan
Tugas-tugas yang dibutuhkan untuk memperoleh umpan balik dari pelanggan dengan
didasarkan pada evaluasi representasi perangkat lunak, yang dibuat selama masa
perekayasaan dan diimplementasikan selama masa pemasangan.
Model spiral menjadi sebuah pendekatan yang realistis bagi perkembangan sistem dan
perangkat lunak skala besar. Karena perangkat lunak terus bekerja selama proses bergerak,
pengembang dan pemakai memahami dan bereaksi lebih baik terhadap resiko dari tiap tingkat
evolusi.
Perencanaanan
Analisis resiko
Komunikas
pelanggan
Perekayasaan
Evaluasi pelanggan
Konstruksi dan
peluncuran
Page 29 of 120
Gambar. Model spiral
Rational Unified Process adalah proses rekayasa perangkat lunak yang menyediakan
pendekatan disiplin untuk menandai tugas-tugas dan tanggung jawab dalam pengembangan
organisasi. RUP berfokus pada perangkat lunak kualitas tinggi yang mengakomodasi
kebutuhan end user dengan jadwal dan anggaran biaya yang dapat diprediksikan.
Page 30 of 120
Gambar. Rational Unified Process
Business modeling
Requirements
Page 31 of 120
Analisis dan desain menunjukkan bagaimana sistem akan direalisasikan dalam
fase implementasi. Kita ingin membangun sistem yang :
Analisis dan desain menghasilkan model desain dan model analisis. Desain model
berlaku sebagai blueprint yang menggambarkan bagaimana source code disusun dan
ditulis.
Implementation
Page 32 of 120
Berisi panduan untuk mengatur berbagai variasi perkembangan sistem
perangkat lunak, pelacakan versi mana yang digunakan dalam pembuatan perangkat
lunak, pembuatan program individual atau keseluruhan berdasar spesifikasi yang
diminta user dan kebijakan pengembangan perangkat lunak
Environment
Deployment
Rapid Application Development (RAD) adalah salah satu metode pengembangan suatu
sistem informasi dengan waktu yang relatif singkat. Untuk pengembangan suatu sistem
informasi yang normal membutuhkan waktu minimal 180 hari, akan tetapi dengan
menggunakan metode RAD suatu sistem dapat diselesaikan hanya dalam waktu 30-90 hari.
Tujuan utama dari semua metode pengembanga sistem adalah memberikan suatu
sistem yang dapat memenuhi harapan dari para pemakai, akan tetapi sering kali di dalam
melakukan pengembangan suatu sistem tidak melibatkan para pemakai sistem secara
Page 33 of 120
langsung, sehingga hal ini menyebabkan sistem informasi yang dibuat jauh dari harapan
pemakai yang dapat berakibat sistem tersebut walaupun dapat diterima tetapi para pemakai
enggan untuk menggunakannya atau bahkan para pemakai menolak untuk menggunakannya.
Pada saat RAD diimplementasikan, maka para pemakai bisa menjadi bagian dari
keseluruhan proses pengembangan system dengan bertindak sebagai pengambil keputusan
pada setiap tahapan pengembangan. RAD bisa menghasilkan suatu system dengan cepat
karena sistem yang dikembangkan dapat memenuhi keinginan dari para pemakai sehingga
dapat mengurangi waktu untuk pengembangan ulang setelah tahap implementasi.
Metode RAD mempunyai 3 tahapan utama seperti yang terlihat pada gambar dibawah
ini :
Tahapan-tahapan RAD :
Pada tahap ini, user dan analyst melakukan semacam pertemuan untuk melakukan
identifikasi tujuan dari aplikasi atau system dan melakukan identifikasi kebutuhan
informasi untuk mencapai tujuan. Hal terpenting dalam tahap ini adalah adanya
keterlibatan dari kedua belah pihak, bukan hanya sekedar persetujuan akan proposal yang
sudah dibuat. Untuk lebih jauh lagi, keterlibatan user bukan hanya dari satu tingkatan pada
suatu organisasi, melainkan beberapa tingkatan organisasi sehingga informasi yang
dibutuhkan untuk masing-masing user dapat terpenuhi dengan baik.
2. Design workshop (proses desain)
Pada tahap ini adalah melakukan proses desain dan melakukan perbaikan-perbaikan
apabila masih terdapat ketidaksesuaian desain antara user dan analyst. Untuk tahap ini
Page 34 of 120
maka keaktifan user yang terlibat sangat menentukan untuk mencapai tujuan, karena user
bisa langsung memberikan komentar apabila terdapat ketidaksesuaian pada desain.
Biasanya, user dan analyst berkumpul menjadi satu dan duduk di meja melingkar dimana
masing-masing orang bias melihat satu dengan yang lain tanpa ada halangan.
3. Implementation (implementasi)
Setelah desain dari sistem yang akan dibuat sudah disetujui baik itu oleh user dan analyst,
maka pada tahap ini programmer mengembangkan desain menjadi suatu program. Setelah
program selesai baik itu sebagian maupun secara keseluruhan, maka dilakukan proses
pengujian terhadap program tersebut apakah terdapat kesalahan atau tidak sebelum
diaplikasikan pada suatu organisasi. Pada saat ini maka user bias memberikan tanggapan
akan sistem yang sudah dibuat serta persetujuan mengenai sistem tersebut.
Page 35 of 120
BAB 3 ANALISA KEBUTUHAN
Menurut arti kamus, kebutuhan adalah sesuatu yang diminta, sesuatu yang dibutuhkan.
Sedangkan menurut IEEE (The Institute of Electrical and Electronics Engineers)
kebutuhan adalah :
• Kondisi atau kemampuan yang diperlukan pemakai untuk menyelesaikan suatu
persoalan, atau untuk mencapai sebuah objek.
• Kondisi atau kemampuan yang harus dipenuhi oleh sistem, dalam arti memenuhi
kontrak, standar, spesifikasi atau dokumen formal lain yang diinginkan.
b. Munculnya ide untuk membuat sebuah perangkat lunak baru (sebagai sebuah
kemajuan).
2. Non-behavioral
Mendefinisikan atribut sistem yang terkait untuk membentuk pekerjaan
tersebut. Termasuk deskripsi lengkap tentang efisiensi, keamanan (security),
rehability maintenability (bagaimana perawatan untuk sistem), dan portability
(bisa dipindahkan dari satu perangkat keras ke perangkat keras lainnya).
Page 36 of 120
• Jika dapat dideteksi, dilakukan perbaikan pada setiap tahap proses.
• Jika tidak dapat dideteksi, kesalahan baru kelihatan setelah produk selesai
dibuat.
2. Sintesis
Mengubah kebutuhan yang belum terstruktur menjadi model atau gambar dengan
memanfaatkan teknik dan metodeanalisis tertentu.
3. Metode Analisis
Metode atau teknik untuk melakukan analisis kebutuhan perangkat lunak
dikelompokkan berdasarkan pendekatan yang diambil pada saat melakukan aktivitas
tersebut.
Berorientasi Aliran Data (Data Flow Oriented atau Functional Oriented) dengan
teknik top down atau bottom up.
Page 37 of 120
Pada proses kegiatan analisi system perencanaan Proyek (Project Planning) merupakan
awal dari serangkaian aktivitas secara kolektif dari sebuah proses Manajemen Proyek
Perangkat Lunak
Yang pertama dalam proses perencanaan ini adalah Estimation (perkiraan)
Bertujuan untuk melihat kondisi umum ke depan
Siap menerima kondisi yang berada dalam tingkat ketidak pastian.
Estimasi menjadi dasar bagian semua aktivitas perencanaan proyek yang lain, dan
Perencanaan proyek memberikan sebuah peta jalan bagi suksesnya Rekayasa
Perangkat Lunak
Untuk mendapatkan data kita perlu melakukan beberapa kegiatan (Perancangan Sistem
Informasi, Tata Sutabri, 2005);
1. Observasi
2. Interview
3. Kuisioner
4. Korespondensi
Page 38 of 120
2. Aspek Dalam SRS
Dalam Suatu SRS ada 2 aspek yang harus bisa dilihat :
1. Fungsi
Menjelaskan fungsi dari perangkat lunak (digunakan untuk apa keperluan apa),
sifat lunak dan datanya.
2. Non-Fungsi
a. Dependability
i. reliability
ii. maintainbility
iii. security
iv. integrity
b. Ergonomic
c. Performance
d. Contraint
Jika salah (incorrect), artinya spesifikasi yang ditulis adalah bukan yang
diinginkan.
2. Tepat (precise)
1. Pemakai (user)
2. Client
Page 39 of 120
Yang biasa melakukan kontak teknik pertama dengan client. Bertugas
menganalisis persoalan, menerima requirement dan menulis requirement.
4. Software engineer
Yang bekerja setelah kebutuhan perangkat lunak dibuat (bekerja sama dengan
sistem engineer berdasarkan SRS)
5. Programmer
7. Maintenance group
Memantau dan merawat performansi sistem perangkat lunak yang dibuat selama
pelaksanaan dan pada saat modifikasi muncul (80% dari pekerjaan).
8. Technical Support
Page 40 of 120
BAB 4 ANALISA JADWAL
PERANCANGAN PERANGKAT LUNAK
PRINSIP PENJADUALAN
Sejumlah prinsip dasar yang bisa menuntun penjadualan proyek perangkat lunak adalah :
PEMBAGIAN : proyek harus dibagi-bagi kedalam sejumlah tugas dan aktivitas yang
dapat dikendalikan
SALING KETERGANTUNGAN : Saling ketergantungan dari setiap tugas dan aktivitas
yang dibagi-bagi harus ditentukan
ALOKASI WAKTU : Setiap tugas yang akan dijadualkan harus dialokasikan dalam
sejumlah satuan kerja
VALIDASI KERJA : Setiap proyek memiliki sejumlah staf tertentu. Pada saat alokasi
waktu dilakukan, manajer proyek harus memastikan bahwa tidak akan ada kelebihan
alokasi jumlah manusia pada suatu saat tertentu.
Page 41 of 120
BATASAN TANGGUNG JAWAB : Setiap tugas yang dijadualkan harus ditugaskan
kepada satu anggota tim tertentu.
BATASAN KELUARAN : Setiap tugas yang dijadualkan harus memiliki keluaran
tertentu. Untuk proyek perangkat lunak, keluaran biasanya dalam bentuk hasil kerja
(seperti rancangan modul) atau sebagian dari hasil kerja
KEJADIAN PENTING YANG DITENTUKAN : Setiap tugas atau kelompok tugas
harus dihubungkan dengan kejadian penting proyek
Example (2)
With 2 months remaining, 2 additional people are added
Therefore, the number of communication path: 6!/(2!4!) = 15
productivity of 2 new staffs = 2 * (5000/12 month) * 2 month = 1680 LOC
So,
team productivity: 20,000 + 1680 – 250*15 less than 18,500 LOC/year
Page 42 of 120
TIPE-TIPE PROYEK
Meskipun mudah untuk mengembangkan system klasifikasi yang luas, kebanyakan
organisasi perangkat lunak menemui proyek dengan tipe-tipe sebagai berikut :
I. Concept Development Project : diinisiasi untuk mencari konsep bisnis yang baru atau
aplikasi beberapa teknologi baru
II. New Application Development Project : dilakukan sebagai konsekuensi permintaan
pelanggan yang khusus
III. Application Enhancement Project : terjadi ketika perangkat lunak yang ada
mengalami modifikasi utama pada fungsi, kinerja atau interface yang dapat diamati
oleh pemakai akhir
IV. Application Maintenance Project : dilakukan untuk membetulkan, menyesuaikan atau
memperluas perangkat lunak yang ada dengan cara yang tidak begitu jelas bagi
pemakai akhir.
V. Reengineering Project : proyek yang dikerjakan dengan maksud membangun system
(warisan) yang ada secara keseluruhan atau sebagian.
Page 43 of 120
JARINGAN KERJA
A graphic representation of the task flow for the project
Sometimes used as a mechanism for inputting task sequence and dependencies
to an automated tools
The concurrent nature of the tasks may lead to critical path, that is, tasks that
must be completed on schedule
MENDEFINISIKAN JARINGAN KERJA
I.5a
I.3a
Concept
Tech. Risk
Implement.
Assessment
I.3c I.5c
Tech. Risk Concept
Assessment Implement.
PENJADUALAN
Metode PERT (Program Evaluation and Review Technique) & CPM (Critical Path
Method)
PERT & CPM digunakan untuk :
1. Determine critical path
2. Establish most likely time estimates for individual task
3. Calculate “boundary times” that define a time “window” for particular task
Task, terkadang disebut Work Breakdown Structure (WBS)
(akan dibahas lengkap pada mata kuliah manajemen proyek perangkat lunak)
Page 44 of 120
ALOKASI KERJA (USAHA)
Page 45 of 120
BAB 5 ANALISA PEMODELAN
PEMODELAN ANALISIS
Adalah model yang menggunakan kombinasi teks dan diagram untuk menggam
barkan kebutuhan data, fungsi dan kebiasaan yang mudah dimengerti dan
ditinjau.
Biasanya menggunakan metode :
1. Analisa terstruktur
2. Analisa Berorientasi Objek
Pada inti model ada Kamus Data (DD) – penyimpan yang berisi deskripsi dari semua objek
data yang dikonsumsi atau diproduksi oleh perangkat lunak.
Page 46 of 120
Disitu ada tiga diagram yang mengelilingi inti yaitu :
a. Entity Relationship Diagram yang menggambarkan hubungan antara objek data.
ERD adalah notasi yang digunakan untuk melakukan aktivitas pemodelan data.
b. Data Flow Diagram yang melayani dua tujuan :
i. Memberikan indikasi mengenai bagaimana data di transformasi pada saat
data bergerak melalui system
ii. Untuk menggambarkan fungsi-fungsi (dan sub-fungsi) yang mentransformasi
aliran data
c. State Transition Diagram yang menunjukkan bagaimana system bertingkah laku
sebagai akibat dari kejadian eksternal. Untuk melakukannya, STD menunjukkan
berbaga model tingkah laku (disebut state) system dan cara dimana transisi dibuat
dari satu state ke state lainnya. STD berfungsi sebagai dasar bagi pemodelan tingkah
laku.
STATEMENT OF SCOPE
Adalah deskripsi relatif dari sistem yang dibangun untuk
indicates data that are input, output and basic functionality
indicates conditional processing (at a high level)
implies certain constraints and limitations
Page 47 of 120
Tentukan “operasi” dengan member garis bawah yang ganda untuk semua kata kerja
aktif terhadap
Proses-proses yang berkaitan dengan aplikasi
Tranformasi (perubahan bentuk) data
Pertimbangkan “layanan” lain yang akan dibutuhkan oleh objek (masalah)
Bentuk-bentuk objek
a. Eksternal entity (printer)
b. Benda (laporan, tampilan)
c. Kejadian
d. Peranan (manajer, supervisor)
e. Unit organisasi (divisi, kelompok)
f. Tempat (pabrik, bank)
g. Struktur (record pegawai)
Page 48 of 120
Adalah objek data yang terdiri dari kumpulan atribut yang bertindak seperti aspek, kualitas,
cirri / karakteristik atau pendefinisj objek
NOTASI ERD
ada tiga bentuk relationship yang dapat terjadi antar entitas
Objek1 1 relationship
1 Objek2
relationship
Objek1 1 M Objek2
relationship
Objek1 M N Objek2
MEMBANGUN ERD
Page 49 of 120
1. Level 1—modelkan semua objekdata (entiti) dan koneksinya dengan yang lain
2. Level 2—modelkan semua entitas dan hubungan
3. Level 3—modelkan semua entitas, hubungan dan atribut yang disiapkan lebih jauh
Contoh :
Program Studi Sistem Informasi dikepalai oleh seorang Ketua Program Studi yang
membina beberapa Dosen. Satu Dosen dapat mengajar satu atau lebih Mata Kuliah,
namun satu dosen tadi bisa saja mengajar lebih dari 1 kelas. 1 kelas diisi oleh banyak
Mahasiswa, dimana mahasiswa tsb bisa saja mengambil beberapa mata kuliah
1 1
Prog. Studi dikepalai Ka. ProDi
1 1
membina
M
M Dosen M
Memiliki
M M
mengampu
N
Mt. Kuliah mengajar
M
N
N
diambil Mahasiswa
N Kelas M N
menangani diisi oleh
Page 50 of 120
MEMBUAT MODEL ALIRAN (FLOW MODEL)
Setiap system berbasis computer adalah transformasi informasi …………
SISTEM
INPUT BERBASIS OUTPUT
KOMPUTER
EKSTERNAL ENTITI
PROSES
ALIRAN DATA
DATA STORE
EKSTERNAL ENTITI
Page 51 of 120
PROSES
Berfungsi merubah data (input menjadi output)
Data harus selalu diproses dalam beberapa cara untuk mencapai fungsi system
Nama proses MINIMAL terdiri dari gabungan dua kata, yaitu gabungan kata kerja dan
kata benda (misal Hitung Gaji, Cetak Laporan)
TIDAK BOLEH menggunakan kata-kata PROSES
DATA FLOW
Data flows menunjukkan arah mengalirnya data / informasi melalui system dan data
apa yang dibawa
Sebagai penunjuk dari mana data tsb berasal dan ke arah mana data / data yang
telah diolah (informasi) nya dituju
Nama aliran data HARUS KATA BENDA
TIDAK BOLEH menggunakan kata-kata DATA atau INFORMASI
DATA STORE
Sebagai tempat penyimpanan data yang akan digunakan untuk keperluan
selanjutnya
Nama harus sesuai content
Eksternal
Entiti Data1
DATA STORE-1
Page 52 of 120
DFD berkembang menjadi beberapa tingkatan yang lebih rinci
Selalu dimulai dengan diagram konteks
Selalu memperlihatkan eksternal entity
Selalu ada label data flow yang ditunjukkan dengan panah
Tidak menggambarkan prosedur logika
Jadual test
0 Syarat Kelulusan
Lembar Jawaban SISFO
PENERIMAAN
Hasil Test MHS BARU
Page 53 of 120
CONTOH DFD
Form Pendaftaran Ulang
CALON
MAHASISWA Form Pendaftaran
1.0
Jadual test Entry
Calon
Mhs
C_MHS
2.0
Buat
Jadual
Test
Lembar Jawaban
3.0
Koreksi
Hasil Test Lembar
Jawaban
4.0
Entry
FPU
M_MHS
5.0
PIMPINAN Daftar Mhs Baru Cetak
UNIVERSITAS Daftar
Mhs Baru
Page 54 of 120
PANDUAN LAIN YANG HARUS DIPERHATIKAN
Keseimbangan aliran data dan DFD harus diperhatikan dalam tingkatan lanjutannya
Membangun level 1 DFD akan lebih banyak membantu
Gunakan rasio maksimum 1:5 (kira-kira) dalam pengembangan setiap proses
Setiap proses di uraikan sampai masing-masingnya hanya mengerjakan 1 tugas
Page 55 of 120
EVALUASI DAN PERTANYAAN
Page 56 of 120
Kontrol data terpusat
Hal ini dapat mempermudah pengontrolan data. Contohnya ingin mengupdate
data mahasiswa, maka kita hanya perlu mengupdate semua data di masing-
masing bagian atau divisi, tetapi hanya cukup meliahat di satu database saja
yang terdapat di server pusat.
Menghemat biaya perangkat
Dengan memiliki database secara terpusat maka masing-masing divisi tidak
harus memiliki perangkat untuk menyimpan database, karena database tersebut
sudah di simpan di server pusat. Hal ini tentunya dapat memangkas pembelian
perangkat.
Keamanan Data
Hampir semua Aplikasi manajemen database sekarang memiliki fasilitas
manajemen pengguna. Manajemen pengguna ini mampu membuat hak akses
yang berbeda-beda disesuaikan dengan kepentingan maupun posisi pengguna.
Selain itu data yang tersimpan di database diperlukan password untuk
mengaksesnya.
Memudahkan dalam pembuatan aplikasi baru
Page 57 of 120
STUDI KASUS
Conceptual Data Model (CDM)
Membuka software PowerDesigner, kemudian klick new project setelah itu pilih
conceptual diagram.
Setelah tampil layar putih, maka pilih icon entity untuk membuat entitas entitas.
Page 58 of 120
Pembuatan tabel karyawan
Attribute dari tabel karyawan, pada field kode_karyawan diberi primary key dan
mandatory.
Page 59 of 120
Pembuatan tabel gaji.
Attribute dari tabel gaji, pada field kode_gaji diberi primary key dan mandatory.
Page 60 of 120
Pembuatan tabel transaksi.
Atrribute dari tabel transaksi, pada field kode_transaksi diberi primary key dan
mandatory.
Page 61 of 120
Pembuatan tabel jabatan.
Attribute dari tabel jabatan, pada field kode_jabatan diberi primary key dan
mandatory.
Page 62 of 120
Pembuatan tabel item_penjualan
Page 63 of 120
Pembuatan tabel member.
Attribute dari tabel ,ember,pada field kode_member diberi primary dan mandatory.
Page 64 of 120
Pembuatan tabel menu.
Attribute dari tabel menu, pada kode_menu diberi primary key dan mandatory.
Page 65 of 120
Relationship
Page 66 of 120
Untuk melakukan pengecekan error atau tidaknya suatu CDM maka dengan cara F4
lalu muncul kotak dialog dibawah ini, jika isi nya kosong, maka tidak terjadi error.
Page 67 of 120
Maka akan muncul kotak dialog PDM Generations Options seperti tampilan dibawah
ini.
Pada tab detail tambahkan tbl_ pada table prefix, kemudian rubah update rule dan
delete rule menjadi cascade. Gunanya agar bisa dilakukan delete maupun update
pada tiap relasinya.
Page 68 of 120
Setelah di apply dan ok, maka akan tampil seperti gambar dibawah ini.
Generate Database
Pilih database kemudian klick generate database.
Page 69 of 120
Pada DBMS rubah ke mysql 5.0 karena kami menggunakan database mysql versi 5.
Query Database
/*===========================================================
===*/
/* DBMS name: MySQL 5.0 */
/* Created on: 22/12/2015 11:50:11 */
/*===========================================================
===*/
drop table if exists TBL_GAJI;
drop table if exists TBL_ITEM_PENJUALAN;
drop table if exists TBL_JABATAN;
drop table if exists TBL_KARYAWAN;
drop table if exists TBL_MEMBER;
drop table if exists TBL_MENU;
drop table if exists TBL_TRANSAKSI;
/*===========================================================
===*/
/* Table: TBL_GAJI */
/*===========================================================
===*/
create table TBL_GAJI
(
KODE_GAJI int not null,
KODE_KARYAWAN int not null,
GAJI int,
Page 70 of 120
primary key (KODE_GAJI)
);
/*===========================================================
===*/
/* Table: TBL_ITEM_PENJUALAN */
/*===========================================================
===*/
create table TBL_ITEM_PENJUALAN
(
ID_PENJUALAN int not null,
KODE_TRANSAKSI int not null,
KODE_MENU int not null,
HARGA_PER_ITEM int,
KUANTITAS_PER_ITEM int,
JUMLAH_HARGA_PER_ITEM int,
primary key (ID_PENJUALAN)
);
/*===========================================================
===*/
/* Table: TBL_JABATAN */
/*===========================================================
===*/
create table TBL_JABATAN
(
KODE_JABAATAN int not null,
NAMA_JABATAN text,
primary key (KODE_JABAATAN)
);
/*===========================================================
===*/
/* Table: TBL_KARYAWAN */
/*===========================================================
===*/
create table TBL_KARYAWAN
(
KODE_KARYAWAN int not null,
KODE_JABAATAN int not null,
KODE_GAJI int,
Page 71 of 120
NAMA_KARYAWAN text,
ALAMAT_KARYAWAN text,
TANGGAL_LAHIR_KARYAWAN date,
NOMOR_HP_KARYAWAN numeric(8,0),
JENIS_KELAMIN_KARYAWAN text,
primary key (KODE_KARYAWAN)
);
/*===========================================================
===*/
/* Table: TBL_MEMBER */
/*===========================================================
===*/
create table TBL_MEMBER
(
KODE_MEMBER int not null,
NAMA_MEMBER text,
EMAIL_MEMBER text,
NO_HP_MEMBER numeric(8,0),
ALAMAT_MEMBER text,
TGL_LAHIR_MEMBER date,
JENIS_KELAMIN_MEMBER text,
primary key (KODE_MEMBER)
);
/*===========================================================
===*/
/* Table: TBL_MENU */
/*===========================================================
===*/
create table TBL_MENU
(
KODE_MENU int not null,
NAMA_MENU text,
HARGA_MENU int,
DESKRIPSI_MEU text,
primary key (KODE_MENU)
);
/*===========================================================
===*/
Page 72 of 120
/* Table: TBL_TRANSAKSI */
/*===========================================================
===*/
create table TBL_TRANSAKSI
(
KODE_TRANSAKSI int not null,
KODE_KARYAWAN int not null,
KODE_MEMBER int not null,
TANGGAL_TRANSAKSI date,
DISKON float,
TOTAL_HARGA_SELURUHNYA float,
primary key (KODE_TRANSAKSI)
);
alter table TBL_GAJI add constraint FK_MEMILIKI foreign key
(KODE_KARYAWAN) references TBL_KARYAWAN (KODE_KARYAWAN) on
delete cascade on update cascade;
alter table TBL_ITEM_PENJUALAN add constraint FK_MENGAMBIL foreign key
(KODE_MENU) references TBL_MENU (KODE_MENU) on delete cascade on
update cascade;
alter table TBL_ITEM_PENJUALAN add constraint FK_MENGHITUNG foreign
key (KODE_TRANSAKSI) references TBL_TRANSAKSI (KODE_TRANSAKSI)
on delete cascade on update cascade;
alter table TBL_KARYAWAN add constraint FK_MEMILIKI2 foreign key
(KODE_GAJI) references TBL_GAJI (KODE_GAJI) on delete cascade on update
cascade;
alter table TBL_KARYAWAN add constraint FK_MEMPUNYAI foreign key
(KODE_JABAATAN) references TBL_JABATAN (KODE_JABAATAN) on delete
cascade on update cascade;
alter table TBL_TRANSAKSI add constraint FK_MELAKUKAN foreign key
(KODE_MEMBER) references TBL_MEMBER (KODE_MEMBER) on delete
cascade on update cascade;
alter table TBL_TRANSAKSI add constraint FK_MELAYANI foreign key
(KODE_KARYAWAN) references TBL_KARYAWAN (KODE_KARYAWAN) on
delete cascade on update cascade;
Page 73 of 120
Import Database
Buka phpmyadmin, dan buat database toko.
Pilih tab import, pada choose file pilih file toko.sql kemudian klick go.
Berikut adalah hasil setelah diimport pada database toko menggunakan DBMS
MySql versi 5.
Page 74 of 120
Pendahuluan
BAB 6 UML
UML merupakan gabungan dari metode Booch, Rumbaugh (OMT) dan Jacobson.
Tetapi UML ini akan mencakup lebih luas daripada OOA&D. Pada pertengahan
pengembangan UML dilakukan standarisasi proses dengan OMG (Object
Management Group) dengan harapan UML akan menjadi bahasa standar pemodelan
pada masa yang akan datang.
UML disebut sebagai bahasa pemodelan bukan metode. Kebanyakan metode terdiri
paling sedikit prinsip, bahasa pemodelan dan proses. Bahasa pemodelan (sebagian
besar grafik) merupakan notasi dari metode yang digunakan untuk mendesain secara
cepat.
Bahasa pemodelan merupakan bagian terpenting dari metode. Ini merupakan bagian
kunci tertentu untuk komunikasi. Jika anda ingin berdiskusi tentang desain dengan
seseorang, maka Anda hanya membutuhkan bahasa pemodelan bukan proses yang
digunakan untuk mendapatkan desain.
UML merupakan bahasa standar untuk penulisan blueprint software yang digunakan
untuk visualisasi, spesifikasi, pembentukan dan pendokumentasian alat-alat dari
sistem perangkat lunak.
UML dimulai secara resmi pada oktober 1994, ketika Rumbaugh bergabung dengan
Booch pada Relational Software Corporation. Proyek ini memfokuskan pada
penyatuan metode Booch dan OMT. UML versi 0.8 merupakan metode penyatuan
yang dirilis pada bulan Oktober 1995. Dalam waktu yang sama, Jacobson bergabung
dengan Relational dan cakupan dari UML semakin luas sampai diluar perusahaan
OOSE. Dokumentasi UML versi 0.9 akhirnya dirilis pada bulan Juni 1996. Meskipun
pada tahun 1996 ini melihat dan menerima feedback dari komunitas Software
Engineering . Dalam waktu tersebut, menjadi lebih jelas bahwa beberapa organisasi
perangkat lunak melihat UML sebagai strategi dari bisnisnya. Kemudian dibangunlah
UML Consortium dengan beberapa organisasi yang akan menyumbangkan sumber
dayanya untuk bekerja, mengembangkan, dan melengkapi UML.
Di sini beberapa partner yang berkontribusi pada UML 1.0, diantaranya Digital
Equipment Corporation, Hewlett-Packard, I-Logix, Intellicorp, IBM, ICON
Computing, MCI Systemhouse, Microsoft, Oracle, Relational, Texas Instruments dan
Unisys. Dari kolaborasi ini dihasilkan UML 1.0 yang merupakan bahasa pemodelan
yang ditetapkan secara baik, expressive, kuat, dan cocok untuk lingkungan masalah
yang luas. UML 1.0 ditawarkan menjadi standarisasi dari Object Management Group
(OMG). Dan pada Januari 1997 dijadikan sebagai standar bahasa pemodelan.
Page 75 of 120
Pendahuluan
Pemeliharaan UML terus dipegang oleh OMG Revision Task Force (RTF) yang
dipimpin oleh Cris Kobryn. RTP merilis editorial dari UML 1.2 pada Juni 1998. Dan
pada tahun 1998 RTF juga merilis UML 1.3 disertai dengan user guide dan
memberikan technical cleanup.
1. View
View digunakan untuk melihat sistem yang dimodelkan dari beberapa aspek yang
berbeda. View bukan melihat grafik, tapi merupakan suatu abstraksi yang berisi
sejumlah diagram.
Beberapa jenis view dalam UML antara lain: use case view, logical view, component
view, concurrency view, dan deployment view.
Page 76 of 120
Pendahuluan
Ø Logical view
Mendeskripsikan bagaimana fungsionalitas dari sistem, struktur statis (class, object,
dan relationship ) dan kolaborasi dinamis yang terjadi ketika object mengirim pesan
ke object lain dalam suatu fungsi tertentu.
View ini digambarkan dalam class diagrams untuk struktur statis dan dalam state,
sequence, collaboration, dan activity diagram untuk model dinamisnya.
View ini digunakan untuk perancang (designer) dan pengembang (developer).
Ø Component view
Mendeskripsikan implementasi dan ketergantungan modul. Komponen yang
merupakan tipe lainnya dari code module diperlihatkan dengan struktur dan
ketergantungannya juga alokasi sumber daya komponen dan informasi administrative
lainnya.
View ini digambarkan dalam component view dan digunakan untuk pengembang
(developer).
Ø Concurrency view
Membagi sistem ke dalam proses dan prosesor.
View ini digambarkan dalam diagram dinamis (state, sequence, collaboration, dan
activity diagrams) dan diagram implementasi (component dan deployment diagrams)
serta digunakan untuk pengembang (developer), pengintegrasi (integrator), dan
penguji (tester).
Ø Deployment view
Mendeskripsikan fisik dari sistem seperti komputer dan perangkat (nodes) dan
bagaimana hubungannya dengan lainnya.
View ini digambarkan dalam deployment diagrams dan digunakan untuk pengembang
(developer), pengintegrasi (integrator), dan penguji (tester).
2. Diagram
Diagram berbentuk grafik yang menunjukkan simbol elemen model yang disusun
untuk mengilustrasikan bagian atau aspek tertentu dari sistem.
Sebuah diagram merupakan bagian dari suatu view tertentu dan ketika digambarkan
biasanya dialokasikan untuk view tertentu. Adapun jenis diagram antara lain :
Ø Class Diagram
Menggambarkan struktur statis class di dalam sistem. Class merepresentasikan
sesuatu yang ditangani oleh sistem. Class dapat berhubungan dengan yang lain
melalui berbagai cara: associated (terhubung satu sama lain), dependent (satu class
tergantung/menggunakan class yang lain), specialed (satu class merupakan
spesialisasi dari class lainnya), atau package (grup bersama sebagai satu unit).
Sebuah sistem biasanya mempunyai beberapa class diagram.
Page 77 of 120
Pendahuluan
Ø State Diagram
Menggambarkan semua state (kondisi) yang dimiliki oleh suatu object dari suatu
class dan keadaan yang menyebabkan state berubah. Kejadian dapat berupa object
lain yang mengirim pesan.
State class tidak digambarkan untuk semua class, hanya yang mempunyai sejumlah
state yang terdefinisi dengan baik dan kondisi class berubah oleh state yang berbeda.
Ø Sequence Diagram
Menggambarkan kolaborasi dinamis antara sejumlah object. Kegunaanya untuk
menunjukkan rangkaian pesan yang dikirim antara object juga interaksi antara object,
sesuatu yang terjadi pada titik tertentu dalam eksekusi sistem.
Ø Collaboration Diagram
Menggambarkan kolaborasi dinamis seperti sequence diagrams. Dalam menunjukkan
pertukaran pesan, collaboration diagrams menggambarkan object dan hubungannya
(mengacu ke konteks). Jika penekannya pada waktu atau urutan gunakan sequence
diagrams, tapi jika penekanannya pada konteks gunakan collaboration diagram.
Ø Activity Diagram
Menggambarkan rangkaian aliran dari aktivitas, digunakan untuk mendeskripsikan
aktifitas yang dibentuk dalam suatu operasi sehingga dapat juga digunakan untuk
aktifitas lainnya seperti use case atau interaksi.
Ø Component Diagram
Menggambarkan struktur fisik kode dari komponent. Komponent dapat berupa source
code, komponent biner, atau executable component. Sebuah komponent berisi
informasi tentang logic class atau class yang diimplementasikan sehingga membuat
pemetaan dari logical view ke component view.
Ø Deployment Diagram
Menggambarkan arsitektur fisik dari perangkat keras dan perangkat lunak sistem,
menunjukkan hubungan komputer dengan perangkat (nodes) satu sama lain dan jenis
hubungannya. Di dalam nodes, executeable component dan object yang dialokasikan
untuk memperlihatkan unit perangkat lunak yang dieksekusi oleh node tertentu dan
ketergantungan komponen.
Page 78 of 120
Pendahuluan
Page 79 of 120
Pendahuluan
Namun UML tidak terbatas untuk pemodelan software. Pada faktanya UML banyak
untuk memodelkan sistem non software seperti:
- Aliran kerja pada sistem perundangan.
- Struktur dan kelakuan dari Sistem Kepedulian Kesehatan Pasien
- Desain hardware dll.
Page 80 of 120
Use Case Diagram
Tujuan Praktikum:
1. Praktikan mampu membuat sebuah skenario suatu sistem yang nantinya dapat
diimplementasikan menjadi sebuah perangkat lunak.
2. Praktikan bisa memahami alur dari setiap tahap yang digunakan dalam perancangan
perangkat lunak menggunakan UML.
3. Praktikan dapat memahami hubungan atara actor dengan use case diagram.
4. Praktikan mampu membuat use case diagram dari skenario yang telah ada.
Kelakuan Sistem :
1. Kebutuhan sistem adalah fungsionalitas apa yang mesti disediakan oleh sistem, apakah
didokumentasikan pada model use case yang menggambarkan fungsi sistem yang
diharapkan (use case), yang mengelilinginya (actor) dan hubungan antara actor dengan
use case (use case diagram).
2. Use case model dimulai pada tahap inception dengan mengidentifikasi actor dan use case
utama pada sistem. Kemudian model ini diolah lebih matang di tahap elaboration untuk
memperoleh lebih detail informasi yang ditambahkan pada use case.
1.1 Actor
Pada dasarnya actor bukanlah bagian dari use case diagram, namun untuk dapat
terciptanya suatu use case diagram diperlukan beberapa actor dimana actor tersebut
mempresentasikan seseorang atau sesuatu (seperti perangkat, sistem lain) yang
berinteraksi dengan sistem. Sebuah actor mungkin hanya memberikan informasi
inputan pada sistem, hanya menerima informasi dari sistem atau keduanya menerima
dan memberi informasi pada sistem, actor hanya berinteraksi dengan use case tetapi
tidak memiliki kontrol atas use case. Actor digambarkan dengan stick man .
Actor dapat digambarkan secara secara umum atau spesifik, dimana untuk
membedaka nnya kita dapat menggunakan relationship
Contoh :
Customer
Commercial
Customer
Page 81 of 120
Use Case Diagram
Mendokumentasikan actors
a. Jika documentation window belum terlihat, buka dengan memilih Documentation
menu dari View menu.
b. Klik untuk memilih Actor di browser.
c. Tempatkan cursor di documentation window, lalu ketikkan dokumentasi yang
diinginkan.
UseCase
Page 82 of 120
Use Case Diagram
Catatan : actor dan use cases dapat juga langsung diciptakan dalam sebuah use case
diagram dengan menggunakan toolbar.
Tipe relasi/ stereotype yang mungkin terjadi pada use case diagram:
1. <<include>> , yaitu kelakuan yang harus terpenuhi agar sebuah event dapat
terjadi, dimana pada kondisi ini sebuah use case adalah bagian dari use case
lainnya.
2. <<extends>>, kelakuan yang hanya berjalan di bawah kondisi tertentu seperti
menggerakkan alarm.
3. <<communicates>>, mungkin ditambahkan untuk asosiasi yang menunjukkan
asosiasinya adalah communicates association . Ini merupakan pilihan selama
asociasi hanya tipe ralationship yang dibolehkan antara actor dan use case.
Berikut ini adalah contoh dari sebuah studi kasus yang menagani Aplikasi pada
sebuah ATM dengan skenario sbb:
Sebuah bank mengoperasikan ATM dan mengelola banyak tabungan, setiap nasabah
memiliki setidaknya satu rekening tabungan pada satu bank tertentu. Setiap
tabungan dapat diakses melalui kartu debit. Proses utama sistem ATM
berkomunikasi dengan pusat komputer dan didesain untuk menangani beberapa
transaksi. Setiap transaksi menunjuk sebuah tabungan tertentu. Suatu transaksi akan
menghasilkan satu dari dua hal berikut: transaksi diterima atau mengeluarkan pesan
penolakan transaksi".
Untuk melakukan sebuah transaksi akan melalui dua tahap: pengecekan tabungan
dan pemroses transaksi. Proses pengecekan tabungan akan menetapkan persetujuan
untuk proses transaksi. Jika persetujuan ditolak, ATM akan mengeluarkan pesan
penolakan, namun jika diterima, transaksi akan diproses de ngan menggunakan
nomor rekening tabungan dan ATM membaca dari kartu debit.
Pengecekan tabungan dilakukan bersamaan pada saat ATM memvalidasi kartu debit
dari bank yang bersangkutan. Jika kartu valid, password akan dicek dengan nasabah.
Page 83 of 120
Use Case Diagram
Authenticate User
Withdrawal
User Bank
Transfer
Gambar 1.3 Use Case Diagram Studi Kasus ATM
Untuk memudahkan kita dalam menganalisa skenario yang akan kita gunakan pada fase-fase
selanjutnya maka kita dapat melakukan pemilahan terhadap skenario tersebut, antara lain:
ACTOR SISTEM
1. User memasukkan kartu debit
2. ATM meminta PIN dari user
3. User memasukkan PIN dan
menekan OK
4. ATM memverifikasi dengan Bank
bahwa kartu dan PIN adalah legal
dari Rekening yang benar
5. ATM meminta jenis transaksi
Page 84 of 120
Use Case Diagram
ACTOR SISTEM
1. User memilih menu withdrawal
2. ATM meminta jumlah uang yang
akan ditarik
3. User memasukkan jumlah uang
yang akan ditarik
4. ATM mencek jumlah uang yang
akan ditarik dengan saldo
minimal yang diperbolehkan pada
bank tersebut.
5. Update saldo
6. ATM mengeluarkan uang
7. ATM mencetak nota dan
mengeluarkan kartu
Page 85 of 120
Use Case Diagram
Jurnal Modul 1
1. Evaluasi use case yang digunakan pada studi kasus pada modul 1. Jika dirasakan
perlu, modifikasi use case diagram Sistem ATM.
2. Buatlah use case diagram dari kasus dibawah. Catatan: kasus di bawah akan
digunakan pada semua modul pada praktikum ini (modul 1 – modul 6)
Nama Kasus : SISTEM PENJUALAN ITEM SUPERMARKET
Deskripsi :
Studi kasus ini mengembangkan desain sistem penjualan item pada suatu
supermarket. Sistem ini menangani sistem pemrosesan tersebar.
Business Rules
• Item adalah barang yang dijual di supermarket dan harus terdaftar di dalam
sistem.
• Kasir menjual item kepada pembeli. Terdapat 2 jenis kasir, yaitu kasir biasa dan
kasir express. Kasir express hanya melayani penjualan max 5 item.
• Sistem menangani penjualan item, pemasokan barang, penukaran item.
• Pada penukaran item, item yang ditukarkan diusahakan merupakan item yang
sama, namun jika supplier tidak menyediakan lagi maka dapat ditukarkan dengan
item yang lain seharga item yang kadaluarsa atau sesuai dengan perjanjian.
Page 86 of 120
Candidat Class & Interaction Diagram
Tujuan Praktikum:
1. Praktikan dapat menentukan candidate class dari skenario yang telah ada.
2. Praktikan dapat menggambarkan interaction diagram baik dengan sequence maupun
collaboration diagram.
3. Praktikan dapat membedakan antara sequence dengan colla boration diagram dan
mengunakannya dalam perancangan perangkat lunak dengan UML.
Class adalah deskripsi sekelompok object dari property (atribut), sifat (operasi),
relasi antar object dan sematik yang umum. Class merupakan template untuk
membentuk object. Setiap object merupakan contoh dari beberapa class dan object
tidak dapat menjadi contoh lebih dari satu class.
Penamaan class menggunakan kata benda tunggal yang merupakan abstraksi yang
terbaik.
Pada UML, class digambarkan dengan segi empat yang dibagi. Bagian atas
merupakan nama dari class. Bagian yang tengah merupakan struktur dari class
(atribut) dan bagian bawah merupakan sifat dari class (operasi).
Page 87 of 120
Candidat Class & Interaction Diagram
Customer
name
address
CreditRating():String
Dari skenario pada modul 1 untuk studi kasus pada ATM, kita dapat mendefenisikan
candidate class, dimana candidate class secara kasar dapat diambil dari kata benda
yang ada, atau sesuai dengan apa yang telah dijelaskan diatas.
Candidate Class
No Kategori Object Nama Object Perlu/tidak
1. Object Fisik ATM (Mesin), ATM card Perlu
2. Transaksi Withdrawal, Transfer Perlu
3. Butir yang terlibat pada ………. ……….
transaksi
4. Peran User(Pemegang ATMCard) Perlu
Bank Perlu
5. Piranti ATM Perlu
Komputer Tidak perlu
6. Proses Withdrawal Perlu
Update Tidak perlu
7. Katalog Daftar Account Perlu
ATM
ATM Card
User Transfer
BANK
Withdrawal
Untuk memahami Class lebih lanjut akan kita bahas pada modul 3.
Page 88 of 120
Candidat Class & Interaction Diagram
Use case realization menggambarkan bagaimana realisasi dari setiap use case yang
ada pada use case model. Untuk menggambarkan bagaimana realisasi dari suatu use
case dapat menggunakan beberapa diagram, diantaranya adalah Class Diagram
owned by Use Case Realization serta Interaction Diagram.
Ketika kita memberikan pesan, aksi yang dihasilkan adalah sebuah pernyataan
tereksekusi yang membentuk abstraksi dari prosedur komputasi. Sebuah aksi mungkin
menghasilkan perubahan kondisi.
Interaction diagram digunakan ketika kita ingin melihat kelakuan dari beberapa
object dalam use case tunggal. Diagram ini baik saat menunjukkan kolaborasi
diantara object-object, namun kurang baik dalam mendefinisikan behavior.
Ada dua macam Interaction Diagram yaitu : Sequence Diagram dan Collaboration
Diagram.
Dalam UML, object pada diagram sequence digambarkan dengan segi empat yang
berisi nama dari object yang digarisbawahi. Pada object terdapat 3 cara untuk
menamainya yaitu : nama object, nama object dan class serta nama class.
Page 89 of 120
Candidat Class & Interaction Diagram
Contoh :
BNI Nama Object
Dalam diagram sequence, setiap object hanya memiliki garis yang digambarkan garis
putus-putus ke bawah. Pesan antar object digambarkan dengan anak panah dari object
yang mengirimkan pesan ke object yang menerima pesan.
Page 90 of 120
Candidat Class & Interaction Diagram
: ATM : ATMCard
: User
RequestCard( )
InsertCard( )
VerifyCard( )
CardOK( )
RequestPIN( )
EnterPIN( )
VerifyPIN( )
PIN OK( )
EnterAmount( )
<<Create>>
CheckForSufficientFunds( )
DebitSaldo( )
Authorized( )
Setcash( )
DispenceCash( )
PrintReceipt( )
Page 91 of 120
Candidat Class & Interaction Diagram
2: InsertCard( )
6: EnterPIN( )
: ATM
1: RequestCard( )
: User 5: RequestPIN( )
3: VerifyCard( )
4 : C a r d O K ( 7): V e r i f y P I N ( )
8: PIN OK( )
: ATMCard
Page 92 of 120
Candidat Class & Interaction Diagram
2: EnterAmount( )
: ATM
1: Amount( )
: User 8: DispenceCash( )
9: PrintReceipt( )
6: Authorized( )
: Saving : Withdrawal
Account Transaction
4: CheckForSufficientFunds( )
Jurnal Modul 2
.
1. Buatlah sequence diagram dan collaboration diagram yang berasal dari use case
Transfer pada Sistem ATM. Tambahkan candidate class apabila dianggap perlu.
2. Carilah sequence diagram dan collaboration diagram yang berasal dari use case-
use case pada SISTEM PENJUALAN ITEM SUPERMARKET. Lakukan
perubahan yang dianggap perlu pada diagram-diagram sebelumnya.
Page 93 of 120
Class Diagram
Pada modul sebelumnya kita sudah mengupas sedikit tentang object dan candidate class, dan
pada modul ini kita akan membahas lebih dalam tentang bagaimana suatu class dapat
dibentuk, hubungan anatar class beberapa class turunan.
Identitas (Identify) artinya setiap object yang unik Pada UML, object digambarkan
dengan segiempat dan nama dari object diberi garis bawah.
Mahasiswa
Gambar 3.1 Object
Mendefinisikan Class
Seperti telah dijelaskan sebelumnya, stereotypes memberikan kemampuan untuk
membuat elemen pemodelan yang baru. Beberapa stereotype untuk class adalah
entity, boundary, control, utility dan exception.
Membuat class
1. Klik kanan Logical View pada browser.
2. Pada menu bar pilih New, Class. Sebuah class bernama New Class ditempatkan
pada browser.
3. Ketika new class masih tersorot, masukkan nama class yang diinginkan.
Contoh :
<<entity>>
Informasi Mahasiswa
Page 94 of 120
Class Diagram
Karena proses analisa dan desain adalah iterasi, daftar class akan berubah sesuai
waktu. Class awal mungkin tidak akan menjadi class yang akan diimplementasikan.
Sehingga candidate class sering digunakan untuk menggambarkan himpunan awal
dari class yang ditemukan pada sistem.
Untuk merancang class diagram, Rational Unified Process yang merupakan hasil
pengembangan dari Rational Objectory Process menggunakan use case realization
yang menggambarkan bagaimana realisasi dari setiap use case yang ada pada use ca se
model. Untuk menggambarkan bagaimana realisasi dari suatu use case dapat
menggunakan beberapa diagram, diantaranya adalah Class Diagram owned by Use
Case Realization serta Interaction Diagram.
Untuk menggambarkan use case realization di sini akan menggunakan class diagram
owned by use case realization. Setiap use case yang ada di-breakdown sehingga akan
dapat terlihat entitas-entitas apa saja yang terlibat dalam merealisasikan sebuah use
case. Entitas-entitas ini akan menjadi candidate class dalam Class Diagram.
Page 95 of 120
Class Diagram
3.2.1 Attribut
Attribut adalah salah satu property yang dimiliki oleh class yang menggambarkan
batasan dari nilai yang dapat dimiliki oleh property tersebut. Sebuah class mungkin
memiliki beberapa atribut atau tidak memilikinya sama sekali. Sebuah atribut
merepresentasikan beberapa property dari sesuatu yang kita modelkan, yang dibagi
dengan semua object dari semua class yang ada. Contohnya, setiap tembok memiliki
tinggi, lebar dan ketebalan. Atribut dalam implementasinya akan digambarkan
sebagai sebuah daftar (list) yang diletakkan pada kotak dibawah nama class. Ia seperti
halnya nama class merupakan teks. Biasanya huruf pertama dari tiap kata merupakan
huruf kapital, terkecuali untuk huruf awal. Sebagai contohnya : birthDate.
Customer
-name
-address
-birthDate
Untuk lebih lanjut kita pun bisa menspesifikasikan atribut beserta jenis data yang kita
gunakan untuk atribut tersebut.
Wall
-Tinggi : float
-Lebar : float
-Tebal : float
-Kualitas : bool
3.2.2 Operasi
Sebuah operasi adalah sebuah implementasi dari layanan yang dapat diminta dari
beberapa object dari class , yang mempengaruhi behaviour. Dengan kata lain operasi
adalah abstraksi dari segala sesuatu yang dapat kita lakukan pada sebuah object dan ia
berlaku untuk semua object yang terdapat dalam class tersebut. Class mungkin
memiliki beberapa operasi atau tanpa operasi sama sekali.contohnya adalah sebuah
class “kotak” dapat dipindahkan, diperbesar atau diperkecil. Biasanya (namun tidak
selalu), memanggil operasi pada sebuah object akan mengubah data atau kondisi dari
object tersebut. Operasi ini dalam implementasinya digambarkan dibawah atribut dari
sebuah class.
Kotak
+Pindah()
+Perbesar()
+Perkecil()
Gambar 3.5 Contoh dari operasi.
Page 96 of 120
Class Diagram
Untuk lebih lanjut kita pun bisa menspesifikasikan semua parameter yang terlibat
dalam operasi tersebut.
sensorPanas
reset()
setAlarm(t:temperature)
value():temperature
Gambar 3.6 contoh lain dari operasi.
Kosongnya kotak tempat pengisian bukan berarti tidak ada. Karena itu kita dapat
menambahkan tanda (“…”) pada akhir daftar yang menunjukkan bahwa masih ada
atribut atau operasi yang lain.
Page 97 of 120
Class Diagram
Company Department
Page 98 of 120
Class Diagram
Membuat multiplicity
1. Klik ganda garis relationship untuk membuat specification terlihat.
2. Pilih tab detail untuk role yang akan dimodifikasi (Role A Detail atau Role B
Detail).
3. Masukkan multiplicity yang diinginkan
Nasabah Bank
1..* 1
• Sebuah object Nasabah berelasi dengan tepat satu object Bank, misal :
Irma berelasi dengan Bank Dana.
• Sebuah object Bank berelasi dengan satu atau tak hingga nasabah. Misal :
Bank Dana berelasi dengan Irma, Ilham, Norman, dsb.
Pegawai
mengatur
1..*
0..*
0..*
Page 99 of 120
Class Diagram
Menemukan Relationships
Untuk menemukan relationships class-class yang ada dapat dilakukan dengan
memeriksa skenario dan pertukaran message diantara class-class yang ada. Pada
tahap analisa, dua relationship yang ditemukan adalah asosiasi dan agregasi.
Dikarenakan metode yang digunakan merupakan iterative maka relationship akan
berubah seiring dengan fase analisis dan desain.
Membuat operation
1. Klik kanan class pada browser.
2. Pilih New, Operation. Sebuah operation bernama Opname muncul pada browser.
3. Masukkan nama yang diinginkan.
Mendokumentasikan operation
1. Klik tanda “+” di sebelah class pada browser untuk meng-expand class.
2. Klik untuk memilih operation .
3. Tempatkan cursor pada documentation window lalu masukkan Dokumentasi.
Membuat Attribute
1. Klik kanan class pada browser.
2. Pilih New, Attribute . Pada browser akan tampil attribute Name.
3. Pilih nama yang dinginkan untuk atribut tersebut.
3.4 Inheritance
Inheritance merupakan kemampuan untuk membuat hierarki yang terdiri atas class-
class, dimana terdapat struktur dan atau behavior (kelakuan) diantara class-class.
Istilah superclass digunakan oleh class yang menyimpan informasi umum. Keturunan
dari superclass disebut subclass.
Sebuah subclass mewarisi semua atribut, operasi dan relationship yang dipunyai oleh
semua superclass-superclassnya. Inheritance disebut juga hierarki is-a (adalah
sebuah) atau kind -of (sejenis). Subclass dapat menggunakan atribut dan operasi
tambahan yang hanya berlaku pada level hierarkinya. Karena inheritance relationship
bukan sebuah relationship diantara object yang berbeda, maka relationship ini tidak
pernah diberi nama, penamaan role juga tidak digunakan dan multiplicity tidak
digunakan. Terdapat dua cara untuk menemukan inheritance, yaitu generalization dan
specialization .
3.4.1 Generalization
Generalization menjamin kemampuan untuk membuat superclass yang melingkupi
struktur dan behaviour yang umum pada beberapa class dibawahnya (subclass).
Shape
-origin
+move()
+display()
+resize()
Square
3.4.2 Specialization
Specialization menjamin kemampuan untuk membuat subclass yang berfungsi untuk
menambah atribut dan operasi superclass.
Membuat Inheritance
1. Buka class diagram yang akan menampilkan hierarki inheritance.
2. Klik icon class dari toolbar dan klik pada class diagram untuk menempatkan icon
class tadi.
3. Pada class yang dipilih tadi, masukkan nama class. (Catatan: class seharusnya
seharusnya sudah dibuat di browser dan ditambahkan ke class diagram)
4. Klik icon generalization di toolbar.
5. Klik pada subclass dan drag icon garis generalization menuju superclass.
6. Ulangi langkah 5 untuk setiap tambahan subclass.
InformasiDosen InformasiMahasiswa
ATM
ATMCode
Cash
Bank InsertCard()
EnterAmount()
Name Check Sufficient()
Address EjectCard()
1 * 1
DispenceCard()
EnterPIN()
1
ValidateCard()
ValidatePIN()
*
Saving Account
*
Transaction
Account Number
Date
Name
Time
Address
TransactionID
Balance
1 1..*
Create Account() Create Transaction()
3.5 Package
Jika sistem hanya memiliki sedikit class, kita dapat mengaturnya dengan mudah.
Sebagian besar sistem dibuat dari banyak class sehingga kita memerlukan suatu
mekanisme untuk mengelompokkannya bersama untuk memudahkan dalam hal
penggunaan, perawatan, dan penggunaan kembali . Package adalah kumpulan dari
dari package atau class yang berelasi. Dengan mengelompokkan class dalam
package, kita bisa melihat level yang lebih tinggi dari model kita atau kita bisa
menggali model dengan lebih dalam dengan melihat apa yang ada di dalam package.
Jika sistemnya kompleks, package mungkin dibuat di awal fase elaborasi sebagai
fasilitator komunikasi. Untuk sistem yang lebih sederhana, class-class yang didapat
pada tahap analisa mungkin dikelompokkan dalam suatu package. Di UML, package
digambarkan sebagai folder.
People
Information
Package A Package B
Client Supplier
Gambar 3.15 Relasi Package
Jurnal Modul 3
State transition diagram tidak akan dibuat untuk setiap class di sistem. State
transition diagram hanya dibuat untuk class yang berkelakuan dinamis . Interaction
diagram dapat dipelajari untuk menentukan dynamic object di sis tem, yaitu object
yang menerima dan mengirim beberapa pesan. State transition diagram juga sangat
berguna untuk meneliti kelakuan dari sebuah kumpulan whole class dan control class.
4.1.1 States
State adalah sebuah kondisi selama kehidupan sebuah object ketika object memenuhi
beberapa kondisi, melakukan beberapa action, atau menunggu sebuah event. State
dari sebuah object dapat dikarakteristikkan oleh nilai dari satu atau lebih atribut-
atribut dari class.
Notasi UML untuk state adalah empat persegipanjang/bujur sangkar dengan ujung
yang dibulatkan, seperti ditunjukkan pada gambar 1.
State transition diagram meliputi seluruh pesan dari object yang dapat mengirim dan
menerima. Skenario merepresentasikan satu jalur yang melewati sebuah state
transition diagram. Jarak waktu antara dua pesan yang dikirim oleh sebuah object
merepresentasikan sebuah state . Oleh karena itu, sequence diagram ditentukan untuk
menemukan state-state sebuah object (lihat pada ruang antara garis-garis yang
merepresentasikan pesan-pesan diterima oleh object).
Membuat State
1. Klik untuk memilih icon state dari toolbar.
2. Klik untuk menempatkan state pada state transition diagram.
3. Dengan state masih dipilih, masukkan nama state.
Ada dua cara untuk membuat transisi sebuah state – otomatis dan tidak otomatis.
State transition yang otomatis terjadi ketika activity dari state awal telah lengkap –
tidak ada event yang terasosiasi dengan state transition yang belum bernama. State
transition yang tidak otomatis disebabkan oleh sebuah event ternama (salah satu dari
object atau dari luar sistem). Kedua tipe dari state transition dipertimbangkan untuk
membuat waktu nol dan tidak dapat diinterupsi. Sebuah state transition
direpresentasikan oleh sebuah panah yang menunjuk dari state awal ke state
berikutnya.
Kelakuan mungkin sebuah action yang sederhana, atau kelakuan merupakan sebuah
event yang terkirim ke object lain. Sesuai dengan action-action dan guard -guard,
kelakuan ini secara tipikal dipetakan ke operasi-operasi dalam object. Notasi UML
untuk state detailed information ditunjukkan gambar 4.4.
State name
entry : simple action
entry: ^class name.event name
do: simple action
do: ^class name.event.name
exit: simple action
do: ^class name.event name
OFF
Start
Turn ON
Turn OFF
Calceled/Completion
Serving Idle
User
Card Inserted
Insert Card
CardNotAccepted
Verifying
card
CardAccepted
Enter PIN
Verifying
Error<3 PIN Cancel
PIN valid
PIN Invalid
Error=3
Blocking End
Membuat Swimlanes
1. Klik kanan pada use case yang akan dibuat activity diagram, kemudian pilih
Select in Browser. Use case yang dipilih akan tersorot pada browser.
2. Klik kanan use case yang tersorot di browser, kemudian klik New, Activity
Diagram.
3. Beri nama activity diagram.
4. Buka activity diagram dengan double klik
5. Pilih icon swimlane dari toolbar dan klik ke dalam activity diagram.
6. Buka Specification dari swimlane dengan cara double klik header swimlane
(NewSwimlane) pada diagram.
7. Beri nama swimlane dengan nama sesuai dengan role bisnis yang menjalankan
aktivitas -aktivitas.
8. Klik OK.
Catatan: untuk membuat aktifitas dan transition lainnya dapat dilakukan dengan
mengulang langkah 2 sampai 5.
(Card,Receipt)
Jurnal Modul 4
A. 1. Periksa Statechart Diagram yang ada pada studi kasus ATM, lakukan perubahan
yang dianggap perlu pada diagram-diagram sebelumnya.
2. Dengan menggunakan SISTEM PENJ UALAN ITEM SUPERMARKET.
a. Buatlah Statechart Diagram yang diperlukan untuk memperlihatkan kelakuan
sistem yang dinamis.
b. Lakukan perubahan yang dianggap perlu pada diagram-diagram sebelumnya.
Modul 5 Refinement
Tujuan Praktikum:
1. Praktikan dapat menganalisa kembali diagram-diagram yang dibuat pada tahap analisa
dan mampu membedakan dengan tahap selanjutnya (desain dan implementasi).
2. Praktikan bisa memahami alur dari setiap tahap yang digunakan dalam perancangan
perangkat lunak menggunakan UML.
3. Praktikan mampu memperbaiki kekurangan yang ada pada masing-masing diagram pada
tahap-tahap sebelumnya.
Pada modul ini kita akan me-review diagram-diagram yang pernah kita gunakan pada tahap
sebelumnya, hal ini memungkinkan kita untuk melakukan perubahan pada beberapa class dan
object yang dianggap perlu namun belum tergambar pada waktu analisa. Karena kita akan
beranjak pada implementasi, maka ada beberapa class baru yang akan muncul seperti user
interface.
insert card
verify card
request PIN
PIN "OK"
1: insert card
: ATM
5: Verify PIN
<<Form>>
Login : ATM
Card
6: PIN "OK"
Gambar 5.2 Collaboration Diagram for Authenticate User’s ATM
Request amount
Enter amount
Check for sufficient funds( )
debit( )
Set cash( )
Dispense cash ()
Request Continuation ()
"No"
Print Recept ()
Eject Card
Take a card
5: debit( )
10: "No"
14: Take a card
: ATM : Saving
Acount
7: Dispense cash () 6: Set cash( )
: User 8: Request Take Cash ()
9: Request Continuation ()
11: Print Recept ()
12: Eject Card 4: Check for sufficient funds( )
13: Request Take a card
3: Enter amount 1: <<Create>>
<<Form>>
: Withdrawal
Witdrawal
2: Request amount
ATM
ATMCode
Cash
Bank InsertCard()
EnterAmount()
Name Check Sufficient()
Address EjectCard()
1 * 1
DispenceCard()
1 EnterPIN()
ValidateCard() <<Form>>
ValidatePIN() Login
*
Saving Account
*
Transaction
Account Number
Date
Name
Time
Address
Balance TransactionID
1 1..*
Create Transaction()
Create Account()
<<Form>> <<Form>>
Form_Withdrawal Form-Transfer
Tujuan Praktikum:
1. Praktikan dapat menentukan komponen-komponen apa saja yang akan dibangkitkan dari
class diagram yang telah dibuat dan menggambarkannya dalam component diagram.
2. Praktikan dapat menggambarkan deployment diagram.
Elemen pemodelan pada component view adalah package dan component dengan
hubungan yang ada. Sebuah package pada component view menggambarkan partisi
fisik pada sistem. Component View Package sering disebut subsystem. Package-
package diatur dalam lapisan hierarki dimana setiap lapisan mempunyai interface.
Fakta bahwa object oriented system cenderung menja di sebuah sistem yang berlapis-
lapis tidaklah mengherankan. Hal ini sesuai dengan definisi object, yakni melakukan
satu hal.
Membuat Component
<<Application>>
Bank server
Autenticate
<<Application>>
ATM
Withdrawal Transfer
Transaction
Untuk membuat hubungan antara node, klik icon connection dari toolbar, klik pada
salah satu node pada deployment diagram dan drag sambungan tersebut pada node
lainnya.
TCP/IP
<<Network>> ATM
Mechine
LC
Jurnal Modul 6
1. Evaluasi Component dan Deployment Diagram untuk Sistem ATM Lakukan perubahan
yang dianggap perlu pada diagram-diagram sebelumnya.
2. Buatlah Component dan Deployment Diagram SISTEM PENJUALAN ITEM.
Lakukan perubahan yang dinggap perlu pada diagram-diagram sebelumnya.
DAFTAR PUSTAKA
TIM Dosen. 2014. Modul Pembelajaran dan Praktikum Rekayasa Perangkat Lunak. Jakarta. Fakultas
Teknik, Universitas Mercubuana
Liana Linda. 2015. Modul UML. Jakarta. Jurusan Sistem Informasi, Fakultas Ilmu Komputer, Universitas
Mercubuana Jakarta.