Unified Process (UP) dan Unified Modeling Language (UML)

Untuk UML kita sering mendengarnya, terutama bagi mahasiswa jurusan ilmu komputer, teknik informatika, ataupun sistem informasi. Sementara UP, sepertinya jarang terdengar, terkadang kurikulum pun tidak memasukannya. Biasanya UP dipisahkan dengan UML karena UP merupakan bagian dari proses perancangan perangkat lunak. Terkadang juga masuk dalam materi analisa dan disain sistem informasi.

Untuk informasi mengenai apa itu UP bisa dilihat di internet, misalnya wikipedia yang sepertinya akurat, sesuai dengan teori yang ada. Untuk yang ingin detilnya bisa lihat rujukan buku milik Jim Arlow (Arlow & Neustadt, 2005) atau karangan Craig Larman (Larman, 2005).

Lalu hubungannya apa UP dengan UML? Sebelumnya ada istilah Rational Unified Process (RUP) yang merupakan benchmark IBM untuk menggambarkan proses perancangan perangkat lunak. Untuk menghindari penamaan pabrikan/vendor, tri-amigos: Ivar Jacobson, James Rumbaugh dan Grady Booch menerbitkan buku khusus UP. Mereka merupakan para pencetus UML, tool untuk penggambaran dan pemodelan sistem berbasis obyek. Jadi UP itu pemodelan dan framework proses sementara UML hasil dari prosesnya (masih dalam bentuk blue-print).

UP bersifat iteratif yang tiap iterasi terdiri dari tahapan-tahapan sebagai berikut, untuk menghafalnya disingkat IEKT:

  • Incepsi: penentuan tujuan-tujuan (life cycle objectives)
  • Elaborasi: pembuatan arsitektur sistem
  • Konstruksi: kapasitas dan kemampuan sistem dibentuk
  • Transisi: produk siap uji

Buku Arlow membahas keempat tahapan UP tersebut yang dikombinasikan dengan waterfall (requirements, analisis, disain, implementasi dan testing, disingkat RADIT). Bentuknya di tiap-tiap RADIT ada IEKT dari UP. Namun ada juga yang sebaliknya, di tiap IEKT-nya UP ada RADIT. Namun yang dibahas di buku adalah yang bentuk pertama. Sementara itu ketika melihat buku Larman yang cukup tebal, ternyata UP hanya sampai Elaborasi. Tidak ada konstruksi dan transisi. Belum sempat saya baca sampai sana, hanya saja ada elaborasi-1, elaborasi-2. Bukunya cukup tebal dengan bahasa Java sebagai ilustrasinya.

Sempat saya baca juga dalam satu kolom khusus dalam buku Larman, bahwa tidak ada peluru perak (istilahnya senjata pamungkas pembunuh vampir) dalam bentuk tools atau teknik perancangan perangkat lunak, dikatakan oleh Dr. Frederick Brookes (lihat buku Mythical Man-month). Jadi kalau ada yang bilang suatu teknik itu ampuh untuk segala bentuk sistem, dipastikan tidak mungkin alias gombal, baik yg mengatakan itu dosen ataupun sales CASE (alat bantu pembuatan software). Tetap saja jika pengguna tidak memahami konsep Object Oriented akan kesulitan menggunakan CASE jenis apapun (dibahas di buku: “Death by UML Fever” karangan Booch). Seperti biasa, tiap buku berbeda-beda pahamnya, seperti post yang lalu bahwa beberapa buku analisa disain/rekayasa perangkat lunak (Pressman, 2001; Sommerville, 2007) masih mentolerir menggunakan non-object programming dengan UML. Tidak ada salahnya juga menggunakan model lain yg bukan standar UML untuk penggambaran sistem berbasis objek asal bermaksud memperjelas pembacaan model (Fowler, 2004). Tetapi alangkah idealnya jika sistem yg dirancang dengan UML berbasis object. Selamat ber-UML.

Reference

