Diagram UML

1. USE CASE DIAGRAM

Diagram Use Case adalah diagram yang menunjukkan fungsionalitas suatu sistem atau kelas dan bagaimana sistem tersebut berinteraksi dengan dunia luar dan menjelaskan sistem secara fungsional yang terlihat user. Biasanya dibuat pada awal pengembangan. 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 system 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.

CONTOH

Pada Latihan Pertama Seorang siswa untuk menjadi anggota harus mendaftar terlebih dahulu kepada petugas setelah mendaftar mahasiswa tersebut boleh membaca buku. Jika sudah menjadi anggota, siswa tersebut boleh meminjam buku kepada petugas perpustakaan dan mengembalikannya sesuai dengan ketentuan tersebut apabila anggota tersebut telat mengembalikan buku maka anggota dikenakan denda dan membayar denda tersebut kepada petugas.

2. Diagram Communication

Communication diagram sejenis dengan diagram interaksi, yang lebih menekankan pada link data diantara bermacam-macam partisipan pada interaksi tersebut.

3.  Sequence Diagram

Sequence diagram adalah suatu diagram yang menggambarkan interaksi antar obyek dan mengindikasikan komunikasi diantara obyek-obyek tersebut. Diagram ini juga menunjukkan serangkaian pesan yang dipertukarkan oleh obyek-obyek yang melakukan suatu tugas atau aksi tertentu. Obyek-obyek tersebut kemudian diurutkan dari kiri ke kanan, aktor yang menginisiasi interaksi biasanya ditaruh di paling kiri dari diagram.

Pada diagram ini, dimensi vertikal merepresentasikan waktu. Bagian paling atas dari diagram menjadi titik awal dan waktu berjalan ke bawah sampai dengan bagian dasar dari diagram. Garis Vertical, disebutlifeline, dilekatkan pada setiap obyek atau aktor. Kemudian lifeline tersebut digambarkan menjadi kotak ketika obyek melakukan suatu operasi , kotak tersebut disebut activation. Obyek dikatakan mempunyai live activation pada saat tersebut.
Pesan yang dipertukarkan antar obyek digambarkan sebagai sebuah anak panah antara activation box pengirim dan penerima.

4. CLASS DIAGRAM

Definisi Class Diagram
Class adalah kumpulan objek-objek dengan dan yang mempunyai struktur umum, behavior umum, relasi umum, dan semantic/kata yang umum. Class-class ditentukan/ditemukan dengan cara memeriksa objek-objek dalam sequence diagram dan collaboration diagram. Sebuah class digambarkan seperti sebuah bujur sangkar dengan tiga bagian ruangan. Class sebaiknya diberi nama menggunakan kata benda sesuai dengan domain/bagian/kelompoknya (Whitten L. Jeffery et al, 2004).

Class Diagram adalah diagram yang menunjukan class-class yang ada dari sebuah sistem dan hubungannya secara logika. Class diagram menggambarkan struktur statis dari sebuah sistem. Karena itu class diagram merupakan tulang punggung atau kekuatan dasar dari hampir setiap metode berorientasi objek termasuk UML (Henderi, 2008). Sementara menurut (Whitten L. Jeffery et al 2004:432) class diagram adalah gambar grafis mengenai struktur objek statis dari suatu sistem, menunjukan class-class objek yang menyusun sebuah sistem dan juga hubungan antara class objek tersebut.

Elemen-eleman class diagram dalam pemodelan UML terdiri dari: Class-class, struktur class, sifat class (class behavior), perkumpulan/gabungan (association), pengumpulan/kesatuan (agregation), ketergantungan (dependency), relasi-relasi turunannya, keberagaman dan indikator navigasi, dan role name (peranan/tugas nama).

Simbol-simbol class diagram
1. Class: Class adalah blok - blok pembangun pada pemrograman berorientasi obyek.Sebuah class digambarkan sebagai sebuah kotak yang terbagi atas 3 bagian. Bagian atas adalah bagian nama dari class. Bagian tengah mendefinisikan property/atribut class. Bagian akhir mendefinisikan methodmethod dari sebuah clas.





2. Association : Sebuah asosiasi merupakan sebuah relationship paling umum antara 2 class dan dilambangkan oleh sebuah garis yang menghubungkan antara 2 class. Garis ini bisa melambangkan tipe-tipe relationship dan juga dapat menampilkan hukum-hukum multiplisitas pada sebuah relationship.(Contoh: One-to-one, one-to-many,many-to-many).


