BAB II TINJAUAN PUSTAKA. definisi ringkas dan formal dari sistem Informasi

ADLN – PERPUSTAKAAN UNIVERSITAS AIRLANGGA

BAB II TINJAUAN PUSTAKA

2.1. Konsep Sistem Informasi Sebelum membahas konsep sistem Informasi, berikut ini akan diberikan definisi ringkas dan formal dari sistem Informasi. 2.1.1. Definisi sistem informasi Sistem adalah serangkaian komponen yang saling berinteraksi untuk mencapai suatu tujuan. Setiap sistem memiliki karakter yang unik yang membedakan sistem tersebut dengan sistem lainnya. Setiap komponen dalam sistem memiki kontribusi penting bagi sistem dan hilangnya salah satu komponen dalam sistem memiliki dampak cukup besar terhadap perilaku sistem dalam mencapai tujuannya (Van Belle, 2003). Informasi adalah data (representasi dari fakta) yang diolah untuk suatu tujuan yang berguna melalui suatu proses tertentu (Van Belle, 2003). Sistem informasi adalah suatu sistem yang mengumpulkan dan mengolah data untuk menghasilkan suatu informasi yang ditujukan kepada penggunanya (Van Belle, 2003). Definisi lain dari sistem informasi adalah sistem terorganisisir dan terintegrasi yang mengumpulkan, memasukkan, dan memproses data serta menyimpan, mengelola, mengontrol dan menyampaikan informasi, yang digunakan oleh organisasi untuk mencapai tujuannya (O’Brien, 2005).

7 SKRIPSI

ANALISIS ALFREDO DAN ... CHRISTIAN DHERMAWAN SIHOMBING


8 2.1.2. Pengembangan sistem informasi Pengembangan sistem informasi dapat diartikan menyusun suatu sistem informasi yang baru untuk menggantikan sistem informasi yang lama secara keseluruhan atau memperbaiki sistem yang telah ada. Tahapan – tahapan dalam pengembangan sistem informasi antara lain (Van Belle, 2003) : a. Perencanaan Sistem Pada tahap ini, pengembang menentukan tujuan pembuatan sistem baru, batasan sistem baru, mengidentifikasi permasalahan utama yang menyebabkan organisasi membutuhkan adanya sistem baru dan memeriksa solusi yang mungkin atas permasalahan tersebut. b. Analisis Sistem Pada

tahap

ini,

pengembang

mengidentifikasi

spesifikasi

kebutuhan sistem dari pengguna dan mengembangkan konsep penyelesaian permasalahan. c. Perancangan Sistem Pada tahap ini, pengembang membuat suatu rancangan berdasarkan spesifikasi kebutuhan sistem dari pengguna yang diperoleh pada tahap analisis. d. Pembangunan Sistem Pada tahap ini, pengembang membangun sistem dengan melakukan penerjemahan rancangan sistem yang dibuat pada tahap perancangan ke dalam bentuk kode program.

SKRIPSI



9 e. Implementasi Sistem Pada tahap ini, pengembang melakukan instalasi sistem baru pada lingkungan pengguna, serta memberikan pelatihan pengguna mengenai penggunaan sistem baru. f. Pemeliharaan Sistem Pada tahap ini, pengembang melakukan permeliharaan sistem yaitu dengan memperbaiki sistem jika terdapat fitur sistem yang mengalami error.

2.1.3. Metode pengembangan sistem informasi Metode pengembangan sistem informasi terbagi atas 3 jenis metode antara lain (Sommerville, 1985) : a. Top-down structured design Metode ini menerapkan algorithmic decomposistion dalam penanganan masalah kompleksitas dalam pengembangan suatu sistem. Algorithmic decomposistion fokus pada urutan atau prosedur sistem sehingga kurang mendukung adanya perubahan dalam sistem, namun sebagian besar sistem dan perangkat lunak telah dikembangkan dengan metode perngembangan ini. b. Data-driven design Dalam metode ini, struktur sistem yang akan dikembangkan berasal dari pemetaan sistem input dan output. Seperti metode terstruktur, metode ini telah cukup banyak diterapkan oleh para pengembang, seperti

SKRIPSI



10 pada pengembangan sistem informasi manajemen yang melibatkan hubungan secara langsung antara input dengan output pada sistem. c. Object-oriented analysis and design Metode ini menerapkan object-oriented decomposistion dalam penanganan masalah kompleksitas dalam pengembangan suatu sistem. Object-oriented decomposistion fokus pada subjek dan operasi yang ditangani oleh subjek. Metode ini memodelkan sistem sebagai kumpulan dari objek dimana objek itu sendiri merupakan bentuk instance dari kelas dan kelas tersebut merupakan bagian dari hirarki kelas.

