II TINJAUAN PUSTAKA
2.9 Alat Pemodelan Proses Bisnis
2.9.1 Business Process Modeling Notation (BPMN)
Business Process Modeling Notation (BPMN) yaitu suatu metodologi baru yang dikembangkan oleh Business Process Modeling Initiative sebagai suatu
standard baru pada pemodelan proses bisnis. BPMN juga sebagai alat desain pada sistem yang kompleks berbasis pesan (message-based). Tujuan utama dari BPMN adalah menyediakan notasi yang mudah digunakan dan bisa dimengerti oleh semua orang yang terlibat dalam bisnis, yang meliputi bisnis analis yang memodelkan proses bisnis, pengembang teknik yang membangun sistem yang melaksanakan bisnis, dan berbagai tingkatan manajemen yang harus dapat membaca dan memahami proses diagram dengan cepat sehingga dapat membantu dalam pengambilan keputusan (Rosmala & Falahah 2007).
Notasi BPMN yang baru juga dirancang untuk sifat sistem berbasis layanan web. BPMN dapat memodelkan pesan kompleks yang dilewatkan diantara pelaku bisnis atau bagian dari pelaku bisnis, kejadian yang menyebabkan pesan dilewatkan, dan aturan bisnis yang membatasi kejadian tersebut. BPMN memungkinkan proses bisnis dipetakan ke bahasa eksekusi bisnis berbasis XML seperti Business Process Execution Language for Web Service (BPEL4WS) dan
Business Process Modeling Language (BPML). Informasi pada bahasa eksekusi bisnis ini dapat divisualisasikan dengan notasi umum. Contoh penerapan notasi BPMN pada sistem berbasis layanan web adalah seperti pada Gambar 7.
Smart Sell Bidder Read Item Description Item of Interest Found
Contact Seller For Further Information
Read Sellers Feedback
Buy Item Now Deal with Seller? Contact Seller Review Seller’s Credentials No Yes No Bid Verify Bidder Credentials Close Auction End of Auction Item Sold Subject
to Payment Message Flow
Sequence Flow Pools
Salah satu kelebihan diagram BPMN adalah kemampuan memodelkan aliran pesan. Diagram bisnis proses tradisional mampu memodelkan aliran proses secara sekuensial, dari kejadian awal sampai hasil akhir. Dalam lingkungan e-commerce, tentunya, orang mengirim pesan kepada yang lain sebagai bagian dari aliran proses. Pesan ini menuntun pada penggambaran dan pemahaman proses
business to business dan business to customer (Rosmala & Falahah 2007).
2.9.2 IDEF
Model IDEF dibuat berdasarkan pada analisis struktur dan teknik perencanaan SADT yang telah disempurnakan oleh Integrated Computer Aided
Manufacturing (ICAM) tahun 1993. IDEF digunakan untuk mengembangkan
representasi grafis terstruktur dari sebuah sistem atau perusahaan (Syaiful & Permadi 2005). Model IDEF
1. Input yaitu sesuatu yang ditransformasikan oleh suatu aktivitas.
digambarkan dengan persegi panjang dan empat jenis arah panah di sekitar persegi panjang. Persegi panjang merupakan fungsi atau kegiatan yang dijelaskan dalam ungkapan verbal. Anak panah yang masuk dari sebelah kiri mewakili input, dari kiri ke kanan menggambarkan output, dari atas ke bawah menunjukan pengawasan (control), dan anak panah bawah adalah mekanisme (Mechanism) yang mengimplimentasikan suatu dukungan terhadap aktivitas (Jeong et al. 2009).
IDEF tersusun dari sebuah building blocks, yang terdiri dari 2 macam, yaitu aktifitas dan ICOM. Aktivitas adalah komponen suatu sistem yang menjalankan atau melakukan suatu tindakan. Sedangkan ICOM yaitu komponen suatu sistem yang digunakan oleh suatu aktivitas. ICOM terdiri dari :
2. Control yaitu sesuatu yang menentukan bagaimana suatu aktivitas terjadi tetapi tidak ditransformasikan.
3. Output yaitu sesuatu yang dihasilkan oleh aktivitas.
4. Mechanism yaitu antara lain orang, fasilitas, dan mesin yang menjalankan aktivitas (Syaiful & Permadi 2005).
Elemen dari IDEF yaitu suatu persegi panjang (untuk aktifitas kotak
membuat gambar dan gambar tersebut disusun untuk pembentukan model IDEF. Elemen-elemen tersebut dapat dilihat pada Gambar 8.
Function (Phrase starting with Verb)
Control (noun)
Input (noun) Output (noun)
Mechanism (noun)
Gambar 8 Notasi pada model IDEF (Jeong, et al. 2009).
Dalam model IDEF ada tiga elemen utama yaitu konsep, bahasa, dan pragmatik. Konsep dasar terdiri dari tujuh langkah yang harus diikuti yaitu (1) harus secara tepat menggambarkan kawasan masalah, yaitu suatu model grafik dari sistem harus dikembangkan sehingga elemen-elemen sistem tersebut serta interaksi-interaksinya dapat didefenisikan, didokumentasikan, dibahas, dan dianalisis secara efektif; (2) model harus memiliki suatu struktur atas bawah, modular dan hirarki. Model harus menggambarkan atas bawah sistem melalui pendefinisian elemen-elemen sistem modular yang berintegrasi untuk membentuk suatu hirarki; (3) model harus memisahkan fungsi dari rancangan sistem. Fungsi dasar dapat diubah dan rencana baru dapat dibuat untuk keperluan fungsi yang baru tersebut; (4) model harus mencerminkan objek atau tindakan-tindakan dan kasus yang terjadi, yaitu kaedah pemodelan harus mampu menggambarkan seluruh bentuk proses dan kasus-kasus yang terjadi; (5) bentuk model harus grafik. Bentuk model harus tercatat dalam grafik bukan matematik ataupun teks yang dapat berkomunikasi secara ringkas dan tepat yang mencerminkan fungsi-fungsi nyata serta proses; (6) model harus produk bagi kelompok kerja yang disiplin dan terkoordinasi serta sesuai untuk membangunkan sebuah model dan untuk mendapatkan persetujuan bersama; (7) model harus menampilkan seluruh informasi dalam teks (Rita et al. 2010).
Bahasa ditulis dalam bentuk simbol dan kotak, serta panah grafik dalam bentuk skema yang terstruktur guna menghasilkan model IDEF. Bahasa digunakan untuk menuangkan maksud para penganalisa, pembaca, dan pekerja. Pragmatik IDEF
2.9.3 Unified Modeling Language (UML)
menyiapkan cadangan bagi pengguna IDEF. Dalam banyak hal, pragmatik begitu dekat dengan konsep dan bahasa dimana hal tersebut tidak dapat dipisahkan, sehingga dengan pragmatik pengguna dapat menggunakan model IDEF.
Unified Modeling Language (UML) adalah alat bantu (tool) untuk
pemodelan sistem, “UML adalah bahasa yang dapat digunakan untuk spesifikasi, visualisasi, dan dokumentasi sistem object-oriented software pada fase pengembangan. UML merupakan unifikasi dari metode Booch, Object Modelling Technique (OMT), dan notasi objectory, serta ide-ide terbaik metodologi lainnya seperti terlihat pada Gambar 9. Dengan menyatukan notasi metode-metode objek oriented tersebut, UML merupakan standar dasar dalam bidang analisis dan desain berorientasi-objek. (Nurokhim & Rohmah 2002).
UML Rumbaugh Jacobson Meyer Pre-and Post-conditions Harel State charts Wirfs-Brock Responsibilities Fusion Operation descriptions, message numbering Embly Singleton classes Gamma et al. Frameworks, patterns, notes Shlaer-Mellor
Object life cycles
Odell
Classification
Booch
Gambar 9 Unifikasi berbagai metode pengembangan objek ke dalam UML (Quatrani 1999).
Menurut Dharwiyanti dan Wahono (2003) konsep dasar dari UML adalah mendefinisikan beberapa diagram. Diagram tersebut antara lain use case diagram,
class diagram, statechart diagram, acvtivity diagram, sequence diagram, collaboration diagram, component diagram, dan deployment diagram.
Use case diagram, yaitu menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Suatu use case merepresentasikan sebuah interaksi antara aktor dengan sistem. Use case merupakan sebuah pekerjaan tertentu, diantaranya adalah login ke sistem, dan membuatsebuah daftar belanja. Seorang/sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan sistem untuk melakukan pekerjaan-pekerjaan tertentu. Use case diagram dapat membantu untuk menyusun kebutuhan (requirement) sebuah sistem, mengkomunikasikan rancangan dengan klien, dan merancang test case untuk semua feature yang ada pada sistem.
Class diagram, yaitu suatu diagram yang menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan satu dan yang lainnya seperti
containment, pewarisan, asosiasi, dan lain-lain. Class mempunyai tiga area pokok yaitu nama class, atribut, dan 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.
Statechart diagram, menggambarkan transisi dan perubahan keadaan (dari satu state ke state yang lain) suatu objek pada sistem sebagai akibat dari stimuli
yang diterima. Pada umumnya statechart diagram menggambarkan class tertentu (satu class dapat memiliki lebih dari satu statechart diagram).
Activity diagram, menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang, bagaimana masing-masing alir berawal, decision yang mungkin terjadi, dan bagaimana aktivitas 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 perilaku 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.
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 atas 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 menjadi 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.
Collaboration diagram, merupakan salah satu cara untuk menggambarkan skenario dari sistem yang akan dirancang. Diagram ini juga menggambarkan interaksi antar objek seperti sequence diagram, tetapi lebih menekankan pada peran masing-masing objek dan bukan pada waktu penyampaian message. Setiap
message memiliki sequence number. Messages dari level yang sama memiliki prefiks yang sama.
Component diagram, menggambarkan struktur dan hubungan antar
komponen piranti lunak, termasuk ketergantungan (dependency) di antaranya. Komponen piranti 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. Umumnya komponen terbentuk dari beberapa class dan/atau package, tapi dapat juga dari komponen-komponen yang lebih kecil. Komponen dapat juga berupa interface, yaitu kumpulan layanan yang disediakan sebuah komponen untuk komponen lain.
Deployment diagram, menggambarkan detail bagaimana komponen didistribusikan dalam infrastruktur sistem (di mana komponen akan terletak pada mesin, server atau piranti keras apa). Kemudian menunjukkan bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisikal. Sebuah node adalah server, workstation, atau piranti keras lain yang digunakan untuk mendistribusikankomponen dalam lingkungan sebenarnya. Hubungan antar node (misalnya TCP/IP) dan requirement dapat juga didefinisikan dalam diagram ini.