UNIFIED MODELLING LANGUAGE UML UNIFIED MODELLING LANGUAGE

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 Navigable Compisition 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 Navigable 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 meng-implementasikannya 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.