2.2. Sistem Akuntansi Pembelian Sebelum membahas sistem akuntansi pembelian, berikut ini akan diberikan definisi ringkas dan formal dari sistem akuntansi pembelian. 2.2.1. Definisi sistem akuntansi pembelian “Sistem akuntansi pembelian digunakan dalam perusahaan untuk pengadaan barang yang diperlukan oleh perusahaan. Transaksi pembelian dapat digolongkan menjadi dua: pembelian lokal dan impor. Pembelian lokal adalah pembelian dari pemasok dalam negeri, sedangkan impor adalah pembelian dari pemasok luar negeri” (Mulyadi, 2001). 2.2.2. Fungsi terkait Fungsi yang terkait dalam sistem akuntansi pembelian adalah (Mulyadi, 2001) :

SKRIPSI



11 a. Fungsi Gudang Dalam sistem akuntansi 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 barang-barang yang langsung pakai (tidak diselenggarakan persediaan barang di gudang), permintaan pembelian diajukan oleh pemakai barang. b. 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. Dalam struktur organisasi pada suatu perusahaan, fungsi pembelian berada di tangan Bagian Pembelian. c. Fungsi Penerimaan Dalam sistem akuntansi pembelian, fungsi ini bertanggung jawab untuk melakukan pemeriksaan terhadap jenis, mutu, dan kuantitas barang yang 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. Dalam struktur organisasi pada suatu persahaan, fungsi penerimaan berada ditangan Bagian Penerimaan.

SKRIPSI



12 d. Fungsi Akuntansi Fungsi akuntansi yang terkait dalam transaksi pembelian adalah fungsi pencatat utang dan fungsi pencatat persediaan. Dalam sistem akuntansi 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 berfungsi sebagai catatan utang atau menyelenggarakan kartu utang sebagai buku pembantu utang. Dalam sistem akuntansi pembelian, fungsi pencatat persediaan bertanggung jawab untuk mencatat harga pokok persediaan barang yang dibeli ke dalam kartu persediaan. Dalam struktur organisasi pada suatu perusahaan, fungsi pencatat utang berada di tangan Bagian Utang sedangkan fungsi pencatat persediaan berada di tangan Bagian Kartu Persediaan.

2.3. Metode Berorientasi Objek Metode berorientasi objek digunakan untuk memodelkan sistem dan menangani masalah kompleksitas dalam pengembangan sistem. Berikut ini akan dijelaskan mengenai metode berorientasi objek. 2.3.1. Istilah – istilah penting dalam metode berorientasi objek Terdapat tiga istilah penting yang melekat dalam pengembangan metode berorientasi objek, antara lain (Grady Booch, 1994) :

SKRIPSI



13 a. Object-oriented analysis (OOA) Object-oriented analysis adalah salah satu metode analisis yang mengidentifikasi kebutuhan sistem dari perspektif kelas dan objek yang ditemukan dalam pendefinisian masalah. b. Object-oriented design (OOD) Object-oriented design adalah salah satu metode perancangan yang meliputi proses object-oriented decomposition dan bentuk notasi yang menggambarkan struktur dari kelas dan objek serta rancangan arsitektur dari tiap modul dan proses dalam sistem. Contoh bentuk notasi adalah Unified Modelling Language (UML). c. Object-oriented programming (OOP) Object-oriented

programming

adalah

salah

satu

metode

implementasi dimana setiap program diorganisasikan sebagai kumpulan dari objek dimana setiap objek merupakan bentuk instance dari kelas dan kelas kelas tersebut merupakan bagian dari hirarki kelas yang disatukan melaui hubungan inheritance atau pewarisan.

2.3.2. Kelas dan objek Kelas adalah sekumpulan objek yang berbagi struktur dan perilaku yang sama. Objek adalah bentuk instance dari kelas. Setiap objek memiliki suatu kondisi, perilaku dan identitas yang unik. Objek yang memiliki kemiripan dalam perilaku didefinisikan dalam kelas yang sama (Grady Booch,1994)

SKRIPSI



14 2.3.3. Elemen – elemen penting dalam metode berorientasi objek Terdapat tiga istilah penting yang melekat dalam pengembangan metode berorientasi objek, antara lain (Grady Booch, 1994) : a.

Abstraction Abstraction menggambarkan karakteristik obyek yang paling penting dan paling dominan yang bisa digunakan untuk membedakan obyek tersebut dari obyek lainnya serta dengan tegas memberikan batas – batas konseptual yang relative dengan perspektif pembaca.

