BAB 2

LANDASAN TEORI

2.1 Sistem infomasi Akuntansi

2.1.1 Pengertian Sistem Informasi Akuntansi

Menurut Wilkinson et al. (2000,p7), Sistem Informasi Akuntansi

adalah kesatuan struktur dalam sebuah entitas, seperti perusahaan, yang

mempekerjakan sumber-sumber fisik dan komponen lain untuk

mengubah data ekonomi ke dalam informasi akuntansi, dengan tujuan

untuk memuaskan kebutuhan informasi dari beragam pemakai.

Menurut Jones dan Rama (2003,p5) adalah subsistem atau bagian

dari Management Information System (MIS) yang menyediakan

informasi akuntansi dan keuangan, serta informasi lain yang diperoleh

dari transaksi akuntansi secara rutin.

Sedangkan menurut Romney dan Steinbart (2003,p2), sistem

informasi akuntansi terdiri dari 5 komponen:

1. Orang–orang yang mengoperasikan sistem dan melaksanakan

berbagai fungsi.

2. Prosedur, baik manual maupun terkomputerisasi yang melibatkan

pengumpulan, pemprosesan, dan penyimpanan data tentang aktivitas

perusahaan.

3. Data mengenai proses bisnis perusahaan.

4. Software yang digunakan untuk memproses data perusahaan.

9

5. Infrastruktur teknologi informasi termasuk komputer dan alat jaringan

komunikasi.

Menurut Romney dan Steinbart (2003,p2-3), kelima komponen

tersebut memungkinkan sistem informasi akuntansi memenuhi 3 fungsi

penting dalam perusahaan yakni:

1. Mengumpulkan dan menyimpan data mengenai aktivitas yang

dilaksanakan oleh perusahaan, sumber daya yang dipengaruhi oleh

aktivitas tersebut dan pihak yang berpartisipasi dalam berbagai

aktivitas sehingga manajemen, karyawan dan pihak luar yang

berkepentingan dapat memeriksa apa yang telah terjadi.

2. Mentranformasikan data menjadi informasi yang berguna untuk

pengambilan keputusan yang membantu manajemen dalam

merencanakan, melaksanakan dan mengendalikan aktivitas.

3. Menyediakan kontrol yang cukup untuk menjaga aset perusahaan,

termasuk data, untuk menjamin bahwa data tersedia ketika diperlukan

serta akurat dan dapat diandalkan.

Jadi dapat disimpulkan bahwa Sistem Informasi Akuntansi adalah

suatu kesatuan struktur interaksi komponen-komponen yang terdiri dari

manusia, prosedur, data, software, dan teknologi informasi yang bertugas

mengubah data menjadi informasi akuntansi dimana informasi akuntansi

ini dapat berguna dalam pengambilan keputusan bagi pihak internal

maupun eksternal perusahaan.

10

2.1.2 Kegunaan Sistem Informasi Akuntansi

Menurut pendapat Wilkinson et al. (2000,p8), tujuan dan

kegunaan sistem informasi akuntansi adalah:

1. Mendukung operasional sehari-hari.

2. Mendukung pengambilan keputusan bagi pengambil keputusan

internal.

3. Untuk memenuhi kewajiban atau tanggung jawab yang sesuai dengan

jabatannya.

2.2 Sistem Informasi Akuntansi Penjualan dan Piutang Usaha

2.2.1 Pengertian Penjualan

Standard Akuntansi Keuangan (2004,PSAK no.23.1)

mendefinisikan, “Penjualan barang meliputi barang yang diproduksi

perusahaan untuk dijual dan barang yang dibeli untuk dijual kembali

seperti barang dagang yang dibeli pengecer atau tanah properti lain yang

dibeli untuk dijual kembali. Dan penjualan jasa biasanya menyangkut

tugas yang secara kontraktual telah disepakati oleh perusahaan, jasa

tersebut dapat diserahkan selam satu periode atau secara lebih dari satu

periode.”

Berdasarkan pendapat Warren, Reeve dan Fess (2005, p.300),

“Penjualan adalah jumlah yang dibebankan ke pelanggan untuk barang

yang dijual, baik secara tunai maupun kredit.”

11

Jadi dapat disimpulkan bahwa penjualan merupakan pemindahan

risiko dan manfaat kepemilikan barang atau jasa dari pihak yang

memiliki barang atau jasa (penjual) pada pihak yang membutuhkan

barang atau jasa tersebut (pembeli). Kegiatan penjualan terdiri dari

penjualan barang atau jasa serta kredit maupun tunai. Kegiatan penjualan

ini merupakan salah satu sumber penghasilan utama bagi setiap

perusahaan.

2.2.2 Pengertian Piutang Usaha

Menurut Horngren et al. (2002,p312), piutang merupakan klaim

dalam bentuk uang kepada perusahaan atau individu. Piutang adalah

sebuah perjanjian untuk menerima kas dari pelanggan yang kepada

pelanggan tersebut perusahaan telah menjual dan menyerahkan barang

atau jasa.

Menurut Gelinas et al. (2005), proses piutang adalah sebuah

struktur interaksi people, peralatan, metode-metode, dan kendali-kendali

yang didesain untuk membuat dan mencatat arus informasi yang

melakukan kegiatan yang meliputi:

1. Mendukung perulangan kegiatan rutin dari departemen credit, kasir,

dan departemen piutang.

2. Mendukung proses pemecahan masalah dari manajer keuangan.

3. Membantu dalam persiapan dari laporan internal dan eksternal.

Berdasarkan pengertian diatas, maka dapat disimpulkan piutang

merupakan klaim dalam bentuk uang terhadap pihak lainnya, yang timbul

12

sebagai suatu transaksi yang telah dilakukan sebelumnya dan didukung

dari departemen bersangkutan dalam mengkoreksi transaksi-transaksi

sebelumnya untuk menghasilkan laporan untuk pihak internal maupun

eksternal.

2.2.3 Syarat Kredit

Untuk menghindari tidak tertagihnya piutang, perusahaan

memakai standar kredit. Menurut Weston (1999) yang diterjemahkan

oleh oleh Sirait, A., dalam menilai resiko kredit dapat dilakukan penilaian

terhadap 5C dari calon pelanggan, yaitu:

1. Character.

Karakter mengacu sampai sejauh mana pelanggan berusaha

memenuhi kewajiban kreditnya. Dalam kaitan ini, laporan

pengkreditan menyajikan informasi mengenai latar belakang prestasi

perusahaan dan orang-orangnya.

2. Capacity.

Kapasitas adalah penilaian subjektif mengenai kemampuan pelanggan

untuk membayar. Hal ini dapat tercermin dari laporan keuangan

pelanggan di masa lalu dan metode yang ditempuhnya dalam

menjalankan usaha, atau bisa juga dengan meninjau pabrik atau toko

pelanggan bersangkutan.

13

