8

BAB 2

LANDASAN TEORI

2.1 Sistem Informasi Akuntansi

2.1.1 Pengertian Sistem Informasi Akuntansi

Menurut Gelinas dan Oram (1996), ”Sistem Informasi Akuntansi adalah suatu

subsistem khusus dari Sistem Informasi Manajemen yang bertujuan untuk

mengumpulkan, memproses, dan melaporkan informasi yang berhubungan dengan

transaksi-transaksi keuangan” (p.16).

Menurut pendapat Bodnar yang diterjemahkan oleh Amir Abadi Jusuf (2000),

”Sistem Informasi Akuntansi didefinisikan sebagai kumpulan sumber daya, seperti

manusia, peralatan, yang diatur untuk mengubah data menjadi informasi” (p.1).

Sedangkan menurut Moscove, dkk (2001) ”Sistem Informasi Akuntansi adalah

subsistem informasi dalam sebuah organisasi yang mengumpulkan informasi dari

berbagai subsistem suatu entitas dan mengkomunikasikannya kepada subsistem

pengolah informasi organisasi” (p.7)

Berdasarkan pengertian diatas, maka dapat disimpulkan Sistem Informasi

Akuntasi adalah kombinasi dari berbagai sumber daya yang dirancang untuk

mentransformasikan data keuangan menjadi informasi yang dibutuhkan oleh

manajemen.

9

2.1.2 Subsistem Sistem Informasi Akuntansi

Menurut Hall (2001), Sistem Informasi Akuntansi terdiri atas tiga subsistem

utama antara lain sebagai berikut :

1. Sistem Pemrosesan Transaksi (SPT) / Transaction Processing System (TPS)

merupakan pusat dari seluruh fungsi sistem informasi dengan :

a. Mengkonversi peristiwa ekonomi ke transaksi keuangan

b. Mencatat transaksi keuangan dalam record akuntansi (jurnal dan buku

besar)

c. Mendistribusikan informasi keuangan yang utama ke personel operasi

untuk mendukung kegiatan operasional harian mereka.

2. Sistem Pelaporan Buku Besar/Keuangan (SBB/PK) / General Ledger / Financial

Reporting System (GL/FRS).

Sistem Buku Besar (SBB) dan Sistem Pelaporan Keuangan (SPK) adalah

subsistem yang saling erat terkait . Namun, karena interdependensi operasional

mereka, keduanya dipandang sebagai suatu sistem tunggal yang integratif –

SBB/SPK. Besarnya input ke Sistem Buku Besar datang dari siklus transaksi.

Rangkuman aktifitas siklus transaksi ini diproses oleh Sistem Buku Besar untuk

memperbaharui akun-akun kontrol buku besar.

Sedangkan Sistem Pelaporan Keuangan mengukur dan melaporkan status

sumber daya keuangan dan perubahan dalam sumber daya-sumber daya tersebut,

informasi ini dikomunikasikan terutama bagi pemakai eksternal.

3. Sistem Pelaporan Manajemen (Management Reporting System)

Sistem Pelaporan Manajemen menyediakan informasi keuangan internal

yang diperlukan untuk mengatur sebuah bisnis. Para manajer membutuhkan

10

informasi yang berbeda untuk berbagai jenis keputusan yang harus dilakukan.

Laporan yang dihasilkan meliputi anggaran, laporan varians, analisis biaya-

volume-laba, dan laporan yang menggunakan data biaya lancar (bukan yang

historis)” (p.12).

2.1.3 Komponen Sistem Informasi Akuntansi

Romney dan Steinbart (2003) menyatakan, ”Sistem Informasi Akuntansi

terdiri dari lima komponen, yaitu :

1. People, yang mengoperasikan sistem dan melakukan berbagai fungsi.

2. Procedures, baik yang manual maupun otomatis termasuk dalam kegiatan

pengumpulan, pemrosesan, dan penyimpanan data tentang kegiatan

organisasi

3. Data, tentang kegiatan / proses bisnis organisasi

4. Software, digunakan untuk memproses data organisasi

5. Information Technology Infrastructure, termasuk didalamnya komputer, dan

peralatan komunikasi jaringan” (p.2).

2.1.4 Siklus Transaksi Pada Sistem Informasi Akuntansi

Menurut Boockholdt (1999), ”siklus transaksi akuntansi dibagi menjadi empat

bagian, yaitu:

1. Financial Cycle. Consist of those accounting transactions that record the acquisition

of capital from owner and creditor, the use of that capital to acquire productive

assets, and the reporting to owners and creditors on how is used. Dapat diartikan

sebagai berikut: siklus keuangan terdiri dari transaksi akuntansi yang mencatat

11

akuisisi modal dari pemilik dan kreditur, yang penggunaannya untuk memperoleh

asset produktif yang dilaporkan kepada pemilik dan kreditur.

2. Expenditure Cycle. Consist of those transaction incurred to acquire material and

overhead items for the conversion process of the business. Dapat diartikan sebagai

berikut: siklus pengeluaran terdiri dari transaksi yang terjadi untuk memperoleh

bahan baku dan barang overhead yang digunakan dalam proses konversi.

3. Conversion Cycle. Contains those transaction incurred when input are converted

into salable goods or services. Dapat diartikan sebagai berikut: siklus konversi terdiri

dari transaksi yang terjadi pada saat input dikonversi menjadi barang yang dapat

dijual atau jasa.

4. Revenue Cycle. Includes the accounting transactions that record that generation of

revenue from the output of the conversion process. Dapat diartikan sebagai berikut:

siklus pendapatan termasuk dalam transaksi akuntansi yang mencatat generasi

pendapatan dari output yang dihasilkan dalam proses konversi. (p.520-523).”

2.2 Sistem Informasi Akuntansi Penggajian dan Pengupahan

2.2.1 Pengertian Gaji dan Upah

Menurut Mulyadi (2001), ”Gaji adalah pembayaran atas penyerahan jasa yang

dilakukan oleh karyawan yang dibayarkan secara tetap per bulan. Sedangkan upah

adalah pembayaran atas penyerahan jasa yang dilakukan oleh buruh yang dibayarkan

berdasarkan hari kerja, jam kerja, atau jumlah satuan produk yang dihasilkan oleh

karyawan” (p.373).

12

2.2.2 Tujuan Sistem Informasi Akuntansi Penggajian dan Pengupahan

Menurut Wilkinson et al. (2000), ”Tujuan dari Sistem Informasi Akuntansi

Penggajian dan Pengupahan adalah:

1. Untuk meyakinkan bahwa status, tarif upah atau gaji, dan potongan atas gaji

karyawan telah diotorisasi.

2. Untuk membayar jasa aktual dari karyawan dengan tepat

3. Untuk mencatat, mendistribusikan, dan melaporkan biaya yang berhubungan dengan

karyawan dengan tepat dan akurat”

2.2.3 Fungsi yang Terkait

Menurut Mulyadi (2001), ”Fungsi yang terkait dalam sistem informasi akuntansi

penggajian dan pengupahan adalah sebagai berikut:

1. Fungsi kepegawaian

Fungsi ini bertanggung jawab untuk mencari karyawan baru, menyeleksi calon

karyawan, memutuskan penempatan karyawan baru, membuat surat keputusan tarif

gaji dan upah karyawan, kenaikan pangkat dan golongan gaji, mutasi karyawan dan

pemberhentian karyawan.

2. Fungsi Pencatat waktu

Fungsi ini bertanggung jawab untuk menyelenggarakan catatan waktu hadir

bagi semua karyawan perusahaan. Sistem pengendalian intern yang baik

