Seri Tutorial Rational Rose

1. Pendahuluan
Rational Rose merupakan sebuah perangkat pemodelan secara visual  yang memiliki banyak kemampuan (powerful) untuk pembentukan sistem berorientasi obyek yang menggunakan Unified Modeling Language (UML). UML merupakan bahasa pemodelan yang dapat digunakan secara luas dalam pemodelan bisnis, pemodelan perangkat lunak dari semua fase pembentukan dan semua tipe sistem, dan pemodelan secara umum dari berbagai pembentukan / konstruksi yang memiliki dua perilaku yaitu baik statis maupun dinamis.
Tutorial ini akan membahas cara pemakaian Rasional Rose dengan mengambil sebuah kasus untuk mempermudah pemahaman. Namun demikian tutorial ini bersifat sangat sederhana karena pemakaian perangkat lunak ini sangat ditentukan pada system yang akan dibangun dan variasinya. Tutorial ini dapat dianalogkan dengan kursus privat mengendarai mobil. Mobil merupakan sebuah sarana transportasi yang dapat digunakan untuk berbagai keperluan, dalam kursus privat hanya diajarkan bagaimana cara mengoperasikan, perpindahan gigi, gas, rem, light sign, klakson, dsb. Kemahiran mengendarai ditentukan banyak jam pakai dengan berbagai kasus di jalan dan hal itu tidak diberikan dalam kursus privat tersebut.
Untuk mempermudah dalam memahami penggunaan rasional rose dalam tutorial ini disusun dengan urutan sebagai berikut:
1. Pendahuluan
2. Penjelasan istilah yang akan digunakan
3. Penjelasan bagian-bagian dari rasional rose
4. Penjelasan cara menggunakan
5. Studi Kasus

2. Istilah-istilah yang digunakan
Dalam UML, bagian-bagian yang digunakan yaitu: views, diagram, dan elemen model.
a. View. View menunjukkan perbedaan dari berbagai aspek-aspek suatu sistem yang dimodelkan. View bukan sebuah graph, tetapi sebuah abstraksi yang terdiri dari beberapa diagram. Hanya dengan mendefinisikan sejumlah view, dimana setiap view menunjukkan aspek yang berbeda dan saling terpisah dari sistem, maka gambaran sebuah sistem secara komplit dapat dibentuk. Rational rose memiliki empat view yaitu: Use case View, Logical View, Component View, dan Deployment View.
b. Diagram. Diagram merupakan graph yang menjelaskan tentang isi dari sebuah view. UML memiliki beberapa tipe diagram yang berbeda yang dapat digunakan untuk mengkombinasi  dalam menyusun semua dari sebuah sistem. Rational Rose 2000, memiliki delapan diagram yaitu: Use case diagram, Sequence diagram, Collaboration diagram, Activity Diagram, Class Diagram, Statechart Diagram, Component Diagram dan Deployment Diagram.
c. Elemen Model. Konsep-konsep yang digunakan dalam diagram merupakan elemen-elemen model yang menyatakan konsep-konsep berorientasi obyek secara umum , seperti class, object, dan message, serta hubungan antar konsep-konsep tersebut termasuk association, dependency, dan generelization. Sebuah elemen model digunakan dalam beberapa diagram yang berbeda tetapi selalu memiliki simbol dan arti yang sama.

3. Komponen GUI Rational Rose 2000©
Komponen utama GUI dari Rational Rose® diperlihatkan pada gambar dibawah :
1. Standard toolbar 6. Spesification
2. Browser 7. Elemen Model (icon)
3. Diagram window
4. Diagram toolbar
5. Documentation windows

Menggambar UML Class Diagram

UML Class Diagram

Class Diagram memiliki tiga area pokok :
1. Nama (dan stereotype)
2. Atribut
3. Operasi/metode

Gambar Class Diagram

Apabila atribut dan operasi digabungkan maka ini disebut function. Atribut dan operasi dapat memiliki salah satu sifat berikut :
• Private, tidak dapat dipanggil dari luar class yang bersangkutan. Notasi: “-“
• Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak yang mewarisinya. Notasi: “#”
• Public, dapat dipanggil oleh siapa saja. Notasi: “+”

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.

Gambar berikut ini merupakan contoh class diagram dari sebuah interface “Person”

Gambar <<Interface>> Class Diagram

   

Class dapat dikelompokkan menjadi package seperti gambar di bawah ini:

Gambar Package Class Diagram

Hubungan Antar Class
1. Asosiasi, yaitu hubungan statis antar class. Sebuah association adalah hubungan antar benda struktural yang terhubung diantara obyek. Kesatuan obyek yang terhubung merupakan hubungan khusus, yang menggambarkan sebuah hubungan struktural diantara seluruh atau sebagian. Umumnya assosiation digambarkan dengan sebuah garis yang dilengkapi dengan sebuah label, nama, dan status hubungannya
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. Sebuah generalization adalah menggambarkan hubungan khusus dalam obyek anak/child yang menggantikan obyek parent / induk . Dalam hal ini, obyek anak memberikan pengaruhnya dalam hal struktur dan tingkah lakunya kepada obyek induk.
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.