3. Capital.

Modal dapat dilihat dari analisis laporan keuangan perusahaan.

Penekanan utamanya adalah pada rasio resiko, yaitu rasio utang

terhadap aktiva, rasio lancar, dan rasio kemampuan membayar beban

bunga.

4. Collateral.

Kolateral atau agunan/jaminan adalah setiap aktiva yang ditawarkan

pelanggan sebagai jaminan agar memperoleh kredit.

5. Condition.

Keadaan mengacu pada kecenderungan umum perekonomian serta

perkembangan yang terjadi di daerah tertentu atau pada sektor

ekonomi tertentu yang bisa mempengaruhi kemampuan pelanggan

untuk memenuhi kewajibannya.

2.2.4 Sasaran Sistem Informasi Akuntansi Siklus Penjualan

Menurut Wilkinson et al. (2000,p416), tujuan utama dari siklus

penjualan dan piutang usaha adalah untuk memfasilitasi pertukaran

barang atau jasa dengan sejumlah uang tertentu dari pelanggan.

Berikut adalah sasaran dari siklus pendapatan:

1. Untuk mencatat pelanggan secara cepat dan tepat.

2. Untuk memverifikasi bahwa pelanggan layak mendapatkan kredit.

3. Untuk mengirimkan produk pada tanggal yang telah disetujui.

14

4. Untuk melakukan penagihan atas produk atau jasa secara tepat pada

waktunya dan dengan proses yang benar.

5. Untuk mencatat dan mengklasifikasi penerimaan kas secara cepat dan

tepat.

6. Untuk posting penjualan dan penerimaan kas ke akun pelanggan yang

tepat dalam jurnal khusus penjualan dan penerimaan kas.

7. Untuk mengamankan produk sampai dikirim.

8. Untuk mengamankan kas sampai disetor.

2.2.5 Dokumen yang Terkait

Mengacu Wilkinson et al. (2000, p419) dokumen yang terkait

dalam aplikasi sistem penjualan dan piutang usaha adalah:

1. Customer order.

Adalah purchase order yang diterima dari pelanggan atau form yang

dipersiapkan oleh karyawan penjualan dari perusahaan penjual.

2. Sales order.

Adalah form formal, yang memiliki banyak copy yang disiapkan dari

customer order.

3. Picking list.

Adalah copy dari sales order, dokumen terpisah yang dikirim ke

gudang dan dalam pengambilan barang yang dipesan.

4. Packing slip.

Adalah copy dari sales order atau picking list yang ditempelkan

bersama barang ketika dipersiapkan untuk pengiriman.

15

5. Shipping notice.

Biasanya merupakan copy dari sales order atau dokumen pengiriman

terpisah yang berfungsi sebagai bukti bahwa barang telah dikirimkan.

6. Sales invoice.

Adalah dokumen yang dikirimkan ke pelanggan untuk menyatakan

berapa jumlah penjualan.

7. Remitance advice.

Adalah dokumen yang menunjukkan jumlah penerimaan kas dari

pelanggan.

8. Deposit slip.

Adalah dokumen yang menyertai penyetoran kas ke bank.

9. Back order.

Adalah dokumen yang dipersiapkan ketika kuantitas dari persediaan

tidak mencukupi sales order.

10. Credit memo.

Adalah dokumen yang memungkinkan pengurangan kredit pelanggan

untuk pengembalian penjualan/penyisihan penjualan.

11. Credit application.

Adalah sebuah form dipersiapkan ketika pelanggan baru mengajukan

kredit.

12. Sales person call report.

Adalah form yang digunakan untuk menggambarkan panggilan yang

dibuat oleh sales person kepada pelanggan potensial dan

mengidentifikasi hasil dari panggilan tersebut.

16

13. Delinquent notice.

Adalah catatan yang dikirimkan kepada pelanggan yang melewati

batas saldo kredit.

14. Write-off notice.

Adalah dokumen yang dipersiapkan oleh manajer kredit ketika akun

dinyatakan tidak dapat ditagih.

15. Cash register receipt.

Adalah form yang digunakan oleh retailer untuk mencerminkan kas

yang diterima.

16. Bill of Lading.

Adalah dokumen pengiriman yang digunakan untuk perusahaan

pengiriman yang akan mengirimkan produk.

2.2.6 File/Catatan yang Terkait

Menurut Wilkinson et al. (2000, p444), file-file atau catatan yang

digunakan dalam aplikasi sistem penjualan dan piutang usaha adalah:

1. File Master: Master Pelanggan, Persediaan, Piutang.

2. File Transaksi: File Sales Order, Shipping, Sales Invoice, Billing,

General Ledger.

3. File Reference: Shipping Reference, Pricing Reference, Sales History.

4. Jurnal memo kredit, jurnal penerimaan kas, buku besar pembantu

piutang.

17

2.2.7 Fungsi yang Terkait

Menurut Bodnar dan Hopwood (2004, p265-268, p321), dapat

disimpulkan bahwa fungsi yang terkait dalam siklus penjualan meliputi:

1. Fungsi Penjualan.

Fungsi ini antara lain bertugas menerima pesanan pelanggan,

meminta otorisasi kredit, mengisi faktur penjualan tunai, serta

menentukan tanggal dan tujuan pengiriman.

2. Fungsi Kredit.

Fungsi ini antara lain bertugas meneliti status kredit pelanggan dan

memberikan otorisasi kredit pada pelanggan.

3. Fungsi Gudang.

Fungsi ini antara lain bertugas menyimpan dan menyiapkan barang

yang dipesan pelanggan.

4. Fungsi Pengiriman.

Fungsi ini antara lain bertugas menyerahkan barang atas dasar surat

pesanan penjualan yang diterimanya dari fungsi penjualan.

5. Fungsi Penagihan.

Fungsi ini antara lain bertugas memverifikasi pesanan berdasarkan

dokumen-dokumen pesanan yang diterimanya kemudian membuat

dan mengirimkan faktur pada pelanggan.

6. Fungsi Akuntansi.

Fungsi ini antara lain bertugas membuat pencatatan transaksi

penjualan, piutang, serta penerimaan kas secara periodik.

18

7. Fungsi Kas.

Fungsi ini antara lain bertanggung jawab sebagai penerima kas dari

hasil penjualan untuk diteruskan ke bank.

8. Fungsi Pemeriksa atau Audit Internal.

Fungsi ini antara lain bertanggung jawab dalam melaksanakan

penghitungan kas yang ada ditangan fungsi kas secara periodik, serta

bertanggung jawab dalam melakukan rekonsiliasi bank untuk

mengecek ketelitian catatan kas yang diselenggarakan oleh fungsi

akuntansi.

2.2.8 Prosedur Siklus Penjualan

Mengacu pada Wilkinson et al. (2000,p422), prosedur siklus

penjualan adalah:

1. Sales Order Entry