Arlow, J., & Neustadt, I. (2005). UML 2 and the Unified Process (Second). United States: Pearson Education Limited.

Fowler, M. (2004). UML Distilled (3rd ed.). United States: Pearson.

Larman, C. (2005). Applying UML and Patterns (3rd ed.). United States: Pearson.

Pressman, R. S. (2001). Software Engineering – A Practitioner’s Approach (Fifth Edit). New York: McGraw Hill.

Sommerville, I. (2007). Software Engineering – Eighth Edition. London: Pearson Education Limited.

 

Iklan

Membaca Lebih dari Satu Buku

Buku teks atau buku ajar ada bermacam-macam. Ada yang berupa kumpulan penulis-penulis yang membahas topik tertentu (book chapter atau book section), ada pula yang hanya beberapa penulis membahas seluruh topik di suatu buku (buku teks). Sementara itu kebanyakan buku teks dibuat dalam bentuk kompilasi, yaitu kumpulan informasi yang berasal dari beragam sumber buku. Nah, kompilasi ini yang kerap saya jadikan patokan untuk menulis buku, karena lebih mudah. Ada juga jenis buku yang lain yaitu buku terjemahan, yang isinya hanya mengalih-bahasakan dari bahasa asing (biasanya bahasa Inggris) ke bahasa Indonesia tanpa menambah atau mengurangkan isinya. Hak cipta pun masih dipegang oleh buku sumber.

Bacalah

Membaca memang menjadi keharusan seorang pengajar karena informasi selalu berubah, apalagi dunia IT. Dalam kesehariannya terkadang ada debat antara satu dosen dengan dosen lainnya mengenai topik tertentu yang terkadang berimbas kepada siswa yang menjadi bimbingan tugas akhir, skripsi, atau pun tesis. Korban utamanya adalah si mahasiswa yang bingung harus mengikuti siapa? Pembimbing ataukah penguji. Untuk itu sebaiknya berpatokan kepada standar yang ada. Postingan kali ini saya mencoba membahasnya dalam dunia rekayasa perangkat lunak, khususnya UML.

Konflik Akademik

Sering saya menjumpai dosen-dosen yunior yang memang kebanyakan ahli dalam coding atau programming. Mungkin karena kesehariannya berasal dari instruktur lab yang naik pangkat jadi dosen. Terus terang ada manfaatnya karena mereka lebih mengetahui seluk beluk dan kesulitan yang dihadapi oleh mahasiswa yang kuliah IT. Masalah muncul ketika memasuki dunia akademis yang penuh dengan ilmu-ilmu baru yang selalu berkembang. Dosen yunior itu harus mempelajari perkembangan yang terjadi saat ini dan tidak kaku dan bersikukuh dengan bahasa pemrograman atau metode perancangan program yang dikuasainya. Lebih parah lagi, banyak juga yang merasa lebih jago dalam programming sehingga menganggap para dosen senior tidak tahu menahu prakteknya. Boleh saja beranggapan seperti itu, dan saya pun senang belajar dari mereka para dosen junior (sering disebut generasi milenial/generasi y). Sebenarnya malah menguntungkan para dosen-dosen senior.

Terus Membaca dan Belajar

Membaca buku-buku UML terkadang tidak ada habisnya. Muncul buku-buku baru yang terkadang membuat pusing jika kita tidak mampu memfilter-nya. Namun hanya membaca satu buku juga berbahaya karena membuat pembaca berfikiran sempit dan hanya memandang kebenaran dari satu sudut pandang saja, yaitu buku yang dia baca.

Misalnya pertama kali saya membaca satu buku yang khusus membahas UML, seluruh diagram dibahas. Namun di buku yang lain, dikatakan tidak semua developer menggunakan diagram UML, misalnya hanya diagram kelas, object, dan sequence. Tetapi buku yang lain yang berorientasi analisa disain menganggap diagram kelas dan use case lah yang penting, karena tidak semua stakeholder memahami pemrograman yang cocok dengan diagram sequence. Bahkan saya membaca satu buku khusus yang hanya membahas style yang baik dalam menggambar UML, misalnya ketika menggambar use case diagram, user di sebelah kiri dan admin di sebelah kanan dengan di tengah-tengahnya use case, unik juga. Tetapi bermanfaat juga sih, mengingat banyak siswa yang menggambar use case diagram acak adut, walaupun benar tetapi sulit dicerna.