b. Encapsulation Encapsulation adalah proses pengelompokkan elemen – elemen dalam proses abstraksi yang membentuk struktur dan perilaku objek. Encapsulation menyembunyikan banyak hal yang terdapat dalam obyek yang tidak perlu diketahui oleh obyek lain. Encapsulation diwujudkan dengan membuat suatu kelas interface yang akan dipanggil oleh obyek lain, sementara didalam obyek yang dipanggil terdapat kelas lain yang mengimplementasikan apa yang terdapat dalam kelas interface. Obyek lain hanya tahu dia perlu memanggil kelas interface tanpa perlu tahu proses apa saja

yang

dilakukan

didalam

kelas

implementasinya

dan

untuk

menuntaskan proses tersebut perlu berhubungan dengan obyek mana saja. c. Modularity Modularity adalah properti dari sistem yang telah didekomposisi menjadi serangkaian kohesif dan kumpulan modul. Modularity membagi

SKRIPSI



15 sistem yang rumit menjadi bagian-bagian yang lebih kecil yang bisa mempermudah developer memahami dan mengelola obyek tersebut. d. Hierarchy Hierarchy berhubungan dengan abstraksi dan modularitas, yaitu pembagian berdasarkan urutan dan pengelompokkan tertentu. Misalnya untuk menentukan obyek mana yang berada pada kelompok yang sama, obyek mana yang merupakan komponen dari obyek yang memiliki hirarki lebih tinggi. Semakin rendah hirarki obyek berarti semakin jauh abstraksi dilakukan terhadap suatu obyek.

2.4. Unified Modeling Language (UML) UML singkatan dari Unified Modelling Language yang berarti sebagai bahasa pemodelan standar. Sebagai bahasa pemodelan, UML memiliki sintaks dan semantik (Chonoles, 2003). Ketika kita membuat model menggunakan konsep UML terdapat beberapa aturan yang harus diikuti seperti bagaimana membuat elemen-elemen dalam model saling berhubungan harus mengukuti standar yang ada (Widodo, 2011). UML diaplikasikan untuk beberapa tujuan tertentu, antara lain (Widodo, 2011) : a. Merancang perangkat lunak. b. Sarana komunikasi antara perangkat lunak dengan proses bisnis. c. Menjabarkan sistem secara rinci untuk analisa dan mencari apa yang dibutuhkan sistem. d. Mendokumentasi sistem yang ada, proses-proses dan organisasinya.

SKRIPSI



16 UML menyediakan beberapa diagram sebagai model seperti use case diagram, class diagram, activity diagram dan lain sebagainya. 2.4.1. Business use case diagram Diagram use case bisnis digunakan untuk mempresentasikan bisnis yang dilakukan organisasi. Diagram use case bisnis digambarkan menurut perspektif dari organisasi dan tidak membedakan apakah aktivitas tersebut dilakukan secara manual atau otomatis menggunakan perangkat lunak. Diagram use case bisnis menunjukkan interaksi antara use case bisnis dan aktor bisnis (Sholiq, 2010). Diagram use case bisnis akan memberikan model lengkap tentang apa yang dilakukan organisasi, siapa yang ada di dalam organisasi, serta siapa yang berada di luar organisasi. (Nugroho, 2005) Berikut adalah notasi-notasi yang digunakan dalam business use case diagram : 1. Aktor Bisnis Aktor Bisnis adalah seseorang atau sesuatu yang ada di luar organisasi. Aktor bisnis berinteraksi dengan organisasi dan terlibat dalam kegiatan bisnis organisasi. Posisi aktor bisnis di luar organisasi yang sedang dimodelkan, tetapi terlibat dalam kegiatan organisasi. Sebagai contoh, aktor bisnis dalam suatu organisasi antara lain pelanggan, investor, ataupun supplier. Notasi aktor bisnis digambarkan pada gambar 2.1.

Gambar 2.1. Aktor bisnis

SKRIPSI



17 2. Pekerja Bisnis Pekerja Bisnis adalah suatu peran di dalam organisasi, bukan posisi atau jabatan. Karena pekerja bisnis adalah peran seseorang dalam organisasi dan bukan posisi seseorang, maka seseorang dapat saja memiliki peran yang berbeda dalam organisasi. Notasi pekerja bisnis digambarkan pada gambar 2.2.

Gambar 2.2. Pekerja bisnis

3. Use Case Bisnis Use Case Bisnis adalah model yang digunakan untuk menggambarkan sebuah proses bisnis organisasi. Use case bisnis menginformasikan tentang aktivitas bisnis utama yang organisasi lakukan. Notasi use case bisnis digambarkan pada gambar 2.3.

Gambar 2.3. Use Case bisnis

