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 transaksi-

transaksi 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 barang-

barang 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 barang-

barang 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 object-

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

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

Component

Architectural

Application

domain

Problem

domain

Specifications for

Model

Requirements

Specifications for

System Choice

System Definition

23

berguna untuk memfasilitasi komunikasi yang baik antara pengguna dalam

sistem.

Rich picture difokuskan pada aspek-aspek penting dari sisem

tersebut, yang ditentukan sendiri oleh pengembang sistem dengan

mengunjungi perusahaan untuk melihat bagaimana perusahaan beroperasi,

berbicara dengan banyak orang untuk mengetahui apa yang harus terjadi

atau seharusnya terjadi, dan mungkin melakukan beberapa wawancara

formal.

2.6. Analisa Problem Domain

Menurut Mathiassen L. Et al. (2000)” problem domain adalah

bagian dari konteks yang diatur, dimonitor, atau dikendalikan oleh sistem”

(p. 45). Analisis problem-domain memfokuskan pada informasi apa yang

harus ditangani oleh sistem dan menghasilkan sebuah model yang

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

(behaviour) yang ada dalam problem domain. Untuk lebih jelasnya

kegiatan-kegiatan yang dilakukan dalam analisis problem-domain dapat

dilihat pada table 2.1 berikut ini.

24

Tabel 2.1. Kegiatan Problem-Domain Analysis

Kegiatan Isi Konsep

Kelas Objek dan event yang merupakan

bagian dari problem domain

Kelas, objek, event

Struktur Bagaimana kelas dan objek saling

berkaitan

Generalisasi, agregasi, asosiasi,

dan cluster

Behaviour Property dinamik yang dimiliki

objek

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

( 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).

Class Event

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

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

class 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-owned-

by”. 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 class-

class 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*

-c..d*

-a..b*

-c..d*

Ket : a-d adalah multiplicity

Gambar 2.4 Notasi object structure

( Sumber : Mathiassen L. Et al. , 2000, p337)

30

car person0..* 1..*

Gambar 2.5 Association Structure

( Sumber : Mathiassen L. Et al. , 2000, p77)

2.6.3. Behaviour

Menurut Mathiassen Et al. (2000) kegiatan behaviour adalah

kegiatan terakhir dalam analisa problem-domain yang bertujuan untuk

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

system sepanjang waktu(p. 89). Tugas utama dalam kegiatan ini adalah :

menggambarkan pola perilaku (behavioral pattern) dan attribute dari

setiap kelas. Hasil dari kegiatan ini adalah statechart diagram yang dapat

dilihat pada gambar 2.6 dibawah ini :

Gambar 2.6 Statechart diagram

( Sumber : Mathiassen L. Et al. , 2000, p90)

Perilaku dari suatu object ditentukan oleh urutan event-event (event

trace) yang harus dilewati oleh object tertentu tersebut sepanjang waktu.

31

Sebagai contoh : kelas “pelanggan” harus melalui event trace : account

opened – amount deposited – amount withdrawen – amount deposited –

account closed sepanjang hidupnya.

Tiga jenis notasi untuk behavioral pattern yaitu sequence dimana

event muncul satu per satu secara berurutan; selection dimana terjadi

pemilihan satu event dari sekumpulan event yang muncul; iteration

dimana sebuah event muncul sebanyak nol atau beberapa kali.

2.7. Application Domain Analysis

Menurut Mathiassen Et al. (2000) application domain adalah

organisasi yang mengatur, memonitor, atau mengendalikan problem

domain.(p.115). Analisis application-domain memfokuskan pada

bagaimana target sistem akan digunakan dengan menentukan kebutuhan

function dan antarmuka sistem. Untuk lebih jelasnya kegiatan-kegiatan

yang dilakukan dalam analisis application-domain dapat dilihat pada table

2.3 berikut ini

Tabel 2.3 Kegiatan Analisis Application Domain

Kegiatan Isi Konsep

Usage Bagaimana sistem berinteraksi dengan

orang lain dan sistem lain dalam konteks

Use case dan actor

Function Bagaimana kemampuan sistem dalam

memproses informasi

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 berbeda-

beda.

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

manajer penjualan

penjual

sistem akuntansi

sales

membuat batasan

menganalisa risiko

kesepakatan harga

merekam kesepakatan

update rekening

kesepakatan nilai

<<include>>()

<<include>>()

* *

* *

**

* *

* *

**

**

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

komponen-komponen

Arsitektur komponen

Proses 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 Ukuran dari

Usable Kemampuan sistem untuk menyesuaikan diri dengan

konteks, organisasi yang berhubungan dengan pekerjaan dan

teknis.

Secure Ukuran keamanan sistem dalam menghadapi akses yang

tidak terotorisasi terhadap data dan fasilitas.

