1.1. Paradigma Dan Prinsip Berorientasi Objek.

Pada awal mula rekayasa perangkat lunak dibuat pemrograman terstruktur menjadi mainstream. Para programmer mulai mengembangkan blok-blok kode yang baku untuk melaksanakan operasi seperti misalnya operasi pembuatan laporan, pencetakan, dan operasi lainnya yang kemudian diduplikasikan dan disisipkan di dalam program-program aplikasi. Dengan demikian dapat mengurangi waktu pengembangan aplikasi yang baru, hal ini akan akan menjadi rumit apabila perubahan harus dilakukan pada blok kode program. Sebab pengembang harus lebih dulu membuat perubahan dimana kode tersebut nantinya akan di gunakan kembali pada aplikasi yang berbeda.

Pemrograman terstruktur (menggunakan bahasa pemrograman terstruktur seperti bahasa pascal, basic, foxpro dan lainya) memberikan beberapa tantangan dalam pengembangan perangkat lunak kedepan, dan tantangan tersebut dijawab dengan pemrograman berorientasi objek (bahasa C++, Java, Visual Basic) untuk memecahkan permasalahan yang dihadapi.

Pada Object Oriented Programming, pengembang aplikasi membuat blok-blok kode yang disebut dengan Class atau Object dimana Class dan Objek ini digunakan oleh berbagai macam program aplikasi untuk kebutuhan yang berbeda. Jika salah satu Class atau Object dimodifikasi maka pengembang hanya membuat satu perubahan saja pada Class atau Object tersebut sehingga instan class akan mengikuti perubahan yang terjadi. Didalam paradigma berorientasi objek pengembang mempunyai sudut pandang yang berbeda terhadap applikasi. Dengan pendekatan berorientasi objek, aplikasi dibagi menjadi bagian-bagian kecil object (berupa Class) yang tidak terikat satu sama lain. Selanjutnya aplikasi dibangun dengan menyatukan object-object kecil ini menjadi aplikasi yang lengkap dan siap untuk digunakan. Sebagai contoh object dalam pemrograman berorientasi objek adalah kontrol server seperti Textbox, Combobox, Button dan kontrol-kontrol lainya, atau programmer dapat membuat definisi class tersendiri secara khusus.

Pada pemrograman terstruktur untuk merancang sebuah form dengan kontrol listbox, textbox dan button di dalamnya, programmer harus menuliskan baris kode yang panjang untuk membuat tampilan form dan masing-masing kontrol tersebut kedalam struktur kode program yang terdiri dapat terdiri dari record, prosedur dan fungsi. Contoh yang lainya apabila programmer ingin menampilkan tombol Ok dan Cancel yang dapat menerima masukan melalui event klick mouse, maka programer menulis kode program untuk menampilkan bentuk tombol OK dan Cancel tersebut dengan menggunakan unit grafis, kemudian menuliskan kode untuk kejadian (event) klik mouse pada tombol tersebut untuk menjalankan fungsi tertentu didalam aplikasi.

Salah satu keuntungan pendekatan berorientasi objek adalah kemampuan untuk membangun komponen secara seketika dan langsung dapat digunakan secara berulang-ulang. Misalnya dengan menambahkan kontrol combobox didalam form dan mengatur nilai properti dari combobox tersebut sesuai dengan kebutuhan dalam aplikasi. Sehingga memanfaatkan form yang mengandung object yang sama pada kebutuhan lainya sangat dimungkinkan, hanya dengan merubah nilai properti dari objek tersebut dan kode program.

Lalu bagaimana paradigma berorientasi objek ini berbeda dengan pendekatan terstruktur dalam pengembangan perangkat lunak ?.

Pada pendekatan terstruktur, aktivitas-aktivitas yang dilakukan oleh tim pengembang perangkat lunak adalah :

1. Bertanya kepada user, informasi apa saja yang mereka butuhkan.

2. Mendesain basisdata untuk menyimpan informasi tersebut.

3. Mendesain tampilan layar untuk memasukkan informasi yang akan disimpan didalam basis data dan pembuatan laporan yang dapat dicetak.

Dari aktivitas diatas dapat disimpulkan bahwa pada pendekatan terstruktur lebih terpusat pada informasi, bukan pada perilaku sistem, maka pendekatan semacam ini disebut dengan pendekatan data-centric. Pendekatan data-centric sangat sesuai untuk desain program untuk penyimpanan informasi dalam basisdata dan pengolahannya. Namun akan muncul permasalahan jika digunakan untuk mendesain aplikasi bisnis, dimana perubahan aturan bisnis dan perilaku suatu sistem tidak mudah untuk diterapkan.

Pendekatan berorientasi objek telah dikembangkan untuk menjawab permasalahan tersebut, pendekatan berorientasi objek tidak hanya pada informasi namun juga melibatkan perilaku sistem yang satu sama lain berbeda. Maka diterapkanlah prinsip-prinsip berorientasi objek yaitu encapsulation, polymorphisme dan inheritance.