4. Relasi Asosiasi Relasi Asosiasi adalah relasi antara aktor bisnis atau pekerja bisnis dan use case bisnis. Relasi asosiasi mengindikasikan bahwa aktor bisnis atau pekerja bisnis tertentu berkomunikasi terhadap fungsionalitas yang disediakan dalam use case bisnis. Dengan kata lain, aktor bisnis tertentu terlihat dalam aktivitas utama

SKRIPSI



18 organisasi, atau pekerja bisnis tertentu sedang menjalankan peran di aktivitas utama organisasi. Notasi relasi Asosiasi digambarkan pada gambar 2.4.

Gambar 2.4. Relasi Asosiasi

5. Relasi Generalisasi Relasi Generalisasi digunakan ketika ada dua atau lebih aktor bisnis, pekerja bisnis, atau use case bisnis yang sangat serupa. Pada relasi generalisasi, arah panah menunjuk dari aktor spesifik ke aktor umum. Notasi relasi Generalisasi digambarkan pada gambar 2.5.

Gambar 2.5. Generalisasi

6. Entitas Bisnis Entitas Bisnis adalah objek yang digunakan atau yang dihasilkan oleh organisasi saat melakukan aktivitas bisnis. Entitas bisnis meliputi sesuatu yang pekerja bisnis hadapi sehari-hari. Misalnya, daftar penjualan, daftar akun, atau segala sesuatu yang relevan untuk aktivitas bisnis. Notasi entitas bisnis digambarkan pada gambar 2.6.

SKRIPSI



19

Gambar 2.6. Entitas Bisnis

Gambar 2.7. Contoh Diagram Use Case Bisnis

2.4.2. System use case diagram Diagram ini memperlihatkan himpunan use-case dan aktor-aktor. Diagram ini sangat penting untuk mengorganisasikan dan memodelkan perilaku dari suatu sistem yang dibutuhkan serta diharapkan pengguna (Nugroho, 2005). Berikut adalah notasi-notasi yang digunakan dalam system use case diagram : 1. Aktor Aktor adalah segala sesuatu yang berinteraksi dengan sistem. Aktor dapat dibagi atas tiga jenis aktor antara lain : pengguna sistem, sistem lain yang berinteraksi dengan sistem, serta waktu. Notasi aktor digambarkan pada gambar 2.8. Actor

Gambar 2.8 : Aktor

SKRIPSI



20 2. Use-Case Use-Case

adalah

fungsionalitas

yang

dimiliki

oleh

sistem

yang

menggambarkan bagaimana aktor akan menggunakan atau memanfaatkan sistem. Dengan melihat use-case, maka pengguna dapat melihat fungsionalitas apa yang akan disediakan oleh sistem dan menyetujui (atau menolak) lingkup sistem sebelum sebelum proyek berjalan lebih jauh. Notasi use-case digambarkan pada gambar 2.9. Use-Case

Gambar 2.9 : Use-Case

3. Relasi Asosiasi Relasi Asosiasi adalah relasi yang terjadi antara aktor dengan use-case yang berupa asosiasi, yang digambarkan dengan garis lurus dengan panah di salah satu ujungnya. Notasi relasi asosiasi digambarkan pada gambar 2.10.

Use-Case

Actor

Gambar 2.10 : Relasi Asosiasi

4. Include Relationship Include Relationship adalah relasi cakupan yang memungkinkan suatu usecase menggunakan fungsionalitas yang disediakan use-case lain. Notasi include relationship digambarkan pada gambar 2.11. <>

Use-Case

Use-Case 1

Gambar 2.11 : Include Relationship

SKRIPSI



21 5. Extend Relationship Extend Relationship adalah relasi yang memungkinkan use-case dapat memperluas fungsionalitas yang disediakan use-case lain. Notasi extend relationship digambarkan pada gambar 2.12. <<extend>>

UseCase1

UseCase

Gambar 2.12 : Extend Relationship

6. Generalisasi Generalisasi digunakan untuk memperlihatkan bahwa beberapa aktor atau usecase memiliki sesuatu yang bersifat umum. Dengan generalisasi pengguna dapat mengelompokkan sifat-sifat umum dari sejumlah aktor atau use-case menjadi aktor atau use-case tunggal yang dapat mewariskan sifat umumnya kepada aktor atau use-case yang lain. Notasi generalisasi digambarkan pada gambar 2.13.

Main Actor

Actor Sub

Sub Actor

Gambar 2.13 : Generalisasi

Gambar 2.14. Contoh System Use Case

Diagram

SKRIPSI



22 2.4.3 Activity diagram Diagram ini memodelkan event-event yang terjadi dalam suatu use-case. Diagram