Cara menggambarkan class diagram
1. Gunakan use case table yang sudah dibuat sebelumnya dengan memberikan highlight semua kata benda yang dapat menjadi potensial obyek.
2. Bedakan tipe-tipe obyek tersebut karena mereka dapat berupa interface, package, dan lainnya. Apabila obyek tersebut berupa nama atribut dari sebuah class, maka obyek ini harus ditolak.
3. Setelah mendapatkan daftar class, maka gambarkan high level class diagram beserta dengan kardinalitas serta deskripsi relasinya.
4. Kemudian gambarkan detailed class diagram di mana hubungan antar class sudah ditambahkan. Jangan lupa untuk menuliskan semua atribut dan operasi beserta dengan sifat mereka. Pada umumnya sifat atribut pada sebuah tabel adalah private (tidak dapat dipanggil dari luar class yang bersangkutan). Sedangkan sifat dari operasi yaitu public (dapat dipanggil oleh siapa saja).
5. Jangan lupa untuk melakukan normalisasi terhadap class jika belum dibuat sebelumnya.

Berikut ini ditunjukkan notasi dari Kelas Diagram

Gambar Notasi Class Diagram

Berikut ini contoh class diagram beserta dengan hubungan antar kelas.

Gambar Contoh Hubungan Antar Kelas

Berikut ini adalah contoh menggambar Diagram Kelas melalui Video Youtube:
http://www.youtube.com/watch?v=w2m-7YcHVck

Video Pengantar ini juga dapat dilihat sebagai awal untuk memahami UML Class Diagram:
http://www.youtube.com/watch?v=5d2blHVH3h8

Pemodelan Perangkat Lunak

Saya sudah sering menulis tentang topik ini: pemodelan perangkat lunak, namun karena adanya kebutuhan untuk "mengumpulkan" tulisan-tulisan saya yang tersebar, menjadi lebih mudah dibaca, maka saya (kembalil) menulis topik ini.

Silahkan baca disini, bagi yang ingin mengetahui mengenai UML sebagai Bahasa Pemodelan Perangkat Lunak:

1. UML dan Pemodelan Software: tulisan ini membahas mengenai jenis-jenis diagram yang ada pada UML, beserta kegunaannya, dan pada proses SDLC mana diagram itu dapat digunakan http://stanlysk.blogspot.com/2012/04/pemodelan-dengan-uml.html
2. Model Sistem Perangkat Lunak: tulisan ini membahas tentang LINK official UML, serta maksud dan tujuan digunakannya UML sebagai alat pemodelan perangkat lunak. http://stanlysk.blogspot.com/2012/07/model-sistem-perangkat-lunak.html
3. UML Use Case Diagram; bagian tulisan ini menjelaskan secara mendetail, langkah-langkah logis tertentu dalam memodelkan perangkat lunak, dengan pendekatan user-oriented dan menggunakan UML Use Case Diagram http://stanlysk.blogspot.com/2012/05/use-case-diagram.html
4. Sequence Diagram; bagian tulisan ini menjelaskan secara mendetail, langkah-langkah logis tertentu dalam memodelkan perangkat lunak, dengan menggunakan UML Sequence Diagram  http://stanlysk.blogspot.com/2012/05/sequence-diagram.html

Bagi yang ingin melihat Video Tuturial tentang Pemodelan menggunakan UML, maka saya menganjurkan beberapa LINK Youtube dibawah ini:

1. Pengenalan tentang UML, klik disini: http://www.youtube.com/watch?v=FkRwbVUVFvE&feature=fvwrel

2. Use Case Diagram, klik disini: http://www.youtube.com/watch?v=Zk-580BqSNY&feature=fvwrel

3. Class Diagram, klik disini: http://www.youtube.com/watch?v=w2m-7YcHVck&feature=relmfu

4. Sequence Diagram, klik disini: http://www.youtube.com/watch?v=4WDbte6cPa8&feature=relmfu

Tautan dibawah ini, adalah daftar tools yang bisa digunakan untuk menggambar model UML:

http://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools

Model Sistem Perangkat Lunak

Pertanyaan pertama yang selalu muncul di benak pengembang perangkat lunak adalah "mengapa harus repot-repot membuat model sistem dari perangkat lunak yang akan dibangun?"