1.2. Prinsip-prinsip Berorientasi Objek (Object Oriented).

a. Encapsulation.

Pada konsep object oriented, kombinasi antara informasi dengan perilaku yang spesifik yang selanjutnya dibungkus (disatukan) menjadi suatu object disebut dengan encapsulation. Definisi object secara umum disebut dengan Class. Cara lain untuk melihat sebuah encapsulation adalah dengan membagi aplikasi ke dalam bagian-bagian kecil dari fungsi yang memiliki keterkaitan.

Sebagai contoh, sebuah informasi yang berkenaan dengan suatu rekening bank (sebagai nama object), memiliki informasi nomor rekening, saldo, nama nasabah, alamat jenis rekening, suku bunga, dan tanggal buka rekening (sebagai atribut objek). Perilaku dari sebuah rekening bank misalnya membuka dan menutup tabungan, menarik uang, dan perubahan alamat nasabah (sebagai methoda, operasi objek rekening bank).

Selanjutnya object, atribut dan perilaku disatukan dan dibungkus (encapsulation) bersama-sama ke dalam suatu obyek dengan nama rekening. Dengan demikian terbentuklah sebuah Class dengan nama Rekening dengan atribut dan methodanya.

Rekening Nama Class

Nomor rekening

Nama nasabah

Alamat nasabah

Jenis rekening

Suku bunga

Tanggal pembukaan

Saldo

Atribut-atribut Class

Membuka tabungan

Menutup tabungan Menarik uang

Perubahan alamat nasabah

Methoda Class

Gambar 1.1. Bagian=bagian Class

Sehingga apabila terjadi perubahan pada sistem perbankan yang berhubungan dengan rekening dapat dengan mudah diterapkan kedalam objek rekening tersebut. Keuntungan lain dari encapsulation adalah membatasi efek perubahan sistem secara keseluruhan. encapsulation dapat dianalogikan sebagai suatu sistem air di danau, dan kebutuhan akan suatu perubahan sebagai batu karang yang besar, apabila batu karang tersebut di jatuhkan kedalam air danau maka akan menyebabkan :

1. Munculnya riak air ke segala arah sampai ke tepi danau dan terjadi tumbukan antar riak air.

2. Batu karang tersebut membuat efek yang sangat besar pada sistem air di danau.

Apabila danau tersebut kita sekat dengan sebuah penghalang pada beberapa bagian maka efek riak oleh jatuhnya batu karang tersebut dapat kita batasi. Perhatikan ilustrasi enkapsulasi dibawah ini :

Gambar 1.2 Analogi Encapsulation.

Gambar 1.3. Encapsulation Model Sistem ATM pada Bank.

b. Inheritance

Dalam konsep object oriented, inheritance adalah suatu mekanisme yang membolehkan kita membuat atau menciptakan suatu objek baru (derived object/class) dari objek dasarnya (base object/class) disebut juga konsep parent-child. Objek anak (childI) mewarisi sifat dan kualitas yang dimiliki dari objek orangtua (parent). Contoh inheritance pada dunia nyata adalah makhluk hidup berjenis mamalia, diamana terdapat banyak sekali jenis makhluk hidup mamalia yang masing-masing memiliki karakteristik yang unik satu sama lain seperti pada ilustrasi berikut ini. Bahwa object mamalia memiliki turunan objek seperti kucing, anjing, dan paus.

Gambar 1.4. Inheritance Objek Hewan Mamalia

Dengan inheritance maka akan mengurangi pemeliharaan, misalnya jika terjadi suatu perubahan pola perilaku, ciri-ciri atau bentuk pada makhluk hidup mamalia, maka secara otomatis objek anak akan menerima warisan perubahan itu dengan spesifikasi yang sama dengan objek parentnya. Contoh lain pada aplikasi komputer yaitu Inheritance pada model jendela (window), misalnya kita memiliki 4 buah jendela, apabila pemakai melakukan perubahan antarmuka (tampilan penampang) pada jendela, maka maka harus melakukan perubahan pada setiap jendela satu persatu. Akan berbeda apabila salah satu jendela menjadi parent dan 3 jendela yang lain menjadi child, maka dengan mengakses dan melakukan perubahan yang diinginkan pada jendela parent, maka akan secara otomatis jendela child akan melakukan perubahan yang sama.

Gambar 1.5. Inheritance Objek Jendela (Window).

c. Polymorphism.

Polymorphisme menggambarkan suatu kejadian/event dalam format yang berbeda baik bentuk, langkah-langkahnya maupun jenisnya. Pada dunia nyata bentuk sebuah polymorphisme seperti misalnya perintah “Bersuara !” maka masing-masing objek akan menghasilkan keluaran yang berbeda.

a. Orang akan bersuara “apa khabar”.

b. Kucing akan bersuara “ngeong”.