Siklus pendapatan dimulai dengan penerimaan order dari pelanggan.

Sales order entry dijabarkan menjadi 3 langkah, yaitu:

a. Taking customer order

Order dari pelanggan dapat diterima dengan berbagai macam cara

melalui surat, telepon, website atau melalui karyawan penjualan di

lapangan.

b. Credit approval

Persetujuan kredit meliputi pengecekan customer master file

untuk memverifikasi akun yang sudah ada, mengidentifikasi limit

kredit, dan memverifikasi jumlah pemesanan sekarang ditambah

19

jumlah akunnya tidak melebihi limit. Jika kredit limit tidak

melebihi, order diterima. Jika melebihi limit, keputusan

diserahkan pada manajer kredit.

c. Pengecekan Persediaan

Menentukan apakah persediaan yang dipesan tersedia. Jika tidak

tersedia, dibuatlah back order. Pemberitahuan ke bagian

pembelian untuk kebutuhan atas persediaan tersebut. Jika order

diterima, sales order dibuat order acknowledgment untuk

pelanggan, picking list untuk bagian gudang, packing list untuk

bagian pengiriman.

2. Shipping

Terdiri dari 2 langkah, yaitu:

a. Pick dan Pack

Bagian gudang menggunakan picking ticket untuk

mengidentifikasi produk, dan jumlah dari tiap produk, untuk

dipindahkan dari persediaan. Bagian gudang yang mencatat

jumlah barang yang akan diangkut. Kemudian barang

dipindahkan ke bagian pengiriman.

b. Ship order

Bagian pengiriman yang membandingkan jumlah fisik persediaan

dengan informasi dari picking list dan packing slip.

3. Billing

Setelah mendapatkan informasi barang telah dikirim, prosesnya

adalah membuat sales invoice. Bagian penagihan menyatukan

20

informasi dari bagian penjualan mengenai harga barang dan bagian

pengiriman mengenai tipe dan jumlah barang yang dikirim.

Account receivable menggunakan informasi dari sales invoice untuk

mendebit akun pelanggan dan mengkreditnya jika akun tersebut

sudah diterima pembayarannya.

Bila menggunakan open-invoice method, pelanggan membayar

menurut tiap invoice. Memberikan remittance advice beserta

uangnya. Bila menggunakan balance-forward method, pelanggan

membayar jumlah yang tertera di monthly-statement.

4. Cash Collection

Pelanggan akan mengirimkan remittance advice, karyawan akan

membuat remittance entry yang akan mengubah akun account

receivable pelanggan. Jumlah pembayaran diberikan kepada kasir.

Karyawan yang membuat remittance entry dengan karyawan yang

menerima kas berbeda.

2.2.9 Laporan Sistem Informasi Akuntansi Penjualan Pada Akhir Periode

Menurut Wilkinson et al. (2000,p428), laporan yang diperlukan

pada akhir periode adalah:

1. Laporan Penjualan.

Adalah laporan yang berisikan ringkasan dari transaksi penjualan

dalam satu periode.

21

2. Laporan Penerimaan Kas.

Adalah laporan di mana berisikan ringkasan penerimaan kas atas

berbagai transaksi yang terjadi dalam satu periode.

3. Accounts Receivable Summary.

Adalah ringkasan dari perubahan saldo piutang dari masing-masing

pelanggan dalam satu periode.

4. Accounts Receivable Aging Schedule.

Adalah ringkasan umur piutang dari masing-masing pelanggan di

mana dianalisis, yang selanjutnya berguna untuk proses penagihan.

2.3 Pengendalian Internal

2.3.1 Pengertian Pengendalian Internal

Menurut Gelinas et al. (2005,p237), pengendalian internal adalah

sebuah sistem dari elemen-elemen terintegrasi, bertindak bersama-sama

untuk menindak lanjuti jaminan yang layak untuk sebuah hasil dari

organisasi atas tujuan proses bisnis.

2.3.2 Unsur-Unsur Pengendalian Internal

Berdasarkan pada pendapat Gelinas et al. (2005,p244), terdapat

dua unsur pengendalian internal yaitu:

1. Control goals of operation processes

Effectiveness: ukuran kesuksesan dari satu atau lebih tujuan

proses yang merefleksikan kriteria yang digunakan untuk menilai

efektivitas berbagai proses bisnis.

22

Efficiency: ukuran produktivitas sumber daya yang digunakan

untuk mencapai tujuan.

Security of resources: perlindungan proses organisasi dari

kerugian, kebangkrutan, penyingkapan, peniruan, dan

penyalahgunaan lainnya.

2. Control goals of information processes

Input validity: tujuan pengendalian menjamin bahwa masukan

data disetujui secara tepat dan menunjukkan objek dan keadaan

ekonomi saat ini.

Input completeness: pengendalian menjamin bahwa semua

kejadian atau objek valid yang dimasukkan ke dalam sistem.

Input accuracy: tujuan pengendalian yang menjamin bahwa

kejadian secara benar dimasukkan ke dalam sistem.

Update completeness: tujuan pengendalian menjamin bahwa

semua kejadian yang dimasukkan dalam komputer dan

direfleksikan masing-masing dalam master data.

Update accuracy: tujuan pengendalian menjamin bahwa data

yang dimasukkan dalam komputer, direfleksikan secara benar ke

masing-masing master data.

2.3.3 Sistem Pengendalian Internal Sistem Informasi Akuntansi Penjualan

Berdasarkan pendapat Wilikinson et al. (2000), struktur

pengendalian intern dalam sistem penjualan kredit meliputi:

23

1. General Controls

Organizational Controls

Pemisahan fungsi antara bagian operasional (seperti bagian

gudang dan pengapalan) dengan bagian pencatatan.

Documentation Controls

Dokumentasi harus lengkap dan up-to-date.

Asset Accountability Controls

Buku besar pembantu piutang harus dimaintain dan direkonsiliasi

secara berkala dengan rekening kontrol di buku besar. Catatan

persediaan juga harus direkonsiliasi secara periodik, dilakukan

perhitungan fisik atas jumlah persediaan yang ada.

Management Practices Controls

Karyawan, termasuk programmer dan akuntan harus diberikan

pelatihan. Audit harus dilakukan terhadap kebijakan penjualan

dan penerimaan kas. Manajer harus melakukan review terhadap

analisis periodik dan laporan-laporan mengenai kegiatan

akuntansi dan transaksi yang disahkan melalui komputer.

Data Center Operation Controls

Staf TI dan akunting harus diawasi, dan kinerja mereka direview

dengan bantuan laporan kontrol proses komputer dan pencatatan

akses.

24

Authorization Controls

Semua transaksi penjualan kredit termasuk retur penjualan harus

diotorisasi oleh manajer kredit.

Access Controls

Menggunakan password, gudang dan kas yang terlindung secara

fisik, melakukan back-up terhadap file piutang dan persediaan ke