mensyaratkan fungsi pencatatan waktu hadir karyawan tidak boleh dilaksanakan

oleh fungsi operasi atau oleh fungsi pembuat daftar gaji dan upah.

3. Fungsi Pembuat Daftar Gaji dan Upah

13

Fungsi ini bertanggung jawab untuk membuat daftar gaji dan upah yang berisi

penghasilan bruto yang menjadi hak dan berbagai potongan yang menjadi beban

setiap karyawan selama jangka waktu pembayaran gaji dan upah. Daftar gaji dan

upah diserahkan oleh fungsi pembuat daftar gaji dan upah kepada fungsi akuntansi

guna pembuatan bukti kas keluar yang dipakai sebagai dasar untuk pembayaran gaji

dan upah kepada karyawan.

4. Fungsi Akuntansi

Fungsi ini bertanggung jawab untuk mencatat kewajiban yang timbul dalam

hubungannya dengan pembayaran gaji dan upah karyawan (misalnya: utang gaji dan

upah karyawan, utang pajak, utang dana pensiun)

5. Fungsi Keuangan

Fungsi ini bertanggung jawab untuk mengisi cek guna pembayaran gaji dan

upah dan menguangkan cek tersebut ke bank atau melakukan transfer gaji dan upah

ke rekening karyawan.” (h.382-384).

2.2.4 Dokumen yang Digunakan

Menurut Mulyadi (2001), ”Dokumen yang digunakan dalam sistem akuntansi

penggajian dan pengupahan adalah:

1. Dokumen pendukung perubahan gaji dan upah

Dokumen-dokumen ini umumnya dikeluarkan oleh fungsi kepegawaian

berupa surat-surat keputusan yang bersangkutan dengan karyawan, misalnya: surat

keputusan pengangkatan karyawan baru, kenaikan pangkat, perubahan tarif upah,

penurunan pangkat, pemberhentian sementara dari pekerjaan (skorsing),

pemindahan, dan lain sebagainya. Tembusan dokumen-dokumen ini dikirimkan ke

14

fungsi pembuat daftar gaji dan upah untuk kepentingan pembuatan daftar gaji dan

upah.

2. Kartu jam hadir

Dokumen ini digunakan oleh fungsi pencatat waktu untuk mencatat jan hadir

setiap karyawan di perusahaan.

3. Kartu jam kerja

Dokumen ini digunakan untuk mencatat waktu yang dikonsumsi oleh tenaga

kerja langsung pabrik guna mengerjakan pesanan tertentu. Dokumen ini diisi oleh

mandor pabrik dan diserahkan ke fungsi pembuat daftar gaji dan upah untuk

kemudian dibandingkan dengan kartu jam hadir, sebelum digunakan untuk distribusi

biaya upah langsung kepada setiap jenis produk atau pesanan.

4. Daftar gaji dan daftar upah

Dokumen ini berisi jumlah gaji dan upah bruto setiap karyawan, dikurangi

potongan-potongan berupa PPh Pasal 21, utang karyawan, iuran untuk organisasi

karyawan, dan lain sebagainya.

5. Rekap daftar gaji dan rekap daftar upah

Dokumen ini merupakan ringkasan gaji dan upah per departemen, yang dibuat

berdasarkan daftar gaji dan upah. Dalam perusahaan yang produksinya berdasarkan

pesanan, rekap daftar upah dibuat untuk membebankan upah langsung dalam

hubungannya dengan produk kepada pesanan yang bersangkutan.

6. Surat pernyataan gaji dan upah

Dokumen ini dibuat oleh fungsi pembuat daftar gaji dan upah bersamaan

dengan pembuatan daftar gaji dan upah atau dalam kegiatan yang terpisah dari

pembuatan daftar gaji dan upah.dokumen ini dibuat sebagai catatan bagi setiap

15

karyawan mengenai rincian gaji dan upah yang diterima setiap karyawan beserta

berbagai potongan yang menjadi beban setiap karyawan.

2.2.5 Jaringan Prosedur yang Membentuk Sistem

Menurut Mulyadi (2001), ”Jaringan prosedur yang membentuk sistem penggajian

adalah:

1. Prosedur pencatatan waktu hadir

2. Prosedur pembuatan daftar gaji

3. Prosedur distribusi biaya gaji

4. Prosedur pembuatan bukti kas keluar

5. Prosedur pembayaran gaji

Sedangkan jaringan prosedur yang membentuk sistem pengupahan adalah

sebagai berikut:

1. Prosedur pencatatan waktu hadir

2. Prosedur pencatatan waktu kerja

3. Prosedur pembuatan daftar gaji

4. Prosedur distribusi biaya gaji

5. Prosedur pembuatan bukti kas keluar

6. Prosedur pembayaran gaji

Prosedur Pencatatan Waktu Hadir

Prosedur ini bertujuan untuk mencatat waktu hadir karyawan. Pencatatan waktu

hadir ini dilaksanakan oleh fungsi pencatat waktu dengan menggunakan daftar hadir

pada pintu masuk kantor administrasi atau pabrik. Pencatatan waktu hadir dapat

menggunakan daftar hadir biasa dimana karyawan harus menandatanganinya setiap

16

hadir dan pulang dari perusahaan, atau dapat menggunakan kartu hadir (berupa clock

card) yang diisi secara otomatis dengan menggunakan mesin pencatat waktu (time

recorder machine). Pencatatan waktu hadir ini diselenggarakan untuk menentukan gaji

dan upah karyawan. Bagi karyawan yang digaji bulanan, daftar hadir digunakan untuk

menentukan apakah karyawan dapat memperoleh gaji penuh atau harus dipotong akibat

ketidakhadiran mereka. Daftar hadir ini juga digunakan untuk menentukan apakah

karyawan akan menerima gaji saja atau menerima tunjangan lembur.

Prosedur Pencatatan Waktu Kerja

Dalam perusahaan manufaktur yang produksinya berdasarkan pesanan,

pencatatan waktu kerja diperlukan bagi karyawan yang bekerja di fungsi produksi untuk

keperluan distribusi biaya upah karyawan kepada produk atau pesanan yang menikmati

jasa karyawan tersebut.

Prosedur Pembuatan Daftar Gaji dan Upah

Dalam prosedur ini, fungsi pembuat daftar gaji dan upah membuat daftar gaji dan

upah karyawan. Data yang dipakai sebagai dasar pembuatan daftar gaji adalah surat-

surat keputusan mengenai pengangkatan karyawan, kenaikan pangkat, pemberhentian

karyawan, penurunan pangkat, daftar gaji bulan sebelumnya dan daftar hadir.

Prosedur Distribusi Biaya Gaji dan Upah

Dalam prosedur distribusi biaya gaji dan upah, biaya tenaga kerja didistribusikan

kepada departemen-departemen yang menikmati manfaat tenaga kerja. Distribusi biaya

tenaga kerja ini dimaksudkan untuk pengendalian biaya dan perhitungan harga pokok

produk.

Prosedur Pembayaran Gaji dan Upah

17

Prosedur pembayaran gaji dan upah melibatkan fungsi akuntansi dan fungsi

keuangan. Fungsi akuntansi membuat perintah pengeluaran kas kepada fungsi keuangan

untuk menulis cek guna pembayaran gaji dan upah kemudian membagikan cek gaji dan

upah tersebut kepada karyawan.” (h.385-386).

2.3 Sistem Pengendalian Intern

2.3.1 Pengertian Sistem Pengendalian Intern

Menurut Gelinas & Oram (1996), “Internal control is a system integrated elements

– people, structure, processes and procedures – acting together to provide reasonable

