6
LANDASAN TEORI
2.1. Service
Oriented
Architecture
Dalam bidang komputasi, istilah Service Oriented Architecture (SOA) mengekspresikan sebuah perspektif mengenai arsitektur software yang mendefinisikan penggunaan service untuk mendukung kebutuhkan pengguna software. Dalam sebuah lingkungan yang menggunakan SOA, sumber daya-sumber daya dalam sebuah area jaringan tersedia sebagai service yang independen yang dapat diakses tanpa pengetahuan tentang implementasi platform di belakangnya (Wikipedia).
Service Oriented Architecture (SOA) merupakan sebuah paradigma yang mengatur dan memanfaatkan kemampuan terdistribusi yang berada di bawah kontrol domain yang berbeda-beda (OasisSOArm06).
SOA Kontemporer merepresentasikan arsitektur yang terbuka, dapat diperluas (extendsible), mebentuk kesatuan (federated), dan dapat disusun (composable) yang mempromosikan orientasi service dan terdiri dari service-service yang otonom, dapat diukur kualitasnya (QoS-capable), datang dari beragam vendor, memungkinkan sistem yang beragam dapat bekerja sama (interoperable), dapat ditemukan (discoverable), dan dapat digunakan kembali secara potensial, yang diimplementasikan sebagai Web service (Thomas Erl).
Service Oriented Architecture (SOA) merupakan gaya perancangan yang memandu semua aspek pada proses pembuatan dan penggunaan business
service di seluruh lifecycle (mulai dari konsep hingga selesai), serta mendefinisikan dan mempersiapkan infrastruktur IT yang memungkinkan aplikasi-aplikasi yang berbeda dapat saling bertukar data dan berpartisipasi dalam proses bisnis tanpa dibatasi oleh sistem operasi atau bahasa pemrograman yang digunakan oleh aplikasi tersebut (Eric Newcomer and Greg Lomow).
Dari definisi di atas, dapat ditarik kesimpulan bahwa terdapat tiga konsep teknis utama pada SOA yaitu service, interoperability, dan loose coupling. SOA bertujuan untuk mengabstraksi dengan menitikberatkan pada aspek bisnis dari sebuah masalah dengan bagian fundamentalnya yang disebur service. Pada dasarnya, sebuah service adalah representasi IT dari fungsionalitas bisnis. Sasaran SOA adalah untuk menstrukturisasi sistem terdistribusi yang luas bedasarkan abstraksi fungsi dan business rule. Dengan sistem-sistem yang sifatnya heterogen, tujuan pertama SOA adalah memudahkan sistem-sistem tersebut untuk saling berhubungan. Hal inilah yang disebut interoperability yang tinggi. Untuk SOA, interoperability yang tinggi merupakan sebuah permulaan, bukan akhir, yang menjadi dasar untuk memulai implementasi fungsionalitas bisnis (service) yang menyebar ke seluruh sistem terdistribusi. Dengan begitu banyak sistem yang terlibat, menimbulkan kompleksitas yang tinggi, maka masalah sekecil apapun dapat menghentikan seluruh bisnis. Hal ini harus dapat dihindari sehingga dibutuhkan fleksibilitas, skalabilitas, dan fault tolerance. Kunci untuk mencapai tujuan ini adalah loose coupling yang merupakan konsep untuk
meminimalisir ketergantungan, sehingga sistem dapat terus berjalan meskipun ada bagian yang rusak, dan mencegah bottleneck.
Untuk berhasil membangun SOA, komponen penting yang harus diperhatikan adalah infrastruktur, arsitektur, dan proses (termasuk metaproses dan governance). Infrastruktur merupakan bagian teknis dari SOA yang memungkinkan tingkat interoperability yang tinggi. Infrastruktur yang dimaksud biasa disebut sebagai enterprise service bus (ESB). ESB berperan dalam pemanggilan service antara sistem-sistem yang heterogen dan bertanggung jawab dalam transformasi data, intelligent (routing), berhubungan dengan keamanan (security) dan kehandalan (reliability), manajemen service, pengawasan (monitoring), dan pencatatan (logging). Arsitektur sangat penting untuk memberi batasan pada SOA agar dapat menciptakan sistem yang berjalan dengan baik dan mudah di-maintain. Batasan-batasan ini dibuat berdasarkan situasi konkrit (kebutuhan dan konteks) supaya dapat menghasilkan arsitektur sistem yang sesuai. Sebuah sistem yang besar tidak hanya dikontrol oleh satu atau sekelompok kecil orang, oleh karena itu, proses-proses utama harus disiapkan terlebih dahulu, yaitu meliputi Business Process Modeling atau BPM (memecah proses bisnis menjadi aktivitas yang lebih kecil, dalam hal ini menjadi service), service lifecycle (mendefinisikan langkah-langkah apa saja yang harus dilakukan oleh service untuk menjadi nyata), Model-driven software development atau MDSD (proses untuk menghasilkan kode yang akan digunakan untuk berhubungan dengan service). Seluruh metaproses dari semua proses serta strategi SOA secara keseluruhan disebut governance.
Untuk industri dengan sepuluh karakteristik berikut, SOA tidak hanya siap untuk diimplementasikan, tetapi juga akan memberikan dampak yang besar bagi peningkatan efisiensi dan efektivitas perusahaan. Kesepuluh karakteristik tersebut meliputi, yang pertama, ekosistem bisnis yang luas dan kompleks, di mana perusahaan memiliki interaksi yang rumit dengan supplier atau vendor, customer, serta kerja sama dengan pihak-pihak lain seperti partner dan anak perusahaan. Yang kedua adalah perubahan industri yang cepat, di mana persaingan bisnis menuntut perubahan-perubahan seperti teknologi, produk, atau service baru, pembentukan kerja sama baru, serta banyaknya aktivitas merger dan akuisisi perusahaan. Yang ketiga adalah adanya business practice yang bersifat unik dan penting yang terkandung di dalam software perusahaan. Yang keempat adalah sistem computer yang fleksibel di mana software aplikasi ditulis dalam bentul modul-modul sehingga dapat dengan mudah beradaptasi dengn kondisi bisnis yang berubah. Yang kelima adalah kesiapan organisasi dalam menghadapi perubahan, di mana organisasi tidak terjebak dengan cara-cara lama dan tidak mau berubah. Yang keenam adalah tingkat kehandalan IT dalam mendukung bisnis perusahaan, di mana aplikasi berjalan di level performa yang diharapkan dan dibutuhkan. Yang ketujuh adalah sejauh mana teknologi mendukung standar (legal) perusahaan, karena terdapat hubungan langsung antara praktek legal perusahaan dengan Service Oriented Architecture. Yang kedelapan adalah adanya kontrol yang baik mengenai penempatan business rule di dalam software aplikasi sehingga jika terjadi perubahan infrstruktur teknologi, business rule tersebut dapat diidentifikasi secara terorganisir. Yang
kesembilan adalah data korporat yang fleksibel dan berkualitas, di mana perusahaan harus mulai melihat data sebagai service informasi yang dapat dengan mudah dipindahkan dan menaruh perhatian pada data yang berkualitas. Kemudian yang terakhir adalah kemampuan software untuk berkoneksi dengan entiti di luar organisasi, di mana pendekatan bisnis dan teknis perusahaan harus sejalan dengan tujuan bisnis serta tersosialisasi juga kepada partner dan supplier.
2.2. Service
Service secara ideal merupakan fungsi bisnis yang bersifat self-contained dan stateless yang menerima satu atau lebih request dan mengembalikan satu atau lebih response melalui interface standar dan well-defined. Service juga dapat melakukan unit kerja-unit kerja diskrit seperti mengedit dan memproses transaksi. Service tidak boleh tergantung pada status sebuah fungsi atau proses lainnya. Teknologi yang digunakan untuk menciptakan service, seperti bahasa pemrograman, tidak dijadikan bagian dari definisinya (Wikipedia).
SOA berfokus pada proses bisnis. Proses-proses ini dilakukan dalam aktivitas-akivitas yang berbeda pada sistem yang berbeda juga. Tujuan utama sebuah service adalah merepresentasikan langkah yang alami dari sebuah fungsionalitas bisnis.
Secara teknis, service merupakan sebuah interface untuk pesan-pesan (message) yang mengembalikan informasi dan atau mengubah status sebuah
entitas yang berkaitan di backend. Service juga memiliki atribut yang disebut kontrak yang merupakan spesifikasi lengkap dari sebuah service antara penyedia (provider) tertentu dan pengguna (consumer).
Service juga biasanya mempunyai atribut-atribut tambahan yang sering kali tidak semuanya dapat diaplikasikan oleh sebuah service. Atribut-atribut tambahan tersebut meliputi:
1. Self-Contained. Tujuan perancangan di dalam SOA memang menciptakan service yang self-contained, yaitu bersifat independen, otonom, dan dapat memenuhi kebutuhannya sendiri (autarkic). Namun beberapa ketergantungan masih terjadi, seperti penggunaan tipe data dasar yang dapat digunakan bersama-sama oleh semua service.
2. Coarse-Grained. Service merupakan abstraksi yang menyembunyikan detil implementasi dari konsumen. Tapi harga yang harus dibayar untuk abstraksi ini adalah waktu yang lebih lama. Oleh karena itu, lebih baik memiliki satu service yang mentransfer semua data yang diperlukan antara penyedia dan konsumen daripada memiliki banyak service yang mengolah jumlah data yang sama. Selain itu, rincian kasar (coarse granuality) membantu memisahkan data internal service penyedia dari antarmuka eksternal. Memiliki service untuk tiap akses ke service atribut (yaitu, service untuk masing-masing setter dan getter) akan menghasilkan objek terdistribusi yang meningkatkan ketergantungan antara sistem yang terdistribusi.
3. Visible/Discoverable. Untuk menggunakan suatu service, harus mengetahui bahwa service itu ada. Seringkali ada tempat umum dimana anda dapat mencari suatu service dan / atau yang menggambarkan semua rincian service. Service juga dapat ditemukan dari mulut ke mulut.
4. Stateless. Kadang-kadang, service didefinisikan sebagai stateless. Statelessness merupakan salah satu aspek service yang paling membingungkan karena beberapa state selalu terlibat. Pertanyaannya adalah dimana dan untuk berapa lama state ada, dan apakah itu merupakan state teknikal atau bisnis.
5. Idempotent. Jika anda menggunakan suatu service yang memodifikasi sesuatu, dan anda tidak mendapatkan respon konfirmasi, anda punya masalah. Apakah modifikasi terjadi dan anda hanya tidak mendapatkan hasil atau apakah service terputus sebelum modifikasi terjadi? Jika anda ragu, dan anda dapat mengirim kembali service tanpa masalah, service anda idempotent. Idempotency adalah kemampuan untuk melakukan kembali suatu operasi jika anda tidak yakin operasi tersebut selesai. Hal ini membuat hidup lebih mudah, sehingga memiliki service idempotent merupakan tujuan (jika harga tidak terlalu tinggi). Namun, ada kasus dimana tujuan ini sulit dicapai.
6. Reusable. Menghindari redudansi merupakan tujuan umum pengembangan software. Idealnya setiap fungsionalitas harus diimplementasikan hanya sekali. Satu kasus bisnis yang umum
untuk SOA adalah mengarah ke penggunaan kembali yang lebih baik karena semua sistem yang memerlukan fungsionalitas tertentu cukup memanggil service yang sama. Hal ini dimungkinkan, tetapi memiliki keterbatasan. Salah satu keterbatasannya berhubungan dengan performa, sehingga penggunaan kembali mungkin menjadi suatu tujuan tetapi bukan suatu aturan.
7. Composable. Service dapat menggunakan/memanggil service lainnya. Artinya fungsionalitas bisnis yang lebih luas dapat dibagi menjadi langkah-langkah yang lebih kecil yang juga adalah service. Inilah sebabnya mengapa suatu SOA selalu terdiri dari kategori “ service ”.
8. Technical. Sering kali, definisi dari SOA dapat juga dipanggil sebagai “service teknis” yang tidak harus menggambarkan fungsi dari bisnis. Sebagai contoh, jika kita memiliki sebuah infrastruktur SOA untuk layanan bisnis, kita dapat menggunakan infrastruktur ini untuk melakukan pertukaran data teknis. Dalam kasus ini, kita dapat berargumen bahwa kita menggunakan service teknis, atau kita langsung menggunakan infrastruktur SOA, dengan beranggapan service bisnis menjadi bagian dari tingkatan lain dari abstraction. Lakukan apa pun yang sesuai, tetapi harus diingat bahwa tujuan dari SOA adalah berkonsentrasi pada fungsionalitas bisnis.
9. Qos dan SLA. Seperti yang dikemukakan di awal, sebuah kontrak service harus terdiri dari segala sesuatu yang seorang pemanggil
seharusnya tahu untuk menggunakan service tersebut. Karena alasan ini, cepat atau lambat kita akan mulai untuk mendeteksi atribut-atribut yang tidak digunakan, termasuk di dalamnya atribut Qos dan SLA mengenai performa sewaktu runtime, ketahanan, dan lainnya. Bagaimana pun, SOA tetap akan bisa digunakan walaupun jika service tersebut tidak mempunyai atribut Qos dan SLA.
10.Kondisi Pre dan Post. Menurut ide dari “Design by Contract” (oleh Bertrand Meyer), kondisi sebelum dan sesudah implementasi menentukan tingkah laku semantik dari service. Kondisi sebelum menyatakan bahwa kewajiban sebuah service konsumen yang dapat digunakan bila service tersebut dipanggil. Kondisi sesudah menyatakan garansi atas output yang dihasilkan berhasil dengan sukses.
11.Vendor Diverse. SOA merupakan sebuah konsep untuk sistem besar yang terdistribusi, dan sistem ini biasanya bersifat heterogen. Meskipun, dapat menggunakan platform yang berbeda dan produk yang berbeda untuk mengimplementasikan service yang sesuai kebutuhan. Bagaimanapun, ini dapat disebut sebagai kelebihan dari SOA daripada atribut dari service.
12. Interoperable. Kemampuan untuk dapat dioperasikan oleh banyak sistem merupakan inti utama kebutuhan akan SOA. Dalam hal ini, service dapat dipanggil oleh siapa saja, yang telah didefinisikan terlebih dahulu.
2.3.
Service Oriented Modeling and Architecture
(SOMA)
SOMA merupakan sebuah metode software development life-cycle yang ditemukan dan dikembangkan oleh IBM untuk perancangan aplikasi berbasis SOA. SOMA mendefinisikan teknik-teknik kunci, serta peranan dalam sebuah proyek SOA dan work breakdown structure (WBS)-nya. WBS ini berisi tugas-tugas, produk input dan output untuk tugas-tugas tersebut, serta petunjuk yang dibutuhkan untuk secara mendalam melakukan analisi, perancangan, implementasi, juga pada saat deployment service, komponen, dan flow yang dibutuhkan dalam membangun solusi SOA yang kuat dan reusable. Metode SOMA terdiri dari tujuh fase utama seperti ditunjukkan pada gambar di bawah ini.
Jika gambar di atas menggambarkan pola kapabilitas dan sifat fractal alami dari metode SOMA, maka gambar di bawah ini akan mengilustrasikan alur proses yang biasanya terjadi dalam mengeksekusi metode SOMA.
Gambar 2.2 Life cycle SOMA
Ketujuh fase utama dalam metode SOMA akan dijabarkan sebagai berikut:
1. Business modeling and transformation. Pada fase ini, proses bisnis yang terjadi dimodelkan, disimulasikan, serta dioptimalisasi. Sebagai catatan, fase ini tidak harus dilakukan, namun sangat direkomendasikan untuk dilakukan.
2. Solution management. Metode SOMA memiliki isi yang standar untuk semua solusi SOA. Meskipun begitu, variabel-variabel yang digunakan
dalam metode SOMA dapat dibuat spesifik untuk tipe solusi tertentu. Variabel-variabel seperti task, work product, role, dan guidance yang akan didefinisikan secara spesifik untuk tipe solusi tertentu dan akan diekstrak sebagai template bagi metode ini disebut solution template.
3. identification. Fase ini terfokus pada upaya mengidentifikasi tiga konstruksi fundamental yang membangun SOA, yaitu service, component, dan flow. Untuk menemukan solusi service yang lengkap, maka berbagai teknik identifikasi service harus digunakan. Tiga teknis utama yang biasanya digunakan adalah goal-service modeling (GSM), dekomposisi domain, dan analisis existing asset.
4. specification. Pada tahap ini dilakukan perancangan SOA baik secara garis besar (high-level design) maupun bagian detailnya yang signifikan. Model service yang telah diidentifikasi pada tahap sebelumnya, sekarang diuraikan lebih jauh berdasarkan service dependencies, flow dan komposisi, event, rule dan policy, operasi, message, kebutuhan nonfungsional, serta state management decision.
5. Realization. Pada fase ini prototype selesai dibuat untuk menguji arsitektur yang telah dibuat serta mencari kemungkinan adanya faktor-faktor resiko yang muncul. Proses seleksi dan instansiasi pola yang digunakan akan menjadi dasar sebuah deployment SOA yang berhasil dan bersifat repeatable. Kategori-kategori pola yang berkoresponden akan dipilih untuk menangani masalah-masalah domain seperti pola information service untuk realisasi
informasi, pola ESB untuk skenario integrasi, serta pola rule untuk realisasi rule.
6. Implementation. Pada fase ini, service, fungsional, dan komponen teknikalnya dikonstruksikan, dibuat, dan dikumpulkan untuk merealisasikan service, komponen, dan flow. Selain itu dilakukan juga tes terhadap unit, intergrasi, dan sistem.
7. Deployment, Monitoring, and Management. Fase ini terfokus pada bagaimana mengemas, melengkapi, dan mengeksekusi user-acceptance testing, serta bagaimana melakukan proses deployment service pada lingkungan produksi yang sebenarnya (production environment). Monitoring akan dilakukan terhadap proses bisnis dan performa di production environment.
2.4. Business
Process
Modeling
Service merupakan bagian dari proses bisnis. Oleh karena itu fokus harus ditujukan pada proses bisnis terlebih dahulu sebelum merealisasikan service. Secara garis besar, proses implementasi proses bisnis baru dengan SOA dapat dilakukan dengan dekomposisi top-down yaitu dengan menentukan langkah-langkah proses mana saja yang manual dan yang harus didukung oleh IT, kemudian membagi-bagi proses menjadi bagian yang lebih kecil berdasarkan kapan mereka berjalan dan sistem mana yang bertanggung jawab terhadap mereka, serta memecah aspek-aspek yang kompleks menjadi lagkah-langkah yang dapat dikelola.
Gambar 2.3 Proses, subproses, dan aktivitas menjadi service
Pengembangan secara iterative merupakan satu-satunya cara untuk merealisasikan system yang kompleks dalam jangka waktu yang dapat diterima. Dengan pendekatan ini, pengerjaan dimulai dari bagian kecil dari seluruh sistem untuk direalisasikan ke dalam solusi yang sesuai. Kemudian baru dikembangkan dengan menambahkan fungsi baru, merancang kembali solusi yang sudah ada, dan memfaktorisasi perilaku saat ini. Sebagai hasilnya, sistem akan menjadi lebih baik dan lebih baik lagi, secara bertahap memenuhi kebutuhan dengan cara yang tepat.
Selain pendekatan iteratif, terdapat beberapa cara lain untuk menemukan kebutuhan akan service baru, di antaranya adalah:
o Process Decomposition, yaitu dengan membagi-bagi proses menjadi bagian (langkah-langkah atau aktivitas) yang lebih kecil atau sederhana untuk mengidentifikasi service yang dibutuhkan.
o Domain Decomposition, yaitu dengan menganalisa domain sehingga akan diketahui service-service apa saja yang perlu disediakan.
o Business Event Tracing, yaitu dengan menganalisa dan mengawasi apa yang memicu fungsi bisnis sehingga dapat didefinisikan service yang sesuai.
o Bottom-up, yaitu dengan memeriksa sistem yang sudah ada, dalam hal ini memeriksa backend, untuk mengidentifikasi service terenkapsulasi yang dibutuhkan.
Business Process Management memungkinkan seorang analis bisnis untuk menyelaraskan sistem IT dengan tujuan strategis dengan menciptakan proses bisnis perusahaan yang bersifat well-defined, memantau performanya, dan melakukan optimisasi untuk mencapai efisiensi operasional yang lebih besar. Setiap proses bisnis dimodelkan sebagai tugas-tugas pengolahan individual.
Business Process Modeling merupakan teknik untuk memformalkan langkah-langkah dari sebuah proses bisnis, serta orang-orang, organisasi, dan sistem yang bertanggung jawab terhadap langkah-langkah tersebut dan data yang terkait dengan setiap langkah. BPM sangat cocok digabungkan dengan SOA karena menyediakan bahasa yang dapat memanfaatkan business service yang sifatnya reusable.
Sebuah Business Process Model dasar terdiri dari beberapa komponen utama:
o Process Step adalah persegi panjang yang mendefinisikan apa yang dilakukan. Nama process step harus merepresentasikan apa yang sedang dilakukan dari perspektif bisnis.
o Gateway membagi dan mengombinasikan alur proses, baik dengan mengombinasikan alur yang paralel maupun dengan membagi alur berdasarkan beberapa kriteria pengambilan keputusan.
o Document merepresentasikan kumpulan data bisnis yang saling berpadu seperti Pemesanan atau Pembayaran.
o Process Flow menghubungkan Process Step dan Gateway untuk menunjukkan dan menekankan urutan tertentu dari proses-proses. o Data Flow menunjukkan bagaimana proses memproduksi dan atau
mengkonsumsi data tertentu.
o Lanes, berlabelkan nama dari Actor, mengatur langkah-langkah dengan menentukan siapa mengerjakan apa.
Gambar 2.4 Business process model
2.5. Value
Chain
Value Chain terbagi dalam dua kumpulan kegiatan utama. Aktivitas di bagian bawah disebut aktivitas pendukung, misalnya bagian HRD dan Keuangan yang harus dimiliki perusahaan untuk mendukung operasional perusahaan, tetapi tidak menambah nilai kepada produk atau jasa yang dijual. Sementara bagian atas diagram mendeskripsikan aktivitas primer, yaitu bisnis utama yang menjadi tulang punggung perusahaan, yang terdiri dari beberapa aktivitas-aktivitas yang menambahkan nilai ke dalam value chain.
Value Chain bermanfaat untuk mengidentifikasi area-area fungsional yang berbeda di dalam perusahaan dan memusatkan perhatian pada bagian
terpenting. Hal ini merupakan mekanisme yang baik untuk menonjolkan tujuan dan sasaran yang ingin dicapai perusahaan serta untuk mulai mengidentifikasi area-area service yang dibutuhkan. Pada umumnya, setiap aktivitas utama dalam value chain akan memiliki satu atau lebih sekumpulan service yang berhubungan dengannya. Hal ini merupakan langkah pertama dalam pembuatan service inventory.
Gambar 2.5 Extended value chain
2.6. Business
Contex
Operasi bisnis baik di dalam maupun di luar perusahaan dibentuk oleh interaksi dan pertukaran informasi antara banyak pihak. Untuk mendeskripsikan semua bentuk interaksi maka digunakanlah Business Contex Daigram. Contex Diagram mengandung bagian utama, yang direpresentasikan oleh persegi panjang, dan pesan yang dipertukarkan direpresentasikan oleh tanda panah. Contex Diagram dibuat dengan menjalankan semua jenis iteraksi
yang berbeda yang dibutuhkan dari awal hingga akhir. Contex Diagram dibuat dengan menggunakan beberapa elemen berikut:
o Actor, yang merupakan bagian utama dalam interaksi (persegi panjang). Biasanya Actor mewakili orang, organisasi, atau sistem. o Message, merupakan informasi yang dipertukarkan antar Actor
(tanda panah). Biasanya Message mewakili dokumen, paket, komunikasi elektronik, dan sejenisnya.
o Subject, merupakan perkara bisnis yang ingin disampaikan oleh Message. Subject tidak secara eksplisit digambarkan dalam diagram, namun akan terlihat melalui interaksi dan pesan. Biasanya Subject mewakili produk dan jasa.
Gambar 2.6 Business contex diagram
Penggunaan Business Contex Diagram akan menyediakan mekanisme komunikasi yang terbaik dengan bisnis itu sendiri karena penggambaran ini terfokus pada konsep bisnis sehingga sifatnya tidak teknis dan mudah
dimengerti secara intuitif. Proses pembuatannya akan menghantar pada pemahaman umum mengenai tiap-tiap bagian dari sebuah bisnis serta langkah awalnya langsung mengidentifikasi fungsi-fungsi dan data yang diperlukan untuk perancangan service.
2.7. Use
Case
Upaya perancangan software sering kali dimulai dengan mengidentifikasi Use Case, yaitu diagram yang menampilkan kapabilitas dari sebuah sistem yang harus disediakan bagi user. Figur orang (stick figure) merepresentasikan Actor, yaitu entitas yang dapat memprakarsai dan berpartisipasi dalam Use Case. Sementara bentuk oval merepresentasikan use case di mana Actor dapat berpartisipasi di dalamnya.
Actor merepresentasikan interaksi atau interface pada sistem dengan user dan atau sistem yang lain dan terlibat dalam pertukaran informasi atau nilai yang terjadi di dalam Use Case. Actor juga diidentifikasi sebagai peran atau area tanggung jawab yang dilakukan di dalam Use Case. Sementara kategori Actor sekunder, yang merepresentasikan pelaku bisnis, tidak selalu muncul dalam diagram Use Case, tetapi akan muncul di dalam Scenario Diagram.
External Actor merupakan Actor di dalam diagram Use Case yang merepresentasikan interface eksternal terhadap fungsionalitas sistem. Sedangkan Primary Business Worker adalah sistem internal yang bertanggung jawab untuk melakukan sebuah fungsi dalam Use Case. Sebuah Business
Worker berkolaborasi dengan Business Worker lainnya dan memanipulasi entitas bisnis untuk menjalankan tanggung jawabnya. Primary Business Worker biasanya diidentifikasi sebagai Actor sekunder di dalam Use Case.
Gambar 2.7 Use case
Untuk setiap Use Case, dibuat scenario Use Case untuk mendefinisikan urutan langkah-langkah yang terjadi di dalam Use Case tersebut. Menentukan level yang tepat bagi Use Case merupakan tantangan bagi banyak pemodel. Use Case tidak boleh terlalu kecil sehingga skenarionya hanya terdiri dari satu aktivitas. Namun, Use Case juga tidak boleh terlalu besar sehingga permodelan prosesnya menjadi sangat luas dan kompleks yang mengakibatkan tujuan menjadi tidak jelas.
Use Case mendefinisikan scenario utama maupun scenario-skenario alternatif yang mungkin terjadi. Scenario alternatif mendeskripsikan cara pemrosesan yang berbeda yang disebabkan oleh situasi yang tidak biasa yang terjadi di tengah alur Use Case. Pendekatan yang dapat dilakukan adalah
dengan menggambar BPM tunggal yang menggunakan gateway (gerbang pembuat keputusan) untuk mengilustrasikan semua situasi yang mungkin terjadi dan menyoroti sebuah alur dengan mewarnai jalurnya. Pendekatan warna ini sangat bermanfaat untuk dapat mempertimbangkan kembali rancangan yang telah dibuat karena semua langkah-langkah dikonsolidasikan dalam diagram tunggal sehingga memastikan konsistensi yang lebih besar dan penggunaan kembali langkah-langkah yang serupa di seluruh scenario yang berbeda, namun agak sulit untuk di-maintain dan tetap menampilkan versi terbaru.
Gambar 2.8 Use case scenario
2.8. Documents
Dokumen dalam hal ini berarti informasi yang dilewatkan antara langkah-langkah dalam sebuah proses. Mereka merepresentasikan suatu kesatuan data bisnis seperti Order atau Payment, di mana data ini harus di-share (dan memiliki definisi semantik umum) ke seluruh langkah-langkah pada proses. Dokumen digunakan sebagai input dan output untuk langkah-langkah di proses bisnis.
Identifikasi dokumen merupakan aspek yang penting untuk menghubungkan BPM ke SOA. Dokumen-dokumen yang telah diidentifikasi dalam permodelan proses digunakan untuk menentukan dokumen yang dilewatkan dalam service interface. Dalam proses bisnis, dokumen yang dimaksud harus berkaitan dengan dokumen yang sebenarnya (real-world document) kapanpun mereka ada. Dalam service, skema dokumen harus berdasarkan model informasi semantik. Jadi identifikasi dokumen selama perancangan proses bisnis harus dikoordinasikan dengan model informasi.
Dokumen sering dilewatkan melalui beberapa langkah dalam sebuah proses. Pada diagram, status dokumen ditunjukkan di dalam tanda kurung (brackets) di sebelah nama dokumen. Hal ini merupakan praktek umum pada perancangan dokumen dalam proses bisnis, dan sangat tepat saat merefleksikan apa yang terjadi pada dokumen yang sebenarnya.
Setiap langkah pada proses diimplementasikan oleh service, yang menerima dokumen pada interface-nya, dan mentransformasi informasi semantik ke dalam data domain internal dari service tersebut. Implementasi service bertanggung jawab untuk mengubah status entitas bisnis dan merefleksikan status yang baru di dokumen output. Dokumen merepresentasikan perubahan status, sementara service mengimplementasikan perubahan status tersebut.
Langkah-langkah dalam Business Process Model harus merepresentasikan aktivitas bisnis tunggal. Business Process Model yang baik harus mendefinisikan elemen-elemen yang independen dari implementasi atau teknologi tertentu.
2.9. Conceptual
Architecture
Conceptual Architecture merupakan gambaran ikhtisar arsitektur secara informal yang bertujuan untuk menyampaikan konsep proyek secara keseluruhan, tujuan, dan pendekatan, batasan, dan interaksi yang akan digunakan kepada nontechnical audience. Di bagian kiri digambarkan front end di mana sistem yang baru akan berinteraksi dengan mereka. Sementara di
bagian kanan digambarkan back end yang merupakan sistem eksternal dan pihak legal di mana sistem baru harus berinteraksi dengan mereka juga. Semuanya ini menggambarkan batasan interaksi dari sistem baru. Bagian tengah Conceptual Architecture merupakan struktur tingkat tinggi atau struktur secara garis besar dari sistem yang baru. Sistem ACME terstruktur dalam 4 area utama:
o Enterprise Business Process, merupakan proses bisnis inti yang menambah nilai kepada produk atau jasa yang dijual. Proses-proses di sini berinteraksi secara langsung dengan komponen di front end dan berhubungan dengan Use Case bisnis serta proses ke depannya yang bertujuan untuk menunjukkan arah dan pendekatan yang potensial di masa depan.
o Common Service, merupakan kelompok service yang melayani semua bidang bisnis.
o Line-of-business Service, merupakan service-service yang spesifik untuk jalur bisnis tertentu.
o Foundation Service, merupakan service-service yang mendukung konstruksi sistem secara keseluruhan, tetapi tidak mengimplementasikan fungsionalitas bisnis.
Gambar 2.10 Conceptual architecture
2.10.
System Analysis and Design
System Life Cycle merupakan sebuah proses organisasional untuk membangun dan memelihara sistem. Proses ini membantu dalam pembuatan rencana proyek pembangunan system, karena memberikan daftar proses dan sub-proses yang dibutuhkan secara garis besar untuk membangun sebuah sistem. System Development Life Cycle memiliki arti sebuah kombinasi atas aktivitas-aktivitas yang bervariasi. Dalam terminologi System Analysis and Design, System Development Life Cycle juga berarti Software Development Life Cycle. Berikut ini merupakan fase-fase pada System Development Life Cycle:
o Preliminary Study merupakan tahap pertama dari system development life cycle di mana dilakukan investigasi singkat mengenai sistem yang tengah dibahas dan memberikan gambaran yang jelas tentang seperti apa sebetulnya sistem fisiknya. Pada prakteknya, penelitian sistem di bagian awal ini ditujukan untuk
mempersiapkan sebuah ’System Proposal’ yang berisi definisi masalah, tujuan penelitian, Term of Reference yang digunakan dalam penelitian, batasan masalah, manfaat yang diharapkan, dll berdasarkan kebutuhan user. System proposal dipersiapkan oleh system analyst untuk diberikan kepada manajemen. Manajemen yang kemudian bisa menerima proposal tersebut sehingga dapat dilanjutkan ke tahapan berikutnya. Manajemen juga dapat menolak proposal yang diajukan atau meminta dibuatkan beberapa perubahan dalam proposal tersebut. Secara garis besar, fase system study memiliki tiga bagian utama, yaitu: identifikasi masalah dan inisiasi proyek, analisis latar belakang, serta penemuan (system proposal).
o Feasibility Study merupakan tahap yang dilakukan jika system proposal telah disetujui oleh manajemen, di mana dilakukan pemeriksaan terhadap kelayakan dari sebuah sistem. Studi kelayakan pada dasarnya merupakan pengujian terhadap sistem yang diajukan berdasarkan kemampuan kerjanya, apakah sudah sesuai dengan kebutuhan user, efektivitas dalam penggunaan sumber daya, dan tentu saja efektivitas biayanya. Hal-hal tersebut dikategorikan sebagai teknikal, operasional, ekonomi, dan schedule feasibility. Tujuan utama dari studi kelayakan bukan untuk menyelesaikan masalah, melainkan untuk mendefinisikan ruang lingkup. Dalam proses studi kelayakan, biaya dan manfaat diperkirakan secara akurat untuk menentukan Return on Investment
(ROI), serta mendefinisikan sumber daya yang dibutuhkan untuk melengkapi detil investigasi. Hasilnya akan berupa laporan kelayakan yang akan diberikan kepada manajemen. Laporan ini dapat diterima, diterima dengan perbaikan, ataupun ditolak.
o Detailed System Study. Detil investigasi sistem disesuaikan dengan tujuan dari sistem yang diajukan. Hal ini mencakup studi yang mendetail terhadap operasi-operasi yang bervariasi yang dilakukan oleh sebuah sistem dan hubungannya dengan sistem-sistem di dalam maupun di luarnya. Selama proses ini, data dikumpulkan melalui dokumentasi yang tersedia, pengambilan keputusan, serta transaksi yang ditangani oleh sistem yang sedang berjalan. Wawancara, observasi lapangan, serta kuesioner adalah alat bantu yang digunakan dalam studi sistem yang mendetail.
o System Analysis. Sistem analisis merupakan sebuah proses yang mengumpulkan data faktual, mengerti proses-proses yang terlibat, mengidentifikasi masalah, dan memberikan saran kelayakan untuk meningkatkan fungsi sistem. Hal ini mencakup mempelajari proses bisnis, mengumpulkan data operasional, mengerti aliran informasi, menemukan bottleneck, dan memberikan solusi yang dapat mengatasi kelemahan sistem demi tercapainya tujuan organisasi. Analisis sistem juga termasuk memecah-mecah proses yang kompleks menjadi bagian-bagian yang lebih kecil termasuk sistem secara keseluruhan, identifikasi penyimpanan data, serta proses manual. Tujuan utama analisis sistem adalah untuk menemukan
jawaban mengenai proses bisnis yang meliputi: apa yang sedang dilakukan, bagaimana sesuatu dilakukan, siapa yang melakukan, kapan dilakukan, kenapa dilakukan, dan bagaimana dapat ditingkatkan? Tujuannya adalah untuk melahirkan sistem baru yang efisien yang dapat memuaskan kebutuhan user saat ini dan dapat dikembangkan di masa yang akan datang. Hasil dari proses ini adalah rancangan sistem secara logika. Analisis sistem merupakan proses iteratif yang terus berkelanjutan sampai didapat solusi yang diinginkan dan dapat diterima.
o System Design. Berdasarkan user requirement dan detail analisis terhadap sistem saat ini, dimulailah proses perancangan sistem yang baru. Fase ini merupakan fase yang paling krusial dalam pembangunan sebuah sistem. Perancangan sistem secara logika yang muncul sebagai hasil dari analisis sistem dikonversi ke dalam perancangan sistem secara fisik. Pada rancangan garis besar, fitur-fitur dari sistem yang baru dispesifikasi. Biaya untuk mengimplementasikan fitur-fitur ini dan manfaat yang akan didapatkan diperkirakan. Jika proyek masih dipandang layak untuk dilajutkan, maka proses perancangan dilanjutkan ke tahap terstruktur/detail. Pada rancangan terstruktur, rancangan sistem ditampilkan dalam bentuk yang lebih terstruktur. Rancangan terstruktur merupakan blue print dari solusi sistem komputer untuk masalah yang diberikan yang memiliki komponen-komponen serta hubungan antar komponen yang sama dengan masalah yang
F Coding, sebenarny processin perancang software Fase-fase sel Testing, Imp Gambar 2.1 ya. Input, ou ng specificat gan, bahasa di mana sist lanjutnya da plementation 11 Fase-fase p utput, databa tion digamba a pemrogram
tem yang bar
alam System n, dan Maint
pada System D
ase, form, co arkan secara man dan pla
ru akan berja m Developm tenance. Development L odification sc a mendetail. atform hard alan juga dit
ment Life Cy Life Cycle cheme, dan Pada tahap dware serta tentukan. ycle adalah