ini

secara

esensial

mirip

dengan

diagram

alir

(flowchart),

memperlihatkan kendali aliran kendali dari suatu aktifitas ke aktifitas lainnya (Nugroho, 2005). Berikut adalah elemen yang ada pada activity diagram : 1.

Activity State Activity State adalah suatu aktivitas yang terjadi dalam sistem. Activity

State juga berperan dalam menggambarkan langkah-langkah dalam aliran kerja. Notasi activity state digambarkan pada gambar 2.15. Activity State

Gambar 2.15 : Activity State

2.

Start State Start State menggambarkan awal dimulainya suatu aliran kerja sistem

sehingga dalam pembuatan suatu activity diagram, penggambaran notasi ini mutlak dilakukan pada tahap awal. Notasi start state digambarkan pada gambar 2.16. Start State

Gambar 2.16 : Start State

SKRIPSI



23 3.

End State End State adalah penanda berakhirnya aliran kerja sistem sehingga dalam

pembuatan suatu activity diagram, penggambaran notasi ini mutlak dilakukan pada tahap akhir. Notasi end state digambarkan pada gambar 2.17. End State

Gambar 2.17 : End State

4.

State Transition State Transition memperlihatkan lintasan dari satu aksi atau aktifitas ke

aksi atau aktifitas berikutnya. Notasi state transition digambarkan pada gambar 2.18. Activity State

Gambar 2.18 : State Transition

5. Decision Decision memperlihatkan dimana keputusan perlu diambil selama terjadi aliran-aliran kerja. Notasi decision digambarkan pada gambar 2.19.

Gambar 2.19 : Decision

6. Fork Fork memperlihatkan pemisahan beberapa aliran dari satu aliran tunggal. Fork mungkin memiliki satu atau lebih aliran yang keluar dan memiliki satu aliran yang masuk. Notasi state transition digambarkan pada gambar 2.20.

SKRIPSI



24

Gambar 2.20 : Fork

7. Join Join menggambarkan sinkronisasi dari dua atau lebih aliran kendali yang konkuren. Join mungkin memiliki satu atau lebih transisi yang masuk dan memiliki satu aliran keluar. Notasi join digambarkan pada gambar 2.21.

Gambar 2.21 : Join

8. Swimlane Swimlane

memperlihatkan

siapa

yang bertanggung jawab

untuk

melaksanakan tugas-tugas tertentu pada activity diagram. Notasi swimlane digambarkan pada gambar 2.22.

Gambar 2.22 : Swimlane

SKRIPSI



25

Gambar 2.23. Contoh Activity

2.4.4 Sequence diagram

Diagram

Diagram ini memperlihatkan event-event yang berurutan sepanjang berjalannya waktu. Setiap sequence diagram menggambarkan aliran-aliran pada suatu use case. Kita dapat membaca diagram ini dengan melihat pada objek-objek dan pesan-pesan yang tergambar dalam diagram. Pesan-pesan diagambarkan diantara garis hidup yang dimiliki dua objek untuk memperlihatkan bagaimana objek-objek itu saling berkomunikasi (Nugroho, 2005). Berikut adalah elemen yang ada pada sequence diagram : 1. Objek Objek dalam diagram ini diambil dari class – class dalam class diagram. Notasi objek digambarkan pada gambar 2.24.

Gambar 2.24 : Objek

SKRIPSI



26 2. Object Message Object Message menggambarkan pesan antara dua objek. Bentuk notasinya digambarkan dalam bentuk panah dengan ujung terbuka yang menghubungkan objek satu dengan objek lain. Contoh Object Message dapat dilihat pada gambar 2.25. A

B 1: message

3. Message to Self

Gambar 2.25. Object Message

Message to Self menggambarkan pesan yang menuju objek itu sendiri. Bentuk notasinya digambarkan dalam bentuk panah dengan ujung terbuka yang menghubungkan objek satu dengan objek itu sendiri. Contoh Message to Self dapat dilihat pada gambar 2.26. Form

1: Draw

Gambar 2.26. Message to Self

SKRIPSI



27

Gambar 2.27. Contoh Sequence Diagram

2.4.5 Collaboration diagram Seperti sequence diagram, collaboration diagram

juga digunakan untuk

