‘
Beberapa waktu yang lalu saya mengajar Object-Oriented Technique dengan topik “Mapping UML to Code”, karena sibuk dan sudah merasa menguasai materi saya tidak membaca dulu materi (slide yang disediakan kampus). Saya jelaskan slide demi slide sampai saya harus menjelaskan bagaimana mapping aggregation dan composition saya mendapatkan slide sebagai berikut.
Slide Composition
Slide Aggregation
Saya bingung bagaimana mejelaskan slide2 tersebut karena menurut pengetahuan saya ada yang salah, jika saya ajarkan sesuai slide2 tersebut saya mengajarkan hal yang salah, jika mengajarkan yg benar menurut saya khawatir nanti jawaban mahasiswa saya jadi dianggap salah karena banyak dosen lain yg menggunakan slide tersebut. waktu itu sulit juga untuk mediskusikan ini dengan dosen lain karena selain saya gak ada kesempatan, sudah terlanjur diajarkan dan konsep slide ini sudah diajarkan cukup lama.
Sok bijaksana saya akhirnya mengajarkan versi slide dan versi saya dengan diakhiri mengatakan diujian nanti jawab sesuai slide karena takut yang periksa ujian bukan saya (kebetulan waktu itu saya belum tahu bagaimana ujian diperiksa. apakah oleh dosen yang mengajar atau di silang dgn dosen lain).
Waktu berlalu saya lupa hal tersebut karena kesibukan lain, kurang-lebih setahun setengah kemudian (juli 2009) saya menjadi pembimbing/penguji beberapa TA disekolah yang serupa tapi tak sama dan saya menyaksikan mahasiswa dibantai (lebay mode = on) oleh penguji lain tentang konsep yang ada dislide diatas dan konsep2 OOP lain yang menurut saya salah-kaprah, salah kaprah ini sebenarnya wajar terjadi karena buku uml yang banyak beredar adalah karangan booch dan teman yang penulisannya menggunakan gaya bahasa dewa/rfc yang sulit dipahami. penasaran apa yang salah?
Pada slide diatas sipenulis berusaha menunjukan perbedaan implementasi aggregation dan composition pada bahasa pemograman java, padahal menurut (Ahmed, 2001) “When working with an implementation language, such as C++, use of aggregation versus composition does map to different code. For example, aggregation implies pass by reference, whereas composition implies pass by value. However, this distinction is not applicable to Java. Hence, the code mapping of aggregation versus composition is the same even though you may still want to model them differently to communicate the intent of the design and highlight elements in an implementation independent fashion.” Maksudnya begini tidak semua bahasa pemograman yang mendukung OOP harus memiliki kemampuan untuk implementasi semua konsep oop. Ada batas minimal suatu bahasa pemrograman bisa disebut mendukung oop, menurut (booch, 1994) batas minimal itu disebut ” four major elements of this model (object model):” yaitu Abstraction, Encapsulation, Modularity, Hierarchy, Terus ditambahkan “By major, we mean that a model without any one of these elements is not object-oriented.” Walaupun yang dimaksud adalah model tapi juga berlaku untuk bahasa pemrograman, suatu bahasa bisa disebut mendukung oop jika bisa 4 hal tersebut. dalam kata lain java memang bahasa OO tapi dengan java “tidak bisa” membedakan aggregation dan composition. Tenang akan saya jelaskan…..
Dalam C++ kita bisa membuat obyek dengan berbagai cara termasuk
Representasi dimemori kurang lebih…
k1 disebut local obyek karena semua isi dari obyek
disimpan di stack dimana semua yang ada disini akan segera dihapus jika keluar scope. sedangkan k2 hanya sebuah pointer untuk sebuah obyek yang tersimpan di heap. Berdasar pada konsep diatas di C++ obyek bisa dipass (sebagai parameter) ke sebuah method dengan dua cara by value atau by reference, by value artinya akan ada dua obyek yang berbeda sedangkan by reference artinya hanya ada satu objek yang digunakan oleh dua variable (reference). Konsep tersebut tidak ada di java, untuk mempermudah para pengguna java desainer java memutuskan bahwa semua obyek dijava akan dipass by reference.
Contoh code java di slide composition Obyek Kendaraan dibuat dengan identitas kendaraan dan pada slide aggregation Obyek Kendaraan dibuat anonymous dengan harapan menjadi hanya milik/bisa diakses Tiket tertentu saja, bagaimana kalau kelas Testing diubah jadi
kode diatas akan menampilkan “true” yang artinya bahwa dua tiket memiliki kendaraan yang sama, kamu mungkin berargumen hilangkan method getKendaraan() atau diubah jadi
tapi usaha kamu akan sia2 jika code Testing jadi
Obyek tiket dan anotherTiket memiliki obyek Kendaraan yang sama. Pertahanan terakhir melarang setAccessible() di java security manager, tapi masalah yang selanjutnya akan dihadapi akan lebih sulit, banyak aplikasi java yang egak jalan.
puas? sebenarnya semua kode diatas sudah berlebihan untuk membahas composition dan aggregation karena melibatkan kelas Testing yang tidak ada didesign. Jadi kesimpulannya jangan bingung dengan Booch Stuff jika bahasa pemograman yang digunakan tidak jelas2 mendukung.
sebagai tambahan UML 2.0 sudah tidak membedakan composition dan aggregation. menurut (Amber, 2004) “In UML 1.x you could model both aggregation and composition, but in UML 2.x the notation for aggregation has been dropped. Although this may sound like a good idea because many people got the two concepts confused I suspect that we are going to see aggregation used on UML class diagrams for some time to come because it has been in common practice since 1997 when the UML was first popularized.”
Masih banyak yang harus dijelaskan tapi sayang kecepatan ngetik saya belum pulih, mengetik jadi menyebalkan.