assurance that an organization achieves both its operation system dan its information

system goals.” Dapat diterjemahkan sebagai berikut: pengendalian internal adalah

elemen-elemen yang terintegrasi membentuk suatu sistem – personel, struktur, proses,

dan prosedur – beraksi bersama untuk memberikan jaminan bahwa organisasi dapat

mencapai tujuan baik dari sistem operasi maupun sistem informasi. (p.197)

Menurut pendapat Romney & Steinbart (2003), ”Internal Control is the plan of

organization and the methods a business uses to safeguard assets, provide accurate and

reliable information, promote and improve operational efficiency, and encourage

adherence to prescribe managerial policies (p.195).” Dapat diterjemahkan sebagai

berikut: pengendalian internal adalah rencana dari organisasi dan metode yang

digunakan oleh suatu bisnis untuk mengamankan harta, menjaga keakuratan dan

keandalan informasi, mempromosikan dan meningkatkan efisiensi operasional, dan

mendorong ketaatan pada kebijakan manajemen yang telah ditetapkan.

Menurut Committee of Sponsoring Organizations (COSO), “Internal Control is a

process effected by an entity’s board of directors, management, and other personnel –

18

designed to provide reasonable assurance regarding the achievement of objectives.”

Dapat diterjemahkan sebagai berikut: pengendalian internal adalah proses yang

dipengaruhi oleh direksi dari suatu perusahaan, manajemen, dan pihak lainnya –

dirancang untuk menyediakan jaminan mengenai pencapaian tujuan organisasi.

Jadi, dapat disimpulkan bahwa pengendalian internal adalah aturan, kebijakan,

prosedur, dan sistem informasi yang dirancang untuk memastikan data keuangan

perusahaan tepat dan dapat diandalkan, untuk meningkatkan efisiensi dan efektifitas

operasi dan untuk memenuhi ketaatan terhadap hukum dan peraturan yang berlaku.

2.3.2 Tujuan Sistem Pengendalian Intern

Menurut COSO, tujuan sistem pengendalian intern adalah sebagai berikut:

1. menghasilkan laporan keuangan yang dapat dipercaya (reliability of financial

reporting)

2. menghasilkan operasi yang efektif dan efisien (effectiveness and efficiency of

operations)

3. memenuhi dalil dan peraturan yang ditetapkan (compliance with applicable laws and

regulations).

2.3.3 Komponen Sistem Pengendalian Intern

Menurut COSO, ada lima komponen dalam sistem pengendalian intern antara lain

sebagai berikut:

1. Control Environmnet

Inti dari semua bisnis adalah orangnya – sifat masing-masing individu,

termasuk integritas, nilai etika, dan kemampuan – dan lingkungan dimana mereka

19

beroperasi. Mereka adalah alat yang mengendalikan organisasi dan merupakan dasar

dari segala sesuatu.

2. Control Activities

Prosedur dan kebijakan pengendalian harus ditetapkan dan dijalankan untuk

membantu meyakinkan bahwa tindakan yang dilakukan oleh pihak manajemen untuk

menanggulangi resiko dan untuk mencapai tujuan organisasi terlihat efektif.

3. Risk Assessment

Perusahaan harus berhati-hati terhadap resiko yang dihadapi. Perusahaan

harus membentuk suatu tujuan, yang digabungkan dengan penjualan, produksi,

pemasaran, keuangan, dan aktivitas lainnya sehingga perusahaan dapat beroperasi

dengan baik. Perusahaan juga harus menyusun sebuah mekanisme untuk

mengidentifikasi, menganalisis dan mengatur resiko-resiko yang berhubungan

dengan masing-masing bagian.

4. Information and communication

Yang mengelilingi aktifitas pengendalian adalah sistem informasi dan

komunikasi. Mereka memungkinkan orang-orang dari perusahaan menerima dan

saling bertukar informasi yang dibutuhkan untuk memimpin, mengatur, dan

mengontrol operasi yang ada.

5. Monitoring

Keseluruhan proses harus diawasi dan melakukan perubahan bila diperlukan.

Dengan cara ini, sistem dapat bereaksi dengan lebih dinamis, berubah sesuai dengan

kondisi yang ada.

20

2.3.4 Matriks pengendalian (Control Matrix)

Menurut Gelinas & Oram (1996), ”The control matrix is a tool that assist you in

analyzing a systems flowchart and related narrative or data dictionary descriptions. It

establishes the criteria to be used in evaluating a particular system.” Pengertian tersebut

dapat diterjemahkan sebagai berikut: matriks pengendalian adalah suatu alat yang dapat

membantu kita dalam menganalisis sebuah sistem flowchart dan cerita yang

berhubungan atau penjelasan kamus data. Matriks tersebut membuat kriteria yang dapat

digunakan dalam mengevaluasi sistem tertentu.

Dibawah ini adalah tabel dan penjelasan mengenai komponen-komponen yang

terdapat dalam control matrix.

Generic Control Goals

Control Goals for the Operation System

• Ensure effectiveness of operations by achieving the following system goals (Itemize

the systems goals for the specific system being analized)

• Ensure efficient employment of resources

• Ensure security of resources (Specify the particular resources for the system being

analyzed)

Control Goals for the Information System

• For the applicable transaction inputs, ensure:

Input validity (IV)

Input completeness (IC)

Input accuracy (IA)

• For the applicable master file, ensure:

Update completeness (UC)

Update accuracy (UA)

Tabel 2.1 Generic Control Goals

21

Berikut ini adalah penjelasan terhadap Generic Control Goals. Dalam control

goals of the operational system terdapat tiga tujuan yang akan dicapai. Tujuan pertama

yang akan dibahas adalah ensure effectiveness of operation. Control goal ini berusaha

untuk memastikan bahwa sistem yang ada dapat mencapai tujuannya. Dalam merancang

suatu sistem, organisasi harus berhati-hati dengna cara membuat sistem tersebut sejelas

mungkin untuk menghindari masalah dikemudian hari ketika tujuan tidak tercapai. In

setting system goals, an organization must be careful to makethem definitive enough to

allow a later assessment of whether or not the goals have been achieved.

Tujuan berikutnya adalah ensure efficient employment of resources. Control goal

ini berusaha untuk mencegah penggunaan sumber daya yang tidak perlu. Secara umum,

pemborosan adalah ukuran dalam istilah finansial. Contoh: slip deposito dicetak secara

otomatis melalui komputer, proses ini kemungkinan lebih efisien daripada dibuat secara

manual.

Tujuan berikutnya yang akan dibahas adalah ensure security of resources. Tujuan

ini menyediakan perlindungan terhadap kerugian, kerusakan, penyingkapan, peniruan,

penjualan, atau penyalahgunaan lainnya atas sumber daya organisasi.

Dalam control goals of the information system terdapat beberapa tujuan yang

akan dicapai. Tujuan pertama adalah memastikan input validity. Untuk mencapai tujuan

ini organisasi harus memelihara keutuhan database dari sistem dan memfasilitasi hasil

dari output sistem yang dapat diandalkan.

Tujuan kedua adalah memastikan input completeness. Untuk mencapai tujuan ini,

mengharuskan semua objek atau event yang ditangkap harus valid untuk dimasukkan

kedalam database sistem.

22

Tujuan ketiga adalah memastikan input accuracy. Tujuan ini berhubungan

dengan berbagai macam data fields yang biasanya merupakan catatan, seperti dokumen

sumber. Tujuan dari input accuracy adalah menyangkut ketepatan/kebenaran dari data

yang dimasukkan ke dalam sistem. Untuk mencapai tujuan ini, kita harus meminimalkan