Ribut terus berlanjut ketika ada yang membaca satu buku pemrograman berorientasi obyek yang menganggap UML harus diterapkan dalam pemrograman berbasis obyek saja. Pemrograman tanpa kelas tidak boleh menggunakan UML. Korbannya tidak lain adalah mahasiswa yang menjadi bimbingannya yang terkadang harus mengikuti outline yang disediakan kampus. Jika dosen itu membaca buku yang lain, dia mungkin akan berubah fikiran karena UML tidak harus untuk pemrograman berorientasi obyek, walaupun memang idealnya untuk berbasis object. Bahkan UML sendiri tidak melarang menggunakan diagram-diagram lainnya selama menambah kejelasan rancangan yang dibuatnya, terutama dalam komunikasi dengan user ataupun stakeholder.

Membaca Buku dengan Tema yang Berbeda

UML sangat berkaitan dengan tema-tema lainnya seperti rekayasa perangkat lunak dan analisa dan disain sistem. Beberapa buku rujukan utama software engineering uniknya sampai saat ini masih mengajarkan metode waterfall yang oleh kebanyakan pengembang saat ini banyak kelemahannya. Tetapi tetap saja 40% metode yang dipakai saat ini oleh pengembang menggunakan waterfall yang lebih mudah walaupun beresiko. Memang struktur yang jelas waterfall cocok dengan time frame perkuliahan. Namun, metode terkini yang bercirikan iterasi dan agile/extreem harus juga diperkenalkan.

Banyak hal-hal lain yang bisa kita pelajari dengan membaca lebih dari satu buku baik tema yang sejenis maupun tema lain yang memang saling berkaitan, misalnya pemrograman berorientasi obyek, rekayasa perangkat lunak, analisa dan disain sistem, pemrograman terstruktur, dan lain-lain. Untuk dunia akademik sendiri mau tidak mau harus menyampaikan seluruh informasi kepada siswa didik. Misalnya, untuk UML sebaiknya tidak hanya diagram-diagram yang sering digunakan di industri, melainkan wajib memberikan informasi secara total, walaupun terkadang membuat pusing baik mahasiswa maupun dosen (biasanya dilimpahkan pusingnya lewat tugas mahasiswa). Juga terkadang harus menghindari produk-produk dari vendor tertentu saja. Menggunakan software open source bisa jadi alternatif. Juga, antara dosen junior dan senior sebaiknya kompak dan saling bekerja sama sehingga bisa memberi ilmu dengan baik kepada siswa didik dan juga meningkatkan kinerja risetnya yang saat ini kita sudah berhasil mengalahkan Thailand dan sedikit lagi Singapura. Selanjutnya tinggal menghadapi Malaysia yang hampir dua kali jumlah publikasinya.

Sengaja saya tidak memberikan sitasi postingan ini karena memang untuk contoh kasus saja yang kemungkinan terjadi untuk tema perkuliahan yang lain. Mungkin pembaca, yang lebih senior dan expert, tidak sependapat dan bisa berbagi pengalaman. Semoga bermanfaat.

The Unified Process

Bagi mahasiswa komputer yang sudah atau sedang mengerjakan skripsi/tugas akhir pasti mengenal istilah SDLC, singkatan dari System Development Life Cycle, standar pembuatan perangkat lunak. Kemunculan metode ini diperuntukan untuk standar pembuatan perangkat lunak tanpa iterasi. Tentu saja memiliki kelemahan, tetapi cukup baik untuk standar, apalagi standar kelulusan mahasiswa. Mahasiswa mengajukan proposal, bimbingan, pembuatan kode program, sidang dan lulus dah.

