Out Line
1.
Pendahuluan
2.
Pemrograman Berorientasi
Objek
3.
UML
1. Pendahuluan
Pengembangan Sistem/Perangkat Lunak
merupakan pekerjaan yang rumit
Pada masa lalu pengembangan software
selalu terlambat, mahal, kurang
memenuhi harapan dan kebutuhan
pengguna.
Banyak software setelah dikembangkan
tidak digunakan.
Saat ini vendor ingin produk softwarenya
1. Pendahuluan
Reliability
Software perlu mempunyai aspek realibilty, yaitu aspek :
◦ Flexibility kemampuan sistem menangani
suatu transaksi atau event/kejadian yang tidak biasa, tidak terduga
◦ Resilence Kemampuan sistem beradaptasi ketika dilakukannya maintenance. Dalam artian ketika maintenance dilakukan dan terdapat
perubahan, maka tidak terjadi/timbul masalah baru.
◦ Quality Membangun sistem/software dengan baik, benar, tepat waktu, tidak crash,
1. Pendahuluan
Metode pemrograman terstruktur
dirasa kurang memadai lagi
Maka :
Perlu ada metode baru yang lebih
sesuai dalam pengembangan
1. Pendahuluan
Costs dan Benefts Objek
Beneft Object
◦
System Stability
◦
Maintainability
◦
Reusable software components
◦
Reality-based systems
◦
Data accessibility
Benefts Objek
System Stability
Resilence to change sebuah program atau sistem informasi setelah diinstal dan
running, sesuai dengan perjalanan waktu dapat mengalami maintence atau
modifkasi sesuai kebutuhan user. Nah ketika proses tersebut dilakukan, sistem dikatakan resilence to change jika
modifkasi tersebut tidak menimbulkan masalah baru pada sistem yang telah
dibangun, dengan waktu yang singkat dan biaya yang sedikit.
Resilence dan stability ini dapat kita
dapatkan dari objek.karena sistem benar-benar dirancang untuk mendukung bisnis user yang berdasarkan pemahaman dasar akan kebutuhan data pada bisnis user
Benefts Objek
Maintainability
Metode sebelum objek cenderung dibuat berdasarkan kebutuhan laporan dan
kebutuhan sekarang, sehingga ketika terjadi maintenance menjadi lebih sukar.
Metode berorientasi objek menghasilkan sistem yang lebih siap untuk proses
Benefts Objek
Reusable software components
Hasil analisa rekayasa perangkat
lunak dan kode program dapat
digunakan ulang. Reusable software
components ini dapat dilakukan oleh
adanya feature inheritance dan
polimorphism. Contohnya
Benefts Objek
Reality-based systems
Memberikan gambaran yang
lebih akurat terhadap operasi
bisnis user dan kebutuhan
Benefts Objek
Data Accessibility
Design database didasari oleh
Benefts Objek
User involvement and ownership
User dapat dilibatkan dalam
pengembangan sistem karena
menggunakan konsep objek yang
lebih mudah dipahami oleh user
meskipun berasal dari disiplin
ilmu yang berbeda-beda.
Sehingga analisa sistem dapat
sesuai dengan apa yang
Cost of Objek
Software yang telah diinstal harus diubah
Legacy system sistem yang telah
ketinggalan zaman yang telah ada dan harus tetap digunakan untuk waktu yang belum dipastikan
Training Ulang
Bahasa pemrograman baru
Konsep baru
Perlu rencana yang matang untuk proses
1. Pendahuluan
Pemrograman Berorientasi Objek
(OOP) menggantikan metode
terstruktur.
UML (Unifed Modeling
Language)sebagai tool untuk
melakukan analisa, design dan
implementasi perangkat lunak
yang berorientasi objek.
Rational Rose sebagai software
2. Pemrograman Berorientasi
Objek
Pemrograman Terstruktur membuat blok-blok standar kode untuk melakukan operasi tertentu, kemudian menyalinnya ke aplikasi lain yang ditulis.
Sulit ketika terjadi perawatan karena harus merubah keseluruhan kode program
OOP menciptakan blok-blok program yang disebut objek. Objek ini kemudian di pakai pada berbagai aplikasi.
Jika terjadi perubahan, maka perubahan
hanya dilakukan sekali saja, objek lain yang menjadi turunannya akan mewarisi
2. Pemrograman Berorientasi
Objek
Prinsip OOP :
Pembungkusan (Encapsulation)
◦
Menggabungkan potongan-potongan
informasi dan perilaku spesifk yang
bekerja pada informasi tersebut,
kemudian mengemasnya menjadi
objek.
atau
ATM
Contoh Encapsulation Pada
Perbankan
Informasi/properties objek rekening : No rekening, Nama , alamat dll
Perilaku/method objek rekening : buka,
tutup, penarikan, penyimpanan, ubah nama, ubah alamat dll
Kita bungkus/encapsulate informasi dan perilaku tersebut pada objek rekening
Pembungkusan
(Encapsulation)
Manfaat lain encapsulation
2. Pemrograman Berorientasi
Objek
Pewarisan (Inheritance)
◦
Memungkinkan menciptakan
objek-objek baruberdasarkan objek-objek lain
yang telah ada : objek anak mewarisi
segala sesuatu dari objek induk.
Contoh Pewarisan :
Mamalia
Contoh Pewarisan Pada
Perbankan
Objek Induk Rekening :
Mempunyai karakteristik umum
seperti no rekening, pemilik, tingkat
suku bunga
Objek Turunan (Mempunyai
karakteristik yang unik dan
mewarisi karakteristik umum dari
objek induk)
◦
Rekening Deposito : atribut jatuh
tempo dll
2. Pemrograman Berorientasi
Objek
Polimorfsme
◦
Suatu fungsionalitas yang
diimplementasikan dengan berbagai
cara yang berbeda.
◦
Misalkan dosen bertanya : Apakah
anda sudah paham ?
Beberapa orang menjawab “Ya”, ada
yang menganggukkan kepala sambil
UML
UML
Pemodelan Visual : proses
penggambaran
informasi-informasi secara grafs dengan
notasi-notasi baku yang telah
disepakati sebelumnya.
Notasi sangat penting untuk
alasan
Komunikasi
UML sebagai notasi baku
UML
Diagram-diagram UML
◦
Diagram Kelas
◦
Diagram Objek
◦
Use-Case Diagram
◦
Sequence Diagram
◦
Collaboration Diagram
◦
Statechart Diagram
◦
Activity Diagram
Use-Case Diagram
Menggambarkan interaksi antara
use case dan aktor.
Use case merepresentasikan
fungsionalitas sistem, kebutuhan
dari sisi pengguna.
Actor merepresentasikan orang
Use-Case Diagram
USE CASE DIAGRAM
Menggambarkan fungsionalitas yang diharapkan dari sebuah sistem.
Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”.
Menggambarkan kebutuhan system dari sudut pandang user
Mengfokuskan pada proses komputerisasi (automated processes) Menggambarkan hubungan antara use case dan actor
Use case menggambarkan proses system (kebutuhan system dari
sudut pandang user)
Secara umum use case adalah:
◦ Pola perilaku system
◦ Urutan transaksi yang berhubungan yang dilakukan oleh satu actor
Use case diagram terdiri dari
◦ Use case
◦ Actors
◦ Relationship
◦ System boundary boxes (optional)
USE CASE
Use case dibuat berdasar keperluan actor,
merupakan “apa” yang dikerjakan system,
bukan “bagaimana” system mengerjakannya
Use case diberi nama yang menyatakan apa
hal yang dicapai dari hasil interaksinya
dengan actor.
Use case
dinotasikan dengan gambar
(horizontal ellipse)
Use case biasanya menggunakan kata kerja
Nama use case boleh terdiri dari beberapa
ACTOR
Actor menggambarkan orang, system atau external entitas / stakeholder yang menyediakan atau
menerima informasi dari system
Actor menggambarkan sebuah tugas/peran dan bukannya posisi sebuah jabatan
Actor memberi input atau menerima informasi dari system
Actor biasanya menggunakan Kata benda
Tidak boleh ada komunikasi langsung antar actor Indikasi <<system>> untuk sebuah actor yang
merupakan sebuah system
Adanya actor bernama “Time” yang
mengindikasikan scheduled events (suatu kejadian yang terjadi secara periodik/bulanan)
Association
Associations bukan menggambarkan
aliran data/informasi
Associations digunakan untuk
menggambarkan bagaimana actor
terlibat dalam use case
Ada 4 jenis relasi yang bisa timbul
pada use case diagram
1. Association antara actor dan use case
2. Association antara use case
3. Generalization/Inheritance antara use case
Association antara actor dan use
case
Ujung panah pada association antara actor
dan use case mengindikasikan
siapa/apa
yang meminta interaksi dan bukannya
mengindikasikan aliran data
Sebaiknya gunakan
Garis tanpa panah
untuk association antara actor dan use case
association antara actor dan use case yang
Association antara use case
<<include>> termasuk didalam use
case lain (required) / (diharuskan)
◦ Pemanggilan use case oleh use case lain, contohnya adalah pemanggilan sebuah fungsi program
◦ Tanda panah terbuka harus terarah ke sub use case
◦ Gambarkan association include secara horizontal
B u k a R e k e n i n g
< < i n c l u d e > > c a t a t d a t a p r i b a d i
N a s a b a h
Register for courses
<<include>>
Logon validation <<include>>
Association antara use case
(Lanjut)
<<extend>> perluasan dari use case lain jika
kondisi atau syarat terpenuhi
◦ Kurangi penggunaan association Extend ini, terlalu banyak pemakaian association ini membuat
diagram sulit dipahami.
◦ Tanda panah terbuka harus terarah ke parent/base use case
◦ Gambarkan association extend secara vertical
B u k a R e k e n i n g
< < e x t e n d > >
Generalization/inheritance
antara use case
Generalization/inheritance digambarkan dengan sebuah
garis berpanah tertutup pada salah satu ujungnya yang menunjukkan lebih umum
Gambarkan generalization/inheritance antara use case
secara vertical dengan inheriting use case dibawah base/parent use case
Generalization/inheritance dipakai ketika ada sebuah
keadaan yang lain sendiri/perlakuan khusus (single
condition) B u k a
R e k e n i n g
Generalization/inheritance
antara actor
Gambarkan generalization/inheritance antara
Use case System boundary
boxes
Digambarkan dengan kotak disekitar use case, untuk menggambarkan jangkauan system anda (scope of of your system).
Biasanya digunakan apabila memberikan beberapa alternative system yang dapat dijadikan pilihan
RPL
Prosedur pengisian KRS
1. Buat alur dr prosedur pengisian
KRS
2. Buat alur ketika pengisian KRS
3. Use Case
RPL
RPL