dalam media penyimpanan lain.

2. Application Controls

Input Controls

1) Dokumen-dokumen yang terkait dengan penjualan dan

pengiriman barang bernomor urut tercetak dan diotorisasi oleh

orang yang berwenang.

2) Validasi data pesanan penjualan ketika data dimasukkan

dalam proses.

3) Memperbaiki error yang terdeteksi ketika entry data sebelum

data diposting ke file pelanggan dan persediaan.

Processing Controls

1) Perpindahan barang dari gudang barang jadi dan pengiriman

barang hanya atas dasar otorisasi tertulis.

2) Pengiriman faktur ke pelanggan dilakukan atas dasar

notifikasi dari departemen pengiriman mengenai barang yang

sudah dikirim.

25

3) Penerbitan kredit memo atas retur penjualan hanya dilakukan

jika barang telah dikembalikan.

4) Verifikasi semua catatan komputer terhadap faktur penjualan

sebelum diposting ke file pelanggan. Bandingkan faktur

penjualan dengan dokumen pengiriman, untuk meyakinkan

bahwa barang yang dipesan sesuai dengan yang dikirim.

5) Simpan kas segera setelah diterima untuk menghindari

penyelewengan dana.

Output Controls

1) Menyiapkan laporan bulanan yang harus dikirim pada semua

pelanggan yang berhutang.

2) Copy file dari semua dokumen yang terkait dalam transaksi

penjualan dengan nomor yang berurut, untuk mengecek

apakah ada nomor yang terlewat.

3) Mencetak daftar ringkasan transaksi dan akuntansi secara

periodik sebagai dasar untuk melakukan review.

2.4 Analisis Dan Perancangan Sistem Berorientasi Objek

2.4.1 Pengertian Analisis Sistem

Menurut McLeod yang diterjemahkan oleh Teguh (2001,p190),

“Analisis sistem adalah penelitian atas sistem yang telah ada dengan

tujuan merancang sistem baru atau diperbaharui.”

26

2.4.2 Pengertian Perancangan Sistem

Berdasarkan pendapat McLeod (2001,p192) yang diterjemahkan

Teguh, mendefinisikan “Perancangan sistem adalah penentuan proses dan

data yang diperlukan oleh sistem baru.”

2.4.3 Pengertian Metode Analisis Dan Desain Berorientasi Objek

Menurut Whitten et al. (2001, p97), Object–Oriented Analysis

dan Design (OOA&D) berusaha untuk menggabungkan data dan proses

menjadi suatu gagasan tunggal yang disebut objects. OOA&D

memperkenalkan objects diagrams yang mendokumentasikan sistem

dipandang dari segi objects dan interaksinya.

Mengacu pada pendapat Mathiassen, ”OOA&D‘s main activities:

problem-domain analysis, application-domain analysis, architectural

design, and component design.” Dapat diartikan OOA&D adalah

kumpulan panduan umum untuk melakukan analisis dan desain.

Selanjutnya mengacu pada pendapat Mathiassen et al. (2000) bahwa

keuntungan dari OOA&D adalah:

1. Dapat digunakan untuk memodelkan hampir semua fenomena dan

dapat dinyatakan dalam bahasa umum (natural language).

1) Noun menjadi object atau class.

2) Verb menjadi behavior.

3) Adjective menjadi attributes.

27

2. Ada kaitan yang erat antara object-oriented analysis, object-oriented

design, object-oriented user interface dan object-oriented

programming.

Notasi standar yang digunakan dalam OOA&D adalah dengan

menggunakan UML (Unified Modeling Language). UML adalah sebuah

modeling language, bukan sebuah metode.

Berdasarkan pengertian di atas, maka dapat disimpulkan metode

analisis dan desain berorientasi objek adalah cara melakukan analisis dan

desain dengan mengabungkan data dan proses menjadi suatu objek.

2.4.4 System Definition

System definition adalah deskripsi ringkas dari sistem

terkomputerisasi yang diekspresikan dalam bahasa natural. Tujuan system

definition adalah untuk memilih sistem aktual yang akan dikembangkan.

Hal ini dilakukan dengan mengklarifikasikan interpretasi, kemungkinan

dan konsekuensi dari beberapa solusi alternatif secara sistematis.

2.4.5 FACTOR Criterion

Menurut Mathiassen et al. (2000,p39), FACTOR Criterion terdiri

dari enam elemen, yaitu:

1. Functionality: fungsi-fungsi sistem yang mendukung tugas

application domain.

28

2. Application Domain: Bagian-bagian dalam organisasi yang

mengadministrasi, memonitor, atau mengendalikan sebuah problem

domain.

3. Conditions: kondisi-kondisi yang dibawahnya sistem akan

dikembangkan dan digunakan.

4. Technology: teknologi yang digunakan untuk mengembangkan sistem

dan teknologi yang daripadanya sistem akan dijalankan.

5. Objects: objek-objek utama dari problem domain.

6. Responsibility: tanggung jawab keseluruhan sistem yang berkaitan

dengan konteksnya.

2.4.6 Tahapan OOAD

Menurut Mathiassen et al. (2000), analisis dan perancangan

berorientasi objek terdiri dari 4 aktivitas utama seperti diilustrasikan

dalam gambar 2.1 yang meliputi analisis problem domain, analisis

application domain, architectural design dan component design.

Gambar 2.1 Empat Aktivitas Utama Dalam OOA&D

29

2.4.7 Problem-Domain Analysis

Mengacu pada Mathiassen et al. (2000), problem domain adalah

bagian dari konteks yang diatur, dimonitor, atau dikendalikan oleh

sistem. Analisis problem-domain memfokuskan pada informasi yang

harus ditangani oleh sistem dan menghasilkan sebuah model yang

merupakan gambaran dari kelas-kelas, objek-objek, struktur dan perilaku

dalam problem domain.

Aktivitas dalam problem domain meliputi: Classes, Structure, dan

Behaviour. Tujuan dari Problem Domain Analysis adalah

mengidentifikasikan dan memodelkan problem domain.

Gambar 2.2 Aktivitas Dalam Problem Domain

Tabel 2.1 Kerangka Analisis Problem Domain

Kegiatan Isi Konsep

ClassObjek dan event yang mana merupakan bagian dari problem domain?

Class, objek, event

StructureBagaimana classdan objek saling terkait satu sama lain secara konseptual?

Generalisasi, agregasi, asosiasi, dan cluster

Behaviour Properti dinamik mana yang dimiliki oleh objek?

Event trace, behavioural pattern, dan atribut

30

2.4.7.1 Class

Class adalah “a description of collection of objects

sharing structure, behavioural pattern, and attributes.”

Mengacu pada Mathiassen et al. (2000), kegiatan kelas

merupakan kegiatan pertama dalam analisis problem domain.

Ada beberapa tugas utama dalam kegiatan ini, yaitu: abstraksi