c. Burung akan bersuara “cuit cuit”.

Contoh lain suatu polymorphisme adalah sistem menggambar sebuah grafik atau bidang. Ketika seseorang ingin menggambarkan suatu gambar/grafik, apakah garis, lingkaran, atau kotak maka sistem akan memberikan perintah “gambarkan!”, dengan perintah yang sama setiap objek akan menghasilkan keluaran (output) yang berbeda-beda tergantung dengan jenis objek yang bersangkutan.

a. Dalam kode program non-Polymorphisme dapat dituliskan seperti berikut :

Function Shape.drawMe()

{

SWITCH Shape.Type

Case “Circle”

Shape.drawCircle();

Case “Rectangle”

Shape.drawRectangle();

Case “Line”

Shape.drawLine();

END SWITCH

}

b. Dalam kode program Polymorphisme dapat dituliskan seperti berikut :

Function draw()

{

Shape.drawMe();

}

Fungsi DrawMe() berfungsi untuk menggambar bentuk suatu objek gambar tertentu sesuai dengan keluaran yang diinginkan. Di dalam kasus yang nonpolymorphic suatu fungsi drawRectangle harus ditambahkan dalam kode program untuk suatu objek bentuk sebuah kotak. Juga, fungsi drawMe(), bentuk obyek harus diubah untuk mengakomodasi bentuk yang baru.

Dengan polymorphism untuk menciptakan suatu gambar segiempat (rectangle) dengan drawMe() yang berfungsi untuk menggambar dirinya sendiri akan menghasilkan keluaran berupa bentuk gambar kotak, sedangkan fungsi Draw() berfungsi untuk memulai operasi menggambar.

1.3. Sistem Notasi Graphikal Dan Pemodelan Visual.

a. Visual Modeling.

Visual Modeling adalah proses memperoleh informasi dari model dan menampilkannya dengan nyata menggunakan suatu standard satuan unsur-unsur grafis. Keuntungan memodelkan sistem secara visual (visual modelling) :

1. Terjadinya “hubungan komunikasi” antara pemakai, pengembang perangkat lunak, sistem analis, penguji, manajer, dan orang yang terlibat dalam suatu proyek pengembangan perangkat lunak.

2. Manusia adalah makhluk visual, kita mampu memahami sesuatu yang komplek secara lebih baik ketika diwujudkan secara visual (yaitu dengan melihatnya).

b. Notasi Graphikal.

Pemodelan visual memerlukan notasi grafis yang digunakan untuk merepresentasi (menggambarkan) aspek-aspek sebuah sistem. Ada tiga bentuk notasi yang populer yaitu :

1) Notasi Booch.

2) Object Modeling Technology (OMT).

3) Unified Modeling Language (UML), UML merupakan standart yang telah diadopsi oleh mayoritas industri.

1) Notasi Booch.

Nama notasi ini sesuai nama penciptanya yaitu Grady Booch. Pada perusahaan Rational Software Coorporation, Booch telah menulis sebuah buku tentang kebutuhan dan keuntungan pemodelan visual. Booch telah mengembangkan suatu notasi grafis untuk menghadirkan berbagai aspek suatu model sistem. Object dalam notasi Booch diwakili oleh ilustrasi gambar grafis berupa awan, hal ini menggambarkan fakta bahwa object dapat berupa apapun secara abstrak. Notasi Booch meliputi bermacam bentuk tanda panah untuk menunjukkan jenis hubungan antara object-object dalam model sistem.

Gambar 1.6. Sistem ATM dengan Notasi Booch.

2) Notasi Object Management Technology (OMT).

Notasi OMT diciptakan oleh Dr. Yakobus Rumbaugh. Rumbough telah menulis beberapa buku tentang analisa dan disain sistem. Didalam buku yang berjudul : “Modeling Object Oriented and Disain” yang diterbitkan oleh Prentice Hall/Aula, tahun 1990. Rumbaugh mendiskusikan pentingnya memperagakan (memvisualisasikan dalam bentuk gambar) komponen-komponen sistem di dunia nyata yang disebut dengan object-object. OMT menggunakan grafik lebih sederhana dibanding Booch dalam menggambarkan sistem.

Gambar 1.7. Notasi Rumbough (OMT) untuk sistem ATM.

3) Notasi Unified Modeling Language (UML).

Notasi UML muncul dari Grady berkolaborasi dengan Booch, Dr. Yakobus Rumbaugh, Ivar Jacobson, Rebecca Wirfs Brock, Petrus Yourdon, dan ahli-ahli lainya. Jacobson telah menulis buku tentang bagaimana memperoleh kebutuhan suatu sistem di dalam paket transaksi yang disebut dengan use case. Jacobson juga mengembangkan suatu metoda untuk disain sistem Rancang-Bangun Perangkat lunak Object Oriented (OOSE) yang fokus pada analisa sistem. Booch, Rumbaugh, dan Jacobson, dikenal sebagai “Three Amigos,”. Notasi UML telah menjadi standar industri dalam pengembangan perangkat lunak dengan memodelkanya dalam notasi grafis. Notasi UML digambarkan sama dengan notasi OMT.