Memang, jika hanya melihat dari "satu sisi", maka langkah pemodelan sistem perangkat lunak, seperti membuang waktu. Namun demikian, pada kenyataannya, tidaklah demikian. Para pengembang perangkat lunak yang punya banyak "jam terbang" dan telah mengembangkan berbagai "model" akan menyetujui bahwa langkah pemodelan merupakan langkah yang penting dan strategis, dalam pengembangan perangkat lunak.

Sedikitnya ada beberapa alasan mengapa para pengembang "pemula" tidak memahami pentingnya langkah pemodelan perangkat lunak, diantaranya adalah:

1) terlalu banyak melibatkan pekerjaan "dokumentasi" perangkat lunak;

2) tidak menggambarkan persyaratan non - fungsional

3) tidak dapat menggambarkan keseluruhan aplikasi yang akan dikembangkan

4) jika modelnya terlalu "mendetail" maka justru akan membuat kebingungan.

Para pengembang "pemula" JUSTRU harus mengubah paradigma diatas, dengan meyakini bahwa model perangkat lunak, merupakan syarat penting untuk memulai kegiatan pengembangan perangkat lunak. Misalnya, dengan menggunakan model diagram, maka pengembang dapat "mengkomunikasikan" dengan pengguna, perihal perangkat lunak yang akan dikembangkan. Dari sisi pengembang, maka model perangkat lunak akan menjadi "panduan" pada langkah-langkah selanjutnya.

Banyak notasi yang dapat digunakan untuk memodelkan perangkat lunak, yang umum digunakan adalah:

Diagram Konteks,

Data Flow Diagram

Diagram Aktivitas

Diagram Use Case

Diagram Kelas

Diagram Sekuens

Diagram Navigasi

UML adalah salah notasi pemodelan yang umum digunakan dalam industri perangkat lunak. Untuk acuan RESMI dari notasi pemodelan UML, dapat mengklik tautan dibawah ini:
1. http://www.uml.org/

2. http://www.omg.org/index.htm

3. Document Associated with UML version 2.0:

http://www.omg.org/spec/UML/2.0/

4. UML version 2: In support on model driven development:

http://www.ibm.com/developerworks/rational/library/05/321_uml/

UML di IDE Netbeans

(Gambar diambar dari javastudy.wordpress.com)

Setelah sedikit mengutak-atik Netbeans Community, akhirnya saya mendapat kabar kalo UML sudah bisa digunakan di IDE Netbeans 6.9.1. Biasanya saya menggunakan Rational Rose untuk membuat model diagram UML, tapi akhirnya saya "tergoda" juga untuk menggunakan IDE Netbeans.

Sedikit perbedaan adalah, pada Rational Rose, disediakan fitur untuk menggambar diagram2 UML yang lebih lengkap, sedangkan untuk IDE Netbeans hanya disediakan Class Diagram, Activity Diagram, Use Case Diagram, Sequence Diagran dan State Diagram. Dari sudut pandang seorang dosen, maka saya mengatakan bahwa diagram2 tersebut sudah cukup untuk digunakan dalam perkuliahan maupun sebagai bagian dari Laporan Tugas Proyek dan Tugas Akhir.

Fitur click-and-drag yang disediakan Netbeans dalam menggambar UML Diagram, tentu saja memberikan kemudahan tersendiri bagi para pengguna IDE ini. Ditambah dengan fitur "reverse engineering" yang akan memudahkan kita untuk men-generate code dari diagram2 yang telah kita gambar.

Berikut ini adalah petunjuk instalasi Plug In UML:

https://docs.google.com/open?id=0BxSxy7HfW5oJT056NEItNF9PQUE

Berikut ini adalah Petunjuk Pemakaian UML di Netbeans:

https://docs.google.com/open?id=0BxSxy7HfW5oJVk1NdTZ0LUxvbjA

Berikut ini adalah Video Petunjuk Penggunaan UML di Netbeans:

http://www.youtube.com/watch?v=31BnR2AKazM

Untuk yang ingin mengetahui UML secara lebih mendalam melalui Video, dapat melihat link ini:

http://www.youtube.com/watch?v=FkRwbVUVFvE&feature=fvwrel

Sequence Diagram

Menggambar Sequence Diagram

Apa tujuan membuat UML Sequence Diagram? Ada beberapa tujuan mengapa harus membuat Sequence Diagram diantaranya adalah 1). untuk menggambarkan interaksi antar objek di dalam dan di sekitar sistem termasuk pengguna, display, dan sebagainya, yang digambarkan dengan hubungan message dan waktu; 2) untuk menggambarkan skenario atau rangkaian langkah-langkah yang dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu.

Cara menggambarkan sequence diagram:

1) Sequence diagram terdiri atas dimensi vertikal (waktu) dan dimensi horizontal (obyek-obyek yang terkait).

2) Diawali dari apa yang men-trigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan.

3) Masing-masing objek, termasuk aktor, memiliki lifeline vertikal.