fenomena dari problem domain dalam objek dan kegiatan;

klasifikasi objek dan event; pemilihan kelas-kelas dan event-

event yang akan dipelihara informasinya oleh sistem.

Tujuan dari mendefinisikan class adalah untuk mencari

elemen dari sebuah problem domain, yaitu objects, classes, dan

events.

1. Object: suatu entitas yang mempunyai identitas, state dan

behavior . Dalam problem-domain analysis, sebuah object

adalah abstraksi dari fenomena yang ada dalam problem-

domain tersebut. Object diberi karakter melalui event-nya.

2. Class: objek yang berbagi structure, behavior pattern, dan

atribut. Dalam menentukan class, terlebih dahulu dicari

kandidat untuk class. Candidate class dapat diperoleh dari

kata benda dalam keterangan atau pembicaran, daftar dari

tipe objek, cari persamaan dengan sistem komputer, atau

literatur teknis di dalam problem domain. Penamaan class

harus sederhana, mudah dibaca, tepat, tidak

membingungkan seperti yang digunakan di problem domain.

31

Hasil dari tahap ini berupa sebuah event table dengan class-

class dan event-event yang terkait.

3. Event: insiden yang terjadi seketika yang melibatkan satu

atau lebih object. Event candidates dapat diperoleh dari kata

kerja di dalam penjelasan atau wawancara dengan user.

Dalam membuat event candidates, sebaiknya memilih kata-

kata sederhana dan mudah dibaca, ada di dalam problem-

domain, dan memperlihatkan sebuah event tunggal. Semua

kata-kata tersebut lalu dievaluasi berdasarkan kriteria

apakah event tersebut instan, atomic, dan dapat diidentifikasi

dengan jelas ketika terjadi.

Kegiatan class akan menghasilkan sebuah Event Tabel.

Seperti yang terlihat pada tabel dibawah ini, merupakan

contohnya, dimana dimensi horizontal berisi class-class yang

terpilih, dimensi vertikal berisi event-event terpilih. Sebuah

tanda cek digunakan untuk mengindikasikan objek-objek dari

class yang berhubungan dalam event tertentu.

Tabel 2.2 Contoh Event Table

Event ClassCustomer Assistant Apprentice Appointment Plan

Reserved √ √ √ √Cancelled √ √ √Treated √ √Employed √ √Resigned √ √Graduated √Agreed √ √ √

32

Pada gambar di bawah ini menjelaskan mengenai

subactivity dari class. Dimulai dengan mengidentifikasi, objek,

dan kemudian melakukan abstraksi dan klasifikasi,

mengembangkan susunan class yang relevan dan potensial

untuk model problem domain. Dalam aktivitas secara paralel, di

identifikasi dan dikembangkan serupa dengan beberapa event.

Kemudian secara sistematik dievaluasi banyak kandidat dan

memilih beberapa class dan event yang relatif meliputi model

problem domain. Pada akhirnya, menaruh event ke class.

Eval uat e and sel eectsyst emat i cal l y

Fi nd candi dat es f or event sFi nd Candi dat esf or cl asses

Event Tabl eEvent Tabl e

Gambar 2.3 Subactivity Dalam Pemilihan Class

Dan Event Problem Domain

2.4.7.2 Structure

Structure adalah hubungan antara classes dan objects.

Tujuan dari structure adalah untuk menggambarkan hubungan

yang struktural antara class dan obyek di dalam sebuah problem

domain. Hasil dari structure adalah sebuah class diagram

dengan class dan structure. Class diagram adalah diagram yang

33

menggambarkan kumpulan dari classes dan hubungan

terstruktur. Menurut Mathiassen et al. (2000) menyatakan

bahwa ada empat tipe hubungan struktural di mana keempatnya

dibagi ke dalam dua bagian yaitu:

1. Class Structure

Generalization Structure

Sebuah class umum (superclass) menjelaskan properties

pada sekelompok class khusus (subclass).

Generalization dapat dikatakan sebagai hubungan “is-

a”, mengekspresikan inheritance yang berarti sub class

akan mempunyai attribute dan operation yang sama

dengan superclass. Sebagai contoh dapat dikatakan “a

customer is a person”.

Person

Customer Employee

Gambar 2.4 Contoh Generalization Structure

Cluster Structure

Kumpulan dari class-class yang saling berhubungan.

Cluster digambarkan dengan notasi file folder yang

didalamnya terdapat kumpulan class berkaitan.

34

Hubungan antara class dari cluster yang berbeda

biasanya menggunakan association structure.

Gambar 2.5 Contoh Cluster Structure

2. Object Structure

Aggregation

Sebuah object superior (the whole) mengandung

sejumlah object (the part). Aggregation diformulasikan

sebagai hubungan “has-a”, contoh: “a car has a body”.

Aggregation juga dapat diformulasikan sebagai “is-part-

of”, contoh: “the body is a part of the car”.

Menurut Mathiassen et al. (2000) ada tiga tipe struktur

aggregation, yaitu:

i. Whole-part, objek superior adalah jumlah dari objek

inferior, jika dilakukan penambahan atau penghapusan

objek inferior, maka akan mengubah pokok objek

superior.

mobil

Mesin

Silinder

Bus

Taksi

-**

1*

<<cluster>>mobil

35

ii.Container-content, objek superior adalah container

bagi objek inferior, jika melakukan penambahan

maupun penghapusan objek inferior, tidak akan

mengubah pokok objek superior.

iii.Union-member, objek superior adalah objek inferior

yang terorganisasi. Tidak akan terjadi perubahan pada

objek superior apabila melakukan penambahan atau

penghapusan objek inferior tetapi ada batasannya.

Car

Body Wheel

11 1 -.4..*

Gambar 2.6 Contoh Aggregation Structure

Association

Hubungan yang ada dalam dua atau lebih object, tetapi

hubungan ini bukan merupakan hubungan yang sangat

kuat seperti aggregation karena object satu tetap ada

walaupun object yang lain tidak ada. Association

diterjemahkan sebagai garis yang menghubungkan

object-object.

car person0..* 1..*

Gambar 2.7 Contoh Association Structure

36

2.4.7.3 Behaviour

Gambaran dari urutan event yang mungkin terjadi pada

semua object dalam sebuah class. Tujuan dari aktivitas ini

adalah untuk memodelkan bagian yang dinamis dari sebuah

problem domain. Menurut Mathiassen et al. (2000) konsep dari

behaviour antara lain meliputi:

1. Event trace: urutan event yang terjadi pada suatu objek yang

spesifik.

2. Behavioural Pattern: deskripsi dari event traces yang

mungkin terjadi pada semua objek di dalam sebuah kelas

3. Attribute: sebuah keterangan property dari kelas atau event.

Hasil dari kegiatan behavior adalah statechart diagram.