ketidaksesuaian data yang dimasukkan ke dalam sistem.

Tujuan ke empat adalah untuk memastikan update completeness. Tujuan ini

memberikan jaminan bahwa semua data yang dimasukkan kedalam komputer tergambar

dalam masing-masing master file.

Tujuan ke lima adalah untuk memastikan update accuracy. Tujuan ini

menyediakan jaminan bahwa data yang dimasukkan kedalam komputer mencerminkan

keakuratan dalam masing-masing master file.

Berikut ini adalah contoh control matrix

Control Goals of the Operations System Control Goals of the Information System

Ensure effectiveness of operations by achieving

the following

system goals :

For time card inputs,

ensure :

For the employee/

payroll file,

ensure :

Recommended Control Plans

A B C

Ensure efficient

employment of

resources

Ensure security

of resources

(cash, and employee/

payroll file)

IV IC IA UC UA M-1 : Penanganan employee/payroll master file secara independent

M-1 M-1

P-1 : Rekonsiliasi antara rekening koran bank (untuk pembayaran gaji) dengan daftar gaji

P-1

Tabel 2.2 Control Matrix

23

Penjelasan terhadap Control Matrix : 1. Effectiveness of operations, within which three representative system goals are

listed : A – Provide employees with timely paychecks B – Provide timely filling of tax returns and other reports to government agencies C – Comply with the requirements of payroll tax laws and regulations

2. IV = Input Validity 3. IC = Input Completeness 4. IA = Input Accuracy 5. UC = Update Completeness 6. UA = Update Accuracy 7. M = Missing adalah control plans yang missing dalam sistem penggajian dan

pengupahan pada PT. Istana Kebayoran Raya Motor dan akan diusulkan dalam sistem yang baru

8. P = Present adalah control plans yang sudah diterapkan dalam sistem yang berjalan

2.4 Konsep Analisis dan Perancangan Berorientasi Objek

2.4.1 Pengertian Object Oriented Analysis and design

Menurut Mathiassen et al (2000), “Objek adalah kesatuan dengan identity, state

dan behaviour (p.4). Menurut Larman (1998), “Analisis adalah bagian dari suatu objek

yang digunakan untuk menentukan sistem yang dibutuhkan, sedangkan desain adalah

rancangan yang digunakan untuk menjelaskan sistem tersebut. Object oriented analysis

menekankan pada penemuan dan mendeskripsikan objek atau konsep pada problem

domain. Sedangkan objek oriented design menekankan pada pendefinisian software

object yang diimplementasikan pada bahasa pemrograman” (p6). Dari definisi diatas

dapat disimpulkan bahwa object oriented analysis and design merupakan kegiatan untuk

menentukan problem domain dan kemudian mencari pemecahan masalah yang logical

yang berbasiskan objek.

24

2.4.2 Objek

Menurut pendapat Lau (2001), ”Objek merupakan abstraksi baik untuk hal-hal

konseptual maupun fisik. Objek memiliki keadaan dan identitas yang melekat. Objek

mencapai tingkah laku tertentu melalui suatu kumpulan operasi yang didefinisikan

diawal, yang mana dapat masuk atau merubah keadaannya. (p.1).”

Menurut Mathiassen et al, et al (2000), ”Objek adalah suatu entitas dengan

identitas, keadaan (tingkatan hidup) dan tingkah laku. Objek merupakan dasar dalam

Object Oriented Analysis and Design (OOA&D). Setiap objek digambarkan secara

berkelompok (kumpulan) karena ada beberapa objek yang memiliki sifat atau fungsi

yang sama yang dikenal dengan istilah class. Sedangkan Iclass adalah suatu deskripsi

atas kumpulan objek yang saling menggunakan struktur, pola tingkah laku, dan atribut

secara bersama-sama. (p.4).”

Dapat disimpulkan model yang berorientasi objek terdiri dari sejumlah objek-

objek yang umumnya berkorespondesi dengan objek pada dunia nyata. Contohnya:

sebuah objek dapat berupa nota pembelian, mobil atau telepon seluler. Karakteristik

yang dimiliki objek antara lain:

1. Tiap objek dapat memiliki satu atau lebih informasi individual yang unik. Inilah

yang disebut attribute dimana tiap attribute mempunyai nilai. Contohnya: sebuah

mobil memiliki attribute warna biru, kuning dan sebagainya.

2. Objek dapat melakukan suatu operasi yang disebut behaviour. Operasi ini dapat

dipicu dari stimulus dari luar maupun dalam objek

3. Objek dapat dikomposisikan menjadi bagian-bagian terpartisi yang dinyatakan

dengan hubungan consist of atau aggregate.

25

2.4.3 System Definition

Menurut Mathiassen et al (2000), “System definition adalah a conscise

description of a computerized system expressed in natural language ” (p.24). Definisi

sistem merupakan suatu gambaran secara umum bagaimana suatu sistem berjalan dalam

perusahaan tersebut. Dalam skripsi ini adalah sistem penggajian dan pengupahan.

Rich Picture

Menurut Mathiassen 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. “Rich picture is an informal

drawing that presents the illustrator’s understanding of a situation” (p.26). Rich picture

juga dapat digunakan sebagai alat yang berguna untuk memfasilitasi dan

menggambarkan komunikasi yang baik antara pengguna dengan sistem.

Rich picture difokuskan pada aspek-aspek penting dari sistem tersebut, yang

ditentukan oleh pengembang dengan mengunjungi perusahaan untuk melihat bagaimana

sistem itu beroperasi, berbicara dengan orang-orang yang mengerti apa yang terjadi atau

seharusnya terjadi, dan mungkin melakukan beberapa wawancara informal maupun

formal. Berikut ini adalah contoh Rich Picture.

26

Customer Service

Teller

Nasabah

$ $$

Calon Nasabah

Pendaftaran Nasabah Baru Memiliki rekening

Mengentry data nasabah baru

Information Systems

Melakukan transaksi setoran,penarikan, dan transfer

Mengentry transaksi

ATM BCA

melakukan transaksipenarikan & transfer melalui

ATM BCA

Mengentry transaksi

Gambar 2.1 Contoh Rich Picture

2.4.4 The FACTOR Criterion

Menurut Mathiassen et al (2000, p39), kriteria FACTOR terdiri dari enam

elemen, sebagai berikut:

Kriteria Penjelasan

Functionality Fungsi sistem yang mendukung tugas-tugas application domain

Application Domain Bagian organisasi yang mengadministrasi, memonitor, dan

mengontrol problem domain

Condition Kondisi dimana sistem akan dikembangkan dan digunakan

Technology Mencakup teknologi yang digunakan untuk mengembangkan

sistem dan teknologi dimana sistem akan dijalankan

Objects Objek utama dari problem domain

Responsibility Tanggung jawab keseluruhan dari sistem dalam hubungannya

dengan konteks

Tabel 2.3 The FACTOR Criterion

27

2.4.5 Problem-domain analysis

Mengacu pada Mathiassen et al (2000), “Problem-domain analysis adalah

analisa terhadap sistem bisnis dalam dunia nyata yang dapat diatur, dimonitor, atau

dikendalikan oleh sistem. Tujuan dari problem domain analysis adalah untuk

mengidentifikasikan dan membuat model dari problem domain. Tujuan dari aktivitas ini

adalah membangun sebuah model yang dapat digunakan untuk merancang dan

mengimplementasikan sebuah sistem yang dapat memproses, berkomunikasi dan

menyajikan informasi mengenai problem domain. Hasil dari problem domain analysis

adalah membuat class diagram. Gambar berikut ini adalah contoh class diagram.