Gambar 1.8. Notasi UML untuk sistem ATM.

Konsolidasi UML dimulai pada tahun 1993, dimana Masing-masing personal dalam “Three Amigos” menyertakan gagasan metodologinya masing-masing. Sampai pada akhirnya pada tahun 1995, unified method diperkenalkan. Dalam perkembanganya Pada tahun 1996 UML Versi 1.0 di sahkan, dan Pada tahun 1997 di serahkan kepada sebuah organisasi yang bernama Object Technology Group (OTG). Telah banyak pengembang perangkat lunak mulai mengadopsi UML versi 1.0 dan OMG akhirnya merelease UML versi 1.1 sebagai standar industri.

1.4. Memahami Diagram UML.

UML memberikan fasilitas dalam memodelkan suatu sistem untuk dalam bentul diagram-diagram yang berbeda dimana diagram-diagram ini menggambarkan aspek dari sistem dengan konteks yang berbeda-heda. Dengan sebuah perangkat lunak bantu (Rational Rose) akan memudahkan pengembang didalam memodelkan sebuah sistem perangkat lunak. Diagram-diagram itu terdiri dari :

a. Bisnis Use Case diagram.

b. Use Case diagram.

c. Activity diagram.

d. Sequence diagram.

e. Collaboration diagram.

f. Class diagram.

g. Statechart diagram.

h. Component diagram.

i. Deployment diagram.

Masing-masing diagram dalam notasi UML menggambarkan sistem dalam kontek yang berbeda-beda.

a. Bisnis Use Case diagram.

Diagram yang digunakan untuk menggambarkan fungsionalitas suatu sistem dalam organisasi secara keseluruhan (global). Bussines Use Case digunakan secara luas selama aktivitas memodelkan suatu proses bisnis dan untuk menjelaskan konteks suatu sistem. Dengan diagram ini dasar untuk membuat atau menciptakan suatu Use Case dimulai, dimana sebuah usecase sebenarnya adalah mengambarkan sebuah fungsi yang berada didalam sistem. Diagram ini tidak membedakan proses yang dilakukan secara manual maupun proses yang dilakukan secara otomatis. Didalam Bussines Use Case kita dapat melihat :

  • Interaksi yang terjadi antara Bussines Use Case dengan aktor bisnis.
  • Gambaran umum suatu proses bisnis.
  • Peranan dari aktor-aktor (pelaku) bisnis.

Aktor-aktor bisnis bisa berbentu siapa saja atau apa saja yang berada diluar suatu fungsi bisnis yang berinteraksi didalam proses bisnis tertentu.

Gambar 1.8. Diagram Bisnis Usecase Sebuah Lembaga Keuangan.

b. Use Case Diagram.

Diagram yang menggambarkan interaksi antara use case dengan aktor didalam suatu fungsi bisnis. Use case menggambarkan kemampuan atau fungsionalitas dari sistem secara spesifik (detail). Aktor-aktor adalah orang-orang atau sistem lain yang menyediakan atau menerima informasi kedalam atau dari sistem tersebut. Use case lebih memfokuskan pada penggambaran proses-proses yang otomatis. Sebuah diagram Bussines Use Case dapat memiliki lebih dari satu Use Case Diagram didalamnya. Dibawah ini digambarkan contoh diagram Use Case sistem ATM pada sebuah bank.

Gambar 1.9. Use Case Diagram Sistem ATM.

Diagram diatas menggambarkan interaksi antara aktor-aktor dengan use case didalam sistem. Pelanggan melakukan suatu aktivitas use case yaitu : menarik uang, menyimpan uang, mentransfer dana, membayar, melihat saldo dan mengubah nomor PIN. Pada Use case “Mengubah Nomor PIN” dapat dilakukan oleh petugas bank maupun oleh pelanggan dengan persyaratan-persyaratan tertentu, oleh karena nomor PIN nasabah bank bersifat privat untuk masing-masing nasabah. Pada Use case “Melakukan Pembayaran” menggambarkan sebuah anak panah yang menuju ke aktor credit system (aktor bukan orang), credit system digambarkan sebagai aktor karena merupakan sistem lain yang berada diluar sistem ATM. Gambar anak panah dari use case menuju ke aktor menggambarkan bahwa use case meghasilkan informasi yang digunakan oleh aktor tersebut.

c. Activity Diagram.