memperlihatkan aliran – aliran pada use case. Sementara sequence diagram berurutan menurut waktu, collaboration diagram berfokus pada relasi – relasi yang terjadi antara objek yang satu dengan objek lainnya. Sequence diagram dan collaboration diagram memperlihatkan fokus yang sama, tetapi dari sudut pandang yang berbeda. Dengan collaboration diagram, pengguna akan lebih mudah melihat relasi relasi antar objek. (Nugroho, 2005). Elemen – elemen yang digunakan pada collaboration diagram memiliki kemiripan, hanya saja dibedakan oleh beberapa elemen yang menunjukkan adanya relasi antar objek, antara lain : 1. Link to self Memperlihatkan bahwa suatu objek memanggil operasinya sendiri. Contoh Link to Self dapat dilihat pada gambar 2.28.

Gambar 2.28. Link to Self

SKRIPSI



28 2. Link Message Menambahkan pesan antara dua objek atau dari suatu objek ke dirinya sendiri. Contoh Link Message dapat dilihat pada gambar 2.29. 1: message A

B

Gambar 2.29 Link message

3. Reverse Link Message Menambahkan pesan dalam arah berlawanan antara dua objek atau dari suatu objek ke dirinya sendiri. Contoh Reverse Link Message dapat dilihat pada gambar 2.30. A

B 1: message

Gambar 2.30. Reverse Link Message

Gambar 2.31. Contoh Collaboration Diagram

2.4.6 Class diagram Diagram ini dapat memperlihatkan himpunan kelas-kelas, antarmukaantarmuka, kolaborasi-kolaborasi serta relasi-relasi. Selain itu, diagram ini juga

SKRIPSI



29 dibuat untuk melihat melihat hubungan antar kelas (Nugroho, 2005). Berikut adalah unsur-unsur dalam class diagram : a. Nama kelas beserta stereotype dari tiap kelas. Jenis – jenis stereotype (type dari kelas) antara lain :

1.

Boundary class Boundary class adalah kelas-kelas yang berada pada batasan antara sistem

dengan lingkungan. Kelsa-kelas ini mencakup form-form, laporan-laporan, antarmuka-antarmuka ke perangkat-perangkat keras seperti printer atau scanner, serta antarmuka ke sistem yang lain. Notasi boundary class digambarkan pada gambar 2.32.

Gambar 2.32 : Boundary Class

2.

Control class Control class bertanggung jawab untuk mengkordinasi upaya-upaya yang

dilakukan kelas-kelas lainnya. Kelas ini bersifat optional, tetapi jika kelas ini digunakan maka kelas ini digunakan untuk setiap use-case, yang fungsinya adalah mengendalikan urutan-urutan event yang mengalir pada use-case. Notasi control class digambarkan pada gambar 2.33.

Gambar 2.33 : Control Class

SKRIPSI



30 3.

Entity Class Entity Class memelihara informasi-informasi yang mungkin akan disimpan

oleh sistem ke dalam tempat penyimpanan yang persisten. Notasi entity class digambarkan pada gambar 2.34.

Gambar 2.34 : Entity Class

b. Atribut dan Operasi Atribut dan operasi dapat memiliki salah satu sifat berikut : 1.

Private. Atribut atau operasi yang bersifat private tersembunyi dari kelas-kelas lain

sehingga kelas-kelas lain tidak dapat mengakses dan memanfaatkannya. Atribut atau operasi yang bersifat private, pada notasinya tedapat gambar gembok. 2.

Protected Atribut atau operasi yang bersifat protected hanya dapat diakses oleh anggota

kelas yang bersangkutan serta kelas-kelas lain yang menjadi turunannya dalam hierarki pewarisan (inheritance). Atribut atau operasi yang bersifat protected, pada notasinya tedapat gambar kunci. 3.

Public Atribut atau operasi yang bersifat public tampak bagi semua kelas sehingga

dapat diakses dan dimanfaatkan oleh semua kelas yang ada.dapat dipanggil oleh siapa saja.

SKRIPSI



31 c. Hubungan Antar Class 1.

Asosiasi. Asosiasi adalah koneksi semantik antara suatu kelas dengan kelas yang

lainnya. Bentuk notasinya digambarkan dengan garis lurus yang menghubungkan antar kelas. Contoh Asosiasi dapat dilihat pada gambar 2.35. A

B Gambar 2.35. Asosiasi

2.

Dependencies. Berbeda dengan asosiasi, dependency selalu bersifat satu arah dan

memperlihatkan bahwa, meski suatu kelas tidak menginstansiasi yang lainnya, kelas tersebut tidak perlu mengirim pesan ke kelas yang lainnya. Bentuk notasinya digambarkan dengan garis panah putus-putus dengan ujung panah terbuka yang menghubungkan antar kelas. Contoh Dependencies dapat dilihat pada gambar 2.36. Penumpang

Penerbangan

Gambar 2.36. Dependencies

3.

Agregasi Agregasi merupakan bentuk yang lebih kuat dari asosiasi.Agregasi adalah