+memesan_barang()+mengupdate_record_penjualan()+menambah_downlevel()+mengupdate_level()+menghitung_jumlah_bonus_agen()

-Kode Agen : Integer-Nama Agen : String-Alamat : String-No. telp : String-Record_penjualan : String-Level : String-Jumlah downlevel : Integer

Agen

+menambah_jenis_barang()+mengupdate_stock_barang()+mengupdate_harga_satuan()

-Kode barang : Integer-Jenis barang : String-Nama barang : String-Harga satuan : Long-Jumlah stock : Integer

Barang

+mencatat_data_pesanan()+mengecek_persediaan_barang()+mendaftarkan_agen_baru()

Customer Service

+mengupdate_stock_barang()+menambah_jumlah_stock_barang()+membaca_pesanan_dari_agen()+melaporkan_kehabisan_stock_kpd_puchasing()+menerima_barang_dari_supplier()

Warehouse_staff

+menerima_pembayaran()+mencetak_bukti_pembayaran()+mencatat_transaksi_penjualan()

Cashier_staff

+menerima_laporan_kehabisan_stock()+membuat_surat_permintaan_barang()

Purchasing_staff

+membuat_transaksi_pesanan()+menyimpan_transaksi_pesanan()+menghitung_jml_brg_yg_hrs_direorder()

-Kode_pesanan : Integer-Kode_barang : Integer-Jumlah_barang_yang_dipesan : Integer-Jumlah_barang_yang_tersedia : Integer-Jumlah_barang_yang_harus_di_reorder : Integer

Detil Pesanan

+membuat_transaksi_pembelian_barang()+menyimpan_transaksi_pembelian_barang()+menghitung_total_pembelian()

-Kode_pembelian_barang : Integer-Kode_pesanan : Integer-Kode_barang : Integer-Jumlah_barang_yang_dibeli : Integer-Harga_barang : Integer

Detil Pembelian Barang

-Nama_staff : String-Kode_staff : String-Bagian : String

Staff

+membuat_transaksi_penjualan_barang()+menyimpan_transaksi_penjualan_barang()+menghitung_total_penjualan()

-Kode_penjualan_barang : Integer-Kode_barang : Integer-Jumlah_barang_terjual : Integer-Harga_barang : Integer

Detil Penjualan Barang

*

1

1*1*

1*

1

*

*

*

*

*

*

*

+memberikan_data_barang_yg_dipesan()

-Kode_supplier : Integer-Nama_supplier : String-Alamat : String-No_telp : Long

Supplier

+membuka_cabang()+menambah_jumlah_karyawan()

-Kode_cabang : String-Nama_cabang : String-Alamat : String

Cabang1*

1*

+membuat_data_agen()+menyimpan_data_agen()

-Tanggal_transaksi : Date-Kode_pendaftaran_agen : Integer

Transaksi Pendaftaran Agen

+membuat_transaksi_pesanan()+menyimpan_transaksi_pesanan()

-Kode_pesanan : Integer-Tanggal_transaksi : Date-Kode_agen : Integer

Header_Pesanan

+membuat_transaksi_penjualan()+menyimpan_transaksi_penjualan()

-Kode_penjualan_barang : Integer-Tanggal_transaksi : Date-Kode_agen : Integer-Kode_pesanan : Integer

Header_Penjualan_Barang

+membuat_transaksi_pembelian()+menyimpan_transaksi_pembelian()

-Kode_pembelian_barang : Integer-Tanggal_transaksi : Date-Kode_supplier : Integer

Header_Pembelian_Barang

1* 1

* 1*

1

*

1

1

1

*

Gambar 2.2 Contoh Class Diagram

28

Problem-domain analysis dibagi menjadi tiga kegiatan, antara lain: classes,

behaviour, dan structure” (p.46). Kegiatan dari problem-domain analysis dapat dilihat

pada gambar dibawah ini.

Behavior

Classes

Structure

System definition

Model

Gambar 2.3 Aktivitas pada problem domain analysis

2.4.5.1 Classes

Menurut Mathiassen et al (2000), “Class is a description of collection of objects

sharing structure, behavioural pattern, and attribute” (p.53). Class adalah gambaran

atau definisi kumpulan objek yang mempunyai structure, behaviour pattern, dan

attribute yang bersamaan. Class merupakan kegiatan yang pertama dilakukan didalam

analisis problem-domain.

Pemilihan class bertujuan untuk mendefinisikan dan membatasi problem-

domain, sedangkan pemilihan event bertujuan untuk membedakan tiap-tiap class dalam

problem-domain. Menurut Mathiassen et al (2000), “Event merupakan kejadian secara

terus menerus yang melibatkan satu atau lebih dari suatu object.” (p.51).

Classes bertujuan untuk memilih elemen-elemen dari suatu problem domain.

Classes terdiri dari tiga bagian, yaitu:

1. Nama Class, setiap class harus mempunyai nama untuk dibedakan dari suatu

class yang lain

29

2. Attribute, merupakan kepemilikan deskriptif dari class atau event. Setiap class

boleh memiliki beberapa attribute atau sebagian saja

3. Operation, merupakan proses kepemilikan yang spesifik di dalam class dan

diaktifkan melalui class object.

Kegiatan class akan menghasilkan suatu event table. Dimensi horizontal dari

tabel event menggambarkan class-class yang akan dipilih, sementara dimensi vertikal

menggambarkan event-event yang terpilih, tanda cek digunakan untuk mengindikasikan

objek-objek dari kelas yang berhubungan dalam event tertentu.

Class Events 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

Tabel 2.4 Contoh Event Table

2.4.5.2 Structure

Menurut Mathiassen et al (2000), “Structure adalah hubungan antara class

dengan object pada problem domain secara keseluruhan.” (p.336). Structure bertujuan

untuk menggambarkan hubungan terstruktur antara classes dan object dalam problem

domain. Hasil dari kegiatan structure adalah membuat class diagram. Class diagram

menggambarkan kumpulan dari classes dan hubungan yang terstruktur.

Menurut Mathiassen et al (2000) tipe dari object oriented structure terdiri dari

dua bagian, yaitu:

30

1. Class structured, mengekspresikan hubungan konseptual yang statis antar class.

Class structured dibagi menjadi dua, yaitu:

a. Generalization, adalah suatu kelas umum (super class) yang menggambarkan

keadaan atau sifat yang sama kedalam kelompok class yang lebih khusus (sub

class). Generalization secara linguistik diformulasikan sebagai hubungan “is a”.

Generalization mengekspresikan inheritance yang berarti sub class akan

mempunyai attribute dan operation yang sama dengan superclass.

b. Cluster adalah kumpulan kelas yang saling berhubungan yang dapat membantu

memperoleh dan menyediakan ringkasan problem-domain. Contohnya: cluster

“mobil” berisi semua kelas yang berhubungan dengan jenis kelas dan komponen-

komponennya. Cluster digambarkan dengan notasi file folder yang melingkari

class yang saling berhubungan didalamnya.

2. Object structures

Object structures menggambarkan hubungan yang dinamik dan konkret antara

objek-objek dalam problem domain. Hubungan ini berubah secara dinamis tanpa

mempengaruhi perubahan pada class description. Object structures terdiri dari dua

bagian, yaitu:

a. Aggregation, adalah suatu object superior (the “whole”) yang terdiri dari atau

berisi bagian-bagian dari object tersebut (the part). Aggregation structure

mendefinisikan hubungan antara dua buah objek atau lebih. Secara linguistik,

aggregation diformulasi sebagai hubungan “has a”.