Activity diagram menggambarkan alir kerja (urutan aktivitas) dari fungsi suatu sistem. Diagram ini menggambarkan workflow pada awal suatu aktivitas dimulai sampai aktivitas berakhir, aktivitas apa yang terjadi selama workflow berlangsung, dan di dalam urutan atau proses apa suatu aktivitas tersebut terjadi. Aktivitas adalah suatu tugas yang dilakukan oleh aktor. Sebuah aktivitas digambarkan dengan simbol persegi panjang, awal (start) dan akhir (end) menggunakan simbol lingkaran sedangkan statemen pilihan atau pengambilan keputusan menggunakan simbol diamon atau wajik.

Gambar 1.10. Activity Diagram Membuka Rekening (Open Account).

Objek flow di wakili oleh garis panah terputus yang menunjukkan perubahan status (state) yang melakukan aktivitas dari aktor ke aktor lainya. Aktivitas dari satu proses ke proses lain diwakili oleh garis panah tidak terputus yang menunjukkan transisi antar aktivitas. Diagram aktivitas terbagi menjadi beberapa “swimlanes”, setiap swimlanes (aktor yang terlibat dalam diagram aktivitas) memiliki peran yang berbeda dalam workflow.

Dalam suatu swimlanes kita dapat melihat saling memberikan respon antara masing-masing peran satu dengan lainya. Pada simbol transisi menunjukkan “siapa” melakukan komunikasi dengan “siapa”.

d. Sequence Diagram.

Sequence diagram digunakan untuk menggambarkan aliran fungsionalitas dari sebuah use case didasarkan atas urutan sesuai waktu. Misalnya pada proses penarikan uang melalui ATM terjadi beberapa kesalahan yang mungkin, yaitu :

  • Penarikan dana tanpa ketersediaan dana.
  • Kesalahan memasukkan PIN.

Urutan secara sequensial penarikan dana melalui mesin ATM dapat digambarkan dalam diagram sequence sebagai berikut :

Gambar 1.11. Sequence Diagram Penarikan Uang Melalui ATM.

Notasi pada sequence diagram dijelaskan sebagai berikut :

1. Setiap aktor dan objek yang terlibat didalam diagram sequence digambarkan di bagian atas pada diagram.

2. Setiap gambar panah menunjukkan pesan yang dikirim dari aktor ke objek atau dari objek ke objek lainya.

3. Setiap aktor dan objek memiliki sebuah garis vertikal terputus-putus yang menunjukkan satuan waktu tertentu dari suatu pesan yang dikirim dari aktor ke objek atau objek ke objek.

Pada diagram tersebut ditunjukkan 17 langkah proses penarikan dana.

1: Card reader menerima kartu ATM Joe

2: Kartu ATM dibaca oleh Card Reader

3: Card reader menginisialisasi layar

4: Card reader membuka account Joe

5: Layar ATM menampilkan PIN Kepada Joe

6: Joe memasukkan PIN : 1234

7: Layar ATM memverifikasi PIN Joe

8: Layar ATM menampilkan pilihan transaksi

9: Joe memilih transaksi (penarikan dana)

10: Layar ATM menampilkan jumlah dana

11: Joe memasukkan jumlah $20

12: Layar ATM memberi info penarikan dana $20 dari account Joe

13: Account meverifikasi penarikan dana

14: Mengurangi dana $20 dari account Joe

15: Account menyediakan Cash $20 melalui cash dispenser

16: Account menyediakan tanda terima

17: Kartu di keluarkan ke card reader.

e. Collaboration Diagram.

Diagram kolaborasi menggambarkan hubungan antara aktor dan objek yang mengacu pada konteks yang terjadi tanpa melihat urutan berdasarkan waktu. Diagram kolaborasi mirip dengan diagram sequence, berbedaanya bahwa sequence diagram mengacu pada waktu. Objek digambarkan dengan simbol persegi panjang dan aktor seperti gambar orang.

Gambar 1.12. Diagram Collaboration Penarikan Uang melalui ATM

f. Class Diagram.

Class diagram menggambarkan interaksi yang terjadi antar class (Class) yang ada didalam sistem. Class berisi informasi dan perilaku yang dimiliki oleh class tersebut. Class Rekening memiliki informasi No Rekeneing, PIN, dan memiliki methoda (operasi) untuk mengecek dana yang tersimpan di bank. Class yang ada pada diagram class diciptakan untuk objek-objek yang digambarkan pada sequence diagram dan collaboration diagram.

Gambar 1.13. Class Diagram sistem ATM

Class digambarkan dengan segi empat yang terbagi menjadi tiga bagian :

  • Bagian pertama adalah nama class.
  • Bagian kedua adalah attribut class.
  • Bagian ketiga adalah operasi class.

Garis yang menghubungkan antar class merupakan hubungan/relasi komunikasi antar class didalam sistem. Beberapa atribut dan operasi memiliki gambar gembok (padlock) hal ini menunjukkan bahwa attribut tersebut bersifat pribadi (privat) dan operasinya hanya dapat diakses dari dalam class itu sendiri, class lain tidak diperbolehkan mengakses atribut dan methoda privat. No Rekening, PIN dan Saldo adalah atribut pribadi class Rekening. Operasi Deduct Funds() dan Verify Funds() hanya diakses di class Rekening saja, sementara Open() dan Withdraw Funds() melibatkan aktivitas objek atau class lain karena diperlukan adanya interaksi.