SDLC biasanya digunakan untuk pembuatan software konvensional yang terstruktur dan belum berbasis objek. Sementara untuk perancangan software berbasis objek, salah satu standar yang terkenal adalah Unified Process (UP) yang menggunakan visualisasi diagram Unified Modeling Language (UML) dan saat ini menjadi momok menjengkelkan mahasiswa TI/SI karena diagramnya yang cukup banyak untuk diingat: use case, class, dan teman-temannya.

Mempelajari UML sendiri sangat sulit tanpa mempraktekan langsung lewat proses pembuatan perangkat lunak, sering diistilahkan dengan Software Development Process (SDP) atau Software Engineering Process (SEP), walaupun kebanyakan praktisi IT enggan disebut engineer dan lebih suka dibilang developer .. he he yakni kaum yang kerjanya mengkonversi kebutuhan (requirement) menjadi (software).

Di awal UP sering disebut Unified Software Development Process (USDP) tetapi karena mungkin kepanjangan oleh salah satu pencetus UML, Ivar Jacobson, cukup disebut UP. Implementasi pertamanya adalah dilakukan oleh Ericsson (dikenal dengan ericsson approach) di IBM atau dengan istilah terkenalnya Rational Unified Process (RUP).

Ok, cukup panjang membahas hal ini. Butuh satu buku khusus yang sedang saya kerjakan untuk coba diterbitkan, melanjutkan buku terdahulu. Jika ingin mempelajari lebih detil, baca buku khusus UML yang banyak bertebaran baik di toko buku maupun internet, terutama dengan bahasa pengantar bahasa Inggris. Jadi kalau kalian sulit memahami pembahasan UML dengan bahasa Indonesia bisa mendownload yang berbahasa Inggris yang lebih mudah (eh .. kebalik ya).

Using Open ModelSphere for Business Process Modeling

Hari/Tgl/M.Kul/Dosen: Sabtu/30-10-2010/Rahmadya Trias

Software berjenis Computer Aided Software Engineering (CASE) yang beredar di pasaran dimaksudkan untuk mempermudah pengguna dalam membuat suatu perangkat lunak. Beberapa di antaranya harus membeli lisensi (silverrun, powersim, rational rose dan sebagainya) sedangkan beberapa berlisensi open source yang gratis. Salah satunya adalah Open ModelSphare yang akan kita bahas berikut ini. Kita telah mengetahui bahwa jenis CASE ada yang high dan ada yang low. High hanya dimaksudkan untuk modeling sedangkan low bisa membantu programmer membuat coding, walaupun ada beberapa CASE yang sanggup mengkonversi dari modeling menjadi coding.

Setelah didonlot dari situsnya, cobalah untuk menginstalnya. Mari kita bareng-bareng menginstall software Open ModelSphare. Dobel klik pada installer software tersebut. Klik bahasa Inggris, lalu tekan OK hingga menampilkan “Welcome to Open ModelSphere Setup Wizard”. Klik dan sebaiknya baca GNU General Public License versi 3 berikut ini.


Klik “I accept the agreement” lalu tekan next beberapa kali. Setelah memilih letak lokasi instalasi maka akan terjadi proses penginstalan. Setelah FINIS akan muncul program yang telah kita instal berikut ini.


Kita akan diminta CASE jenis apa yang akan kita gunakan. Ada tiga pilihan antara lain Data Model, Business Process Model (BPM) dan UML.


Di sini akan kita coba Busines Process Model dengan model yang sudah lama dikenal antara lain Data Flow Diagram (DFD). Pilih jenis yang sesuai dengan kampus dimana Anda menyelesaikan skripsi. Untuk BSI/Nusa Mandiri biasanya menggunakan Ward-Mellor Notation.


In the link below I try to show you how to use Open ModelSphere in Modeling Business Process. I only show how to add context diagram, nol diagram and detail diagram in brief manner with Gane – Sarson Notation.