3. Composition: Jika sebuah class tidak bisa berdiri sendiri dan harus merupakan bagian dari class yang lain, maka class tersebut memiliki relasi Composition terhadap class tempat dia bergantung tersebut. Sebuah relationship composition digambarkan sebagai garis dengan ujung berbentuk jajaran genjang berisi/solid.

 

4. Dependency : Kadangkala sebuah class menggunakan class yang lain. Hal ini disebut dependency. Umumnya penggunaan dependency digunakan untuk menunjukkan operasi pada suatu class yang menggunakan class yang lain. Sebuah dependency dilambangkan sebagai sebuah panah bertitik-titik. 

 
5. Aggregation : Aggregation mengindikasikan keseluruhan bagian relationship dan biasanya disebut sebagai relasi.

   



 


Keterangan:
• Class / table departemen memiliki ber-Agregasi dengan class / table pegawai,alasannya karena departemen dapat berdiri sendiri tanpa ada pegawai tetapi kinerjanya tidak sempurna. Banyak pegawai dapat bekerja pada satu departemen jadi many to 1.
• Class/table transaksi tidak dapat berdiri sendiri tanpa adanya class/table produk. Begitu juga dengan table produk tidak bisa berdiri sendiri tanpa adanya departemen.
• Banyak pelanggan dapat melakukan banyak tansaksi
• 1 transaksi dapat mencakup banyak produk.

5. ACTIVITY DIAGRAM

Definisi activity diagram yaitu teknik untuk mendiskrpsikan logika procedural, proses bisnis dan aliran kerja dalam banyak kasus kerja personal (workflow) dan alur data (flowchart).

Activity diagram 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.

Simbol Activity Diagram :

Contoh

Diagram pengembalian buku

Pada diagram activity diatas yaitu transaksi dimana sipeminjam mengembalikan buku yang telah dipinjam. Berikut langkah-langkah aktifitasnya :

• Sipeminjam membawa buku yang telah dipinjam kepada petugas perpus,

·         Setelah itu petugas memeriksa data-data sipeminjam dengan menyerahkan kartu member,

·         Petugas juga mengecek buku tersebut apakah benar buku tersebut yang telah dipinjam, jika ya maka si petugas menghitung masa waktu pengembalian buku tersebut. Jika melewati tanggal pengembalian buku yang telah ditetapkan petugas maka sipeminjam wajib membayar denda. Jika tidak maka sipeminjam tidak dikenakan denda. Setelah itu petugas juga memeriksa kondisi buku. Setelah selesai membayar denda, maka petugas wajib memeriksa validasi data sipeminjam atau mengupdatenya bahwa sipeminjam sudah mengembalikan buku tersebut.

6. COMPONENT DIAGRAM

Component diagram menggambarkan struktur dan hubungan antar komponen peranti lunak, termasuk ketergantungan (dependency) diantaranya. Komponen peranti lunak adalah modul berisi code, baik berisi source code maupun binary code, baik library maupun executable, baik yang muncul pada compile time, link time maupun run time. Pada umumnya komponen terbentuk dari bebrapa class dan/ataupackage, tapi dapat juga dari komponen-komponen yang lebih kecil. Komponen dapat juga berupa interface, yaitu kumpulan layanan yang disediakan sebuah komponen untuk komponen lain.

Tipe-tipe Component :

Bentuk-bentuk component ada 3 yaitu:

 Deployment Component: Yang menjadi basis dari executable system. Contoh deployment component diantaranya: DAN LAIN-LAIN(Dynamic Library Link) file exe, Active X Control, Java Beandan lain-lain.

 Work Product Component: Yaitu file-file yang dibutuhkan untuk pembuatan deployment component. Contoh untuk component kedua ini diantaranya file data, file source code dan lain-lain.

 Execution Component: Yang dibuat sebagai hasil dari sistem yang akan dijalankan.

Menurut Fowler(2004) hal penting pada component adalah component mewakili potongan-potongan yang independen yang bisa dipesan dan diperbaharui sewaktu-waktu. Dengan demikian, pembagian sistem kedalam component-component lebih banyak didorong oleh kepentingan marketing dari pada kepentingan teknis. Meskipun demikian harus juga diingat bahwa terlalu banyak component juga kurang bagus, karena susah mengatur dan memeliharanya khususnya yang menyangkut masalah versioning.

7. PACKAGE DIAGRAM

Package Diagram : Basic Concepts