4) Message digambarkan sebagai garis berpanah dari satu objek ke objek lainnya. Pada fase desain berikutnya, message akan dipetakan menjadi operasi/metode dari class.

5) Activation bar menunjukkan lamanya eksekusi sebuah proses, biasanya diawali dengan diterimanya sebuah message.

6) Untuk objek-objek yang memiliki sifat khusus, standar UML mendefinisikan icon khusus untuk objek boundary, controller dan persistent entity.

Berikut saya berikan contoh sebuah proses menggambar Sequence Diagram. Proses bisnis yang digambarkan adalah proses pembelian minuman yang dilakukan oleh seorang actor lewat vending machine. Untuk mempermudah proses penggambaran maka bisnis proses ini dibagi menjadi 3 bagian dengan scenario yang berbeda-beda.

Identifikasi dan klasifikasi obyek adalah: 

Front adalah interface, register adalah controller untuk pembayaran, dan dispenser adalah controller untuk pilihan minuman. 

Scenario pertama mendemonstrasikan proses pembelian dimana:

1) Actor mengisi uang (insert input) sesuai dengan harga minuman. 

2) Input ini diteruskan ke bagian register control. Oleh karena jumlah uang yang dimasukkan sama persis dengan harga minuman, maka dari itu proses ini berhenti disini saja.

3) Selain uang, actor juga menyeleksi minuman yang diinginkan (select selection). Dispenser controller mengirim minuman tersebut ke front. 

Lihar Gambar Sequence Diagram Skenario Pertama dibawah ini:

 Sequence Diagram (Membeli Minuman – Part 1)

Sumber: Schmuller (1999, hal.109)

Scenario kedua:

1) Ada 2 kondisi untuk input yaitu input = price dan input > price.

2) Jika input=price dan pilihan minuman tersedia,maka dispenser akan langsung mengirim minuman tersebut. (Prosesnya sama dengan gambar sequence diagram di atas).

3) Perbedaan antara kedua sequence diagram ini yaitu diagram kedua menambahkan sebuah kondisi jika input > price.

4) Ada 2 hal yang akan divalidasi di sini yaitu:

a. Jika tidak ada uang kembalian tersedia di register controller, maka register akan mengembalikan input (uang) dan transaksi berakhir.

b. Jika ada uang kembalian, maka register akan meneruskan transaksi ini dengan mengirimkan message ke dispenser controller. Kemudian, register akan mengembalikan uang kembalian tersebut. Setelah itu, dispenser controller akan mengirimkan minuman sesuai pilihan si actor.

Lihat Gambar Sequence Diagram Skenario Kedua dibawah ini:

Sequence Diagram (Membeli Minuman – Part 2)

Sumber: Schmuller (1999, hal.111)

Scenario ketiga:

1) Proses ketiga ini adalah lanjutan dari proses sebelumnya.

2) Perbedaannya terletak pada pilihan minuman.

3) Ada 2 hal mengenai pilihan minuman yang akan divalidasi di sini yaitu:

c. Jika minuman yang diinginkan tidak tersedia di dispenser controller, maka dispenser akan menampilkan message untuk memberitahukan hal tersebut ke actor.

d. Jika pilihan minuman tersedia, maka dispenser controller akan mengirimkan minuman sesuai pilihan si actor lewat front interface.

Lihat Gambar Sequence Diagram Skenario Ketiga dibawah ini:

Sequence Diagram (Membeli Minuman – Part 3)

Sumber: Schmuller (1999, hal.111)

TIPS menggambar Sequence Diagram adalah:
PASANGKAN dengan Use Case Tabel !!!
(dan COCOKKAN dengan ACTIVITY DIAGRAM)

Sebuah Video tentang Sequence Diagram, dapat dilihat disini:
http://www.youtube.com/watch?v=4WDbte6cPa8&feature=relmfu

Sebuah Tutorial Menggambar Sequence Diagram dengan menggunakan Visual Paradigm, dapat dilihat disini:
http://www.youtube.com/watch?v=18_kVlQMavE&feature=related

Business Use-case Model

Menggambar Business Use-case Model
 

Business Use-case Model merupakan model yang menggambarkan proses bisnis dari sebuah bisnis atau organisasi dan interaksi proses tersebut dengan pihak luar, seperti para customer dan partner. Model ini diperlukan untuk memperjelas konteks bisnis dari perangkat lunak yang akan dibuat (kadang bersifat optional, dimana dapat diilustrasikan dalam satu atau beberapa business use-case diagram).

Dalam prakteknya Business Use-case Model digunakan bersamaan dengan UML Activity Diagram untuk menggambarkan proses bisnis. Menggunakan model Business Use-case sebenarnya dapat mempertajam pemahaman tim pengembang dan user terkait model bisnis sistem informasi yang akan dikembangkan.
 

Business use-case model dibangun dengan elemen-elemen: Business Actor, Business Use-case, dan Activity Diagram untuk menjelaskan model business use-case
 