Statechart menunjukkan urutan lengkap dari suatu sistem atau

objek yang ada pada event yang telah dibuat. Tiga jenis notasi

untuk behavioral pattern, yaitu:

1. Sequence, yaitu event terjadi satu per satu secara berurutan.

Notasinya adalah “+”.

2. Selection, yaitu satu event dipilih diantara sekumpulan event

yang ada. Notasinya adalah “”.

3. Iteration, yaitu sebuah event terjadi sebanyak nol atau

beberapa kali. Notasinya adalah “”

37

2.4.8 Application Domain Analysis

Mathiassen et al. (2000,p6). mengartikan bahwa application

domain merupakan sebuah kegiatan dari sebuah organisasi yang

mengadministrasi, memonitor atau mengontrol sebuah problem domain.

Tujuan dari Application Domain Analysis adalah untuk menentukan

kebutuhan atau persyaratan penggunaan sistem.

UsageInterface

Function

System Definition

Requirement

Gambar 2.8 Aktivitas dalam Application Domain

2.4.8.1 Usage

Tujuan dari aktivitas ini adalah untuk menentukan

bagaimana actor dapat berinteraksi dengan system. Kegiatan ini

menyediakan gambaran umum system requirement dari sudut

pandang user dan menyediakan dasar untuk mendefinisikan dan

mengevaluasi kebutuhan function dan interface. Aktivitas dalam

usage, antara lain adalah menentukan actor, kemudian membuat

usecase. Menurut Mathiassen et al. (2000) use case diagram

biasanya terdiri atas:

38

1. Actor. Actor adalah abstraksi dari user atau system lain

berinteraksi langsung dengan sistem yang dituju dan

merupakan sebuah peran dan bukannya mewakili orang

tertentu.

2. Use case. Use case adalah sebuah pola interaksi antara

sistem dengan actor dalam application domain. Untuk

mencari usecase dapat dilakukan dengan memeriksa tugas

pada application domain. Agar usecase lebih jelas, maka

dapat dideskripsikan dengan statechart diagram atau narasi.

2.4.8.2 Function

Function merupakan suatu fasilitas yang digunakan untuk

membuat sebuah model berguna bagi actors dalam melakukan

pekerjaannya. Oleh sebab itu didalam function activity

penekanannya berfokus kepada “apa yang akan sistem

lakukan?”. Tujuan dari function adalah untuk menentukan

kemampuan proses sistem informasi. Hasil dari function adalah

sebuah daftar lengkap dari fungsi dengan spesifikasi kompleks.

Untuk membantu dalam menganalisis functions dibagi ke dalam

beberapa tipe yang berbeda, antara lain:

1. Update functions. Merupakan function yang diaktifkan oleh

suatu problem domain event dan menghasilkan suatu

perubahan di dalam model-model state.

39

2. Signal functions. Merupakan function yang diaktifkan oleh

sebuah perubahan didalam model state dan menghasilkan

suatu reaksi di dalam konteks. Reaksi ini mungkin akan

ditampilkan pada para aktor di dalam application domain

atau suatu intervensi langsung di dalam problem domain.

3. Read functions. Merupakan function yang diaktifkan oleh

sebuah kebutuhan akan informasi di dalam tugas aktor dan

menghasilkan sistem yang mempertunjukkan bagian-bagian

dari model relevan.

4. Compute functions. Merupakan function yang diaktifkan

oleh sebuah kebutuhan akan informasi di dalam tugas aktor

dan terdiri dari sebuah perhitungan melibatkan informasi

yang disediakan oleh aktor atau model, hasilnya adalah

sebuah tampilan dari hasil perhitungan.

2.4.8.3 User Interface

Di dalam interfaces akan dijelaskan kebutuhan-kebutuhan

apa saja yang menjadi target system interfaces. Interfaces

digunakan oleh para aktor untuk berinteraksi dengan sistem.

Mathiassen et al. (2000,p151), mendefinisikan interfaces adalah

fasilitas yang membuat sebuah model sistem dan fungsi tersedia

bagi aktor. User interface adalah interface bagi user. System

interface adalah interface bagi sistem lainnya. Ada empat pola

dalam pembuatan user interface, yaitu:

40

1. Menu-selection pattern. Daftar dari berbagai pilihan yang

dapat dipilih oleh user dalam user interface.

2. Form fill in patern. Pola klasik digunakan untuk entry data

pada terminal berbasiskan karakter.

3. Command language pattern. Memungkinkan user

memasukkan dan mengaktifkan perintah yang telah di

format di dalam user interface.

4. Direct manipulation. Memungkinkan user bekerja dengan

object representation. Dengan pola ini user bisa memilih

object dan fungsi untuk memberikan hasil yang nyata secara

cepat.

Tujuan aktivitas ini adalah untuk menentukan antarmuka

sistem. Hasilnya berupa: (i). User interface: dialogue style dan

presentation forms, list lengkap dari elemen user interface,

window dan navigation diagram. (ii). System interface: class

diagram untuk external devices dan protokol untuk interaksi

dengan sistem lainnya

2.4.9 Architecture Design

Mathiassen et al. (2000), menyatakan bahwa tujuan dari

architectural design adalah untuk menstrukturkan sebuah sistem

terkomputerisasi. Hasilnya berupa struktur untuk komponen dan proses

sistem.

41

P r os es A r ch i tec t ur e

C om ponentA rch i t ect ur e

An a l y s i sDo c u me n t

Arch i t ec tu ra lSpec i f i ca t i on

C r i t er i a

Gambar 2.9 Aktivitas dalam Architectural Design

2.4.9.1 Criteria

Menurut Mathiassen et al. (2000), tidak ada cara tertentu

atau yang mudah untuk menghasilkan desain yang baik. Banyak

perusahaan menciptakan suatu standar dan prosedur untuk

memberikan jaminan kualitas atas sistem. Disinilah kegiatan

kriteria membantu dengan menetapkan prioritas desain untuk

proyek tertentu.

Sebuah desain yang baik harus memenuhi prinsip-prinsip

berikut:

1. Tidak memiliki kelemahan.

Sebuah sistem yang baik harus bisa menghilangkan semua

keraguan yang penting. Syarat ini menekankan pada

evaluasi dari kualitas sistem berdasarkan review dan

eksperimen dan membantu dalam menentukan prioritas dari

kriteria yang akan menentukan aktivitas desain. Ada

42

beberapa kriteria umum yang digunakan dalam kegiatan

desain yang terlihat pada Tabel 2.3 dibawah ini:

Criteria Measure of

Usable Kemampuan sistem yang dapat menyesuaikan lingkungan kerja organisasi.

Secure Tindakan pencegahan terhadap akses yang tidak diotorisasi ke data fasilitas.

Efficient Eksploitasi secara hemat atas fasilitas technical platform.

Correct Pemenuhan kebutuhan