Bagi yang pernah belajar jaringan komputer tentu tidak asing dengan istilah package. Package yang dalam bahasa Indonesianya berarti paket dalam dunia networking dimanfaatkan dalam komunikasi datanya dimana data tidak dikirimkan langsung dalam bentuk binernya melainkan dikelompokkan terlebih dahulu dalam paket-paket. Package diagram merupakan salah satu dari delapan/sembilan diagram UML. Atau saat kita download salah satu installer linux, yang kita download berupa package-package. Dalam literatur pemrograman dengan visual basic, saat akan mendeploy software yang baru kita buat kita diminta untuk mengambil package-package yang dibutuhkan. Sedangkan dalam bahasa Java dan C++, package selalu diimport saat kita menuliskan code programnya.

Package merupakan kumpulan dari class. Penggambaran diagram Package mirip dengan simbol folder dalam Microsoft Windows. Kita ambil kasus pada sistem penjualan dan pembelian, maka kita dapat membuat dua package yaitu package penjualan dan package pembelian. Di dalam package penjualan kita bisa menggambarkan use case penjualan. Salah satu manfaat package adalah kemampuannya untuk digunakan pada component lainnya.

Dalam menggunakan package sistem lain dikenal dua istilah yaitu:
1. Import Package: Meminjam package lain yang bertipe public.
2. Access Package: seperti import hanya saja tipe package berubah menjadi private.
Import dilukiskan dengan garis putus-putus dengan panah menunjuk pada package induk (si pemilik kelas) dengan tulisan "import" dekat garis putus-putus tersebut. Sedangkan access dengan cara yang sama, hanya saja tulisan "import" diganti dengan "access".

8. DEPLOYMENT  DIAGRAM

Deployment Diagram adalah diagram yang menggambarkan detail bagaimana komponen di-sebar (di-deploy) kedalam infrastruktur sistem, dimana komponen akan terletak (pada mesin, node, server atau piranti keras apa), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisikal.

Contoh Program :

 Logika Program :

Pada pemakaian jaringan LAN dalam sebuah ruangan, Switch menghubungkan semua PC (komputer) dan tak ketinggalan perangkat keras pendukung lainnya yaitu diantaranya Printer dan Modem. Modem disini berfungsi menghubungkan ke Server.

9. STATE DIAGRAM

 State diagram menggambarkan behavior sistem. Yaitu menggambarkan semua ‘state’ yang yang mungkin di mana object bisa mungkin di mana object bisa diperoleh dan bagaimana ‘state object berubah karena event terhadap object tersebut (Fowler, 1999). State diagram juga menggambarkan lifecycle / siklus hidup object.

State merupakan kondisi atau situasi tertentu dari sebuah elemen (obyek) selama siklus hidupnya.

Macam Macam--macam macam state state (Alhir (Alhir 2003) ,2003) :

·         Simple state

·         Initial state

·         Final state

Simple State

€Simple state menunjukkan kondisi / situasi sebuah elemen. Dalam diagram, simple state ditunjukkan dengan dengan kotak dengan sudut tumpul kotak dengan sudut tumpul. Dalam kotak  tersebut dilabeli dengan nama state dari elemen tersebut.

Initial state

€Initial state menunjukkan state dari elemen saat elemen tersebut dibuat. Dalam diagram, ditunjukkan dengan solid solid filled circle filled circle.Dalam state diagram, hanya ada sebuah initial state untuk tiap elemen.

Final State

€Final state menunjukkan state saat sebuah elemen di-destroy. Dalam diagram, ditunjukkan dengan bull s bull’s eye eye. Dalam state diagram, diperbolehkan ada lebih dari sebuah final state.

10.            Diagram Interaction Overview

Interaction Overview Diagram adalah pencangkokan secara bersama antara activity diagram dengan sequence diagram. Interaction Overview Diagram dapat  dianggap sebagai  activity diagram dimana semua aktivitas diganti dengan sedikit sequence diagram, atau bisa juga dianggap sebagai sequence diagram yang dirincikan dengan notasi  activity diagram yang digunakan untuk menunjukkan aliran pengawasan. 

11.            Composite Structure Diagram

Sebuah diagram struktur komposit adalah diagram yang menunjukkan struktur internal classifier, termasuk poin interaksinya  kebagian lain dari  sistem. Hal ini menunjukkan konfigurasi  dan hubungan  bagian, yang bersama-sama,melakukan perilaku classifier mengandung.

Diagram struktur komposit merupakan jenis diagram struktur statis dalam Unified Modeling Language (UML), yang  menggambarkan struktur internal kelas dan kolaborasi.

Diagram struktur komposit dapat digunakan untuk menjelaskan:

- struktur  dari bagian-bagian yang saling berkaitan

- run-time struktur yang saling berhubungan

12.            Object Diagram