g. Statechart Diagram.

Statechart diagram menyediakan suatu cara bagi model sistem dalam menggabarkan berbagai perubahan status (state) objek. Diagram ini digunakan untuk untuk menggambarkan model sistem yang memiliki perilaku yang dinamis (adanya perubahan status) dari suatu sistem. Tipe diagram ini dapat di perluas yang dapat digunakan untuk membangun sistem secara realtime, sehingga statechart diagram menggambarkan perilaku-perilaku objek. Sebagai contoh sebuah rekening bank dapat berada pada suatu kondisi (status) yang berbeda-beda, misalnya rekening dibuka, rekening ditutup dan ditarik.

Gambar 1.14. Statechart Diagram Class Rekening.

Sebagai contoh proses permintaan penutupan rekening dari seorang nasabah (customer request closer), maka digambarkan dengan anak panah dari state “Open” menuju state “Close”, sehingga suatu aksi (action) atau event (kejadian) tertentu dapat terjadi pada saat status tersebut berlaku. Misalnya aksi yang menyebabkan rekening ditutup adalah jika (saldo < 0) maka state overdrawn akan mengirim pesan (notice) ke nasabah bahwa (saldo < 0), dan cek saldo jika < 0 dan lamanya saldo tersebut > 30 hari maka rekening akan otomatis ditutup. Pada diagram statechart hanya boleh ada satu simbol Start State dan proses yang terjadi antar state disebut sebagai action. Statechart diagram tidak harus dibuat untuk setiap class yang ada didalam sistem, hanya dibuat jika class yang ada didalam sistem sangat kompleks, yaitu jika class dapat berada pada state yang berbeda.

h. Component Diagram.

Component diagram menggambarkan suatu pandangan secara phisik dari sebuah model sistem. Diagram komponen menggambarkan komponen-komponen perangkat lunak dalam sistem dan hubungan antar komponen-komponen tersebut untuk sistem perangkat lunak secara menyeluruh. Komponen didalam diagram komponen terdiri dari dua jenis komponen yaitu :

  • Komponen yang dapat dijalankan (Executable component).
  • Komponen yang berupa pustaka (Code Libraries).

Didalam menggambarkan model sistem dengan Rational Rose masing-masing class dalam class diagram dalam model dipetakan (mapping) untuk suatu komponen (kode sumber program) didalam diagram komponen. Jika komponen telah diciptakan maka komponen-komponen ini ditambahkan kedalam diagram komponen. Contoh Komponen untuk sistem ATM.

Gambar 1.15. Component Diagram untuk ATM Server.

Gambar 1.16. Component Diagram untuk ATM client

Gambar diatas sistem dibangun dengan menggunakan bahasa C++, maka Class ATM screen dipetakan kedalam Component ATM screen. Component yang berwarna hitam dinamakan Package Body (file *.cpp atau file kode sumber), sementara yang berwarna putih adalah Package Spesification (file *.h atau file pustaka). ATM.exe adalah Task Spesification dan merepresentasi aliran (thread) suatu proses ketika dijalankan pada komputer.

i. Deployment Diagram.

Deployement diagram menampilkan layout dari peralatan jaringan dan menggambarkan dimana komponen-komponen tersebut di tempatkan (disebarkan). Pada sistem ATM terdiri dari beberapa subsistem yang dijalankan pada peralatan fisik yang berbeda dan terpisah. ATM client ditempatkan di banyak tempat yang berbeda. ATM client “berkomunikasi” melalui jaringan privat dengan ATM Server Regional. ATM Server executable akan dijalankan di ATM server Regional. Dapat disimpulkan bahwa satu diagram penyebaran menunjukkan set-up secara fisik suatu model sistem. Client. Deployment diagram digunakan oleh manajer proyek, pemakai, arsitek dan staf penyebaran untuk memahami layout fisik dari sistem dan dimana subsistem di tempatkan. Deployment diagram di gambarkan :

Gambar 1.17. Deployment Diagram Sistem ATM.

1.5. Proses Pengembangan Perangkat Lunak.

Ada beberapa model dalam pengembangan perangkat lunak yang ada. Dalam beberapa kurun waktu yang cukup lama pengembangan perangkat lunak menggunakan model waterfall.

a. Model WaterFall.

Model ini menggunakan milestone sebagai titik transisi dan pengujian, artinya setiap aktivitas pada tahap pengembangan harus diselesaikan sebelum menuju tahap pengembangan berikutnya. Sehingga model ini sangat sesuai untuk perangkat lunak dengan syarat-syarat yang telah didefinisikan secara lengkap sebelumnya karena besar kemungkinan tidak adanya perubahan aplikasi dimasa yang akan datang. Kondisi semacam ini akan sangat berpengaruh pada perangkat lunak dan menimbulkan masalah terhadap kebutuhan iterasi dimana aplikasi akan terus berkembang dengan penyesuaian-penyesuaian terhadap kebutuhan, proses bisnis dan lingkungan aplikasi yang terus berubah dari waktu kewaktu.