Reliable Pemenuhan atas ketepatan yang diperlukan fungsi pelaksanaan.

Maintainable Biaya penempatan dan memperbaiki sistem yang rusak.

Testable Biaya dari memastikan bahwa sistem menyebar melaksanakan fungsi diharapkan.

Flexible Kemampuan sistem untuk dapat dimodifikasi terhadap perubahan sistem organisasi.

Comprehensible Tingkat kemudahan sistem untuk dapat dimengerti.

Reusable Kemampuan untuk menggunakan bagian sebuah sistem ke sistem lain yang terhubung.

Portable Biaya memindahkan sistem ke technical form lain.

Interoperable Biaya menggabungkan sistem ke sistem yang lain.Table 2.3 Criteria

2. Menyeimbangkan beberapa kriteria.

Dalam menentukan kriteria sering terjadi konflik. Oleh

karena itu, untuk menentukan kriteria mana yang akan

diutamakan dan bagaimana cara untuk menyeimbangkannya

43

dengan kriteria-kriteria yang lain bergantung pada situasi

tertentu.

3. Usable, flexible, dan comprehensible.

Kriteria ini memiliki validasi umum sehingga dapat

diterapkan pada hampir semua proyek pengembangan

sistem.

2.4.9.2 Component Architecture

Mathiassen et al. (2000,p190), mengutarakan pendapatnya

bahwa component architecture merupakan sebuah struktur

sistem dari komponen-komponen yang berhubungan. Tujuannya

adalah untuk menciptakan sebuah struktur sistem yang dapat

dipahami dan fleksibel. Hasilnya berupa class diagram dengan

spesifikasi dari komponen kompleks. Architectural pattern yang

umum digunakan, yaitu:

1.Layer architecture pattern.

Pattern ini adalah model klasik pada software. Layer

arsitektur terdiri dari beberapa komponen yang ditunjuk

sebagai layer. Design dari tiap komponen menjelaskan

tanggung jawab baik yang di atas atau di bawahnya. Layer

menunjukkan component sedangkan panah menunjukkan

depedencies yang artinya perubahan pada satu komponen akan

mempengaruhi komponen lain.

44

<<component>>Layer i +1

<<component>>Layer i

<<component>>Layer i -1

Gambar 2.10 Layered Architecture Pattern

2.Generic Architecture Pattern.

Pola ini digunakan untuk menguraikan sistem dasar yang

terdiri dari komponen interface, function, dan model. Model

component berada di layer paling bawah, kemudian

dilanjutkan oleh function layer dan paling atas adalah

interface.

< < c o m p o n e n t >>U s e r I nt er f ac e

< < c o m p o n e n t >>S y s t em I nt er f ac e

<<component>>I nterface

< < c o m p o n e n t >>F u n c t i on

< < c o m p o n e n t >>M o d e l

< < c o m p o n e n t >>U I S

< < c o m p o n e n t >>D B S

< < c o m p o n e n t >>N S

< < c o m p o n e n t >>T e c h n i ca l l P l at f orm

Gambar 2.11 Generic Architecture Pattern

45

3.Client Server Architecture Pattern.

Client server architecture pattern dibangun untuk mengatasi

sistem terdistribusi dalam beberapa proses yang tersebar.

Architecture ini terdiri dari sebuah server dan beberapa client.

Server memiliki kumpulan operation yang dapat digunakan

oleh client. Identifikasi komponen, di dalam perancangan

sistem atau subsistem, pada umumnya dimulai dengan layer

architecture dan client server architecture di mana keduanya

merupakan dua layer yang berbeda, tetapi saling melengkapi.

Perbedaannya adalah layer architecture memberikan

hierarchy discipline, sedangkan client server architecture

merupakan ekspresi dari pemikiran jaringan. Dari component

architecture akan menghasilkan class diagram with

specification.

componentClient 1

componentClient 2

componentclient n

componentServer

Gambar 2.12 Client Server Architecture Pattern

46

Client dan server dianggap sebagai sub sistem individu yang

masing-masing memiliki komponen, yaitu: user interface

(U), function (F), dan model (M).

Client Server ArchitectureU U+F+M Distributed presentationU F+M Local presentation

U+F F+M Distributed functionalityU+F M Centralized data

U+F+M M Distributed dataTabel 2.4 Form Distributed Pada Client Server Architecture

2.4.9.3 Process Architecture

Process architecture adalah struktur eksekusi sistem yang

merupakan gabungan dari proses-proses interdependen,

dilakukan untuk mendefinisikan struktur fisik dari sistem.

Hasilnya berupa sebuah deployment diagram. Pada aktivitas ini,

terdapat 3 jenis pattern, yaitu:

1. Centralize Pattern.

Pola ini menyimpan semua data pada server pusat dan user

hanya bisa melihat user interface saja. Keuntungan dari pola

ini adalah dapat diiplementasikan pada client secara murah,

semua data konsisten karena hanya berada disatu tempat

saja, strukturnya mudah dimengerti dan diimplementasikan

serta kemacetan jaringannya moderat.

47

Cl i ent

User I nterface

Si st em I nterf ace

Server

User_I nt erf ace Si stem_I nterface

Funct i on

Model

M o reC l ie n t

Gambar 2.13 Centralize Pattern

2. Distributed Pattern.

Pada pola ini, semua terdistribusi ke user atau client dan

server hanya menyebarkan model yang telah di-update di

antara client. Keuntungan utama dari pola ini adalah waktu

akses yang rendah, sehingga tidak terjadi kemacetan

jaringan, kinerja lebih maksimal, dan back-up data banyak.

Kerugian dalam pola ini adalah banyaknya data redundant

sehingga konsistensi data terancam, kemacetan jaringan

tinggi karena semua update harus disebar kepada semua

client, kebutuhan teknis yang canggih, arsitekturnya lebih

sulit dimengerti dan diimplementasikan.

48

Server

Si st em I nt erf ace

Cl i ent

User_I nt erf ace Si st em_I nt er f ace

Funct i on

Model

M o r eC l ien t

Gambar 2.14 Distributed Pattern

3. Decentralized Pattern Client.

Pola ini berada di antara kedua pola diatas. Pada pola ini

client memiliki data tersendiri sehingga data umum hanya

berada pada data tersebut, sedangkan client menyimpan

data yang merupakan milik bagian application-domain

client tersebut. Keuntungan pola ini adalah konsistensi data,

karena tidak ada duplikasi data antara client dengan client

lain ataupun dengan server, lalu lintas jaringan jarang

karena jaringan hanya digunakan ketika data umum di

server di-update. Kekurangan pola ini adalah bahwa semua

prosesor harus mampu melakukan fungsi yang kompleks

dan memelihara model dalam jumlah besar, sehingga akan

meningkatkan biaya hardware.

49

server

Si stem Interf ace

Cl i ent

User_I nterface Si stem_Interface

Function

Model

M o reC l ie n t