Object diagram adalah diagram yang memberikan gambaran model instance-instance dari sebuag class. Diagram ini digunakan untuk menggambarkan sebuah system pada sebuah sudut pandang waktu tertentu. Dengan menggunakan disgram ini anda dapat memeriksa kabsahan kelas-kelas diagram berikut aturan-aturan multiplisitasnya dengan “real data” dan mengujinya dengan scenario-skenario tertentu. Notasi diagramnya dapat anda lihat pada table.

NOTASI OBJECT DIAGRAM

OBJECT

Object-object diidentifikasikan dengan cara meletakkan nama instancenya kmudian diikuti oleh tanda titik dua didepan nama class-nya. Nilai property/atribut dituliskan berpasangan seperti “nama_atribut=nilai”. Sedangkan notasi sebuah obyek digambarkan segi empat yang terbagi atas 2 bagian.

ASSOCIATION

Object diagram juga dapat mengandung asosiasi, biasanya constraint, detil relationship, multiplisitas yang ada di class diagram tidak disertakan dalam object diagram sebagai upaya memfokuskan perhatian hanya terhadap obyek dan property/atributnya. Asosiasi antar 2 obyek biasanya dinotasikam dengan sebuah garis yang menghubungkan kedua obyek.

13.            Timing Diagram

Timing Diagram adalah bentuk lain dari interaction diagram, dimana fokus utamanya lebih ke waktu. Timing diagram sangat berdaya guna dalam menunjukkan faktor pembatas waktu diantara perubahan state pada objek yang berbeda. Menggambarkan perubahan dalam state atau kondisi dari pengelompokkan instance atau tugas berlebihan

WATERFALL

Waterfall sebagai model rekayasa perangkat lunak

Nama lain dari linear sequential model adalah waterfall yang merupakan model rekayasa perangkat lunak tertua. Dalam model ini terdapat seluruh aktivitas dasar dalam pengembangan perangkat lunak yang sudah penulis jelaskan diatas. Tahapan proses dari setiap aktivitas adalah secara berurutan, sebagai ilustrasi perhatikan gambar berikut:

Gambar: Model pengembangan perangkat lunak Linear Sequential (Waterfall)

Kelemahan dari model ini adalah:

1.    Kebanyakan proyek yang terjadi dilapangan tidak mengikuti alur sequen yang sudah ditetapkan, meskipun pengembang bisa melakukan iterasi terhadap proses, namun model melakukannya secara tidak langsung yang menyebabkan perubahan-perubahan yang terjadi sering membuat para tim pengembang mengalami kebingungan.

2.    User harus menyatakan kebutuhannya secara explisit pada saat awal proyek, dan hal ini hampir tidak mungkin dilakukan mengingat keterbatasan manusia dalam mengakomodir kemungkinan-kemungkinan yang akan terjadi dimasa yang akan datang.

3.    User harus memiliki kesabaran, karena versi yang dapat bekerja dari program tidak akan tersedia sebelum proyek diselesaikan.

Walaupun demikian, model ini mengakomodir semua aktifitas dasar yang terdapat dalam pengembangan perangkat lunak, sehingga bisa dijadikan acuan dasar dalam pengembangan perangkat lunak. Model-model yang lain adalah merupakan pengembangan dari model linear sequential.

Permodelan dalam suatu perangkat lunak merupakan suatu hal yang dilakukan di tahapan awal. Di dalam suatu rekayasa perangkat lunak, sebenarnya masih memungkinkan tanpa melakukan permodelan. Hal ini tidak dapat lagi dilakukan dalam suatu industri perangkat lunak.

Permodelan dalam perangkat lunak merupakan suatu yang harus dikerjakan di bagian awal rekayasa, dan permodelan ini akan mempengaruhi pekerjaan-pekerjaan dalam rekayasa perangkat lunak tersebut.

Model proses perangkat lunak masih menjadi obyek penelitian, tapi sekarang ada banyak model umum atau paradigma yang berbeda dari pengembangan perangkat lunak, antara lain :

• ·         Pengembangan waterfall
• ·         Pengembangan secara evolusioner
• ·         Transformasi formal
• ·         Penggabungan sistem dengan menggunakan komponen-komponen yang dapat digunakan kembali

Waterfall model pertama kali diperkenalkan oleh Winston Royce tahun 1970. Waterfall Model merupakan model klasik yang sederhana dengan aliran sistem yang linier.  Output dari setiap tahap merupakan input bagi tahap berikutnya.