b. Association, adalah suatu hubungan yang berarti antara objek, namun hubungan

ini berbeda dari aggregation. Hubungan ini bukan merupakan hubungan yang

sangat kuat seperti aggregation, karena objek yang satu tetap ada walaupun objek

31

yang lain tidak ada. Secara grafik association diterjemahkan sebagai garis solid

yang menghubungkan objek-objek. Association structure mendefinisikan

hubungan antara dua buah objek atau lebih. Hasil dari aktivitas ini adalah

membuat class diagram yang berisi class dengan hubungan struktur dengan class

lainnya.

Perbedaan antara Association dan Aggregation adalah sebagai berikut :

• Hubungan antar class pada aggregation mempunyai hubungan yang kuat,

sedangkan association tidak.

• Aggregation structure melukiskan hubungan yang defensive dan

fundamental, sedangkan association structure melukiskan hubungan yang

tidak tetap.

2.4.5.3 Behaviour

Mengacu pada pendapat Mathiassen et al (2000), kegiatan behaviour bertujuan

untuk memodelkan apa yang terjadi (perilaku dinamis) dalam problem-domain sistem

sepanjang waktu (p.89). Tugas utama dari kegiatan ini adalah menggambarkan pola

perilaku (behavioural pattern) dan attribut dari setiap kelas. Hasil dari kegiatan ini

adalah statechart diagram.

/ account open

Open/ amount deposited

/ account withdrawn

/ account closed

Gambar 2.4 Contoh “State Chart”

32

Perilaku dari suatu objek ditentukan oleh urutan-urutan event (event trace) yang

harus dilewati oleh objek tertentu sepanjang waktu. Contoh: kelas customer harus

melalui event trace sepanjang hidupnya yaitu: account opened – amount deposited –

amount withdrawn – amount deposited – account closed.

Mengacu pada pendapat Mathiassen et al (2000), ada tiga jenis notasi untuk

behavioural pattern, yaitu:

1. Sequence : sekumpulan event muncul satu per satu

2. Selection : terjadi pemilihan satu event dari sekumpulan event yang muncul

3. Iteration : sebuah event muncul sebanyak nol atau beberapa kali. (p.93)

2.4.6 Application Domain Analysis

Mengacu pada Mathiassen et al (2000), ”Application Domain adalah suatu

organisasi yang mengatur, memonitor, atau mengendalikan problem-domain.

Application domain analysis memfokuskan pada bagaiman target sistem akan digunakan

dengan menentukan kebutuhan function dan interface” (p.117). Kegiatan-kegiatan yang

dilakukan pada application domain dapat dilihat pada gambar dan tabel dibawah ini.

Interfaces

Usage

Functions

System definition

Requirements

Gambar 2.5 Aktivitas application-domain

33

Kegiatan Isi Konsep Usage Function Interface

Bagaimana sistem berinteraksi dengan orang lain dalam konteks Bagaimana kemampuan sistem dalam memproses informasi Kebutuhan antarmuka dari sistem target

Use case dan actor Function Interface, user interface, dan system interface

Tabel 2.5 Kegiatan Application Domain Analysis (Mathiassen et al (2000,p.117))

2.4.6.1 Usage

Mengacu pendapat Mathiassen et al (2000), tujuan dari kegiatan usage adalah untuk

menentukan bagaimana aktor-aktor yang merupakan pengguna atau sistem lain

berinteraksi dengan sistem yang dituju. Interaksi antara actor dan sistem dinyatakan

dalam use case. Mathiassen et al (2000) menyatakan, “Use case is a pattern for

interaction the system and actor in application domain” (p.120), sedangkan “Actor is an

abstraction of user or other systems that interact with target system” (p.119). Tujuan

dari application domain analysis adalah untuk menganalisis kebutuhan dari pengguna

sistem. Prinsip dari aktivitas ini adalah:

• Menentukan application domain dengan use case

• Mengevaluasi use case dalam kerjasama dengan user.

Hasil dari kegiatan usage adalah deskripsi lengkap dari semua use case dan actor

yang ada, yang digambarkan dalam actor table dan use case diagram. Use case diagram

adalah diagram yang menggambarkan fungsi dari sebuah sistem dan berbagai macam

pengguna yang akan berinteraksi dengan sistem.

Untuk mengidentifikasikan actor adalah dengan menentukan bagian dan tugas

dari bagian apa saja yang berhubungan atau terlibat langsung dengan konteks sistem

34

yang dituju. Masing-masing actor memiliki peranan yang berbeda-beda. Aktor dapat

digambarkan dalam actor spesification yang memiliki tiga bagian, yaitu tujuan,

karakteristik, dan contoh. Tujuan menunjukkan peranan dari aktor dalam sistem target,

sedangkan karakteristik menggambarkan aspek-aspek yang penting dari aktor.

Use case dapat dikatakan gambaran suatu interaksi antara sistem dengan aktor.

Untuk menggambarkan suatu use case dapat menggunakan statechart diagram, use case

spesification atau keduanya. Use case specification terdiri dari tiga bagian, yaitu use

case, objects dan function. Use case menjalankan urutan dari sistem yang berjalan,

objects menunjukkan aktor-aktor apa saja yang berhubungan dengan aktifitasi use case

tersebut, dan function akan dijelaskan setelah usage. Berikut ini adalah contoh Use Case

Diagram.

35

Sistem Multi LevelMarketing YJ Store

Memesan barang

Agent

customer service

Mengentry datapesanan

Mengupdate stockbarangWarehouse Staff

Membuat suratpermintaan barang

Purchasing Staff

Mencatat transaksi penjualan

Cashier Staff

Menerima pendaftaran agen baru

Membuat_laporan_pemesanan_barang

Gambar 2.6 Contoh Use Case Diagram

Sequence Diagram

Sequence diagram membantu seorang analis mengidentifikasikan rincian dari

kegiatan yang dibutuhkan untuk menjalankan fungsi dari sebuah use case. Tidak ada

suatu sequence diagram yang benar untuk use case tertentu, melainkan ada sejumlah

kemungkinan sequence diagram yang masing-masing diagram tersebut dapat lebih atau

kurang memenuhi kebutuhan dari use case. Sequence diagram menunjukkan urutan dari

36

suatu kegiatan, event atau fungsi pada suatu use case. Berikut ini adalah contoh

Sequence Diagram.

Membuat surat permintaan barang

Bagian Pembelian Bagian Gudang Transaksi Pembelian Barang Barang

Memberitahu stock barang habis()

Mengecek_persediaan_barang()

Hasil_pengecekan()

Kode_barang_dan_jumlah_barang_yang_dibeli()

Mencetak_surat_pembelian_barang()

Close()

Open()

Gambar 2.7 Contoh Sequence Diagram

2.4.6.2 Function

Mengacu pada Mathiassen et al (2000), kegiatan function memfokuskan pada

bagaimana cara sebuah sistem dapat membantu actor dalam melaksanakan pekerjaan

mereka. Mathiassen et al (2000) menyatakan “Function is a facility for making a model

useful for actor” (p.138). Function memfokuskan pada apa yang bisa dilakukan sistem

untuk membantu actor dalam pekerjaan mereka.

Function memiliki empat tipe, yaitu:

1. Update. Function ini dapat menjadi aktif disebabkan oleh event dari problem-

domain, dan menghasilkan perubahan dalam state dari model tersebut.

37

2. Signal. Function ini menjadi aktif disebabkan oleh perubahan keadaan atau state

dari model dan dapat menghasilkan reaksi pada konteks. Reaksi ini dapat berupa

tampilan untuk actor dalam application domain, atau intervensi langsung dalam

