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 untuk menyediakan infomasi yang berguna bagi penggunanya.
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 dipertanggungjawabkan oleh fungsi pembelian.
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 Model Requiremen ts Compon ent Applicatio n domain 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 Struktur Behaviour Objek dan event yang merupakan bagian dari problem domain Bagaimana kelas dan objek saling berkaitan Property dinamik yang dimiliki objek Kelas, objek, event Generalisasi, agregasi, asosiasi, dan cluster Event trace, behavioural pattern, 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 Event Class Customer Assistant Apprentice Appointment Plan Reserved V V V V Cancelled V V V Treated V V Employed V V Resigned V V Graduated V 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).
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 structure (Mathiassen L. Et al. (2000, p79), yaitu :
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 0..* 1..* person 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 Function Bagaimana sistem berinteraksi dengan orang lain dan sistem lain dalam konteks Bagaimana kemampuan sistem dalam memproses informasi Use case dan actor Function
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 penjual * * membuat batasan update rekening manajer penjualan menganalisa risiko <<include>>() * * kesepakatan nilai <<include>>() kesepakatan harga * * * * sistem akuntansi * * 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 Proses komponen-komponen Bagaimana proses sistem didistribusikan dan dikoordinasi Arsitektur proses ( 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 Usable Ukuran dari 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 Correct Reliable Eksploitasi ekonomis terhadap fasilitas platform teknis. Pemenuhan dari kebutuhan. Pemenuhan ketepatan yang dibutuhkan untuk melaksanakan fungsi. Maintainable Testable Biaya untuk menemukan dan memperbaiki kerusakan. Biaya untuk memastikan bahwa sistem yang dibentuk dapat melaksanakan fungsi yang diinginkan. Fleksible Biaya untuk mengubah sistem yang dibentuk.
40 Criterion Comprehensible Ukuran dari 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 Gambar 2.9 Arsitektur generic «component» NS ( 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» Client 1 «component» Client 2 «component» Client n «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 sebagai kelas dalam sebuah sistem Model component and attribute Function component Bagaimana suatu function diimplementasikan Function component operation and
48 Kegiatan Context Konsep Connecting Bagaimana komponen-komponen Component and component dihubungkan 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
49 Tabel 2.8 Panduan untuk Mempresentasikan Private Events Event-event yang Representasi event-event ini sebagai state hanya terjadi pada attribute pada class yang dijabarkan oleh urutan (sequence) dan statechart diagram. Setiap kali ada selection kejadian yang melibatkan salah satu event Event-event yang tersebut, maka sistem akan menugaskan yang baru kepada state attribute. Intergrasikan attribute dari event yang terlibat dalam class. Representasikan event-event ini sebagai terjadi berulang-ulang (iteration) suatu class baru, dan hubungkan class tersebut dengan class yang dijabarkan pada statechart diagram dengan menggunakan struktur aggregation. Untuk setiap iterasi, 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 cara yang berbeda, representasikan event tersebut dalam hubungan ke class yang menawarkan Common event 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.