User I nterface

functi on

model

Gambar 2.15 Decentralized Pattern

Sumber daya yang umumnya digunakan bersama, yaitu:

Processor. Penggunaan prosesor bersama terjadi bila ada dua

atau lebih proses yang dieksekusi secara bersamaan pada satu

processor.

Program component. Komponen program digunakan bersama

bila terdapat dua atau lebih proses yang secara bersamaan

memanggil operasi pada komponen.

External device. External device dapat digunakan bersama

oleh dua atau lebih proses bersamaan. Misalnya penggunaan

printer yang terhubung melalui network.

50

2.4.10 Component Design

Menurut Mathiassen et al. (2000, p231), component adalah

kumpulan dari bagian-bagian program serta keseluruhan dan memiliki

tanggung jawab yang didefinisikan dengan baik dengan tujuan untuk

menetapkan kebutuhan dari implementasi dalam sebuah architectural

framework.

Tujuan dari kegiatan rancangan komponen ini adalah untuk

menentukan implementasi kebutuhan dalam rangka kerangka arsitektural.

Kegiatan rancangan komponen bermula dari spesifikasi arsitektural dan

kebutuhan sistem, sedangkan hasil dari kegiatan ini adalah spesifikasi

dari komponen yang saling berhubungan. Dalam component design

terdapat beberapa model, yaitu: model component dan function

component.

Gambar 2.16 Component Design

2.4.10.1 Model Component

Mengacu pada Mathiassen et al. (2000), model analisis

problem domain menggambarkan kebutuhan sistem. Kebutuhan

51

sistem kemudian diimplementasikan dalam model component.

Oleh karena itu, dapat disimpulkan bahwa model component

adalah bagian dari sistem yang mengimplementasikan model

problem domain.

Tujuan dari model component adalah untuk mengirimkan

data sekarang dan historik ke function, interface, dan pengguna

dan sistem yang lain. Konsep utama dalam desain model

component adalah struktur. Aktivitas yang dilakukan dalam

model-component design, yaitu:

1. Mengidentifikasikan private events.

Private events adalah event-event yang hanya terdapat

pada satu objek.

2. Mengidentifikasikan common events.

Common events adalah events yang bersifat umum dan

mempengaruhi beberapa objek.

3. Restrukturisasi classes.

Adalah penyederhanaan class diagram yang telah direvisi,

dapat dilakukan melalui generalisasi, asosiasi dan

embedded iteration.

Hasil dari kegiatan model component adalah revisi dari

class diagram dari kegiatan analisis. Kegiatan revisi atau

restrukturisasi class dapat terjadi pada:

52

1. Generalization. Jika terdapat dua class dengan attribute

yang sama maka dapat dibentuk class baru (revised class).

2. Association. Jika terjadi hubungan many-to-many.

3. Embedded iterations. Merupakan embedded didalam

statechart diagram. Misalnya jika sebuah class terdapat

statechart diagram yang mempunyai tiga iterative events,

maka kita dapat membentuk tiga class di dalam perancangan

model.

2.4.10.2 Function Component

Function component merupakan bagian dari sebuah sistem

yang mengimplementasikan kebutuhan-kebutuhan fungsional.

Tujuan dari function component adalah untuk menunjukkan

implementasi dari functions. Hasilnya berupa class diagram

dengan operations dan spesification dari operation yang

kompleks.

2.4.10.3 Connecting Component

Connecting component berfungsi sebagai penghubung

antara komponen untuk mendapatkan fleksibilitas dan

rancangan yang dapat dipahami. Tujuannya adalah untuk

menghubungkan komponen-komponen dari sistem.Terdapat dua

jenis pengukuran, yaitu:

53

1. Coupling: ukuran kedekatan dua class atau component

yang terhubung. Ada empat jenis coupling, yaitu:

o Outside coupling: sebuah class atau component

menunjuk langsung pada property umum dari class

atau component lain.

o Inside coupling: sebuah operasi menunjuk langsung

pada yang lain, property pribadi di dalam class yang

sama.

o Coupling from below: sebuah class yang

diistimewakan menunjuk langsung pada property

pribadi di dalam super class.

o Sideways coupling: sebuah class menunjuk langsung

pada property pribadi di dalam class lainnya.

2. Cohesion: ukuran seberapa baiknya sebuah class atau

component saling terkait. Hasil aktivitas ini berupa class

diagram dari komponen-komponen yang terlibat.

2.4.11 Diagram Dalam Analisis Dan Perancangan Berorientasi Objek

2.4.11.1 Rich Picture

Rich picture adalah sebuah gambaran informal yang

digunakan oleh pengembang sistem untuk menyatakan

pemahaman mereka terhadap situasi dari sistem yang sedang

berlangsung. Rich picture juga dapat digunakan sebagai alat

54

yang berguna untuk memfasilitasi komunikasi yang baik antara

pengguna dalam sistem.

2.4.11.2 Class Diagram

Aktivitas class merupakan aktivitas pertama dalam

analisis problem domain. Tugas utama dalam aktivitas ini

adalah abstraksi fenomena dari problen domain dalam object

dan event, klasifikasi object dan even, pemilihan class dan event

yang informasinya akan dipelihara sistem. Maka, class diagram

merupakan kumpulan class dan hubungannya yang komplek

dengan class lainnya.

2.4.11.3 Statechart Diagram

Statechart diagram menggambarkan tentang tingkah laku

umum dari semua objek kedalam sebuah kelas yang spesifik dan

terdiri dari kondisi (state) dan perubahan diantara objek-objek

tersebut.

2.4.11.4 Use Case Diagram

Use-case diagram menunjukkan hubungan antara aktor

dan use-case. Aktor dan use-case merupakan dua elemen utama

dalam use-case diagram yang saling memberikan peran satu

sama lain.

55

2.4.11.5 Sequence Diagram

Sequence diagram menggambarkan tentang hubungan

interaksi antara beberapa objek dalam jangka waktu tertentu.

Sebuah sequence diagram dapat mengumpulkan rincian situasi

yang komplek dan dinamis yang melibatkan beberapa objek

yang dihasilkan dari class pada class diagram.

2.4.11.6 Navigation Diagram

Navigation diagram adalah jenis statechart diagram yang

khusus, yang berfokus pada kedinamisan user interface secara

keseluruhan. Navigation diagram tidak terdapat dalam UML.

Sebuah window dalam navigation diagram merepresentasikan

sebuah kondisi (state) yang berisi nama dan icon.

2.4.11.7 Deployment Diagram

Deployment diagram menggambarkan tentang konfigurasi

sistem dalam bentuk prosesor dan objek yang dilampirkan pada

prosesor.

2.4.11.8 Window Diagram

Window diagram mendeskripsikan rancangan sebuah

window tunggal dan termasuk rician bagan dari setiap elemen

window. Window diagram tidak terdapat dalam UML.