Business Actor:
Business actor (aktor bisnis) mengambarkan peran yang dimainkan oleh seorang atau sesuatu yang berinteraksi dengan bisnis. Sebuah business actor mengambarkan seorang customer , partner bisnis, atau sebuah sistem informasi yang berhubungan dengan bisnis kita

Gambar dari Business Actor

 

Business Use-case
Business use-case merupakan urutan tindakan yang dimainkan suatu bisnis yang menghasilkan sebuah nilai yang dapat dilihat dan ditunjukan untuk suatu business actor tertentu. Satu business use-case mewakili satu proses bisnis

Gambar dari Business Use-case

Berikut adalah sebuh Contoh Gambar Business use-case Model dari studi kasus sebelumnya disini

UML Use-case Diagram

Menggambar UML Use-case Diagram 

Use-case diagram merupakan model diagram UML yang digunakan untuk menggambarkan requirement fungsional yang diharapkan dari sebuah system. Use-case diagram menekankan pada “siapa” melakukan “apa” dalam lingkungan system perangkat lunak akan dibangun. Use-case diagram sebenarnya terdiri dari dua bagian besar; yang pertama adalah use case diagram (termasuk gambar use case dependencies) dan use case description. 

Berikut adalah Gambar Notasi Use Case

Berikut adalah cara menggambar use-case diagram:

Catatan:

Sebaiknya membuat use-case diagram, diawali dengan membuat FDD terlebih dahulu. Hal ini sekedar untuk membantu mengidentifikasi proses-proses dalam sistem.

1) Mulai dengan mendaftarkan aktor yang berhubungan dengan Use-case, baik sebagai sender maupun receiver.

2) Komponen dalam use-case diagram adalah Nama Use-case, Deskripsi Use-case dan Pelaku yang berpartisipasi dan perannya.

3) Temukan dependency yang mendemonstrasikan hubungan semantik antara dua Use-case. Jika Use-case “A” berubah dapat mengakibatkan Use-case “B” akan berubah pula. 

Ada 2 macam dependency yang perlu diperhatikan yaitu include dan extend.
Dependency include:
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.

Contoh Use-case (include)

 

Ket:
Pasien harus membuat temu janji sebelum diberikan perawatan yang diperlukan untuk mengobati penyakit yang dideritanya. Use-case “Make Appointment” meng-include fungsionalitas dari Use-case “Get Treatment” sebagai bagian dari proses saat dieksekusi.

Dependency extend:
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 (extend):

Ket:
Setelah pasien membuat temu janji dengan dokter, pasien ini  tiba-tiba mendapat halangan sehingga tidak dapat memenuhi janjinya. Oleh karena itu, pasien ini membatalkan janji yang sudah dibuat. Ini merupakan contoh dari kasus extend dimana “Make Appointment” adalah base Use-case dan “Cancel Appointment” merupakan extended Use-case.

Gambar  Contoh Interaksi Antara Aktor dan Sistem (Use-case)

Berikut adalah Contoh Use-case description

Keterangan

Normal course:         

Rangkaian kejadian yang terjadi sesuai harapan
Alternate course:    

Mendokumentasikan kelakuan Use-case jika terjadi exception
Pre-condition:    

Kondisi yang harus dipenuhi sebelum Use-case ini dijalankan. Hal ini dapat dilakukan dengan memberikan penjelasan singkat atau dapat pula berupa nama Use-case.
Post-condition:    

Batasan pada keadaan sistem setelah Use-case ini diesksekusi dengan baik. Dapat berupa nama Use-case.

Sebuah Video Tutorial tentang UML Use Case Diagram dapat dilihat disini:
http://www.youtube.com/watch?v=Zk-580BqSNY&feature=relmfu

UML Activity Diagram

Langkah pertama yang HARUS dilakukan untuk memodelkan perangkat lunak adalah dengan membuat model proses bisnis. Proses bisnis yang dimaksudkan disini adalah proses yang terkait dengan urutan langkah, cara kerja atau bagaimana kita melakukan pekerjaan tertentu. Urutan langkah atau cara kerja inilah yang akan dibangun pada perangkat lunak.

Pemodelan proses bisnis dapat dibagai menjadi dua bagian. Bagian pertama disebut identifikasi problem domain. Pada bagian ini, tim pengembang bekerja sama dengan stakeholders berusaha untuk menemukan setiap permasalahan yang ada dalam proses bisnis. Proses ini dapat dilakukan dengan melalui wawancara, menyebarkan kuesioner ataupun melakukan diskusi. Setelah dilakukan identifikasi problem domain, maka dilanjutkan dengan menyimpulkan kebutuhan user/stakeholders terkait dengan perangkat lunak yang akan dibangun. Pada tahap ini, penting sekali untuk disepakati bersama kebutuhan-kebutuhan apa yang akan diselesaikan oleh perangkat lunak.