problem domain.

3. Read. Function ini menjadi aktif disebabkan oleh kebutuhan informasi dalam

pekerjaan actor dan mengakibatkan sistem menampilkan bagian yang

berhubungan dengan informasi dalam model.

4. Compute. Function ini menjadi aktif disebabkan oleh kebutuhan informasi dalam

pekerjaan actor dan berisi perhitungan yang melibatkan informasi yang

disediakan oleh actor atau model.

Hasil dari kegiatan function adalah daftar dari function (function list) yang lengkap,

yang merinci function-function yang kompleks. Function List dibuat berdasarkan use

case description. Kompleksitas function list dimulai dari yang simple sampai

dengan yang very complex. Untuk mengidentifikasikan function adalah melihat

deskripsi problem domain yang dinyatakan dalam kelas dan event yang dapat

menyebabkan munculnya function read dan update, dan melihat deskripsi

application domain yang dinyatakan use case yang dapat menimbulkan segala

macam tipe function.

2.4.6.3 Interface

Interface digunakan oleh aktor untuk berinteraksi dengan sistem. Mathiassen et

al (2000) menyatakan, “Interface is a facilities that make a system’s model and functions

available to actor” (p.151). Dapat diartikan sebagai berikut: Interface yaitu suatu

38

fasilitas untuk membuat suatu sistem model dan fungsi-fungsi yang tersedia bagi aktor.

Ada dua jenis interface antar muka, yaitu: user interface, dan system interface.

Menurut Mathiassen et al (2000), kegiatan interface mempunyai tiga konsep,

yaitu :

1. Interface, yaitu fasilitas yang membuat model system dan fungsi dapat digunakan

oleh actor

2. User interface, adalah interface untuk pengguna

3. System interface, adalah interface yang digunakan oleh sistem lain untuk berinteraksi

dengan sistem yang dibangun (p.151).

Suatu user interface harus dapat menangani berbagai macam user atau pengguna

yang memiliki kemampuan dan kapabilitas yang berbeda. User interface sangat sulit

untuk dikembangkan apabila tidak menerima umpan balik berupa ide atau masukan yang

berarti dari pengguna. Suatu system interface tidak hanya dapat digunakan untuk sistem

administrasi tetapi dapat digunakan pada sistem-sistem lainnya. System Interface lebih

banyak digunakan pada monitoring system dan control systems.

Ada empat jenis dialog yang penting dalam menentukan interface pengguna,

yaitu:

1. Menu – selection. Suatu jenis dialog yang terdiri dari daftar pilihan-pilihan yang

dapat atau mungkin dilakukan dalam user interface.

2. Form filling. Merupakan pola klasik yang digunakan untuk entri data

3. Command language. Merupakan suatu jenis dialog yang memungkinkan pengguna

memasukkan dan memulai format perintah sendiri.

4. Direct manipulation. User memilih objek dan melaksanakan function atas objek dan

melihat hasil interaksi mereka tersebut.

39

Kegiatan dari interface didasarkan atas hasil dari kegiatan-kegiatan sebelumnya

yang dilakukan, problem domain, function, dan use case. Hasil dari kegiatan ini adalah

sebuah deskripsi dari elemen-elemen user interface maupun system interface yang

lengkap. Interface element harus juga dilengkapi dengan suatu navigation diagram yang

menyediakan sebuah ringkasan dari elemen-elemen user interface dan perubahan antara

elemen-elemen tersebut. Berikut ini adalah contoh user interface.

Gambar 2.8 Contoh User Interface

2.4.7 Architecture Design

Mengacu pada Mathiassen et al. (2000) keberhasilan suatu sistem ditentukan dari

kekuatan desain arsitekturalnya. Arsitektur membentuk sistem yang sesuai dengan sistem

tersebut dengan memenuhi kriteria desain tertentu. Arsitektur berfungsi sebagai kerangka

untuk pengembangan selanjutnya. Suatu arsitektur yang tidak jelas akan menghasilkan

pekerjaan yang sia-sia.

Architecture design adalah merancang arsitektur secara garis besar yang terdiri

dari komponen dan proses. Kegiatan architecture design bertujuan untuk membangun

40

sistem yang terkomputerisasi. Arsitektur membentuk sistem sesuai dengan fungsi sistem

tersebut dan dapat memenuhi kriteria desain tertentu.

Mengacu pendapat Mathiassen et al (2000), di dalam desain arsitektur, terdapat

tiga prinsip dasar, yaitu: define and prioritize criteria, bridge criteria and technical

platform, and evaluate design early (p.175). Kegiatan-kegiatan yang dilakukan didalam

desain arsitektur dapat dilihat pada gambar dan tabel dibawah ini.

Kegiatan Isi Kondisi Kriteria Komponen Proses

Kondisi dan criteria untuk pendesainan Bagaimana sistem dibentuk menjadi komponen-komponen Bagaimana proses sistem dikoordinasikan dan didistribusikan

Criterion Arsitektur komponen Arsitektur proses