Kelebihan dari model ini adalah karena adanya titik transisi yang jelas pada setiap tahap, maka akan memudahkan tim pengembang perangkat lunak dalam memonitor penjadwalan proyek, menetapkan tanggung jawab dan akuntabilitas peran personal dalam proyek perangkat lunak.

Kelemahan dari model ini adalah adanya kendala dalam mengakomodasi perubahan setelah proses pengembangan telah berjalan. Fase sebelumnya harus lengkap dan selesai sebelum memasuki tahap berikutnya. Beberapa kendala yang muncul pada model waterfall adalah :

a. Aspek perubahan pada perangkat lunak sulit dilakukan karena sifatnya yang kaku dimana kebutuhan perangkat lunak harus lengkap.

b. Karena sifat kakunya, model ini cocok manakala kebutuhan telah dikumpulkan secara lengkap sehingga perubahan bisa ditekan sekecil mungkin. Akan tetapi pada kenyataannya sangat jarang sekali pengguna dapat mendefinisikan kebutuhan awal secara lengkap, oleh karena perubahan kebutuhan adalah sesuatu yang wajar terjadi.

c. Waterfall pada umumnya digunakan untuk rekayasa sistem perangkat lunak berkapasitas besar dimana proyek dikerjakan di beberapa tempat berlainan, dan terbagi menjadi beberapa bagian sub-proyek.

Gambar 1.18. Model Waterfall (Sommervile, 2001)

Sesuai dengan namanya ”waterfall” atau air terjun, model waterfall menggunakan tahapan-tahapan seperti air terjun, dimana tahapan-tahapan tersebut terbagi menjadi lima tahapan.

1. Requirements analysis and definition : pada tahap ini tim pengembang mengumpulkan kebutuhan secara lengkap kemudian dianalisis dan mendefinisikan kebutuhan-kebutuhan proses bisnis yang harus dipenuhi oleh perangkat lunak (solusi bisnis) yang akan dibangun.

2. System and software design : pada tahap ini tim pengembang mendesain sistem dan aplikasi meliputi desain konseptual, logikal dan fisikal .

3. Implementation and unit testing : pada tahap ini desain yang telah di rancang diimplementasikan dengan menterjemahkan ke dalam kode-kode program menggunakan sebuah bahasa pemrograman, sekaligus melakukan pengujian terhadap unit-unit program yang telah dibuat.

4. Integration and system testing : tim pengembang menyatukan unit-unit program kemudian melakukan pengujian sistem perangkat lunak secara keseluruhan.

5. Operation and maintenance : tim pengembang melakukan pengoperasian program dan melakukan pemeliharaan terhadap perangkat lunak dengan penyesuaian atau perubahan terhadap situasi sebenarnya.

Pada model ini menerapkan urutan langkah-langkah dalam mengembangkan perangkat lunak yaitu : analisis kebutuhan, desain sistem, pengembangan sistem (coding), test sistem dan penyebaran sistem. Model pengembangan sistem waterfall secara sederhana seperti pada gambar berikut :

b. Model Iterrative.

Metoda baru dalam pengembangan perangkat lunak adalah metode Iterrative dimana pada konsep Iterrative, proyek perangkat lunak dapat dilihat sebagai suatu seri (urutan) dari waterfall yang lebih kecil. Setiap tahap telah didesain cukup lengkap untuk menyelesaikan bagian-bagian penting dari proyek. Tetapi masih kurang untuk meminimalkan kebutuhan dalam merunut kembali rancangan sistem (backtracking).

Gambar 1.19. Model Pengembangan Iterrative (Bogs, 2005)

Pada model ini kita mengenal empat fase, yaitu : Inception (Permulaan), Elaboration (Perluasan), Construction (Konstruksi), dan Transition (Transisi).

1. Inception, merupakan aktivitas awal suatu projek, pada akhir tahap ini menghasilkan keputusan Go/no-Go (proyek dilaksanakan atau tidak).

2. Elaboration, merupakan kelanjutan inception, disini detail use case dan pilihan arsitektur telah dirancang. pada tahap Elaboration aktivitas yang dilakukan adalah analysis, design, coding, and rencana test.

3. Construction, pada tahap ini sebagian besar kode program telah selesai dibuat.

4. Transition merupakan akhir dari persiapan dan penyebaran sistem kepada pemakai. Tugas-tugas pada phase transisi termasuk menyelesaikan produk software, test akhir, dokumentasi user, dan persiapan training untuk pemakai.

Metode Rationale Unified Process (RUP) merupakan salah stu metode yang menerapkan model iterative dalam pengembangan perangkat lunak.