Bagian kedua pemodelan proses bisnis adalah identifikasi solution domain. Solution domain dimulai dengan mengidentifikasi features (berdasarkan needs yang ada) yang harus dibangun pada perangkat lunak. Berdasarkan features ini kemudian ditentukanlah software specification requirements yang akan dibangun.

Jika akan menggunakan UML maka kakas pemodelan yang bisa digunakan dalam pemodelan proses bisnis ini adalah Activity Diagram, Business Use-case Model, Business Object Model (BOM) dan Use-case Diagram. 

Pada bagian tulisan ini, saya akan menuliskan tentang memodelkan proses bisnis dengan Activity Diagram. Activity diagrams menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang: awal proses, decision, akhir proses, proses paralel yang mungkin terjadi pada beberapa eksekusi. Activity diagram tidak menggambarkan behaviour internal sebuah sistem (dan interaksi antar subsistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas. Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu

Notasi dalam Activity Diagram

Cara menggambarkan activity diagram:

1. Menggunakan segiempat dengan sudut membulat untuk menggambarkan aktivitas. Decision digunakan untuk menggambarkan behaviour pada kondisi tertentu. 

2. Untuk mengilustrasikan proses-proses paralel (fork dan join) digunakan titik sinkronisasi yang dapat berupa titik, garis horizontal atau vertikal.

3. Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu.

4. Untuk dapat menggambarkan activity diagram dengan baik, disarankan agar membuat daftar sejumlah aktivitas beserta dengan kondisinya. Tools FDD dapat menjadi sangat berguna untuk mengecek proses-proses serta jalur aktivitas, baik dari level atas maupun level rincinya.

Tentang Activity Diagram:

Sebuah Activity diagram dalam business use-case menggambarkan workflow (aliran kerja) sebuah business use-case. Workflow dari sebuah business use-case menggambarkan apa yang harus dikerjakan bisnis tersebut untuk menghasilkan nilai tertentu untuk business actor yang bersangkutan. Activity diagram di bawah ini memodelkan alur kerja (workflow) sebuah proses bisnis dan urutan aktivitas dalam suatu proses.

Contoh pada Studi Kasus:

Pada sebuah Foodcourt. Pembeli datang ke foodcourt, menuju stand penjual makanan yang dinginkan. Pembeli memesan makanan, jika makanan tersebut ada, maka pesanan disiapkan, jika makanan tersebut tidak ada maka pembeli tidak jadi memesan makanan. Setelah memesan, petugas stand menyiapkan bon dua rangkap dan memberikan bon tersebut kepada pembeli.

Pembeli kemudian membayar makanan yang dibeli di kasir stand dengan menyerahkan bon pembelian. Kasir menghitung jumlah yang harus dibayar pembeli dan menginformasikannya ke pembeli. Pembeli menyiapkan uang dan memberikan kepada kasir. Jika ada kembalian, kasir menghitung kembalian tersebut dan memberikan kembalian beserta bukti pembayaran (struk) serta bon yang sudah ditandai lunas.

Pembeli mencari tempat duduk, penjual stand makanan memberikan makanan kepada pembeli dengan mengambil bon yang sudah ditandai lunas tersebut.

Activity Diagram Pembayaran

Activity Diagram Pemesanan

Sebuah Video Tutorial tentang Activity Diagram dapat dilihat disini:
http://www.youtube.com/watch?v=yAihwmczqsk&feature=related

UML dan Pemodelan Software

Pemodelan pada dasarnya merupakan kegiatan untuk menyederhanakan. Seperti misalnya kita ingin memahami tentang bentuk bumi yang seperti bola. Alih-alih kita melihat bumi dari luar angkasa, maka kita mengambil benda yang “menyerupai” bola, dan kemudian mulai memodelkan bumi yang sebenarnya.

Kegiatan pemodelan perangkat lunak berorientasi obyek adalah kegiatan untuk mencoba menyederhanakan perangkat lunak yang akan kita kembangkan dengan terlebih dahulu membuat model visualisasi (penggambaran model) perangkat lunak yang akan dikembangkan. Pembuatan model visualisasi perangkat lunak dilakukan dengan menggunakan kakas yang disebut Unified Modelling Language atau disingkat UML. 

Jadi, sebenarnya UML adalah:

1. sebuah "bahasa" pemodelan perangkat lunak standar yang dapat digunakan untuk melakukan spesifikasi, visualisasi, konstruksi, dan dokumentasi dari komponen-komponen perangkat lunak.
2. bahasa pemodelan visual yang notasi grafis yang ekspresif dalam arti lengkap dan mudah dipahami, baik oleh pengembang maupun user.
3. menggunakan class dan operation dalam konsep dasarnya, maka ia lebih cocok untuk penulisan piranti lunak dalam bahasa berorientasi obyek seperti C++, Java, C# atau VB.NET.

Tiga hal yang harus diperhatikan agar dapat menguasai UML dengan baik, yaitu:

1. Memahami maksud dan tujuan digunakannya UML
2. Memahami apa yang akan dimodelkan dalam UML
3. Menguasai langkah-langkah pembuatan diagram UML

Ada beberapa notasi grafis dalam UML yang dapat digunakan untuk memodelkan aplikasi perangkat lunak berorientasi obyek. Notasi grafis atau disebut juga diagram tersebut memiliki bermacam-macam sudut-pandang (atau disebut perspektif) untuk menunjukkan model perangkat lunak. Diagram-diagram tersebut juga menunjukkan tingkat abstraksi pemodelan berorientasi obyek yang berbeda-beda. Berikut adalah Ringkasan Diagram UML ver 2.0 yang diambil dari buku System Analysis and Design with UML version 2; An Object-Oriented Approach,2nd Ed. By Allan Dennis, Barbara Wixon, David Tegarden. © John Wiley&Sons, 2010

Bagaimana memodelkan perangkat lunak dengan UML?

Terdapat banyak variasi dalam memodelkan perangkat lunak dengan menggunakan UML. Dibawah ini saya memberikan saran untuk memodelkan perangkat lunak dengan menggunakan UML. Tidak berarti bahwa saran saya ini adalah yang paling tepat, penyesuaian terhadap langkah-langkah pemodelan itu sangat terbuka. Masing-masing pengembang dapat menemukan "best practices"-nya sendiri. Urutan langkah yang disarankan untuk memodelkan perangkat lunak dengan menggunakan UML adalah:

1. Buatlah daftar proses business dari level tertinggi untuk mendefinisikan aktivitas dan proses yang mungkin muncul. Langkah ini dapat dilakukan dengan membuat FDD (functional decomposition diagram) ataupun dengan membuat Business Use Case Model dan Business Object Model (BOM).
2. Petakan use case untuk tiap proses business untuk mendefinisikan dengan tepat fungsionalitas yang harus disediakan oleh sistem. Kemudian perhalus use case diagram dan lengkapi dengan requirement, constraints dan catatan-catatan lain.
3. Definisikan requirement lain (non-fungsional, security dan sebagainya) yang juga harus disediakan oleh sistem dengan mengisi use case table.
4. Berdasarkan use case table, highlight semua potensial obyek dan dari situ pilihlah obyek yang dapat dijadikan sebuah kelas. Kemudian, gambarkan high-level class digram dan detailed class diagram.
5. Setelah class diagram dibuat, kita dapat melihat kemungkinan pengelompokan class menjadi komponen-komponen. Oleh karena itu buatlah component diagram pada tahap ini. Juga, definisikan tes integrasi untuk setiap komponen meyakinkan ia berinteraksi dengan baik.
6. Berdasarkan use case diagram, mulailah membuat activity diagram.
7. Setelah activity diagram selesai dibuat, maka langkah selanjutnya yaitu mendefinisikan objek-objek level atas (package atau domain). Lalu buatlah sequence dan/atau collaboration diagram untuk tiap alir pekerjaan. Jika sebuah use case memiliki kemungkinan alir normal dan error, buatlah satu diagram untuk masing-masing alir.
8. Buatlah rancangan user interface model yang menyediakan antarmuka bagi pengguna untuk menjalankan skenario use case.
9. Perhalus deployment diagram yang sudah dibuat. Detilkan kemampuan dan requirement piranti lunak, sistem operasi, jaringan, dan sebagainya. Petakan komponen ke dalam node.
10. Mulailah membangun sistem. Ada dua pendekatan yang dapat digunakan:
11. Pendekatan use case, dengan meng-assign setiap use case kepada tim pengembang tertentu untuk mengembangkan unit code yang lengkap dengan tes.
12. Pendekatan komponen, yaitu meng-assign setiap komponen kepada tim pengembang tertentu.
13. Lakukan uji modul dan uji integrasi serta perbaiki model berserta codenya. Model harus selalu sesuai dengan code yang aktual.
14. Piranti lunak siap dirilis.

Sebuah Video Tutorial tentang Introduction to UML, bisa dilihat disini:
http://www.youtube.com/watch?v=FkRwbVUVFvE&feature=fvwrel

pengantar UML ...

UML adalah singkatan dari Unified Modeling Language, yaitu suatu notasi pemodelan aplikasi perangkat lunak. Schach[1] menegaskan bahwa UML merupakan bahasa bukan metode. Sebagai bahasa, UML digunakan untuk mendeskripsikan perangkat lunak yang dikembangkan dengan berbagai pradigma pengembangan perangkat lunak dan metodologi. Pendapat Schach[1] didukung oleh Sommerville[2] dan Pressman[3].  

Dennis, Wixom dan Tegarden[4] mendukung pendapat bahwa UML merupakan kumpulan standar pemodelan dengan menggunakan diagram, dimana UML bertujuan untuk menyediakan kosa-kata dari paradigma pengembangan sistem berorientasi obyek guna memodelkan semua tahapan dari daur hidup pengembangan perangkat lunak. Bentley dan Whitten[5], mendukung pemahaman bahwa UML merupakan kumpulan alat pemodelan yang disepakati bersama untuk menjelaskan sistem perangkat lunak. Hal serupa dikemukakan oleh Kendall dan Kendall[6].

Fowler[8] memberikan definisi yang sederhana bahwa UML merupakan kumpulan notasi grafis, yang didukung oleh meta-model tunggal, yang membantu pendeskripsian dan desain sistem perangkat lunak, khususnya sistem yang dibangun menggunakan pemrograman berorientasi obyek. UML merupakan standar yang relatif terbuka yang diatur oleh Object Management Group (OMG), sebuah konsorsium terbuka. OMG berfungsi untuk membuat standar-standar yang mendukung interoperabilitas sistem yang berorientasi objek. Versi terakhir dari UML adalah UML ver 2.0[9].

Menurut Kruchten[10], UML adalah bahasa grafis untuk visualizing, specifying, constructing and documenting setiap artifak dari sistem perangkat lunak.

UML mendukung The 4+1 View Model of Architecture, yakni 

1) The Logical View, 

