BAB 2 LANDASAN TEORI
2.1.
Pengertian Sistem Informasi Menurut O`Brein, James A (2003) sistem informasi adalah “any
organized combination of people, hardware, software, communications networks, and data resources that collects, transforms, and disseminates information in an organization”(p. 7). Menurut Krismiaji (2002) “sistem informasi adalah cara-cara yang diorganisasikan untuk mengumpulkan, memasukkan, mengolah dan menyimpan data, dan cara-cara yang diorganisasi untuk menyimpan, mengelola, mengendalikan, dan melaporkan informasi yang sedemikian rupa sehingga sebuah organisasi dapat mencapai tujuan yang telah ditetapkan”(h. 16). Jadi dapat ditarik kesimpulan bahwa sistem informasi adalah mengorganisasikan sumber daya yang terdiri dari orang, perangkat keras dan
perangkat
lunak
computer
yang
saling
berinteraksi
menyediakan infomasi yang berguna bagi penggunanya.
untuk
8
2.2.
Pengertian Sistem Informasi Akuntansi Pembelian dan Persediaan
2.2.1 Pengertian Sistem Akuntansi Menurut Mulyadi (2001) “sistem akuntansi adalah organisasi formulir, catatan dan laporan yang dikoordinasi sedemikian rupa untuk menyediakan informasi keuangan yang dibutuhkan oleh manajemen guna memudahkan pengelolaan perusahaan”(h. 3). Menurut Bodnar dan Hopwood yang diterjemahkan oleh Amir Abadi Jusuf (2000) “sistem akuntansi adalah suatu organisasi yang terdiri dari metode dan catatan–catatan yang dibuat untuk mengidentifikasikan, mengumpulkan, menganalisis, mencatat, dan melaporkan transaksitransaksi organisasi dan menyelenggarakan pertanggungjawaban bagi aktiva dan kewajiban yang berkaitan”(h. 181). Dengan demikian, sistem akuntansi adalah koordinasi dari formulir, catatan, prosedur, alat-alat yang digunakan untuk mengolah data usaha sedemikian rupa sehingga dapat menyediakan informasi keuangan untuk pihak yang berkepentingan.
2.2.2. Pengertian Sistem Informasi Akuntansi Menurut
Wilkinson, et al. (2000) sistem informasi akuntansi
adalah “unified structure within an entity, such as a business firm, that employs physical resources and other components to transforms economic
9
data into accounting information, with the purpose of satisfying the information needs of a variety of users”(p. 7). Menurut Krismiaji (2002) “sistem informasi akuntansi adalah sebuah sistem yang memproses data dan transaksi guna menghasilkan informasi yang bermanfaat untuk merencanakan, mengendalikan, dan mengoperasikan bisnis”(h. 4). Menurut Bodnar dan Hopwood yang diterjemahkan oleh Amir Abadi Jusuf (2000) “sistem informasi akuntansi adalah sebagai sistem yang berbasis komputer yang dirancang untuk mengubah data akuntansi menjadi informasi, tetapi istilah sistem informasi akuntansi diperluas mencakup siklus-siklus pemrosesan transaksi, penggunaan teknologi informasi, dan pengembangan sistem informasi”(p. 6). Jadi dapat ditarik kesimpulan bahwa sistem informasi akuntansi adalah kumpulan sumber daya yaitu orang dan peralatan yang digunakan untuk menyediakan informasi akuntansi, informasi keuangan atau informasi – informasi lain yang diperoleh pada saat pemrosesan transaksi akuntansi.
2.2.3. Sistem Akuntansi Pembelian Menurut Mulyadi (2001) sistem akuntansi pembelian digunakan dalam perusahaan untuk pengadaan barang yang diperlukan perusahaan. Transaksi pembelian dapat digolongkan menjadi dua : pembelian lokal
10
dan impor. Pembelian lokal adalah pembelian dari pemasok dalam negeri, sedangkan impor adalah pembelian dari pemasok luar negeri(h. 299).
2.2.3.1 Fungsi yang Terkait Menurut Mulyadi (2001) fungsi yang terkait dalam sistem akuntansi pembelian adalah sebagai berikut : •
Fungsi Gudang Dalam sistem akutansi pembelian, fungsi gudang bertanggung jawab untuk mengajukan permintaan pembelian sesuai dengan posisi persediaan yang ada di gudang dan untuk menyimpan barang yang telah diterima oleh fungsi penerimaan. Untuk barangbarang yang langsung pakai (tidak diselenggarakan persediaan barang di gudang), permintaan pembelian diajukan oleh pemakai barang.
•
Fungsi Pembelian Fungsi pembelian bertanggung jawab untuk memperoleh informasi mengenai harga barang, menentukan pemasok yang dipilih dalam pengadaan barang, dan mengeluarkan order pembelian kepada pemasok yang dipilih. Fungsi pembelian berada di tangan Bagian Pembelian.
•
Fungsi Penerimaan
11
Dalam sistem akutansi pembelian, fungsi ini bertanggung jawab untuk melakukan pemeriksaan terhadap jenis, mutu, dan kuantitas barang diterima dari pemasok guna menentukan dapat atau tidaknya barang tersebut diterima oleh perusahaan. Fungsi ini juga bertanggung jawab untuk menerima barang dari pembeli yang berasal dari transaksi retur penjualan. Fungsi penerimaan berada di tangan Bagian Penerimaan. •
Fungsi Akuntansi Fungsi akuntansi yang terkait dalam transaksi pembelian adalah fungsi pencatat utang dan fungsi pencatat persediaan. Dalam sistem akutansi pembelian, fungsi pencatat utang bertanggung jawab untuk mencatat transaksi pembelian ke dalam register bukti kas keluar dan untuk menyelenggarakan arsip dokumen sumber (bukti kas keluar) yang berfunsi sebagai catatan utang atau menyelenggarakan kartu utang sebagai buku pembantu utang. Dalam sistem akutansi pembelian, fungsi pencatat persediaan bertanggung jawab untuk mencatat harga pokok persediaan barang yang dibeli ke dalam kartu persediaan. Fungsi pencatat utang berada di tangan Bagian Utang sedangkan fungsi pencatat persediaan berada di tangan Bagian Kartu Persediaan(h. 300).
12
2.2.3.2.Dokumen Sistem Akuntansi Pembelian Menurut
Mulyadi (2001) pada dasarnya terdapat enam buah
catatan yang paling penting atau utama dalam sistem akuntansi pembelian •
Surat permintaan pembelian
•
Surat permintaan penawaran harga
•
Surat order pembelian
•
Laporan penerimaan barang
•
Surat perubahan order
•
Bukti kas keluar(h. 303)
2.2.3.3 Catatan Sistem Akuntansi Pembelian Menurut Mulyadi (2001) catatan akuntansi yang digunakan untuk mencatat transaksi pembelian adalah : •
Register bukti kas keluar.
•
Jurnal pembelian
•
Kartu utang
•
Kartu persediaan(h. 308)
2.2.4. Pengertian Persediaan Menurut
Mulyadi
(2001)
dalam
perusahaan
manufaktur,
persediaan terdiri dari : persediaan produk jadi, persediaan produk dalam proses, persediaan bahan baku, persediaan bahan penolong, persediaan
13
bahan habis pakai pabrik, persediaan suku cadang. Dalam perusahaan dagang persediaan hanya terdiri dari satu golongan, yaitu persediaan barang dagangan, yang merupakan barang yang dibeli untuk tujuan dijual kembali(h. 553). Menurut Krismiaji (2002) persediaan dalam perusahaan dagang menggunakan sistem persediaan untuk menjamin bahwa barang tersedia untuk dijual kembali. Sistem persediaan merupakan sebuah sistem yang memelihara catatan persediaan dan memberitahu manajer apabila jenis barang tertentu memerlukan penambahan(h. 367). Dengan demikian persediaan dalam perusahaan dagang adalah barang yang dibeli perusahaan untuk tujuan dijualkan kembali kepada pihak lain, dengan mencatatkannya pada dokumen pencatatan persediaan dimana dokumen itu akan digunakan sebagai bukti pencatatan apabila barang persediaan perlu dibeli kembali.
2.2.4.1.Manajemen Persediaan Menurut Handoko (2001) sistem persediaan adalah serangkaian kebijaksanaan dan pengendalian yang memonitor tingkat persediaan yang bertujuan untuk meminimumkan biaya total. Menurut jenisnya persediaan dapat dibedakan menjadi : •
Persediaan bahan mentah, yaitu persediaan barang berwujud yang digunakan dalam proses produksi.
14
•
Persediaan komponen-komponen rakitan, yaitu persediaan barangbarang yang terdiri dari komponen-komponen yang diperoleh dari perusahaan lain, dimana secara langsung dapat dirakit menjadi suatu produk.
•
Persediaan bahan pembantu atau penolong, yaitu persediaan barang-barang yang diperlukan dalam proses produksi, tetapi tidak merupakan bagian barang jadi.
•
Persediaan barang dalam proses, yaitu persediaan barang-barang yang merupakan keluaran dari tiap-tiap bagian dalam proses produksi atau yang diolah menjadi suatu bentuk.
•
Persediaan barang jadi, yaitu persediaan barang-barang yang telah selesai diproses atau diolah(h. 334).
2.2.4.2 Metode Pencatatan Persediaan Menurut Mulyadi (2001) terdapat dua macam metode pencatatan persediaan, yaitu : •
Metode mutasi persediaan Adalah dimana setiap mutasi persediaan dicatat dalam kartu persediaan, cocok digunakan dalam penentuan biaya bahan baku dalam perusahaan yang harga pokok produknya dikumpulkan dengan metode harga pokok pesanan.
•
Metode persediaan fisik
15
Dalam metode ini hanya tambahan persediaan dari pembelian saja yang dicatat, sedangkan mutasi berkurangnya persediaan karena pemakaian tidak dicatat dalam kartu persediaan. Cocok digunakan dalam penentuan biaya bahan baku dalam perusahaan yang harga pokok produknya dikumpulkan dengan metode harga pokok proses(h. 556).
2.3.
Pengendalian Internal Menurut Mulyadi (2001) “sistem pengendalian internal meliputi
struktur organisasi, metode dan ukuran-ukuran yang dikoordinasikan untuk menjaga kekayaan organisasi, mengecek ketelitian dan keandalan data akuntansi, mendorong efisiensi dan mendorong dipatuhinya kebijakan manajemen”(h. 163). Menurut Romney and Steinbart (2004) pengendalian internal adalah “The plan of organization and the method a business used to safe guard assets, provide accurate and reliable information, promote and improve operational efficiency and encourage adherence to prescribed management policies ” (p. 195). Menurut Jones dan Rama (2004) pengendalian internal adalah “ The rules, policies, procedures, and information system used to ensure that a company’s financial data are accurate and reliable and to protect a company’s assets from loss or thef ” (p. 15).
16
Jadi dapat ditarik kesimpulan bahwa pengendalian internal adalah aturan, kebijakan, prosedur dan system informasi yang dirancang untuk memastikan data keuangan perusahaan tepat dan dapat diandalkan, untuk meningkatkan efisiensi dan efektifitas operasional dan untuk memenuhi ketaatan terhadap hukum dan peraturan yang berlaku.
2.3.1. Pengendalian Internal Sistem Akuntansi Pembelian Menurut Mulyadi (2001) unsur-unsur pengendalian internal terdiri dari : •
Organisasi o Fungsi pembelian harus terpisah dari fungsi penerimaan. o Fungsi pembelian harus terpisah dari fungsi akuntansi. o Fungsi penerimaan harus terpisah dari fungsi penyimpanan barang. o Transaksi pembelian harus dilaksanakan oleh fungsi gudang, fungsi pembelian, fungsi penerimaan, fungsi akuntansi.
Tidak
ada
transaksi
pembelian
yang
dilaksanakan secara lengkap oleh hanya satu fungsi tersebut. •
Sistem otorisasi dan prosedur pencatatan
17
o Surat permintaan pembelian diotorisasi oleh fungsi gudang, untuk barang yang disimpan dalam gudang, atau oleh fungsi pemakai barang, untuk barang yang langsung pakai. o Surat order pembelian diotorisasi oleh fungsi pembelian atau pejabat yang lebih tinggi. o Laporan penerimaan barang diotorisasi oleh fungsi penerimaan barang. o Bukti kas keluar diotorisasi oleh fungsi akuntansi atau pejabat yang lebih tinggi. o Pencatatan terjadinya utang didasarkan pada bukti kas keluar yang didukung oleh surat order pembelian, laporan penerimaan barang, dan faktur dari pemasok. o Pencatatan ke dalam kartu utang dan register bukti kas keluar ( voucher register ) diotorisasi oleh fungsi akuntansi. •
Praktik yang sehat o Surat permintaan pembelian bernomor urut tercetak dan pemakaiannya dipertanggungjawabkan oleh fungsi gudang. o Surat order pembelian bernomor urut tercetak dan pemakaiannya pembelian.
dipertanggungjawabkan
oleh
fungsi
18
o Laporan penerimaan barang bernomor urut tercetak dan pemakaiannya
dipertanggungjawabkan
oleh
fungsi
penerimaan. o Pemasok dipilih berdasarkan jawaban penawaran harga bersaing dari berbagai pemasok. o Barang
hanya
diperiksa
dan
diterima
oleh
fungsi
penerimaan jika fungsi ini telah menerima tembusan surat order pembelian dari fungsi pembelian. o Fungsi penerimaan melakukan pemeriksaan barang yang diterima dari pemasok dengan cara menghitung dan menginspeksi barang tersebut dan membandingkan dengan tembusan surat order pembelian. o Terdapat pengecekan terhadap harga, syarat pembelian, dan ketelitian perkalian dalam faktur dari pemasok sebelum faktur tersebut diproses untuk dibayar. o Catatan yang berfungsi sebagai buku pembantu utang secara periodik direkonsiliasi dengan rekening kontrol utang dalam buku besar. o Pembayaran faktur dari pemasok dilakukan sesuai dengan syarat pembayaran guna mencegah hilangnya kesempatan untuk memperoleh potongan tunai.
19
o Bukti kas keluar beserta dokumen pendukungnya dicap “lunas” oleh fungsi pengeluaran kas setelah cek dikirimkan kepada pemasok(h. 312).
2.3.2. Pengendalian Internal Sistem Persediaan. Menurut Render dan Heizer (2001) elemen yang harus ada untuk mendukung pengendalian internal yang baik atas persediaan adalah : •
Pemilihan karyawan, pelatihan, dan disiplin yang baik. Hal-hal ini tidak pernah mudah dilakukan, tetapi sangat penting dalam bisnis makanan, perdagangan besar, dan operasi bisnis eceran di mana karyawannya mempunyai akses kepada barang-barang yang langsung dikonsumsi.
•
Pengendalian yang ketat atas barang yang dating. Melalui sistem kode batang (barcode).
•
Pengendalian yang efektif atas semua barang yang ke luar dari fasilitas(h. 318)
2.4. Reorder Point, Safety Stock, dan EOQ •
Reorder Point (ROP) Menurut Render dan Heizer (2001) “ROP adalah saat persediaan mencapai sebelum nol, perusahaan memesan lagi dan dengan seketika barang yang dipesan diterima” (h. 324).
20
Perhitungan ROP menggunakan rumus : ROP = d x L Dimana : ROP = titik pemesanan ulang
•
d
= permintaan per hari
L
= lead time, waktu pengiriman
EOQ (Economic Order Quantity) Menurut Render dan Heizer (200) “EOQ adalah suatu rumus untuk menentukan kuantitas pesanan yang akan meminumkan biaya persediaan total.” (h. 322). Perhitungan EOQ menggunakan rumus : EOQ = √ 2 D S H Dimana : EOQ = jumlah optimal pemesanan barang. D
= permintaan tahunan barang persediaan dalam unit.
S
= biaya pemasangan atau pemesanan untuk setiap
pemesanan. H •
= biaya penahanan atau penyimpanan per unit per tahun.
Safety Stock Menurut Handoko (2001) untuk menghadapi permintaan yang bervariasi perusahaan biasanya mempunyai tingkat persediaan tertentu sebagai pengaman disebut safety atau buffer stock(h. 355).
21
2.5.
Pengertian Metode Analisis dan Desain Berorientasi Objek
2.5.1.
Pengertian Object Object merupakan dasar dalam object oriented analysis and
design (00A&D). Menurut Mathiassen L., et al (2000) object adalah “ an entity with identity, state, and behaviour” (p. 4). Setiap object tidak digambarkan secara sendiri - sendiri, melainkan istilah class digunakan untuk menggambarkan kumpulan-kumpulan object – object.
2.5.2. Object-Oriented Menurut Mathiassen L., et al (2000) keuntungan dari objectoriented adalah : •
Merupakan
konsep
umum
yang
dapat
digunakan
untuk
memodelkan hampir semua fenomena yang ada di dunia dengan menggunakan bahasa alami. o Noun menjadi object atau class. o Verb menjadi behaviour. o Adjective menjadi attributes. •
Menyediakan informasi yang jelas mengenai context dari sistem.
•
Mengurangi biaya maintenance atau development(p. 5).
22
2.5.3. Object-Oriented Analysis and Design (00A&D) Menurut Mathiassen L., et al (2000) terdapat 4 aktivitas utama dalam OOA&D, yaitu Problem Domain Analysis, Application Domain Analysis, Architectural Design, dan Component Design(p. 14). 4 Aktivitas utama dalam OOA&D dapat dilihat pada gambar 2.1 di bawah.
System Choice System Definition
Proble m domain
Requiremen ts
Applicatio n domain
Compon ent Model
Specifications for
Specifications for
Architectura l
Gambar 2.1 Aktivitas utama dalam OOA&D ( Sumber : Mathiassen L. Et al. , 2000, p15)
2.5.4. Rich Picture Menurut Mathiassen L. Et al. (2000) “rich picture adalah sebuah gambaran informal yang digunakan oleh pengembang sistem untuk menyatakan pemahaman mereka terhadap situasi dari sistem yang sedang berlangsung” (p. 26). Rich picture juga dapat digunakan sebagai alat yang
23
berguna untuk memfasilitasi komunikasi yang baik antara pengguna dalam sistem. Rich picture difokuskan pada aspek-aspek penting dari sisem tersebut, yang ditentukan sendiri oleh pengembang sistem dengan mengunjungi perusahaan untuk melihat bagaimana perusahaan beroperasi, berbicara dengan banyak orang untuk mengetahui apa yang harus terjadi atau seharusnya terjadi, dan mungkin melakukan beberapa wawancara formal.
2.6.
Analisa Problem Domain Menurut Mathiassen L. Et al. (2000)” problem domain adalah
bagian dari konteks yang diatur, dimonitor, atau dikendalikan oleh sistem” (p. 45). Analisis problem-domain memfokuskan pada informasi apa yang harus ditangani oleh sistem dan menghasilkan sebuah model yang merupakan gambaran dari kelas-kelas, objek-objek, struktur dan perilaku (behaviour) yang ada dalam problem domain. Untuk lebih jelasnya kegiatan-kegiatan yang dilakukan dalam analisis problem-domain dapat dilihat pada table 2.1 berikut ini.
24
Tabel 2.1. Kegiatan Problem-Domain Analysis Kegiatan
Isi
Konsep
Kelas
Objek dan event yang merupakan Kelas, objek, event bagian dari problem domain
Struktur
Bagaimana kelas dan objek saling Generalisasi, agregasi, asosiasi, berkaitan
Behaviour
dan cluster
Property dinamik yang dimiliki Event trace, behavioural pattern, objek
dan attribute ( Sumber : Mathiassen L. Et al. , 2000, p48)
2.6.1. Class Menurut Mathiassen L. Et al. (2000) class adalah “a description of collection of objects sharing structure, behavioural pattern, and attributes.” (p. 4). Menurut 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 object dan event; klasifikasi object dan event; pemilihan class dan event yang akan dipelihara informasinya oleh sistem. Pemilihan class tersebut bertujuan untuk mendefinisikan dan membatasi problem domain. Sementara pemilihan kumpulan event yang
25
dialami atau dilakukan oleh satu atau lebih object bertujuan untuk membedakan tiap-tiap class dalam problem domain Kegiatan class akan menghasilkan table event. Dimensi horizontal dari table event berisi classes yang terpilih, sementara dimensi vertikal berisi event-event terpilih dan tanda cek digunakan untuk mengindikasikan objects dari class yang berhubungan dalam event tertentu. Untuk lebih jelasnya, table event dapat dilihat pada tabel 2.2 berikut ini. Tabel 2.2 Contoh Table Event Class Event Customer
Assistant
Reserved
V
Cancelled
V
Treated
V
Apprentice
Appointment
Plan
V
V
V
V
V V
Employed
V
V
Resigned
V
V
Graduated Agreed
V V
V
( Sumber : Mathiassen L. Et al. , 2000, p50)
2.6.2. Structure Menurut Mathiassen Et al. (2000) “tujuan structure adalah untuk mendeskripsikan hubungan struktural antara class dan object”(p. 69).
V
26
Sumber dari tahap ini adalah event table yang dihasilkan dari tahap sebelumnya, sedangkan hasil akhirnya adalah membuat Class Diagram. yaitu diagram yang menyediakan gambaran ikhtisar problem domain yang bertalian secara logis dengan menggambarkan seluruh hubungan struktural antara classes dan objects di dalam model. Menurut Mathiassen Et al. (2000) terdapat dua tipe struktur dalam Object-Oriented, yaitu : •
Class Structure, mengekspresikan hubugan konseptual yang statis antar class. Hubungan statis ini tidak akan berubah, kecuali terjadi perubahan pada deskripsinya. Representasi class structure dapat dilihat pada gambar 2.3 di bawah. Class structure dibagi menjadi dua macam yaitu : o Generalization Strucuture Menurut
Mathiassen Et al. (2000) “generalization
structure adalah hubungan antara dua atau lebih subclass dengan satu atau lebih superclass” (p. 72). Sebuah class yang umum (superclass) mendeskripsikan property umum kepada group dari special class (subclass). Atau dengan kata lain, terjadi penurunan attributes dan behaviour dari superclass, tetapi subclass juga diperkenankan untuk memiliki attributes dan behaviour tambahan. Secara ilmu
27
bahasa, generalization structure diekspresikan dengan formula “is a”, yang direpresentasikan pada gambar 2.2 di bawah. passenger car
taxi
private car
Gambar 2.2 Generalization Strucuture ( Sumber : Mathiassen L. Et al. , 2000, p73) o Cluster Menurut Mathiassen L. Et al. (2000) “cluster
adalah
kumpulan dari class yang berhubungan” (p. 74). Cluster digambarkan dengan notasi file folder yang melingkupi class-class yang saling berhubungan didalamnya. Classclass dalam satu cluster biasanya memiliki hubungan antara
generalization
atau
aggregation.
Sedangkan
hubungan class dengan cluster yang berbeda biasanya berupa association structure.
28
generalization
Gambar 2.3 Notasi Class Structure ( Sumber : Mathiassen L. Et al. , 2000, p337) •
Object structure, mengekspresikan hubungan dinamis dan konkret antar object. Hubungan ini dapat berubah secara dinamis tanpa mempengaruhi
perubahan
deskripsinya.
Biasanya
terdapat
multiplicity yang menspesifikasikan jumlah dari object yang berelasi. Multiplicity dapat berubah string of numbers dan penyebaran interval dengan koma, seperti “0,3,7,9,.. 13,19,*”,”*” disebut many ; dan 0..*”. Representasi object structure dapat dilihat pada gambar 2.4 di bawah. Ada 2 macam object structure yaitu : o Aggregation structure Menurut Mathiassen L. Et al. (2000) aggregation structure adalah hubungan antara dua atau lebih object. Sebuah superior object (whole) memiliki beberapa object (parts). Secara ilmu bahasa, aggregation structure diekspresikan dengan formulasi “has a”, “a part-of”, atau “is-ownedby”.
Terdapat
3
buah
tipe
aggregation
(Mathiassen L. Et al. (2000, p79), yaitu :
structure
29
Whole-part
Container-content
Union-member
o Association structure Menurut Mathiassen L. Et al. (2000) association structure mendefiniskan hubungan antar dua atau lebih object, tetapi berbeda dengan aggregation(p. 76) Hubungan antar classclass pada aggregation mempunyai pertalian yang kuat sedangkan pada association tidak kuat. Secara ilmu bahasa, association
structure
diekspresikan
dengan
formula
“knows” atau “associated-with”. Representasi association structure dapat dilihat pada gambar 2.5 di bawah ini.
*
-a..b
*
-a..b
*
-c..d
*
-c..d
Ket : a-d adalah multiplicity Gambar 2.4 Notasi object structure ( Sumber : Mathiassen L. Et al. , 2000, p337)
30
car
person 0..*
1..*
Gambar 2.5 Association Structure ( Sumber : Mathiassen L. Et al. , 2000, p77)
2.6.3. Behaviour Menurut Mathiassen Et al. (2000) kegiatan behaviour adalah kegiatan terakhir dalam analisa problem-domain yang bertujuan untuk memodelkan apa yang terjadi (perilaku dinamis) dalam problem-domain system sepanjang waktu(p. 89). Tugas utama dalam kegiatan ini adalah : menggambarkan pola perilaku (behavioral pattern) dan attribute dari setiap kelas. Hasil dari kegiatan ini adalah statechart diagram yang dapat dilihat pada gambar 2.6 dibawah ini :
Gambar 2.6 Statechart diagram ( Sumber : Mathiassen L. Et al. , 2000, p90) Perilaku dari suatu object ditentukan oleh urutan event-event (event trace) yang harus dilewati oleh object tertentu tersebut sepanjang waktu.
31
Sebagai contoh : kelas “pelanggan” harus melalui event trace : account opened – amount deposited – amount withdrawen – amount deposited – account closed sepanjang hidupnya. Tiga jenis notasi untuk behavioral pattern yaitu sequence dimana event muncul satu per satu secara berurutan; selection dimana terjadi pemilihan satu event dari sekumpulan event yang muncul; iteration dimana sebuah event muncul sebanyak nol atau beberapa kali.
2.7.
Application Domain Analysis Menurut Mathiassen Et al. (2000) application domain adalah
organisasi yang mengatur, memonitor, atau mengendalikan problem domain.(p.115).
Analisis
application-domain
memfokuskan
pada
bagaimana target sistem akan digunakan dengan menentukan kebutuhan function dan antarmuka sistem. Untuk lebih jelasnya kegiatan-kegiatan yang dilakukan dalam analisis application-domain dapat dilihat pada table 2.3 berikut ini Tabel 2.3 Kegiatan Analisis Application Domain Kegiatan
Isi
Konsep
Usage
Bagaimana sistem berinteraksi dengan Use case dan actor orang lain dan sistem lain dalam konteks
Function
Bagaimana kemampuan sistem dalam Function memproses informasi
32
Kegiatan
Isi
Konsep
Interface
Kebutuhan antarmuka dari sistem target
Interface, user interface dan system interface
( Sumber : Mathiassen L. Et al. , 2000, p117)
2.7.1. Usage Menurut Mathiassen Et al. (2000) kegiatan usage merupakan kegiatan pertama dalam analisis application domain yang bertujuan untuk menentukan bagaimana aktor-aktor yang merupakan pengguna atau sistem lain berinteraksi dengan sistem yang dituju. Interaksi antara actor dengan sistem tersebut dinyatakan dalam use case(p. 119). Menurut Fowler yang diterjemahkan oleh Penerbit Andi (2005) “use case adalah teknik untuk merekam persyaratan fungsional sebuah sistem” (h. 141). Use case mendeskripsikan interaksi tipikal antara para pengguna sistem dengan sistem itu sendiri, dengan memberi sebuah narasi tentang bagaimana sistem tersebut digunakan. Menurut Mathiassen Et al. (2000) use case dapat dimulai oleh aktor atau oleh sistem target. Hasil dari analisis kegiatan usage ini adalah deskripsi lengkap dari semua use case dan actor yang ada yang digambarkan dalam table actor atau use case diagram(p. 120). Cara untuk mengidentifikasi aktor adalah dengan mengetahui alasan actor menggunakan sistem. Masing-masing aktor memiliki alasan
33
yang berbeda untuk menggunakan sistem. Cara lainnya yaitu dengan melihat peran dari actor seperti yang dinyatakan oleh use case dimana actor tersebut terlibat. Masing-masing actor memiliki peran yang berbedabeda. Setiap actor akan berkorespondensi dengan class dalam problem domain yang berbeda karena mereka memiliki pola behavioural object yang berbeda-beda. Actor dapat digambarkan dalam spesifikasi actor yang memiliki 3 bagian yaitu tujuan, karakteristik, dan contoh dari actor tersebut. Tujuan merupakan peran dari actor dalam sistem target. Sementara karakteristik menggambarkan aspek-aspek yang penting dari actor. Use case dapat digambarkan dengan menggunakan spesifikasi use case, dimana use case dijelaskan secara singkat namun jelas dan dapat disertai dengan keterangan object sistem yang terlibat dan function dari use case tersebut atau dengan diagram statechart karena use case adalah sebuah fenomena yang dinamik. Representasi use case dapat dilihat pada gambar 2.7 di bawah ini.
34
membuat batasan
update rekening
* *
*
*
sistem akuntansi manajer penjualan
menganalisa risiko <
>() *
*
kesepakatan nilai <>() kesepakatan harga
* penjual
*
*
* * merekam kesepakata n
* * * sales
Gambar 2.7 Use Case (Sumber : Fowler, 2005, p141)
2.7.1.1.Sequence diagram Menurut Fowler yang diterjemahkan oleh Penerbit Andi (2005) sebuah sequence diagram, secara khusus, menjabarkan behaviour sebuah skenario tunggal. Diagram tersebut menunjukkan sejumlah object contoh dan pesan-pesan yang melewati objects ini di dalam use case(h. 81).
2.7.2. Function Menurut Mathiassen Et al. (2000) kegiatan function memfokuskan pada bagaimana cara sebuah sistem dapat membantu actor dalam melaksanakan pekerjaan mereka. Function memiliki empat tipe yang berbeda yaitu : •
Update,
35
•
Signal
•
Read, function
•
Compute Tujuan
dari
kegiatan
function
adalah
untuk
menentukan
kemampuan sistem memproses informasi. Hasil dari kegiatan ini adalah sebuah daftar function-function yang merinci function-function yang kompleks. Daftar function harus lengkap, menyatakan kebutuhan kolektif dari pelanggan dan actor dan harus konsisten dengan use case(p. 138). Menurut Mathiassen Et al. (2000) cara untuk mengidentifikasikan function adalah dengan melihat deskripsi problem domain yang dinyatakan dalam kelas dan event, dan melihat deskripsi application domain yang dinyatakan dalam use case. kelas dapat menyebabkan munculnya function baca dan update. Event memungkinkan munculnya kebutuhan terhadap function update. Sementara use case dapat menyebabkan munculnya segala macam tipe function(p. 142).
2.7.3. User Interface Menurut Mathiassen Et al. (2000) interface menghubungkan sistem dengan semua actor yang berhubungan dalam konteks. Ada dua jenis dari interface / antar muka yaitu : antar muka pengguna yang menghubungkan pengguna dengan sistem dan antar muka sistem yang menghubungkan sistem dengan sistem yang lainnya.
36
Sebuah user interface yang baik harus dapat beradaptasi dengan pekerjaan dan pemahaman user terhadap sistem. Kualitas antar muka pengguna ditentukan oleh kegunaan atau usability interface tersebut bagi pengguna. Usability bergantung pada siapa yang menggunakan dan situasi pada saat system tersebut digunakan. Oleh sebab itu usability bukan sebuah ukuran yang pasti dan objektif. Ada empat jenis pola dialog yang penting dalam menentukan interface pengguna yaitu : pola menu-selection yang terdiri dari daftar pilihan yang mungkin dalam interface pengguna; pola fill in yang merupakan pola klasik untuk entry data; pola command-language dimana user memasukkan dan memulai format perintah sendiri; pola direct manipulation dimana user memilih object dan melaksanakan function atas object dan melihat hasil dari interkasi mereka tersebut. Kegiatan analisis user interface ini berdasarkan pada hasil dari kegiatan analisis lainnya yaitu model problem domain, kebutuhan functional dan use case. Hasil dari kegiatan ini adalah sebuah deskripsi elemen-elemen interface pengguna dan interface system yang lengkap, dimana kelengkapan menunjukkan pemenuhan kebutuhan pengguna. Hasil ini harus dilengkapi dengan sebuah diagram navigasi yang menyediakan sebuah ringkasan dari elemen-elemen user interface dan perubahan antara elemen-elemen tersebut(p. 151-155).
37
2.8.
Architecture Design Menurut Mathiassen L. Et al. (2000) keberhasilan suatu sistem
ditentukan oleh kekuatan desain arsitekturalnya. Arsitektur membentuk sistem sesuai dengan fungsi sistem tersebut dan dengan memenuhi criteria desain tertentu. Arsitektur juga berfungsi sebagai kerangka untuk kegiatan pengembangan yang selanjutnya. Dan sebuah arsitektur yang tidak jelas akan menghasilkan banyak pekerjaan yang sia-sia(p. 173). Untuk lebih jelasnya, kegiatan-kegiatan yang dilakukan selama tahap desain arsitektur dapat dilihat pada tabel 2.4 berikut ini.
Tabel 2.4 Kegiatan Desain Arsitektur Kegiatan
Isi
Kondisi
Criteria
Kondisi dan criteria untuk pendesainan
Criterion
Komponen
Bagaimana
sistem
dibentuk
menjadi Arsitektur komponen
komponen-komponen Proses
Bagaimana proses sistem didistribusikan dan Arsitektur proses dikoordinasi ( Sumber : Mathiassen L. Et al. , 2000, p176)
38
2.8.1. Criteria Menurut Mathiassen Et al. (2000) dalam menciptakan sebuah desain yang baik diperlukan pertimbangan mengenai kondisi-kondisi dari setiap proyek yang dapat mempengaruhi kegiatan desain yaitu : •
Technical, yang terdiri dari pertimbangan : penggunaan hardware, software dan sistem lain yang telah dimiliki dan dikembangkan; pengaruh kemungkinan penggabungan pola-pola umum dan komponen yang telah ada terhadap arsitektur dan kemungkinan pembelian komponen standar.
•
Conceptual, yang terdiri dari pertimbangan : perjanjian kontrak, rencana untuk pengembangan lanjutan, pembagian kerja antara pengembang.
•
Human, yang terdiri dari pertimbangan : keahlian dan pengalaman orang yang terlibat dalam kegiatan pengembangan dengan sistem yang serupa dan dengan platform teknis yang akan didesain(p.184) Karena
tidak
ada
cara-cara
tertentu
atau
mudah
untuk
menghasilkan suatu desain yang baik. Banyak perusahaan menciptakan suatu standard prosedur untuk memberikan jaminan terhadap kualitas sistem. Disinilah kegiatan criteria dapat membantu dengan menetapkan perioritas desain untuk setiap proyek tertentu. Sebuah desain yang baik memiliki tiga ciri-ciri yaitu : •
Tidak memiliki kelemahan.
39
Syarat ini menyebabkan adanya penekanan pada evaluasi dari kualitas berdasarkan review dan eksperimen dan membantu dalam menentukan prioritas dari criteria yang akan mengatur dalam kegiatan pendesainan. Tabel 2.5 dibawah ini adalah beberapa criteria umum yang digunakan dalam kegiatan desain yang berorientasi object : Tabel 2.5 Criteria Dalam Perancangan Criterion
Ukuran dari
Usable
Kemampuan sistem untuk menyesuaikan diri dengan konteks, organisasi yang berhubungan dengan pekerjaan dan teknis.
Secure
Ukuran keamanan sistem dalam menghadapi akses yang tidak terotorisasi terhadap data dan fasilitas.
Efficient
Eksploitasi ekonomis terhadap fasilitas platform teknis.
Correct
Pemenuhan dari kebutuhan.
Reliable
Pemenuhan ketepatan yang dibutuhkan untuk melaksanakan fungsi.
Maintainable
Biaya untuk menemukan dan memperbaiki kerusakan.
Testable
Biaya untuk memastikan bahwa sistem yang dibentuk dapat melaksanakan fungsi yang diinginkan.
Fleksible
Biaya untuk mengubah sistem yang dibentuk.
40
Criterion
Ukuran dari
Comprehensible
Usaha yang diperlukan untuk mendapatkan pemahaman terhadap sistem.
Reusable
Kemungkinan untuk menggunakan bagian sistem pada sistem lain yang berhubungan.
Portable
Biaya untuk memindahkan sistem ke platform teknis yang berbeda.
Interoperable
Biaya untuk menggabungkan sistem ke sistem yang lain. ( Sumber : Mathiassen L. Et al. , 2000, p178)
•
Menyeimbangkan beberapa criteria. Konflik sering terjadi antar criteria, oleh sebab itu untuk menentukan criteria mana yang akan diutamakan dan bagaimana cara untuk menyeimbangkannya dengan criteria yang lain bergantung pada situasi sistem tertentu.
•
Usable, flexible, dan comprehensible. Criteria ini bersifat universal dan digunakan pada hampir setiap proyek pengembangan sistem.
2.8.2. Component Architecture Menurut Mathiassen Et al. (2000) “arsitektur komponen adalah sebuah struktur sistem yang terdiri dari komponen-komponen yang saling berhubungan” (p.190).. Komponen merupakan kumpulan dari bagian-
41
bagian program yang membentuk suatu kesatuan dan memiliki fungsi yang jelas. Sebuah arsitektur komponen yang baik membuat sistem menjadi lebih mudah untuk dipahami, mengorganisasikan pekerjaan desain, menggambarkan stabilitas dari konteks sistem dan mengubah tugas desain menjadi beberapa tugas yang lebih tidak kompleks. Beberapa pola umum dalam desain komponen arsitektur : •
Arsitektur layered Merupakan bentuk yang paling umum dalam software. Contoh dari pola ini adalah model OSI yang sudah menjadi ISO untuk model jaringan. Sebuah arsitektur layered terdiri dari beberapa komponen yang dibentuk menjadi lapisan-lapisan dimana lapisan yang berada di atas bergantung kepada lapisan yang ada dibawahnya. Perubahan yang terjadi pada suatu lapisan akan mempengaruhi lapisan diatasnya. Representasi arsitektur layered dapat dilihat pada gambar 2.8 di bawah ini.
42
«component» Layer i+1
Upward interface
«component» Layer i
Downward interface
«component» Layer i-1
Gambar 2.8 Arsitektur Layered ( Sumber : Mathiassen L. Et al. , 2000, p193) •
Arsitektur generic Pola ini digunakan untuk merinci sistem dasar yang terdiri dari antar muka, function, dan komponen-komponen model. Dimana komponen model terletak pada lapisan yang paling bawah, diikuti dengan function sistem dan komponen interface diatasnya. Representasi arsitektur generic dapat dilihat pada gambar 2.9 di bawah ini.
43
«component» «component» User Interface
«component» System Interface «component» Function «component» Model
«component» Technical «component» UIS
«component» DBS
«component» NS
Gambar 2.9 Arsitektur generic ( Sumber : Mathiassen L. Et al. , 2000, p196)
•
Arsitektur client-server Pola ini awalnya dikembangkan untuk mengatasi masalah distribusi sistem di antara beberapa processor yang tersebar secara geografis. Komponen pada arsitektur ini adalah sebuah server dan beberapa client. Tanggung jawab daripada server adalah untuk menyediakan database dan resources yang dapat disebarkan kepada client
melalui jaringan. Sementara client memiliki
tanggung jawab untuk menyediakan antarmuka lokal untuk setiap penggunanya. Represetansi arsitektur client-server dapat dilihat pada gambar 2.10 di bawah ini.
44
«component» Client1
«component» Client2
«component» Clientn
«component» Server
Gambar 2.10 Arsitektur client-server ( Sumber : Mathiassen L. Et al. , 2000, p197) Berikut adalah beberapa jenis distibusi dalam arsitektur clientserver dimana U adalah user interface, F adalah function, M adalah model. Representasi client-serve arcrhitecture dapat dilihat pada tabel 2.6 di bawah ini. Tabel 2.6 Client-Server Architecture Client
Server
architecture
U
U+F+M
Distributed presentation
U
F+M
Local presentation
U+F
F+M
Distributed functionality
U+F
M
Centralized data
U+F+M M
Distributed data
( Sumber : Mathiassen L. Et al. , 2000, p200)
45
2.8.3. Process Architecture Menurut Mathiassen Et al. (2000) “arsitektur proses adalah struktur dari eksekusi sistem yang terdiri dari proses-proses yang saling tergantung” (p. 209). Hasilnya berupa sebuah deployment diagram. Pada aktivitas ini , terdapat 3 jenis pola distribusi, yaitu: a) Centralized Pattern Pola ini menyimpan semua data pada server pusat dan user hanya bisa melihat user interface saja. Keuntungan dari pola ini adalah dapat diimplementasikan pada client secara murah, semua data konsisten karena hanya berada di satu tempat saja, strukturnya mudah dimengerti dan diimplementasikan, dan kemacetan jaringannya moderat. b) 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 yang redundant sehingga konsistensi data terancam, kemacetan jaringan yang tinggi karena semua update harus disebar kepada semua client, kebutuhan teknis yang canggih, arsitekturnya lebih sulit dimengerti dan diimplementasikan. c) Decentralized Pattern Client Pola ini berada diantara kedua pola diatas. Pada pola ini client memiliki data tersendiri sehingga data umum hanya berada pada server. Server menyimpan data umum dan function atas data-data tersebut, sedangkan client menyimpan data yang merupakan milik bagian application-domain client tersebut. Keuntungan pola ini
46
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. Untuk mengeksekusi atau menjalankan sebuah sistem dibutuhkan processor. Sedangkan external device adalah processor khusus yang tidak dapat menjalankan program. Arsitektur proses harus dapat memastikan bahwa sistem dapat dijalankan secara memuaskan dengan menggunakan processor yang telah tersedia. Objects yang terlibat dalam sistem berorientasi object yang berjalan dapat dibagi menjadi dua yaitu : Active object yang telah diberikan sebuah proses dan aktif selama sistem dijalankan; dan komponen program, sebuah modul fisik dari kode program yang pasif selama eksekusi sistem kecuali pada saat dipanggil sebagai bagian dari eksekusi proses sampai eksekusi proses tersebut selesai dijalankan. Kegiatan arsitektur proses bermula dari komponen logic yang dihasilkan oleh kegiatan komponen dan bertujuan untuk menentukan struktur fisik dari sebuah sistem dengan : mendistribusikan komponenkomponen program ke processor yang akan digunakan untuk eksekusi sistem, mengkoordinasi pembagian sumber daya dengan active objek dan menghasilkan arsitektur yang tidak memiliki hambatan.
47
Sumber daya yang pada umumnya digunakan secara bersama, yaitu : Processor
•
Program component
•
External device
2.9.
•
Component Design Menurut Mathiassen L. Et al. (2000) tujuan dari kegiatan desain
komponen ini adalah untuk menentukan implementasi kebutuhan dalam rangka kerangka arsitektural. Kegiatan desain komponen bermula dari spesifikasi arsitektural dan kebutuhan sistem, sedangkan hasil dari kegiatan ini adalah spesifikasi dari komponen yang saling berhubungan. Berikut
adalah
beberapa
kegiatan
dari
desain
komponen
yang
direpresentasikan pada tabel 2.7 di bawah ini : Tabel 2.7 Kegiatan Perancangan Komponen Kegiatan
Context
Konsep
Model component
Bagaimana suatu model digambarkan Model component sebagai kelas dalam sebuah sistem
Function component
Bagaimana
suatu
diimplementasikan
and attribute
function Function component operation
and
48
Kegiatan
Context
Connecting
Bagaimana
component
dihubungkan
Konsep komponen-komponen Component connection
( Sumber : Mathiassen L. Et al. , 2000, p232)
2.9.1. Model Component Menurut Mathiassen Et al. (2000) ”model component merupakan bagian dari sebuah sistem yang mengimplementasikan model problemdomain” (p. 236). Kebutuhan sistem kemudian diimplementasikan dalam komponen model. Oleh karena itu dapat disimpulkan bahwa komponen model adalah bagian dari sistem yang mengimplementasikan model problem domain. Tujuan dari komponen model adalah untuk mengirimkan data sekarang dan historical ke function, interface dan pengguna dan sistem yang lain. Konsep utama dalam desain komponen model adalah struktur. Hasil dari kegiatan komponen model adalah revisi dari class diagram dari kegiatan analisis. Kegiatan revisi biasanya terdiri dari kegiatan menambahkan kelas, attribute dan struktur baru yang mewakili event .Revisi class diagram dapat dilakukan dengan memperhatikan private events dan common events. Panduan untuk mempresentasikan private events dapat dilihat pada tabel 2.8 di bawah ini
and
49
Tabel 2.8 Panduan untuk Mempresentasikan Private Events Event-event
yang
Representasi event-event ini sebagai state
hanya
pada
attribute pada class yang dijabarkan oleh
urutan (sequence) dan
statechart diagram. Setiap kali ada
selection
kejadian yang melibatkan salah satu event
terjadi
tersebut, maka sistem akan menugaskan yang baru kepada state attribute. Intergrasikan attribute dari event yang terlibat dalam class. yang
Representasikan event-event ini sebagai
terjadi berulang-ulang
suatu class baru, dan hubungkan class
(iteration)
tersebut dengan class yang dijabarkan
Event-event
pada
statechart
diagram
menggunakan
struktur
Untuk
iterasi,
setiap
dengan
aggregation. sistem
akan
menghasilkan suatu object baru. Integrasikan attribute event ke dalam sebuah class yang baru. ( Sumber : Mathiassen L. Et al. , 2000, p241) Jika suatu event adalah common, sehingga mempengaruhi beberapa object, maka event tersebut perlu dihubungkan dengan salah satu object dan dibuat hubungan struktural
dengan object lain agar tetap dapat
50
mengaksesnya. Panduan untuk mempresentasikan common events dapat dilihat pada tabel 2.9 di bawah ini Tabel 2.9 Panduan untuk Mempresentasikan Common Events Jika event yang terlibat daam statechart diagram
dalam
representasikan hubungan Common event
ke
cara
yang tersebut
event class
yang
berbeda, dalam
menawarkan
representasi paling simple. Jika event yang terlibat dalam statechart diagram
dalam
cara
yang
sama,
pertimbangkan alternatif representasi yang mungkin dapat digunakan ( Sumber : Mathiassen L. Et al. , 2000, p241) Untuk menyederhanakan class diagram yang telah direvisi dari hasil tahapan sebelumnya, dilakukan restrukturisasi class baik melalui generalization, association, maupun embedded iteration.
2.9.2. Function Component Menurut Mathiassen Et al. (2000) “function component merupakan bagian dari sebuah sistem yang mengimplementasikan kebutuhankebutuhan fungsional”(p. 252). Tujuan dari komponen function adalah untuk memberikan akses bagi user interface dan komponen sistem lainnya
51
ke model, oleh karena itu komponen function adalah penghubung antara model dan usage. Function didesain dan diimplementasikan dengan menggunakan operasi
dari
kelas
sistem.
Operasi
adalah
suatu
proses
yang
dispesifikasikan dalam sebuah class dan dijalankan melalui object dari class tersebut. Hasil utama dari kegiatan ini adalah class diagram untuk komponen function dan perpanjangan dari class diagram komponen model. Berikut adalah sub kegiatan dalam perancangan komponen function adalah : Sub kegiatan ini menghasilkan kumpulan operasi yang dapat mengimplementasikan fungsi sistem seperti yang ditentukan dalam analisis problem domain dan function list. •
Merancang function sebagai operation. Ada empat tipe function yaitu:Update, Read, Compute, dan Signal.
•
Menelusuri pola yang dapat membantu dalam implementasi function sebagai operation. Patterns dapat membantu memilih functional design yang mana dapat digunakan dari beberapa pilihan yang dapat membantu merealisasikan functions sebagai sekumpulan operations. Terdapat empat pola yaitu : o Model Class Placement
52
o Function Class Placement o Strategy o Active function •
Spesifikasikan operasi yang kompleks. Apabila
terdapat
operation
yang
kompleks
yang
harus
dideskripsikan dengan lebih detail lagi sehingga di dalam desain tidak ada ketidakpastian yang penting. Terdapat 3 cara untuk melakukannya, yaitu : operation specification, sequence diagram, dan statechart diagram.