1) Fase Inception.

Selama fase ini pengembang menggambarkan bisnis usecase dan menentukan batasan proyek. Dengan mengidentifikasi semua entitas-entitas eksternal yang beriteraksi dengan sistem dengan membuat diagram bisnis usecase. Didalam menggambarkan bisnis use case diagram pertimbangkan kriteria-kriteria keberhasilan, penilain terhadap resiko yang mungkin muncul, dan membuat estimasi sumberdaya yang dibutuhkan. Pada fase ini akan menghasilkan :

a) Dokumen visi proyek yang berisi kebutuhan utama proyek, fitur-fitur kunci dan batasan-batasan utama dalam proyek.

b) Model awal use ecase (10-20% telah selesai).

c) Model awal bisnis use case yang meliputi konteks bisnis, kriteria sukses yang terdiri dari proyeksi penghasilan, pengenalan pasar dan perkiraan finansial.

d) Penilaian awal terhadap resiko yang mungkin muncul.

e) Rencana proyek yang menggambarkan fase-fase dalam iterasi.

f) Model-model bisnis jika diperlukan.

g) Satu atau lebih prototipe.

h) Istilah-istilah didalam proyek telah didefinisikan.

Kriteria evaluasi pada fase ini haruslah telah memenuhi :

a) Stakeholder telah mendefiniskan scope dan biaya proyek.

b) Memahami kebutuhan proyek sebagai bukti kebenaran dari penetapan usecase-usecase utama.

2) Fase Elaboration.

Pada fase ini pengembang menganalisa domain permasalahan yang ada didalam proyek, mengembangkan rencana pengerjaan proyek dan mengeliminasi elemen proyek yang paling beresiko. Pada fase ini pula arsitektur prototipe aplikasi telah di bangun satu kali iterasi atau lebih. Dengan prototipe yang telah dibangun digunakan untuk meringankan resiko spesifik dari proyek yang meliputi studi kelayakan atas komponen (bagian program yang dapat digunakan) atau memberikan demo kepada investor, pelanggan dan pengguna akhir. Pada fase ini akan menghasilkan :

a) Model Use Case sudah mencapai 80%, semua use case dan aktor telah teridentifikasi, sebagian besar diskripsi usecase telah dicatat.

b) Kebutuhan non fungsional dan kebutuhan lain yang tidak berhubungan dengan usecase telah diidentifikasi.

c) Diskripsi arsitektur software sudah selesai.

d) Revisi daftar resiko dan bisnis use case.

e) Rencana pengembangan keseluruhan proyek.

Kriteria evaluasi pada fase ini haruslah telah memenuhi :

a) Stakeholder telah menyetujui untuk pengembangan aplikasi secara lengkap.

b) Apakah rencana untuk fase konstruksi sudah detil dan akurat ?

c) Apakah demo aplikasi telah menunjukkan bahwa elemen-elemen utama resiko telah dapat dipecahkan ?

3) Fase Construction.

Pada fase ini komponen dan fitur aplikasi telah dibangun dan diitegrasikan kedalam produk dan semua fitur aplikasi sudah ditest. Pengelolaan terhadap sumber daya dan mengontrolan operasi digunakan untuk meemgoptimalkan biaya, penjadualan dan kualitas aplikasi. Pada fase ini akan menghasilkan :

a) Produk aplikasi telah diintegrasikan dalam sebuah platform.

b) Manual penggunaan aplikasi sudah selesai.

c) Diskripsi dari release aplikasi (“beta release”) saat ini.

Kriteria evaluasi pada fase ini haruslah telah memenuhi :

a) Apakah release aplikasi sudah stabil dan dapat di instalasi ?

b) Stakeholder telah siap untuk transisi ke dalam komunitas pemakai ?

4) Fase Transition.

Pada fase ini bertujuan untuk melakukan transisi dari aplikasi yang sudah jadi ke komunitas pemakai. Setelah pemakai akhir menggunakan aplikasi dan ditemukan adanya permasalahan maka pada fase ini juga permasalahan yang muncul dipecahkan. Pada fase ini akan menghasilkan :

a) Test beta untuk menyesuaikan dan memenuhi ekspektasi dari pengguna akhir.

b) Melakukan konversi terhadap basisdata yang digunakan.

c) Melatih pengguna akhir dan administrator sistem.

Kriteria evaluasi pada fase ini haruslah telah memenuhi :

a) Apakah pengguna akhir merasa puas ?

5) Fase Iteration.

Fase iterasi merupakan fase pengembangan yang berulang untuk menghasilkan aplikasi final yang terintegrasi. Keuntungan pendekatan iterasi ini adalah :

a) Resiko dapat di tangani lebih awal.

b) Perubahan lebih mudah dikelola.

c) Memperoleh level tertinggi dari penggunaanaan aplikasi.

d) Memperoleh kualitas aplikasi yang lebih baik.