UML UNIFIED MODELLING LANGUAGE
Diagram UML • • • • • • • •
Use Case Activity Sequence Colaboration Class Statechart Componen Deployment
Analisys phase (OOA-object oriented analisys) • OOA – teknik semiformal -> notasi grafis dari semua langkah analisis
Langkah langkah OOA • Use – Case Modelling • Class Modelling • Dinamic Modelling
Use Case Modelling • Menentukan berbagai hasil yang akan di komputasi oleh produk perangkat lunak dengan mengabaikan urutan pembuatannya. (clasical object oriented analisys) • Use case diagram dihubungkan dengan skenario yang dibuat pada tahap requirement analisys
USE CASE Pengendalian Pengajaran
Class Modelling • Menentukan kelas, atribut dan hubungan antar kelas. • Pada tahap ini belum menentukan method method (fungsi) karena akan dilakukan pada tahap desain – prakteknya kadang bisa dilanggar • Salah satu cara penentuan kelas adalah mencari kandidat kelas yang berasal dari use case
Class modelling (cont) • Cara sederhana adalah dengan mengkoleksi kata benda dalam skenario atau dari use-case • Cara yang kedua dengan memanfaatkan CRC card (class responsibility – collaboration)
CRC Card
CRC • (class responsibility – collaboration) adalah sebuah teknik untuk mengecek adanya interaksi antar obyek • Sebelah kiri berisi tanggung jawab, sebelah kanan berisi kelas yang melaksanakan tanggung jawab tersebut • Dari sini akan didapatkan satu set kelas dan tanggungjawabnya serta kelas lain yang berhubungan dengan kelas tersebut
Class Diagram
Dinamic Modelling • Menentukan aksi yang di lakukan oleh masing masing kelas dan subkelas • Menggunakan state diagram.
State diagram presensi
Design Phase (Object Oriented Design) • Membuat diagram interaksi untuk setiap skenario -> sequence diagram, collaboration diagram • Melengkapi diagram kelas secara detail termasuk method methodnya, class diagram • Merancang produk – Component diagram – Deployment Diagram
Sequence Diagram
Diagram Kolaborasi
Diagram Komponen
Diagram Deployment
KONSENTRASI KE KELAS • Kelas merupakan dokumen yang paling dekat dengan program yang akan menjadi produk dari pengembangan aplikasi berbasis obyek • Dokumen lain dalam tahap pengembangan perangkat lunak berorientasi obyek sebenarnya harus di buat, bahkan jika diperlukan boleh menambahkan dokumen lain seperti ERD, DFD atau dokumen lain yang dianggap perlu untuk memperjelas rancangan.
Hubungan Antar Kelas • ASOSIASI • Ketergantungan (Dependensi)
ASOSIASI • Ascociation – Relasi antara 2 elemen dimana keduanya punya posisi yang sama, tidak ada yang lebih penting diantara keduanya. • Asosiasi antara penjual dan pembeli
– Bidirectional Ascociation • Asosiasi antara 2 elemen dimana elemen pertama bertanggungjawab menentukan elemen yang lainnya.
– Unidirectional Ascociation • Asosiasi dimana kelas asal bertanggung jawab terhadap spesifikasi member dari kelas tujuan • Unidirectional ascociation -> kelas asal yg tahu asosiasi ini sedangkan kelas tujuan tidak perlu tahu • Contoh kelas reporttransfer ->kelas rekening
– Class Asscociation • Kelas yang berisi informasi tentang asosiasi yang terjadi antara 2 kelas.
Composition • Composition – Relasi antara 2 elemen dimana elemen child akan terdelete secara cascade pada saat parent elemen terdelete. – Contoh : – Email dengan body
• Navigable Compisition – Relasi komposisi dimana kelas asal bertanggung jawab atas spesifikasi kelas tujuan
Aggregation • Agregation – Relasi antara dua elemen dimana satu kelas memiliki peran yang lebih penting dibanding kelas yang lain, satu kelas adalah bagian dari kelas lain. Standar agregasi kelas yg menjadi bagian memliki lifecycle yang independent dari kelas yg memilikinya – Contoh : – Mobil dengan roda
• Navigable Agregation – Agregasi dimana kelas asal bertanggung jawab mengatur spesifikasi member dari kelas tujuan
Hubungan saling ketergantungan • • • • •
Dependency Realize Usage Permission Abstraction
Dependency • Relasi antara 2 elemen dimana definisinya saling tergantung satu dengan yang lainnya sehingga perubahan pada satu elemen akan • menimbulkan perubahan pada elemen yang lain. • Sebagai contoh ketika satu kelas menggunakan kelas lain sebagai parameter atau tipe data dari salah satu atributnya.
Realize • Relasi semantic antara “classifier” (penentu) . Satu menjadi penentu dan menjamin bahwa ketentan tersebut akan di realisasikan. Relasi seperti ini terjadi antara interface dan kelas yang mengimplementasikannya serta antara Use case dengan colaborasi yang merealisasikannya.
Usage • Hubungan ketergantungan antara satu elemen (clien) membutuhkan keberadaan dari elemen yang lain (supplier) untuk diimplementasikan atau digunakan dengan benar.
Permission • Hubungan yang akan mengesahkan akses dari elemen supplier kepada elemen clien.
Abstraction • Hubungan antara 2 elemen yang merepresentasikan konsep yang sama dalam level abstraksi yang berbeda. • Entitas dengan karakteristik esensial yang membedakannya dengan semua jenis entity yang lain. Abstraksi mendifinisikan batasan dari perspektif viewer.