Tabel 2.6 Kegiatan Architecture Design (Mathiassen et al (2000,p.176)

2.4.7.1 Criteria

Mathiassen et al (2000) menyatakan, tujuan dari sebuah criteria adalah untuk

mempersiapkan prioritas dari sebuah perancangan. Konsep utama pada aktivitas criteria,

yaitu:

• Criteria : menentukan property yang diinginkan dari sebuah arsitektur

• Condition : hal-hal yang bersifat teknis, organisasional, kelebihan dan keterbatasan

manusia yang terlibat dalam tugas.

Criteria adalah suatu sifat istimewa dari sebuah arsitektur. Aktivitas ini bertujuan

untuk membuat desain. Desain yang bagus bukan hanya dinilai dari sifatnya, tetapi

apabila terdapat kekurangan dapat menjadi tidak berguna dalam prakteknya. Secara

41

umum, design yang bagus itu berguna, fleksible dan mudah dimengerti. Hasil dari

kegiatan criteria adalah Collection prioritized criteria.

Karakteristik dalam membuat desain yang baik adalah sebagai berikut:

• Desain yang baik tidak mempunyai kelemahan

Prinsip ini memperlihatkan tujuan utama atau yang paling mendasar dari

object criteria design. Prinsip ini menimbulkan penekanan pada evaluasi kualitas

berdasarkan review dan eksperimen dan membantu dalam menentukan prioritas dari

kriteria. Ada beberapa Kriteria umum yang digunakan dalam kegiatan desain yang

berorientasi objek, yang ditunjukkan dalam tabel dibawah ini.

Criterion Measure of 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 dalam melaksanakan fungsi Maintainable Biaya untuk menemukan dan memperbaiki kerusakan Testable Biaya untuk memastikan bahwa sistem yang dibentuk dapat

melaksanakan fungsi yang diinginkan Flexible Biaya untuk mengubah sistem yang dibentuk 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

Tabel 2.7 Criteria

42

• Desain yang baik mempunyai criteria yang seimbang

Tidak semua kriteria memiliki prioritas. Beberapa kriteria dapat

menunjukkan objektivitas secara keseluruhan, sehingga dapat mewakili kriteria

lainnya.

• Desain yang baik adalah usable, flexibility, dan comprehensibility

Kriteria-kriteria diatas ini bersifat universal dan dapat digunakan pada hampir

setiap proyek pengembangan sistem, bagaimanapun mengorganisasikannya,

menunjukkan tiga kriteria ideal pada proyek pengembangan sistem.

Usable menspesifikasikan kualitas pada sistem yang pokok tergantung

bagaimana cara kerjanya. Flexibility memuat sistem arsitektur merubah organisasi

dan kondisi teknik. Sedangkan comprehensibility memberikan peningkatan pada

sistem komputerisasi, model dan deskripsi harus mudah untuk dipahami.

Mengacu pada pendapat Mathiassen et al (2000), sebuah desain yang baik

diperlukan pertimbangan mengenai kondisi dari setiap proyek yang dapat mempengaruhi

kegiatan desain, antara lain:

a. 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

b. Conceptual, yang terdiri dari pertimbangan perjanjian kontrak, rencana untuk

pengembangan lanjutan, dan pembagian kerja antara pengembang

43

c. 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.

2.4.7.2 Component Architecture

Component Architecture adalah struktur sistem yang terdiri dari komponen yang

saling berhubungan. Component Architecture membuat sistem lebih mudah dimengerti,

menyederhanakan desain dan mencerminkan kestabilan sistem. Komponen merupakan

kumpulan bagian-bagian program yang membentuk suatu kesatuan dan memiliki fungsi

yang jelas.

Tujuan dari membuat aktivitas ini adalah untuk membuat struktur sistem yang

fleksibel dan mudah dimengerti. Menurut pendapat Mathiassen et al (2000), suatu

arsitektur komponen yang baik menunjukkan beberapa prinsip, yaitu mengurangi

kompleksitas dengan membagi menjadi beberapa tugas, menggambarkan stabilitas dari

konteks sistem, dan memungkinkan suatu komponen dapat digunakan pada bagian lain

(p.191). Beberapa pola yang dapat digunakan untuk merancang Component Architecture

adalah sebagai berikut:

1. Layered architecture pattern. Bentuk yang paling umum dalam software, yaitu

terdiri dari beberapa komponen yang dibentuk menjadi beberapa lapisan-lapisan

yang mirip dengan prinsip OSI Layer pada model jaringan, dimana lapisan yang

berada diatas bergantung pada lapisan yang berda dibawahnya, begitu pula

sebaliknya. Arsitektur ini sangat berguna untuk memecah sistem menjadi komponen-

komponen.

44

2. Generic architecture pattern. Pattern ini dapat digunakan untuk menguraikan sistem

dasar yang terdiri dari interface, function, dan model component. Model component

berada di layer yang paling bawah yang kemudian dilanjutkan oleh Function layer

dan yang paling atas adalah Interface layer.

3. Client server architecture pattern. Pattern ini dibangun untuk mengatasi sistem yang

terdistribusi di beberapa proses yang tersebar. Arsitektur ini terdiri dari sebuah server

dan beberapa client. Server memiliki kumpulan operation yang dapat digunakan oleh

client. Client menggunakan server secara indenpenden. Bentuk distribusi dari bagian

sistem harus diputuskan antara client dan server. Identifikasi komponen, di dalam

perancangan sistem atau subsistem, pada umumnya memulai dengan layer

architecture yang menggunakan interface, function, dan model component.

Berikut ini adalah beberapa jenis distribusi dalam arsitektur client-server dimana

adalah User Interface, F adalah Function, dan M adalah Model.

Client Server Architecture

U

U

U+F

U+F

U+F+M

U+F+M

F+M

F+M

M

M

Distributed presentation

Local presentation

Distributed functionality

Centralized data

Distributed data

Tabel 2.8 Jenis Arsitektur client-server

Hasil dari suatu component architecture adalah component diagram yang

menunjukkan hubungan antara komponen (dalam hal ini adalah server dan beberapa

client).

45

Client_Teller Client_Customer_Service Client_Nasabah

Server

Component_UI_Teller

Component_Function_Teller Component_Function_CSComponent_Function_Nasabah

Component_Model_CS Component_Model_Nasabahcomponent_model_teller

Component_UI_CS Component_UI_Nasabah

component_model_server

Gambar 2.9 Contoh Component Diagram

2.4.7.3 Process Architecture

Process architecture adalah struktur eksekusi sistem yang terdiri atau tersusun

dari proses yang saling bergantungan. Tujuan dari aktivitas ini adalah mendefinisikan

struktur sistem.

Menurut Mathiassen et al (2000), ada empat konsep yang harus diketahui,

diantaranya sebagai berikut:

1. Process architecture adalah struktur eksekusi sistem yang tersusun dari proses

yang saling bergantungan.

2. Processor adalah sebuah peralatan yang dapat mengeksekusi sebuah program.

3. Program component adalah modul fisik dari kode program.

46

4. Active object adalah sebuah objek yang telah ditugaskan oleh sebuah proses (p209).

Pada process architecture, sumber daya yang digunakan secara bersama perlu

diidentifikasi untuk mencari bottleneck.

Menurut Mathiassen et al (2000), sumber daya yang pada umumnya digunakan

secara bersama adalah sebagai berikut:

1. Processor. Penggunaan processor secara bersamaan terjadi apabila dua atau lebih

proses yang dieksekusi secara bersamaan pada satu processor.

2. Program component. Program component digunakan secara bersamaan apabila

dua atau lebih proses yang secara bersamaan memanggil operasi pada komponen.

3. External device. External device digunakan secara bersamaan pada saat terjadi

pemrosesan dua atau lebih pada suatu peralatan. Contoh: penggunaan printer yang

terhubung melalui jaringan (p220).

Bottleneck artinya kemacetan yang terjadi pada proses. Seperti yang telah

disebutkan diatas bahwa untuk mencari bottleneck, maka perlu memperhatikan

penggunaan processor, external device, tempat penyimpanan data atau juga sistem

koneksi. Hasil dari process architecture adalah membuat Deployment Diagram.

47

TELLER

User Interface

Function

Model

System Interface

CUSTOMER SERVICE

USER INTERFACE

FUNCTION

MODEL

SYSTEM INTERFACE

SERVER

MOdEL SysteM InterfacE

NASABAH

user interface

function

model

system interface

PrinterPRINTER

ATM

Gambar 2.10 Contoh Deployment Diagram

2.5 Kaitan Analisis dan Perancangan dengan Orientasi Objek

Menurut pendapat Larman (1998), untuk merancang suatu aplikasi piranti lunak,

pada tahap awal diperlukan deskripsi dari permasalahan dan spesifikasi aplikasi yang

dibutuhkan. Apa saja persoalan yang ada dan apa yang harus dilakukan oleh sistem.

Analisis menekankan pada proses investigasi atas permasalahan yang dihadapi

tanpa memikirkan definisi solusinya terlebih dahulu. Jadi, dalam tahap analisis,

dikumpulkan informasi mengenai permasalahan, spesifikasi sistem berjalan, serta

spesifikasi sistem yang diinginkan.

Perancangan menekankan pada solusi logika dan bagaimana memenuhi

spesifikasi yang dibutuhkan serta konstrain yang ada. Inti dari analisis dan perancangan

48

berorientasi objek adalah untuk menekankan pertimbangan atas domain permasalahan

beserta solusinya dari sudut pandang objek (benda, konsep, ataupun entitas).

Tahap analisis berorientasi objek, lebih ditekankan untuk mencari dan

mendefiniskan objek atau konsep yang ada dalam domain atau wilayah lingkup

permasalahan. Dalam tahap perancangan berbasiskan objek, penekanan terletak pada

bagaimana mendefinisikan objek-objek logika dalam aplikasi (software object) yang

akan diimplementasikan ke dalam bahasa pemrograman berorientasi objek. Software

object tersebut juga memiliki attribute-attribute dan method-method. Bagian

perancangan atau desain dilanjutkan dengan tahapan construction atau OO

programming, yakni mengimplementasikan perancangan komponen ke dalam bahasa

pemrograman (p.6).