Model ini telah diperoleh dari proses rekayasa lainnya dan menawarkan cara pembuatan rekayasa perangkat lunak secara lebih nyata.  Model ini melibatkan tim SQA (Software Quantity Assurance) dengan 5 tahapan, dimana setiap tahapan selalu dilakukan verifikasi atau testing.  Tahapan model waterfall meliputi :

·         Requirment

Dalam tahapan ini jasa, kendala dan  tujuandari konsultasi dengan pengguna sistem.  Kemudian semuanya dibuat dalam bentuk yang dapat dimengerti oleh user dan staf pengembang.  Dengan kata lain, dalam tahapn ini dilakukan analisa kebutuhan, kemdian diverifikasi klien dan tim SQA.

·         Specification

Dokumentasi spesifikasi, kemudian diperiksa oleh tim SQA.  Selanjutnya jika disetujui oleh klien, maka dokumen tersebutmerupakan kontrak kerjaantaraklien dan pengembang s0ftware.  Selanjutnya merencanakan jadwal pengembangan software. Jika disetujui oleh SQA, tahap desain baru dilakukan.

·         Design

Proses design sistem membagi kebutuhan-kebutuhan menjadi sistem perangkat lunak atau perangkat keras.  Proses tersebut menghasilkan sebuah arsitektur keseluruhan. Desain perangkat lunak termasuk menghasilkan fungsi sistem perangkatlunak dalam bentuk yang mungkin ditransformasi kedalam satu atau lebih program yang dapat dijalankan.  Tahapan ini telah menentukan alur software hingga pada tahap algoritma detail.  Di akhir tahap ini, kembali diperksa tim SQA.

·         Implementation

Selama tahap ini, desain perangkat lunak disadari sebagai sebuah program lengkap atau unit program.  Desain yang telah disetujui, diubah dalam bentuk kode-kode program.  Tahap ini, kode-kode program yang dihasilkan masih pada tahap modul-modul. Diakhir tahap ini, tiap modul di testing tanpa diintegrasikan.

·         Integration

Unit program diintegrasikan dandiuji menjadi sistem yang lengkap untuk meyakinkan bahwa persyaratan perangkat lunak telah dipenuhi.  Setelah uji coba, sistem disampaikan ke konsumen.

·         Operaton mode & retirement

Normalnya, ini adalah tahap yang terpanjang.  Sistem dipasang dan digunakan. Pemeliharaan termasuk pembetulan kesalahan yang tidak ditemukan pada langkah sebelumnya.  Perbaikan inmplementasi unit sistem dan peningkatan jasa sistem sebagai kebutuhan baru ditemukan.

Setiap tahap dari modelini menggunakan Document Drivent, yaitu tahap selanjutnya selalu bekerja berdasarkan dokumen yang telah diberikan sebelumnya.

Tahapan pada waterfall model tidak akan selesai jika tidak disetujui SQA.  Modifikasi pada tahap tertentu (tidak sesuai dengan dokumen sebelumnya), proses harus kembali pada tahap sebelumnya untuk penyesuaian dan peninjauan ulang.

Dalam prakteknya, setiap langkah sering tumpang tindih dan saling memberi informasi satu sama lain.  Proses perangkat lunak tidak linierdan sederhana,  tapi mengandung urutan iterasi dari aktifitas pengembangan.  Selama di langkah terakhir, perangkat lunak telah digunakan.  Kesalahan dan kelalaian dalam menentukan kebutuhan perangkat lunak original dapat diatasi.

Sayangnya model yang banyak mengandung iterasi, sehingga membuat sulit bagi pihak manajemen untuk memeriksa seluruh rencana dan laporan.  Maka dari itu, setelah sedikit iterasi, biasanya bagian yang telah dikembangkan akan dihentikan dan dilanjutkan dengan langkah pengembangan selanjutnya.

Masalah-masalah selama resolusi selanjutnya, dibiarkan atau diprogram.  Pemberhentian yang prematur dari persyaratan akan berarti bahwa sistem tidak akan sesuai dengan keinginan user.  Mungkin juga sistem terstruktur secarajelek yang sebenarnya merupakan masalah deain akan dibiarkan karenaterkalahkan olehtrik implementasi.

Masalah pendekatan waterfall adalah ketidakluwaesan pembagian proyek ke dalam langkah yang jelas/nyata.  Sistem yang disampaikan kadang-kadang tidak dapatdigunakan sesuai keinginan konsumen.  Namun demikian, model waterfall mencerminkan kepraktisan rekayasa.  Konsekuensinya, model proses perangkat lunak yang berdasarkan pada pendekatan ini, digunakan dalam pengembangan sistem perangkat lunak dan hardware yang luas.