Efficient Eksploitasi ekonomis terhadap fasilitas platform teknis.

Correct Pemenuhan dari kebutuhan.

Reliable Pemenuhan ketepatan yang dibutuhkan untuk melaksanakan

fungsi.

Maintainable Biaya untuk menemukan dan memperbaiki kerusakan.

Testable Biaya untuk memastikan bahwa sistem yang dibentuk dapat

melaksanakan fungsi yang diinginkan.

Fleksible Biaya untuk mengubah sistem yang dibentuk.

40

Criterion Ukuran dari

Comprehensible Usaha yang diperlukan untuk mendapatkan pemahaman

terhadap sistem.

Reusable Kemungkinan untuk menggunakan bagian sistem pada

sistem lain yang berhubungan.

Portable Biaya untuk memindahkan sistem ke platform teknis yang

berbeda.

Interoperable Biaya untuk menggabungkan sistem ke sistem yang lain.

( Sumber : Mathiassen L. Et al. , 2000, p178)

• Menyeimbangkan beberapa criteria.

Konflik sering terjadi antar criteria, oleh sebab itu untuk

menentukan criteria mana yang akan diutamakan dan bagaimana

cara untuk menyeimbangkannya dengan criteria yang lain

bergantung pada situasi sistem tertentu.

• Usable, flexible, dan comprehensible.

Criteria ini bersifat universal dan digunakan pada hampir setiap

proyek pengembangan sistem.

2.8.2. Component Architecture

Menurut Mathiassen Et al. (2000) “arsitektur komponen adalah

sebuah struktur sistem yang terdiri dari komponen-komponen yang saling

berhubungan” (p.190).. Komponen merupakan kumpulan dari bagian-

41

bagian program yang membentuk suatu kesatuan dan memiliki fungsi

yang jelas. Sebuah arsitektur komponen yang baik membuat sistem

menjadi lebih mudah untuk dipahami, mengorganisasikan pekerjaan

desain, menggambarkan stabilitas dari konteks sistem dan mengubah tugas

desain menjadi beberapa tugas yang lebih tidak kompleks.

Beberapa pola umum dalam desain komponen arsitektur :

• Arsitektur layered

Merupakan bentuk yang paling umum dalam software. Contoh dari

pola ini adalah model OSI yang sudah menjadi ISO untuk model

jaringan. Sebuah arsitektur layered terdiri dari beberapa komponen

yang dibentuk menjadi lapisan-lapisan dimana lapisan yang berada

di atas bergantung kepada lapisan yang ada dibawahnya.

Perubahan yang terjadi pada suatu lapisan akan mempengaruhi

lapisan diatasnya. Representasi arsitektur layered dapat dilihat

pada gambar 2.8 di bawah ini.

42

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.

«component» Layer i+1

«component» Layer i

«component» Layer i-1

Upward interface

Downward interface

43

Gambar 2.9 Arsitektur generic

( Sumber : Mathiassen L. Et al. , 2000, p196)

• Arsitektur client-server

Pola ini awalnya dikembangkan untuk mengatasi masalah

distribusi sistem di antara beberapa processor yang tersebar secara

geografis. Komponen pada arsitektur ini adalah sebuah server dan

beberapa client. Tanggung jawab daripada server adalah untuk

menyediakan database dan resources yang dapat disebarkan

kepada client melalui jaringan. Sementara client memiliki

tanggung jawab untuk menyediakan antarmuka lokal untuk setiap

penggunanya. Represetansi arsitektur client-server dapat dilihat

pada gambar 2.10 di bawah ini.

«component»

«component» Technical

«component» Function

«component» Model

«component» User Interface

«component» System Interface

«component» UIS

«component» DBS

«component» NS

44

Gambar 2.10 Arsitektur client-server

( Sumber : Mathiassen L. Et al. , 2000, p197)

Berikut adalah beberapa jenis distibusi dalam arsitektur client-

server 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)

«component» Client1

«component» Client2

«component» Clientn

«component» Server

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 komponen-

komponen 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 and

operation

48

Kegiatan Context Konsep

Connecting

component

Bagaimana komponen-komponen

dihubungkan

Component and

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 problem-

domain” (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

Representasi event-event ini sebagai state

attribute pada class yang dijabarkan oleh

statechart diagram. Setiap kali ada

kejadian yang melibatkan salah satu event

tersebut, maka sistem akan menugaskan

yang baru kepada state attribute.

Event-event yang

hanya terjadi pada

urutan (sequence) dan

selection

Intergrasikan attribute dari event yang

terlibat dalam class.

Representasikan event-event ini sebagai

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.

Event-event yang

terjadi berulang-ulang

(iteration)

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

representasi paling simple. Common event

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 kebutuhan-

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