2) The Implementation View, 

3) The Process View dan 

4) The Deployment View ditambah dengan 

5) The Use Case View.

Lihat Gambar dibawah ini tentang pemetaan UML pada Architecture Model Perangkat Lunak:

Model merupakan representasi lengkap dari sistem perangkat lunak, sedangkan arsitektur merupakan fokus pandangan pada bagian-bagian tertentu dari sistem perangkat lunak. Atau dapat dikatakan arsitektur sistem merupakan cetak-biru aplikasi. Keterhubungan model dan arsitektur sistem perangkat lunak, digambarkan oleh UML.

Tool Yang Mendukung UML
Saat ini banyak sekali tool pendesainan yang mendukung UML, baik itu tool komersial maupun opensource. Beberapa diantaranya adalah:
Rational Rose (www.rational.com)
Together (www.togethersoft.com)
Object Domain (www.objectdomain.com)
Jvision (www.object-insight.com)
Objecteering (www.objecteering.com)
MagicDraw (www.nomagic.com/magicdrawuml)
Visual Object Modeller (www.visualobject.com)
Data seluruh tool yang mendukung UML, lengkap beserta harganya (dalam US dolar) bisa anda pelajari di situs http://www.objectsbydesign.com/tools/umltools_byCompany.html .
Disamping itu, daftar tool UML berikut fungsi dan perbangingan kemampuannya juga dapat dilihat di
http://www.jeckle.de/umltools.htm.