relasi antara suatu keseluruhan ke bagian-bagiannya. Bentuk notasinya digambarkan

dengan

garis

panah

dengan

ujung

panah

terbuka

yang

menghubungkan kelas keseluruhan (ditandai dengan tanda intan atau diamond ) dengan kelas-kelas bagiannya. Contoh Agregasi dapat dilihat pada gambar 2.37.

SKRIPSI



32

Mobil

Mesin

Ban

...

Gambar 2.37. Agregasi

4.

Realisasi Realisasi digunakan untuk memperlihatkan relasi antara suatu kelas dengan

interface-nya, antara paket dengan interface-nya, antara komponen dengan interface-nya, atau antara use case dengan realisasi use case yang bersangkutan. Bentuk notasinya digambarkan dengan garis panah putus-putus dengan ujung panah tertutup yang menghubungkan antar kelas. Contoh Realisasi dapat dilihat pada gambar 2.38.

Class Interface Gambar 2.38. Realisasi

5.

Generalisasi Generalisasi diperlukan untuk memperlihatkan relasi atau hubungan

pewarisan antar unsur dalam diagram kelas. Bentuk notasinya digambarkan dengan garis panah dengan ujung panah tertutup yang mengubungkan kelas induk dengan kelas-kelas turunannya. Contoh Generalisasi dapat dilihat pada gambar 2.39.

Induk

Anak

Anak

Gambar 2.39. Generalisasi

SKRIPSI



33 d. Multiplisitas relasi Multiplisitas memberi petunjuk pada kita tentang banyaknya instansiasi suatu keals berhubungan dengan satu instansiasi kelas yang lain pada suatu waktu tertentu. Notasi-notasi yang dapat digunakan antara lain: 1. ( * ) memilki arti banyak. 2. ( 0 ) memiliki arti nol. 3. ( 1 ) memiiki arti satu. 4. ( 0..* ) memiliki arti nol atau banyak. 5. ( 1..* ) memiliki arti satu atau banyak. 6. ( 0..1 ) memiliki arti nol atau satu. 7. ( 1..1 ) memiliki arti hanya satu.

Gambar 2.40. Contoh Class Diagram

SKRIPSI



34 2.4.7 Statechart diagram Statechart Diagram memungkinkan untuk memodelkan bermacam-macam state yang mungkin dialami oleh obyek tunggal. Diagram statechart digunakan untuk menggambarkan perilaku dinamik sebuah obyek tunggal. Diagram statechart menunjukkan siklus hidup sebuah obyek tunggal, dari saat dibuat sampai obyek tersebut dihapus. Misalkan sebuah Account di bank dapat eksis pada beberapa keadaan yang berbeda. Account tersebut bisa berbeda pada kondisi: buka, tutup, atau kondisi overdraw (keadaan ketika jumlah pengambilan lebih besar dari simpanan yang ada, hal tersebut dimungkinkan di bank tertentu sebagai utang nasabah kepada bank). (Sholiq, 2010) Berikut adalah elemen yang ada pada statechart diagram : 1.

State State adalah kondisi yang mungkin dialami oleh suatu obyek. Terdapat dua

cara untuk mengidentifikasi kondisi obyek yaitu dengan memeriksa nilai attribute atau dengan memperhatikan relasi terhadap obyek lain. Notasi state digambarkan pada gambar 2.41.

Gambar 2.41. State

2.

Transisi Transisi adalah sebuah pergerakan dari satu state ke state lainnya.

Kumpulan transisi-transisi pada sebuah diagram memperlihatkan bagaimana suatu

SKRIPSI



35 obyek bergerak dari satu state ke state yang lain.transisi digambarkan sebagai anak panah dari state sumber ke state tujuan. Notasi transisi digambarkan pada gambar 2.42.

Gambar 2.42. Transisi

3.

Start State Start State digunakan untuk memulai diagram statechart. Notasi start state

digambarkan pada gambar 2.43.

Gambar 2.43. Start State

4. End State End State digunakan untuk mengakhiri diagram statechart.End State dapat dibuat lebih dari satu untuk satu diagram statechart Notasi end state digambarkan pada gambar 2.44.

Gambar 2.44. End State

SKRIPSI



36

Gambar 2.45. Contoh Statechart Diagram

2.4.8 Component diagram Diagram ini memperlihatkan organisasi serta kebergantungan sistem pada komponen-komponen yang telah ada sebelumnya. Diagram ini berhubungan dengan diagram kelas dimana komponen secara tipikal dipetakan ke dalam satu atau lebih kelas-kelas, antarmuka-antarmuka (interfaces), serta kolaborasikolaborasi (Nugroho, 2005). Berikut adalah elemen yang ada pada component diagram : 1. Component Component adalah modul fisik kode. Component menggambarkan modul perangkat lunak dengan antarmuka yang didefinisikan dengan baik. Notasi component digambarkan pada gambar 2.46. Component

