Saat ini piranti lunak semakin luas dan besar lingkupnya, sehingga tidak bisa lagi dibuat asal-asalan.
Piranti lunak saat ini seharusnya dirancang dengan memperhatikan hal-hal seperti scalability,
security, dan eksekusi yang robust walaupun dalam kondisi yang sulit. Selain itu arsitekturnya harus
didefinisikan dengan jelas, agar bug mudah ditemukan dan diperbaiki, bahkan oleh orang lain selain
programmer aslinya. Keuntungan lain dari perencanaan arsitektur yang matang adalah
dimungkinkannya penggunaan kembali modul atau komponen untuk aplikasi piranti lunak lain yang
membutuhkan fungsionalitas yang sama.
Pemodelan (modeling) adalah proses merancang piranti lunak sebelum melakukan pengkodean
(coding). Model piranti lunak dapat dianalogikan seperti pembuatan blueprint pada pembangunan
gedung. Membuat model dari sebuah sistem yang kompleks sangatlah penting karena kita tidak
dapat memahami sistem semacam itu secara menyeluruh. Semakin komplek sebuah sistem, semakin
penting pula penggunaan teknik pemodelan yang baik.
Dengan menggunakan model, diharapkan pengembangan piranti lunak dapat memenuhi semua
kebutuhan pengguna dengan lengkap dan tepat, termasuk faktor-faktor seperti scalability, robustness,
security, dan sebagainya.
Kesuksesan suatu pemodelan piranti lunak ditentukan oleh tiga unsur, yang kemudian terkenal
dengan sebuan segitiga sukses (the triangle for success). Ketiga unsur tersebut adalah metode
pemodelan (notation), proses (process) dan tool yang digunakan.
Lisensi Dokumen:
Seluruh dokumen di IlmuKomputer.Com dapat digunakan, dimodifikasi dan disebarkan
secara bebas untuk tujuan bukan komersial (nonprofit), dengan syarat tidak menghapus
atau merubah atribut penulis dan pernyataan copyright yang disertakan dalam setiap
dokumen.
2
Memahami notasi pemodelan tanpa mengetahui cara pemakaian yang sebenarnya (proses) akan
membuat proyek gagal. Dan pemahaman terhadap metode pemodelan dan proses disempurnakan
dengan penggunaan tool yang tepat.
Apa
Apa itu UML
Unified Modelling Language (UML) adalah sebuah "bahasa" yg telah menjadi standar dalam
industri untuk visualisasi, merancang dan mendokumentasikan sistem piranti lunak. UML
menawarkan sebuah standar untuk merancang model sebuah sistem.
Dengan menggunakan UML kita dapat membuat model untuk semua jenis aplikasi piranti lunak,
dimana aplikasi tersebut dapat berjalan pada piranti keras, sistem operasi dan jaringan apapun, serta
ditulis dalam bahasa pemrograman apapun. Tetapi karena UML juga menggunakan class dan
operation dalam konsep dasarnya, maka ia lebih cocok untuk penulisan piranti lunak dalam bahasabahasa
berorientasi objek seperti C++, Java, C# atau VB.NET. Walaupun demikian, UML tetap
dapat digunakan untuk modeling aplikasi prosedural dalam VB atau C.
Seperti bahasa-bahasa lainnya, UML mendefinisikan notasi dan syntax/semantik. Notasi UML
merupakan sekumpulan bentuk khusus untuk menggambarkan berbagai diagram piranti lunak.
Setiap bentuk memiliki makna tertentu, dan UML syntax mendefinisikan bagaimana bentuk-bentuk
tersebut dapat dikombinasikan. Notasi UML terutama diturunkan dari 3 notasi yang telah ada
sebelumnya: Grady Booch OOD (Object-Oriented Design), Jim Rumbaugh OMT (Object Modeling
Technique), dan Ivar Jacobson OOSE (Object-Oriented Software Engineering).
Sejarah UML sendiri cukup panjang. Sampai era tahun 1990 seperti kita ketahui puluhan metodologi
pemodelan berorientasi objek telah bermunculan di dunia. Diantaranya adalah: metodologi booch [1],
metodologi coad [2], metodologi OOSE [3], metodologi OMT [4], metodologi shlaer-mellor [5],
metodologi wirfs-brock [6], dsb. Masa itu terkenal dengan masa perang metodologi (method war)
dalam pendesainan berorientasi objek. Masing-masing metodologi membawa notasi sendiri-sendiri,
yang mengakibatkan timbul masalah baru apabila kita bekerjasama dengan group/perusahaan lain
yang menggunakan metodologi yang berlainan.
Dimulai pada bulan Oktober 1994 Booch, Rumbaugh dan Jacobson, yang merupakan tiga tokoh
yang boleh dikata metodologinya banyak digunakan mempelopori usaha untuk penyatuan
metodologi pendesainan berorientasi objek. Pada tahun 1995 direlease draft pertama dari UML
(versi 0.8). Sejak tahun 1996 pengembangan tersebut dikoordinasikan oleh Object Management
Group (OMG – http://www.omg.org). Tahun 1997 UML versi 1.1 muncul, dan saat ini versi terbaru
adalah versi 1.5 yang dirilis bulan Maret 2003. Booch, Rumbaugh dan Jacobson menyusun tiga buku
serial tentang UML pada tahun 1999 [7] [8] [9]. Sejak saat itulah UML telah menjelma menjadi
standar bahasa pemodelan untuk aplikasi berorientasi objek.
Konsepsi Dasar UML
Dari berbagai penjelasan rumit yang terdapat di dokumen dan buku-buku UML. Sebenarnya
konsepsi dasar UML bisa kita rangkumkan dalam gambar dibawah.
Rumbaugh
Booch Jacobson
Odell
Shlaer and Mellor
Gamma
Meyer
OMG
(Object Management Group)
Abstraksi konsep dasar UML yang terdiri dari structural classification, dynamic behavior, dan
model management, bisa kita pahami dengan mudah apabila kita melihat gambar diatas dari
Diagrams. Main concepts bisa kita pandang sebagai term yang akan muncul pada saat kita membuat
diagram. Dan view adalah kategori dari diagaram tersebut.
Lalu darimana kita mulai ? Untuk menguasai UML, sebenarnya cukup dua hal yang harus kita
perhatikan:
1. Menguasai pembuatan diagram UML
2. Menguasai langkah-langkah dalam analisa dan pengembangan dengan UML
Tulisan ini pada intinya akan mengupas kedua hal tersebut.
Seperti juga tercantum pada gambar diatas UML mendefinisikan diagram-diagram sebagai berikut:
• use case diagram
• class diagram
• statechart diagram
• activity diagram
• sequence diagram
• collaboration diagram
• component diagram
• deployment diagram
Use Case Diagram
Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang
ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Sebuah use case
merepresentasikan sebuah interaksi antara aktor dengan sistem. Use case merupakan sebuah
pekerjaan tertentu, misalnya login ke sistem, meng-create sebuah daftar belanja, dan sebagainya.
Seorang/sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan sistem
untuk melakukan pekerjaan-pekerjaan tertentu.
Use case diagram dapat sangat membantu bila kita sedang menyusun requirement sebuah sistem,
mengkomunikasikan rancangan dengan klien, dan merancang test case untuk semua feature yang
ada pada sistem.
Sebuah use case dapat meng-include fungsionalitas use case lain sebagai bagian dari proses dalam
dirinya. Secara umum diasumsikan bahwa use case yang di-include akan dipanggil setiap kali use
case yang meng-include dieksekusi secara normal.
Sebuah use case dapat di-include oleh lebih dari satu use case lain, sehingga duplikasi fungsionalitas
dapat dihindari dengan cara menarik keluar fungsionalitas yang common.
Sebuah use case juga dapat meng-extend use case lain dengan behaviour-nya sendiri.
Sementara hubungan generalisasi antar use case menunjukkan bahwa use case yang satu merupakan
spesialisasi dari yang lain.
Contoh use case diagram :
Class Diagram
Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek dan
merupakan inti dari pengembangan dan desain berorientasi objek. Class menggambarkan keadaan
(atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut
(metoda/fungsi).
Class diagram menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan
satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain.
Class memiliki tiga area pokok :
1. Nama (dan stereotype)
2. Atribut
3. Metoda
Atribut dan metoda dapat memiliki salah satu sifat berikut :
• Private, tidak dapat dipanggil dari luar class yang bersangkutan
• Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak yang
mewarisinya
• Public, dapat dipanggil oleh siapa saja
Class dapat merupakan implementasi dari sebuah interface, yaitu class abstrak yang hanya memiliki
metoda. Interface tidak dapat langsung diinstansiasikan, tetapi harus diimplementasikan dahulu
menjadi sebuah class. Dengan demikian interface mendukung resolusi metoda pada saat run-time.
dapat membuat diagram yang terdiri atas package.
1. Asosiasi, yaitu hubungan statis antar class. Umumnya menggambarkan class yang memiliki
atribut berupa class lain, atau class yang harus mengetahui eksistensi class lain. Panah
navigability menunjukkan arah query antar class.
2. Agregasi, yaitu hubungan yang menyatakan bagian (“terdiri atas..”).
3. Pewarisan, yaitu hubungan hirarkis antar class. Class dapat diturunkan dari class lain dan
mewarisi semua atribut dan metoda class asalnya dan menambahkan fungsionalitas baru,
sehingga ia disebut anak dari class yang diwarisinya. Kebalikan dari pewarisan adalah
generalisasi.
4. Hubungan dinamis, yaitu rangkaian pesan (message) yang di-passing dari satu class kepada
class lain. Hubungan dinamis dapat digambarkan dengan menggunakan sequence diagram
yang akan dijelaskan kemudian.
Contoh class diagram :
Activity Diagram
Activity diagrams menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang,
bagaimana masing-masing alir berawal, decision yang mungkin terjadi, dan bagaimana mereka
berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada
beberapa eksekusi.
Activity diagram merupakan state diagram khusus, di mana sebagian besar state adalah action dan
sebagian besar transisi di-trigger oleh selesainya state sebelumnya (internal processing). Oleh
karena itu activity diagram tidak menggambarkan behaviour internal sebuah sistem (dan interaksi
antar subsistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas
dari level atas secara umum.
Sebuah aktivitas dapat direalisasikan oleh satu use case atau lebih. Aktivitas menggambarkan proses
yang berjalan, sementara use case menggambarkan bagaimana aktor menggunakan sistem untuk
melakukan aktivitas.
Sama seperti state, standar UML menggunakan segiempat dengan sudut membulat untuk
menggambarkan aktivitas. Decision digunakan untuk menggambarkan behaviour pada kondisi
tertentu. Untuk mengilustrasikan proses-proses paralel (fork dan join) digunakan titik sinkronisasi
yang dapat berupa titik, garis horizontal atau vertikal.
Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan objek mana
yang bertanggung jawab untuk aktivitas tertentu.
Contoh activity diagram tanpa swimlane:
Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk
pengguna, display, dan sebagainya) berupa message yang digambarkan terhadap waktu. Sequence
diagram terdiri atar dimensi vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait).
Sequence diagram biasa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah
yang dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu. Diawali dari
apa yang men-trigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara internal
dan output apa yang dihasilkan.
Masing-masing objek, termasuk aktor, memiliki lifeline vertikal.
Message digambarkan sebagai garis berpanah dari satu objek ke objek lainnya. Pada fase desain
berikutnya, message akan dipetakan menjadi operasi/metoda dari class.
Activation bar menunjukkan lamanya eksekusi sebuah proses, biasanya diawali dengan diterimanya
sebuah message.
Untuk objek-objek yang memiliki sifat khusus, standar UML mendefinisikan icon khusus untuk
objek boundary, controller dan persistent entity.
Contoh sequence diagram :
Collaboration
terimakasih....(^ ^)