Referensi Site UML
Sebagai referensi dalam mempelajari dan menggunakan UML, situs-situs yang merupakan pointer
penting adalah:
http://www.cetus-links.org/oo_uml.html
http://www.omg.org
http://www.omg.org/technology/uml/
http://www.rational.com/uml
http://www.uml.org/

Tulisan lainnya tentang UML dapat ditemukan disini

Sumber Acuan

[1] Schach, Object Oriented Software Engineering, 8th Ed, McGrawHill, 2008. 

[2] Sommerville, Software Engineering, 8th ed, Pearson Education Limited, 2007

[3] Pressman, Software Engineering, A Practitioner’s Approach, 6th ed, McGrawHill, Singapura, 2005.

[4] Dennis, Wixom and Tegarden, System Analysis and Design with UML, An Object-Oriented Approach, 3dh ed, John Wiley & Sons, International Student Edition, 2010.

[5] Bentley and Whitten, System Analysis and Design for the Global Enterprise, 7th ed, McGrawHill International Edition, 2007.

[6] Kendall and Kendall, System Analysis and Design, 7th ed, Pearson Prentice Hall, 2007.

[7] CMMI Product Team, CMMI® for Development, Version 1.3, Improving processes for developing better products and services, November 2010, TECHNICAL REPORT CMU/SEI-2010-TR-033 , ESC-TR-2010-033, Software Engineering Process Management Program, Unlimited distribution subject to the copyright. http://www.sei.cmu.edu.

[8] Martin Fowler, UML Distilled, A Brief Guide to the Standard Object Modelling Language, 3th ed, Pearson Education, 2004.

[9] www.uml.org., Unified Modelling Language: Superstructure Version 2.0, ptc/03-08-02.

[10] Philippe Kruchten, The Rational Unified Process An Introduction, 3rd ed, Pearson Education, 2004.