Gambar 2.46 : Component

SKRIPSI



37 2. Dependency Hanya ada satu jenis relasi antar komponen, yaitu dependency, yang menggambarkan bahwa suatu komponen bergantung pada komponen (atau komponen-komponen lainnya). Notasi dependency digambarkan sebagai tanda panah dengan garis putus-putus. Notasi dependency digambarkan pada gambar 2.47.

Gambar 2.47 : Dependency

Gambar 2.48. Contoh Component Diagram

2.5 Konsep Metric Evaluasi rancangan sistem sangat penting untuk mengetahui kualitas dari rancangan tersebut. Salah satu cara dalam evaluasi adalah metric, berikut akan dijelaskan mengenai konsep dari metric.

SKRIPSI



38 2.5.1 Definisi metric Metric merupakan salah satu cara dalam mengukur tingkat kuantitatif sebuah rancangan sistem (Amandeep,2009). Metric digunakan dengan tujuan untuk menilai desain object-oriented dari suatu perangkat lunak atau sistem. Terdapat 6 metric yang digunakan untuk evaluasi dari desain object-oriented. 6 metric tersebut dapat dilihat pada tabel 2.1. Tabel 2.1. Metric No. 1 2 3 4 5 6

Metric Object-Oriented Weighted Methods per Class (WMC) Response For a Class (RFC) Coupling Between Objects (CBO) Lack of Cohesion in Methods (LCOM) Depth of Inheritance Tree (DIT) Number of Children (NOC)

Atribut class class coupling cohesion inheritance inheritance

1. Weighted Methods per Class (WMC) Weighted Methods per Class (WMC) digunakan untuk menghitung jumlah kompleksitas dari semua method class. WMC merupakan indikator berapa banyak usaha diperlukan untuk mengembangkan dan mempertahankan class tertentu. Sebuah kelas dengan WMC rendah biasanya menunjuk ke polimorfisme yang lebih besar. Sebuah kelas dengan WMC yang tinggi menunjukkan bahwa kelas adalah kompleks, oleh karena itu sulit untuk menggunakan kembali dan mempertahankan. Apabila terdapat class C1 dengan method c1,…cn maka WMC dirumuskan: (2.1)

SKRIPSI



39 2. Response For a Class (RFC) Response For a Class (RFC) adalah beberapa method dalam sebuah himpunan method yang dapat dipanggil untuk menanggapi pesan yang dikirim ke sebuah objek dari sebuah class. RFC mencakup semua method yang diakses dalam hirarki kelas. RFC terlihat pada kombinasi dari kompleksitas sebuah class melalui sejumlah metode dan jumlah komunikasi dengan class lain. 3. Coupling Between Objects (CBO) Coupling Between Objects (CBO) digunakan untuk mengetahui hubungan atau ketergantungan tiap class. Suatu class jika terlalu erat dengan class lain akan menyulitkan pengujian dan modifikasi, dan membatasi kemungkinan digunakan kembali. 4. Lack of Cohession in Methods (LCOM) Lack of Cohession in Methods (LCOM) digunakan untuk mengukur jumlah method yang tidak terhubung atau perpotongan dalam sebuah class yang mewakili bagian independen dan tidak ada kohesi. Jika ditentukan sebuah class C1 dengan method M1, M2,…Mn dan variable I1, I2,..In maka deerajat similaritas untuk method pada class C1 adalah: (2.2) 5. Depth of Inheritance Tree (DIT) Depth of Inheritance Tree (DIT) didefinisikan sebagai panjang maksimal dari suatu class menuju ke class akar dalam struktur warisan dari suatu sistem. Semakin dalam suatu class pada pohon warisan akan relatif kompleks untuk mengembangkan, menguji dan memelihara.

SKRIPSI



40 6. Number of Children (NOC) Number of Children (NOC) digunakan menghitung jumlah sub-class dari class induk dalam hirarki sebuah class. Semakin tinggi nilai NOC menyebabkan semakin besar reuseability karena inheritance adalah bentuk dari reuse. Semakin besar NOC juga dapat menyebabkan proses pengujian semakin banyak karena apabila terjadi perubahan di suatu class dapat mempengaruhi class yang menjadi subclass dari class tersebut.

SKRIPSI


BAB II TINJAUAN PUSTAKA. definisi ringkas dan formal dari sistem Informasi

Recommend Documents