LBM2005101bab2

BAB

LANDASAN TEORI

2.1 Teori

Umum

2.1.1. Pengertian

Sistem

Menurut

Mulyadi (2001,p2),

Sistem adalah

sekelompok

unsur

yang

erat

berhubungan

satu

dengan

lainnya,

yang

berfungsi

bersama-sama untuk

mencapai

tujuan tertentu.

Menurut

O’brien

(2002,p8),

Sistem adalah

sekelompok

komponen-komponen

yang saling berhubungan yang saling bekerjasama untuk mencapai tujuan yang sama

dengan menerima input dan memproses output dalam proses perubahan organisasi..

Menurut Mathiassen et al

(2000,

p9)

Sistem

adalah kumpulan dari komponen-

komponen peralatan model

requirements, function, and interface.

Dari

beberapa

definisi

atas

dapat

disimpulkan bahwa

sistem

adalah

sekumpulan

komponen

yang

saling

bekerjasama untuk

mencapai

tujuan

guna

memperbaiki organisasi ke arah yang lebih baik.

2.1.2. Pengertian Informasi

Menurut Raymond Mcleod, Jr

(2001,

p4),

Informasi adalah salah

satu

jenis

sumber

daya

yang

tersedia

bagi

manajer, yang

dapat

dikelola seperti

halnya

sumberdaya yang

lain. Informasi dari komputer dapat digunakan oleh para manajer,

non

manajer,

serta

orang-orang

dan

organisasi-organisasi dalam

lingkungan

perusahaan.

Menurut O’brien (2002,p13), Informasi adalah data yang telah diubah bentuknya

menjadi lebih berarti dan berguna bagi pengguna-pengguna khusus.

Informasi adalah data yang telah diproses atau data yang sudah lebih memiliki arti

tertentu

bagi

kebutuhan

penggunanya (McLeod,

2001,

p15).

Suatu

informasi

bisa

berguna haruslah memiliki beberapa ciri-ciri atau karakteristik berikut ini

(Sanyoto,

2003, p22):

1. Reliable (dapat dipercaya)

Informasi

haruslah

bebas

dari

kesalahan

dan

haruslah

akurat

dalam

mempresentasikan suatu kejadian atau kegiatan dari suatu organisasi.

2. Relevan (cocok atau sesuai)

Informasi yang relevan harus memberikan arti kepada pembuat keputusan.

Informasi ini bisa mengurangi ketidakpastian dan bisa meningkatkan nilai dari

suatu kepastian.

3. Timely (tepat waktu)

Informasi yang disajikan tepat pada saat dibutuhkan dan bisa mempengaruhi

proses pengambilan keputusan.

4. Complete (lengkap)

Informasi yang disajikan termasuk didalamnya semua data-data yang

relevan dan tidak mengabaikan kepentingan yang diharapkan oleh pembuat

keputusan.

5. Understandable (dimengerti)

Informasi yang disajikan hendaknya dalam bentuk yang mudah dimengerti

oleh si pembuat keputusan.

Dari berbagai definisi di atas dapat disimpulkan bahwa informasi adalah data yang

diolah menjadi bentuk yang lebih berguna, lebih bermanfaat, dan lebih berarti bagi

yang menerimanya.

2.1.3. Pengertian Sistem

Informasi

Sistem

Informasi

adalah

interaksi

antar

komponen-komponen didalam

suatu

kesatuan

terpadu

untuk

mengolah data

menjadi

informasi sesuai

kebutuhan

penggunanya. ( Sanyoto dan Idris 2003, p8)

Sistem Informasi dapat diorganisasikan dengan adanya gabungan antara manusia,

perangkat keras, perangkat lunak, jaringan komunikasi, dan sumber-sumber data yang

mengumpulkan, mengubah,

dan

menyebarkan

informasi

dalam

suatu

organisasi.

(

O’brien 2002,p7)

Dari definisi diatas sistem

informasi adalah kumpulan dari komponen-komponen

atau

unsur-unsur

yang saling

berhubungan dengan

memiliki

kemampuan dalam

hal

menyimpulkan, memproses, menyimpan, dan mendistribusikan keluaran atau

informasi kepada pemakai dalam rangka memenuhi kebutuhan pemakai.

2.1.4. Pengertian Sistem

Informasi Manajemen

Sistem Informasi Manajemen adalah suatu sistem berbasis komputer

yang

menyediakan informasi bagi beberapa pemakai dengan kebutuhan yang serupa. ( Mcleod

2001, p327).

2.2 Analisis Sistem dan Perancangan

Sistem

2.2.1. Pengertian Analisis Sistem

Analisis

lebih

menekankan atau

mengutamakan pada penyelidikkan dari suatu

masalah ketimbang bagaimana mendefinisikan suatu solusi. ( Larman 1998, p6)

Analisis sistem adalah penelitian terhadap suatu sistem yang telah ada dengan

tujuan untuk merancang sistem baru atau diperbaharui. (Mcleod, 2001, p88)

Ada 6 tahap dalam menganalisis sistem:

1. Mengumumkan Penelitian Sistem.

Ketika

perusahaan

menerapkan

sistem

baru

manajemen

bekerjasama dengan

pekerja perihal sistem baru tersebut.

2. Mengorganisasikan Tim Proyek.

3. Mendefinisikan Kebutuhan Informasi.

Melalui wawancara perorangan, pengamatan, pencarian catatan, dan

survei.

4. Mendefinisikan Kriteria Kinerja Sistem.

Setelah

kebutuhan

informasi

manajer

didefinisikan,

langkah

selajutnya

adalah

menspesifikasi secara tepat apa yang harus dicapai oleh sistem.

5. Menyiapkan Usulan Rancangan.

Analisis sistem memberikan kesempatan bagi para manajer untuk membuat

keputusan teruskan/ hentikan untuk kedua kalinya.

6. Menyetujui atau Menolak Rancangan Proyek.

Manajer dan komite pengarah SIM mengevaluasi

usulan rancangan dan

menentukan apakah memberi persetujuan atau tidak.

2.2.2. Pengertian

Perancangan

Sistem

Perancangan

sistem adalah

penentuan

proses dan data

yang

diperlukan

oleh

sistem

baru,

jika

sistem

itu

berbasis

komputer,

perancangan dapat

menyertakan

spesifikasi peralatan yang akan digunakan. ( Mcleod 2001,p238).

Perancangan sistem adalah proses penterjemahan kebutuhan pemakai informasi

kedalam

alternatif

rancangan sistem

informasi

yang

diajukan pada

pemakai

informasi untuk pertimbangan. ( Mulyadi 2001,p51)

Dari

pengertian diatas

dapat

disimpulkan

bahwa

perancangan sistem

adalah

suatu

langkah penyiapan spesifikasi proses

informasi

merupakan suatu perusahaan

yang

berawal

dari

pengumpulan informasi, pengidentifikasian terhadap kebutuhan

bagi

perusahaan

yang kemudian dari

tahap

analisis

maka dibuat

suatu

rancangan

yang berguna bagi perusahaan.

Tahap-tahap Perancangan sistem:

1. Menyiapkan Rancangan Sistem yang Terinci

Analisis

bekerjasama

dengan

pemakai dan

mendokumentasikan rancangan

sistem

baru dengan alat-alat yang dijelaskan dalam modul teknis

2. Mengindentifikasikan Berbagai Alternatif Sistem

Analisis harus mengindentifikasikan konfigurasi (bukan merk atau model) peralatan

komputer

yang

akan

memberikan hasil

terbaik bagi

sistem

untuk

menyelesaikan

pemrosesan.

3. Mengevaluasi Berbagai Alternatif Konfigurasi Sistem

Analis bekerjasama dengan

manajer, mengevaluasi berbagai alternative. Alternatif

yang dipilih adalah

yang paling memungkinkan subsistem memenuhi criteria

kinerja, dengan kendala-kendala yang ada.

4. Memilih Kofigurasi Terbaik

Analis

mengevaluasi

konfigurasi

subsistem

dan

menyesuaikan

dengan kombinasi

peralatan

sehingga

semua

subsistem mwnjadi

satu

konfigurasi

tunggal.

Setelah

selesai analis membuat rekomendasi kepada manajer untuk disetujui.

5. Menyiapkan Usulan Penerapan

Analis menyiapkan ikhtisar tugas-tugas penerapan yang harus dilakukan.

6. Menyetujui atau Menolak Penerapan Sistem

Jika keuntungan

yang diharapkan

dari sistem

melebihi

biayanya,

penerapan

akan

disetujui.

Dari pendapat yang dikemukakan diatas kami dapat menarik kesimpulan

bahwa

perancangan sistem

merupakan

proses

penterjemah

kebutuhan

pemakai

informasi

dalam

suatu

rancangan untuk

memenuhi kebutuhan pemakai

dan

memberi gambaran yang lebih jelas untuk dijadikan pertimbangan.

2.3 Object Oriented Analysis dan Design (OOAD)

2.3.1 Object

Pengertian object menurut Mcleod (2001, p330) adalah suatu entitas fisik atau

kejadian yang dijelaskan dalam bentuk data dan prosesnya. Menurut Yun Tung Lau

(2001, p1) Object merupakan suatu abstraksi dari suatu entitas fisik atau benda yang

berkenaan dengan konsep. Selain itu object juga mempunyai suatu state dan suatu

sifat identity.

Menurut

Mathiassen, Madsen,

Nielsen

dan

Stage

(2000,

p51),

Object

merupakan suatu entitas

yang memiliki

identity, state dan behavior, pada dasarnya

semua yang ada didunia ini adalah object.

2.3.2

Object Oriented

atau orientasi

objek

merupakan suatu

cara

untuk

melakukan

permodelan

sistem

dengan

berorientasikan pada

object-object

yang

terlibat

dalam

sistem tersebut. Beberapa keuntungan dari Object Oriented adalah:

1. Merupakan

konsep

yang

umum

yang

dapat

digunakan

untuk

memodel

hampir

semua

fenomena

yang

ada

didunia

dan

dapat

dinyatakan dalam

bahasa

umum

(natural

language).

2. Dapat digunakan untuk mengembangkan sistem secara incremental.

3. Memberikan informasi yang jelas tentang konteks dari sistem.

Mengurangi biaya maintenance atau development.

2.3.3

Object Oriented

Analysis (OOA)

Menurut

Larman (1998, p6), Object Oriented

Analysis

merupakan suatu

analisis yang menekankan pada penemuan dan penjabaran object-object atau konsep-

konsep didalam problem domain.

Menurut

Mathiassen, Madsen,

Nielsen

dan

Stage

(2000,p13),

analisis

adalah

aktivitas mengenai persoalan yang diambil secara terpisah dan dijabarkan.

Berdasarkan pengertian-pengertian diatas,

maka

Object Oriented

Analysis

adalah

merupakan

suatu

analisis

yang

menekankan

pada penemuan

dan

penjabaran

object-object

atau

konsep-konsep

yang

mana

menguji

kebutuhan-kebutuhan dari

perspektif kelas

dan

penemuan object-object didalam kamus

problem

domain.

Pada

analisis,

para

pengembang

menggunakan object

untuk

menentukan

kebutuhan-

kebutuhan sistem.

2.3.4

Object Oriented

Design (OOD)

Menurut

Larman

(1998,

p6),

Design

lebih

mengutamakan suatu

solusi

yang

berdasarkan pada

logika,

bagaimana suatu

sistem

memenuhi kebutuhan

atau

permintaan.

Menurut

pendapat

Larman

(1998,

p6)

Object

Oriented

Design lebih

menekankan

pada

pendefinisian

object-object software

secara

logika

yang

pada

akhirnya akan diimplementasikan ke dalam bahasa program yang berorientasi object.

Object-object software tersebut mempunyai attribute dan methods.

Menurut

Mathiassen, Madsen,

Nielsen

dan

Stage

(2000,p13),design

adalah

aktivitas yang membangun bagian yang telah dikenal disatukan dengan cara yang

baru.

Object Oriented Design mempunyai 2(dua) hal penting, yaitu:

1. Object

Oriented

Design

menuntun

kepada

suatu

object

oriented

decomposition.

Object

Oriented

Design

menggunakan metode

yang

berbeda

untuk

menyatakan perbedaan model-model dari rancangan logika (kelas dan struktur

object) dan fisik (modul dan arsitektur proses) sebuah sistem, disamping aspek

statis dan dinamik suatu sistem.

2.3.5

Object Oriented

Analysis dan Design (OOAD)

Menurut pendapat Larman (1998, p6) Object Oriented Analysis

and Design lebih

mengutamakan pertimbangan-pertimbangan

suatu problem domain dan solusinya

yang

berdasarkan

logika

dari

pandangan object-object (benda, konsep, entitas)

yang

ditunjukkan pada gambar di bawah ini:

Analysis

Design

Construction

Pandangan dari

masalah

Solusi yang

didasarkan pada

logika

kode

ambar2.1 Definisi dari aktivitas pengembangan

Menurut

Mathiassen, Madsen,

Nielsen

dan

Stage

(2000,

p10),

Object

Oriented Analysis and Design selalu dimulai dengan sebuah arsitektur dasar yang

mempunyai 3(tiga) komponen, yaitu seperti yang digambarkan di bawah ini:

USERS

OTHER SISTEM

INTERFACES

FUNCTIONS

MODEL

Gambar 2.2 Komponen sistem arsitektur dasar

1. Komponen model (Model component).

Komponen

model

mengandung suatu

model dinamik dari suatu

sistem

problem

domain.

Komponen

model

distrukturisasikan untuk

menyetujui tampilan

user

dari

suatu

problem

domain,

dan

mengupdatenya ketika suatu perubahan yang sangat penting terjadi.

2. Komponen fungsi (Function component).

Komponen

fungsi

mempunyai fasilitas dimana

user

mengupdate

dan menggunakan model komponen.

3. Komponen interface (Interface component).

Komponen

interface

merangkaikan suatu

sistem

kekonteks

itu

sendiri melalui 2 jalan, yaitu:

User

Interfaces yang

mencakup monitor

dengan

text

dan

grafik,

hasil printouts, dan

fasilitas

lain

yang

mengizinkan

user mengaktifkan fungsi sistem.

Sistem

Interface

yang

secara

langsung

terhubung dengan

sistem teknikal yang lain, seperti radar dan sensor.

Menurut Mathiassen, Madsen, Nielsen dan Stage (2000, p12), Perspektif-perspektif

tersebut

terhubung dengan

aktivitas

utama

object

oriented

analysis

and

design,

yaitu:

Problem Domain Analysis,

Application

Domain Analysis,

Architectural Design, dan

Component Design.

Problem

Domain

Analysis

Requirement

for use

Application

Domain

Analysis

Model

Component

Design

Specifications

of component

Specifications

architecture

Architectural

Design

Gambar 2.3 Aktivitas dalam Object-Oriented Analysis and Design

2.3.5.1 Problem Domain

Analysis

Problem

domain

adalah bisnis proses

yang ada

didalam dunia

nyata

yang

dimana diadministrasi, dimonitor, dan dikontrol oleh sistem.

System

Definition

Behaviour

Classes

Structure

Gambar 2.4 aktivitas dalam Problem domain Analysis

1. Classes

Dalam

Problem

Domain

Analysis pertama-tama

dimulai

dengan

aktivitas

classes.

Class

adalah

deskripsi dari

kumpulan

object yang mempunyai structure,

behavior,

pattern, dan attribute

yang

sama. Object adalah suatu entitas

yang

mempunyai identity,

state, dan behavior. Kemudian object diberi karakter sesuai dengan

eventnya. Event

adalah

kejadian

yang

terjadi

seketika

yang

melibatkan satu atau lebih object.

Find

candidates

for classes

Find

candidates

for events

Event

table

Evaluate and

select

systematically

Event

table

Gambar 2.5 Subaktivitas dalam pemilihan problem domain classes dan events

a. Find classes

Penentuan class

biasanya

ditentukan terlebih

dahulu

daripada events. Kita

perlu

menulis

semua kemungkinan

yang

bersangkutan dengan

class.

Kemudian

classes yang

telah

dipilih

akan

menjadi bagian

dari

model problem

domain.

Pemilihan nama

untuk classes

harus

yang sederhana, gampang

dibaca, dan menyatakan

hal yang tunggal.

b. Find events

Penentuan

events merupakan

langkah

dua

setelah

penentuan

classes.

Proses

ini

berdasarkan pada

teknik

pokok

penentuan class.

2. Structure

Dalam structure activity difokuskan pada relasi atau hubungan

antara

classes

dan

object

yang

ada

dalam Problem

Domain

Analysis. Dalam

class

activity

kita

memilih

class

untuk

model

problem domain dan

setiap

class dibuat

dikarakteristikkan oleh

eventnya. Dan

dalam

structure

activity,

kita

melanjutkan

penjelasan yang

ada

dengan

menambah

struktur

hubungannya

antara class dan objects.

Hasil dari structure

activity adalah

membuat Class

Diagram.

Class Diagram

tersebut

menyediakan pandangan terhadap Problem

Domain

sebagai penguraian

secara

struktural antara

hubungan

class dan object di dalam model.

Structure menurut Mathiassen, Madsen, Nielsen dan Stage

(2000, p72) mempunyai 2 tipe, yaitu:

1. Class Structure

Class Stucture dibagi menjadi dua tipe yaitu:

a. Generalization Structure

Generalization

Structure

yaitu

class

umum yang

menguraikan kepemilikan

umum

kepada

suatu

kelompok

class

yang spesial.

Dimana

kita

menyebut

seluk

beluknya

class atau class yang spesifik tersebut sebagai subclass dan

class

yang

general disebut super

class

Generalization

secara linguistik diformulasikan sebagai hubungan “is-a”.

Super class

Sub class

Gambar 2.6 Generalization structure

b. Cluster Structure

Cluster Structure

ialah

suatu

kumpulan dari classes

yang

membantu

untuk

memudahkan dalam

pencarian

problem domain atau disebut juga sebagai koleksi dari class

yang saling berhubungan. Classes di dalam cluster biasanya

dihubungkan melalui Generalization

Structure atau

Aggregation Structure yang lain.

<<cluster>>

Cars

<<cluster>>

People

Car

Owner

Clerk

Engine

Passenger

car

Cylinder

Taxi

Gambar 2.7 Cluster Structure

2. Object Structure

Object Structure dibagi menjadi dua tipe yaitu:

a. Aggregation Structure

Aggregation

Structure

merupakan suatu

hubungan

antara

dua

atau

lebih

object.Aggregation Structure

digambarkan seperti garis antara classes secara keseluruhan

dan bagian-bagiannya, dimana garis tersebut disertai

dengan gambar belah ketupat untuk menjelaskan model

class

secara

keseluruhan. Aggregation

secara

linguistic

diformulasikan sebagai hubungan “has

a”

Gambar 2.8 Aggregation structure

Menurut

Mathiassen, Madsen,

Nielsen, dan

Stage

(2000,p79) terdapat tiga tipe aggegation structure yaitu :

1. Whole part, object superior

adalah jumlah dari

object

inferior,

dimana

jika

kita

menambah atau

menghapus object

inferior

maka kita akan mengubah

pokok object superior.

2. Container-content,

object

superior

merupakan

container bagi object

inferior,

dimana

jika kita

menambah atau

menghapus

object

inferior

maka

kita

tidak akan mengubah pokok object superior.

3. Union-member, object orinted merupakan

object

inferior yang telah terorganisasi,

dimana

waktu kita

menambah atau menghapus object inferior, tidak akan

terjadi perubahan pada object superior.

Sedangkan menurut Larman (1998,p359) terdapat dua

jenis aggregation yaitu :

1. Composite aggregation yang

sering dikenal dengan

compositon.

Yaitu

multiplicity pada

composite

paling

banyak

adalah

satu

serta

dinotasikan dengan

bentuk

diamond

atau belah ketupat.

2. Shared aggregation.

Yaitu

multiplicity pada

composite yang bisa

lebih dari

satu

serta

dinotasikan dengan

bentuk

hollow diamond

atau belah ketupat yang kosong.

b. Association Structure

Association Structure

merupakan

suatu

hubungan

antara

dua

atau

lebih

object.

Tetapi

Association

berbeda

dari

aggregation

dimana

associatied

object

tersebut tidak

mendefinisikan kepemilikan

object

tersebut

atau

hanya

merupakan pengertian hubungan antara sejumlah object.

Association Structure

digambarkan

seperti

garis

sederhana antara classes

yang saling

berkaitan. Kita dapat

menjabarkan keseragaman association

dengan

cara

yang

sama

dengan

aggregation. Karena struktur

association

tidak

mempunyai

urutan sehingga kita

bisa

menempatkan

classes

yang saling berhubungan di mana saja dalam class

diagram.

Car

0..*

1..*

person

Gambar 2.9 Association structure

3. Behavior

Di dalam behavior activity, perluasan

definisi

class

didalam class diagram dapat dilakukan dengan cara menambahkan

deskripsi dari

behavioral

pattern

dan

atribut

dari

setiap

class

(

Mathiassen, Madsen, Nielsen

dan

Stage,

2000,

p89).

Tujuan dari

behavior

ialah

untuk

memodelkan kedinamisan

suatu

problem

domain.

Behavior

menghasilkan suatu

behavior

pattern

dengan

atribut-atribut

untuk setiap class di dalam class diagram. Alat

bantu

yang

biasa

digunakan

untuk

menggambarkan behavior

pattern

ialah statechart diagram.

Behavior pattern

mempinyai tiga notasi (Mathiassen,

Madsen, Nielsen dan Stage, 2000, p93), yaitu:

a. Sequence

Event dalam

suatu

set

terjadi

satu

persatu. Sequence

digambarkan

dengan

membuat

events melalui

beberapa

state,

dan

pada setiap

state hanya akan

mengeluarkan satu

event.

Gambar 2.10 Sequence

b. Selection

Hanya

satu dari sekumpulan

event

yang

terjadi.

Selection

digambarkan

dengan

membuat

semua

kemungkinan event keluar dari state yang sama.

Gambar 2.11 Selection

c. Iteration

Sebuah event

dapat

terjadi dari

nol

sampai

dengan

beberapa

kali.

Iteration digambarkan

dengan

membuat

suatu event kembali ke state awalnya.

Gambar 2.12 Iteration

2.3.5.2

Application Domain Analysis

Menurut

Mathiassen, Madsen,

Nielsen

dan

Stage

(2000,

p6),

Application

Domain adalah

bagian

dari

organisasi yang

mengadministrasi, memonitor, dan

mengkontrol

problem

domain.

Keberhasilan atau

kegagalan

suatu

sistem

sepenuhnya

tergantung

kepada

keberhasilan application

domain

dalam

mengadministrasi dan mengkontrol problem domain.

Menurut Mathiassen,

Madsen, Nielsen dan Stage (2000, p115), tujuan

Application Domain Analysis adalah

untuk

menentukan kebutuhan-kebutuhan

model

system,

yang

memudahkan

untuk

mendefinisikan kebutuhan

usage,

function

dan

interface. Penentuan kebutuhan-kebutuhan

tersebut didasarkan

pada dua prinsip pokok

(Mathiassen, Madsen, Nielsen dan Stage, 2000, p116),

yaitu:

1. Penentuan application-Domain dengan menggunakan use case.

Use case

menawarkan suatu solusi yang baik untuk memecahkan

masalah-masalah yang terjadi di dalam

Application Domain

Analysis.

Use

case

membantu

memusatkan

analysis pada

interaksi antara

user

dan target system.

2. Bekerjasama dengan user.

Menspesifikasikan kebutuhan tidak bisa dilakukan hanya dari satu

pihak

saja.

User

mungkin tidak

terlalu

mengerti untuk

mencurahkan

keinginannya secara

optimal.

Untuk

itu

kerjasama

antara

developer

dengan user sangat diperlukan.

System

Definition

and

model

Interfaces

Iterate

Usag

Requirements

Functions

Gambar 2.13 Aktivitas dalam Application Domain Analysis

1. Usage

Use case merupakan suatu pola interaksi antara sistem dan

actor

di dalam application

domain

Mathiassen,

Madsen,

Nielsen dan Stage

(2000, p120).

Menurut Armour, dkk (2000, p19), Use case merupakan deskripsi

dari

seperangkat urutan

tingkatan

yang

dilakukan

oleh

suatu

sistem

yang akan memberikan nilai yang tampak pada actor.

Dengan

kata

lain,

use

case

adalah

suatu

abstraksi dari

sebuah

interaksi

dengan

sistem

yang

diinginkan.

Use

case bisa

dimulai dari

seorang actor.

Tujuan dari use case

ialah untuk menentukan

bagaimana actor-actor berinteraksi dengan suatu sistem.

Actor

merupakan

sebuah

abstraksi

dari

user atau

sistem-sistem

lain

yang

berinteraksi dengan

target

sistem

menurut

Mathiassen,

Madsen,

Nielsen dan

Stage

(2000, p119).

Actor

juga

dapat

diartikan

sebagai suatu entitas

yang berinteraksi dengan

sistem,

yang bertujuan

untuk

melengkapi suatu event menurut

Armour dan

Mille (2001, p6).

Tentu saja, di dalam

gambaran suatu

use case, kita

harus menyatakan

apakah actor tersebut merupakan mesin atau orang. Hal

ini

dikarenakan spesifik

dari

orang

atau

mesin

tersebut

digambarkan

berbeda.

dalam

use

case

terdapat

berbagai

sub-aktivitas yang

terjadi

menurut Mathiassen, Madsen, Nielsen dan Stage (2000, p120),

yaitu

seperti yang digambarkan dibawah ini:

System

definition

systematically

Find actors

and use case

Explore

patterns

Gambar 2.14 Sub-aktivitas dari Use case

Output yang dihasilkan oleh aktivitas-aktivitas diatas ialah

deskripsi tentang hubungan actor

dan

usecase yang terbentuk menjadi

suatu usecase diagram.

2. Functions

Fungsi

merupakan suatu

fasilitas

untuk

membuat

sebuah

model

yang berguna

bagi

actors

menurut Mathiassen, Madsen,

Nielsen

dan

Stage

(2000,

p138). Fungsi diaktifkan, dijalankan, dan

mengeluarkan

hasil.

Menjalankan fungsi

dapat

mengubah

bagian

model

atau

menciptakan sebuah reaksi pada aplikasi.

Tujuan

dari

aktivitas

ini

adalah

untuk

menentukan kemampuan

proses sebuah sistem informasi dengan menyusun daftar yang lengkap

dari fungsi, seperti spesifikasi detail pada bagian yang kompleks.

Menurut

Lars

Matthiassen (2000,

p138),

Function

mempunyai

beberapa tipe fungsi, yaitu:

a. Fungsi Update

Fungsi update diaktifasikan oleh sebuah problem domain dan

menghasilkan perubahan

pada

model.

Fungsi yang

diperbaharui

sering

digunakan

untuk

membandingkan satu

kejadian

dengan

kejadian lainnya.

Contoh: suatu fungsi yang menerima data dari suatu radar.

b. Fungsi Signal

Fungsi

signal

diaktifitasikan

oleh

perubahan

pada

model

dan

hasil

pada sebuah konteks, reaksi

ini

mungkin digambarkan pada

actors di dalam application domain.

Contoh:

Suatu

fungsi

yang

secara

berkelanjutan mengikuti

jalur

satuannya dan membunyikan alarm.

c. Fungsi Read

Fungsi read diaktifitasikan oleh suatu kebutuhan atas informasi

tugas seorang actor dan menghasilkan bagian

yang relevan dari

suatu model. Fungsi ini berkaitan dengan informasi nyata yang

diperlukan dalam use case dan menghubungkan dengan model-

model. Faktanya bahwa class dengan event, attribute dan structur

secara tidak sengaja sering menentukan arah yang diperlukan

informasi dalam aplikasi domain.

Contoh:

Suatu

fungsi

yang

mencari

dan

mengambil kembali

informasi untuk ditampilkan di monitor mengenai lalu lintas udara,

seperti identitas dari pesawat, posisi dan kecepatan pesawatnya.

d. Fungsi Computing

Fungsi computing diaktifitasikan oleh kebutuhan atas informasi

di dalam bagian tugas actor. Fungsi ini menghubungkan kebutuhan

informasi yang lebih kompleks dan

informasinya tidak bisa segera

ditemukan hanya

dengan

membaca

model.

Fungsi

ini

harus

disamakan dengan

use

case.

Urutan

perhitungan yang tidak bisa

dicampuri

oleh

seorang

actor

seharusnya didukung

oleh

sebuah

fungsi.

Jika

urutan

perhitungan terdiri

dari

beberapa

bagian

alternatif, kita harus mempertimbangkan untuk menggunakan lebih

dari satu fungsi.

Contoh: Suatu

fungsi

yang memprediksikan masa depan

dan jalur

situasinya

dengan

didasarkan pada

posisi

sekarang,

arah

dan

kecepatan pesawat yang relevan.

3. Interfaces

Interfaces

merupakan suatu fasilitas yang membuat sebuah model

sistem

dan

fungsi

berguna

bagi

para

actors

menurut Mathiassen,

Madsen,

Nielsen dan Stage

(2000,

p151).

Actor

manusia

dan

sistem

komputer secara luas memiliki perilaku yang berbeda. Oleh karena itu

interfaces secara garis besar dibagi ke dalam 2 golongan, yaitu:

1. User interfaces.

User

interfaces

merupakan

suatu

hubungan

interaksi

(interface) antar user.

2. Sistem interfaces.

Sistem interfaces

merupakan

suatu

hubungan

interaksi

(interface) antara sistem-sistem yang

lain.Hal-hal

yang diperlukan

interface untuk menampilkan model dan fungsi-fungsi ke user, dan

menghubungkan sistem yang dituju ke sistem-sistem lain dan alat-

alat lain

harus memenuhi

syarat-syarat yang didasarkan oleh

prinsip-prinsip dibawah ini:

1. Kemampuan menyelesaikan aplikasi domain.

User

interface

yang

baik berdasarkan pada

pengetahuan

dari user dan bagaimana sistem akan digunakan.

2. Mengidentifikasi semua elemen interface.

Analisis harus menuju ke deskripsi yang komplit dari user

dan

elemen-elemen

sistem

interface.

Kelengkapan

dibutuhkan

untuk mendukung persetujuan mengenai persyaratan.

2.3.5.3

Architectural

Design

Salah satu faktor keberhasilan suatu sistem dapat dilihat dari berhasil atau

tidaknya suatu arsitektur design (Mathiassen, Madsen, Nielsen dan Stage 2000,

p173). Atau dengan kata lain, architectural

design adalah sebuah struktur sistem

yang terdiri dari komponen-komponen yang saling terhubung.

Tujuan

dari

architectural

design

ialah

untuk

menstrukturisasikan suatu

sistem yang menggunakan komputerisasi menurut Mathiassen, Madsen, Nielsen

dan Stage (2000, p177). Architectural design mempunyai 3 aktivitas yang harus

dikerjakan, yaitu seperti yang ditunjukkan pada gambar dibawah ini:

Analysis

document

Component

architecture

Architectural

specification

Criteria

Process

architecture

Gambar 2.15 aktivitas dalam architectural

design

a. Criteria

Criteria

merupakan penentuan pilihan atas bentuk atau model yang

diinginkan

menurrut

Mathiassen, Madsen,

Nielsen

dan

Stage

(2000,p177).

Criteria

mempunyai tujuan

untuk

membuat

prioritas

design. Hasil dari criteria ialah sebuah kumpulan dari kriteria prioritas.

Menurut Mathiassen,

Madsen,

Nielsen dan Stage, (2000,

p186),

prinsip-prinsip yang terdapat di dalam criteria design adalah:

1. Design yang

baik

tidak

memiliki

banyak

kelemahan.

Suatu

kesalahan

kecil

dapat

menggagalkan

suatu

design.

Design

yang

baik diharuskan

untuk

mendapatkan property

yang baik

dan

pada

waktu yang sama, dapat menghindari yang buruk.

2. Design

yang baik

menyeimbangkan beberapa

criteria. Suatu

design yang baik harus berhubungan dengan beberapa criteria.

Hal

ini

dikarenakan criteria-criteria

tersebut dapat bertentangan

dengan

design. Memprioritaskan seluruh criteria sangatlah

diperlukan.

3. Design yang baik dapat digunakan, fleksibel, dan dapat dimengerti.

Kegunaan suatu

sistem

ditentukan dari

pengaruh

antara

kualitas

teknik

sistem

dan

aplikasinya

tugas

user.

Fleksibilitas dan

koprehensif

membantu

memudahkan pekerjaan

design

dan

implementasi.

Criteria mempunyai beberapa hal yang harus diperhatikan, yaitu:

1. Usable (Dapat digunakan),

yaitu kemampuan

suatu sistem

untuk

beradaptasi terhadap situasi organisasi, tugas, dan hal-hal teknis.

2. Secure

(Keamanan),

yaitu pencegahan

terhadap

akses yang tidak

berwenang akan data dan fasilitas.

3. Efficient

(Efisiensi), yaitu penggunaan secara ekonomis terhadap

fasilitas tecnical platform.

4. Correct (Kebenaran), yaitu sesuai dengan kebutuhan.

5. Reliable

(Dapat

dipercaya),

yaitu

terpenuhinya

ketepatan

yang

dibutuhkan dalam eksekusi fungsi.

6. Maintainable

(Pemeliharaan),

yaitu biaya dalam mencari dan

memperbaiki sistem yang cacat atau rusak.

7. Testable (Dapat diuji), yaitu biaya untuk memastikan bahwa sistem

yang digunakan bekerja sesuai dengan fungsinya.

8. Flexible (Dapat disesuaikan),

yaitu biaya untuk memodifikasikan

sistem yang telah berjalan.

9. Comprehensible (Dapat dipahami), yaitu

usaha

yang diperlukan

untuk memperoleh pengertian yang logis terhadap sistem.

10. Reusable

(Dapat

digunakan

kembali),

adanya

potensi

untuk

menggunakan bagian dari sistem yang dijalankan ke sistem lain.

11. Portable

(Dapat dibawa atau dipindahkan dengan mudah), yaitu

biaya perpindahan sistem ke technical platform yang lain.

12. Interoperable, yaitu biaya

untuk

merangkai

suatu

sistem ke sistem

yang lain.

b. Component Architecture

Komponen

merupakan suatu

kumpulan

dari

bagian-bagian

program

yang

merupakan

suatu

keseluruhan dari

sistem

dan

tugas-

tugas yang telah ditetapkan dengan baik menurut Mathiassen, Madsen,

Nielsen dan Stage (2000, p190).

Arsitektur

kompenen

merupakan

komponen-komponen dari suatu

sistem yang disusun yang saling terhubung. Arsitektur komponen yang

baik

dapat

membuat

sistem

lebih

mudah

dimengerti, mengatur

kerja

design

dan

mencerminkan kestabilan

sistem

menurut

Mathiassen,

Madsen, Nielsen dan Stage (2000, p189-190).

Tujuan dari arsitektur komponen ialah untuk menciptakan struktur

sistem

yang

fleksibel

dan

mudah

dipahami. Class

diagram

menggambarkan inti

dari

arsitektur

komponen.

Diagram

UML

mengandung packages

yang

merupakan

komponen

dan

menunjukkan

saling

ketergantungan

diantara

packages

yang

merupakan

hubungan-

hubungan dari komponen.

Component Architecture

mempunyai

beberapa

pola

umum

yang

dapat digunakan

untuk mendesign

arsituktur komponen secara kreatif

menurut Mathiassen, Madsen,

Nielsen

dan

Stage

(2000,

p192). Pola-

pola tersebut ialah:

Pola arsitektur layer.

Arsitektur layer merupakan suatu model klasik pada software,

dan pola ini sangat berguna untuk memecah sebuah sistem menjadi

komponen-komponen. Pada

setiap

level,

kita dapat

memecah

sebuah komponen yang diberikan

secara vertikal

yntuk membuat

beberapa layer baru dalam bentuk subkomponen yang baru.

Layer

menunjukkan suatu

komponen

dan

anak

panah

menunjukkan DEPENDENCIES, yang artinya apabila terjadi suatu

perubahan pada sebuah komponen, maka komponen yang lain juga

akan ikut terpengaruhi.

Pola arsitektur yang umum (Generic).

Kita

dapat

menggunakan

arsitektur

layer

untuk

mempelajari

sistem

dasar

yang

mencakup

komponen

interface,

function, dan

model. Komponen

model

yang

terdiri

dari

model

object

sistem,

yang

merupakan

layer

paling

rendah,

diikuti

oleh

sistem

fungsi

layer dan bagian atasnya merupakan komponen interface. Interface

layer

dapat

diuraikan ke

dalam 2

bagian,

yaitu

user

interface dan

sistem interface.

Pola arsitektur client-server.

Arsitektur

client-server

semula

dikembangkan untuk

mengatasi

penyebaran dari

sebuah

sistem

diantara

beberapa

prosessor yang tersebar secara geografis. Contoh dari pola ini ialah

sistem

otorisasi

kartu

kredit.

Pola

ini

banyak

digunakan dalam

industri software. Komponen-komponen yang terdapat didalam

pola arsitektur ini adalah server dan beberapa klien.

Aktivitas ini

menghasikan sebuah class

diagram dengan spesifikasi komponen

yang kompleks.

c. Processes Architecture

Proses

arsitektur

merupakan suatu

struktur

eksekusi

sistem

yang

terdiri

dari

proses-proses

yang

saling

bergantungan menurut

Mathiassen, Madsen, Nielsen dan Stage (2000, p211). Unit dasar yang

digunakan untuk

mengeksekusi sistem ialah sebuah processor. Tujuan

dari

design

proses

arsitektur

adalah

untuk

menyusun

eksekusi

pada

level

physical. Hasil

dari

aktivitas proses

ialah

suatu

deployment

diagram

yang

menggambarkan distribusi

dan

kolaborasi

dari

komponen-komponen program

dan

active

project

pada

processor.

Komponen program merupakan suatu

modul

fisik dari kode program.

Sedangkan active object

ialah

suatu object yang

telah ditentukan oleh

sebuah proses menurut Mathiassen, Madsen, Nielsen dan Stage (2000,

p212).

2.3.5.4 Component Design

Menurut

Mathiassen

al (2000,p231)

komponen

adalah

suatu

kumpulan

dari bagian-bagian program dan mempunyai tanggung jawab yang jelas.

Tujuan dari desain komponen ialah untuk menentukan suatu kebutuhan-kebutuhan

implementasi di

dalam

suatu

kerangka

arsitektur.

Hasil

akhir

dari

aktivitas

ini

merupakan suatu deskripsi dari komponen sistem.

1. Model Component

Model

Component

merupakan

bagian

dari

sistem

yang

mengimplementasikan model problem domain. Tujuan dari komponen model

adalah

untuk

memberikan data

yang sekarang dan data

histories ke

user

dan

sistem yang lainnya, serta informasi yang disimpan berhubungan dengan

sistem yang ada di dalam Problem Domain. Dan hasil dari aktivitas komponen

model adalah class diagram dari model komponen.

Class diagram,

behavior pattern,

Represent

Common

Event

Restructure

Classes

and component specifications

Represent

Private

Event

Model component

specification

Gambar 2.16 Subaktivitas dalam model component

a. Represent Private Event

Private

event merupakan event yang

hanya

meliputi satu object

problem domain. Event table

merupakan suatu alat

yang

sangat

berguna untuk

mengidentifikasikan private event. Sebuah event dapat

terjadi lebih dari sekali dan dapat disebut sebagai atribut class.

b. Represent Common Event

Jika

suatu

event adalah

umum

dan

mempengaruhi

beberapa

object,

maka event tersebut harus digambarkan di dalam suatu hubungan antar

object

dan

memungkinkan

penambahan

penghubung

struktural

untuk

memberikan izin kepada objects lain untuk dapat mengakses ke dalam

attribute.

Pemilihan

mengenai

object

mana

yang

akan

digambarkan

oleh event tergantung pada kebutuhan arsitektural, seperti: waktu,

jarak, dan kejelasan.

c. Restructure Classes

Setelah

mendapatkan

class diagram

yang

telah

direvisi,

yang

dihasilkan

dari

seluruh

informasi

yang

didapat

tentang

event, tahap

selanjutnya ialah mempertimbangkan untuk menyederhanakannya.

Dan berikut ada tiga cara untuk melakukannya, yaitu:

a. Menggunakan Generalization untuk menyederhanakan design yang

ada.

b. Menggunakan

Association

untuk

menambah

class

dan

structure,

sehingga anda harus memikirkan kembali structure

yang lama

untuk

melihat

apakah

mreka

menjadi tidak

berguna dan

dapat

dipindahkan.

c. Dan

yang terakhir

memakai penggabungan Analysis Model untuk

memperoleh design model yang lebih sempurna.

2. Function Component

Menurut

Mathiassen et

al (2000,p251)

function component adalah

bagian

dari

sistem

yang

mengimplementasikan kebutuhan

fungsional.

Tujuan

dari

function component adalah

menentukan

implementasi

dari

fungsi-fungsi

yang

telah ada. Karena

function component berfungsi untuk

menghubungkan

model

dan usage.Hasilnya adalah sebuah class diagram dengan kegiatan

dan

spesifikasi yang kompleks

Function list,

class diagram,

component specifications

Explore

pattern

Design

functions as

operations

Specify

complex

operation

Model component

specifications

Function component

specifications

Gambar

2.17 Subaktivitas pada function component design

a. Design Functions as Operations, yaitu:

Update : memberikan update berupa data.

Read : membaca bahwa fungsi tersebut dapat menerima

informasi yang ditampilkan di monitor.

Compute : melakukan perhitungan yang dikirim berupa sinyal.

Signal : memberikan suatu kondisi yang kita cari jika ditemukan

dan sebaliknya juka tidak ditemukan

b. Explore Patterns,

yaitu:

Explore

Patterns

merupakan beberapa

pilihan

design

yang

saling

berhubungan, yang

dapat

membantu

untuk

melaksanakan

fungsi sebagai

satu kesatuan

operasi.

Adapun beberapa

pattern

yang dapat membantu dalam memilih fungsi design :

Model class placement

Function class placement

Strategy

Active Function

c. Specify

Complex

Operations, yaitu:

Menjelaskan

kegiatan-kegiatan yang

kompeks

dengan

terperinci sehingga tidak ada lagi keragu-raguan dalam desain yang

akan

dibuat.

Ada

tiga

bentuk deskripsi

yang berhubungan dengan

spesifikasi operasi

yang

detail

operation

spesification,

sequence

diagram, dan statechart diagram.

3. Connecting Component

Menurut

Mathiassen

(2000,p271)

Connecting

Component adalah

suatu

kegiatan yang bertujuan untuk menghubungkan

komponen sistem. Prinsip

utama untuk menghubungkan komponen tersebut yaitu dengan Highly Cohesive

Classes dan Loosely Coupled Component). Hasil dari kegiatan ini adalah sebuah

class diagram

dengan komponen-komponen yang terlibat di dalamnya. Berikut

ini akan dibahas

mengenai Coupling dan Cohesion :

a) Coupling

Coupling

adalah

suatu

ukuran

yang

digunakan untuk

menentukan

bagaimana dekatnya

hubungan antara

dua class

atau

component.

Coupling dibagi dalam empat bentuk :

Outside coupling

sebuah class atau komponen berdasarkan

secara

langsung pada

public

property

dari class lain atau komponen lain.

Inside

Coupling :

sebuah

operasi

yang

menunjuk secara

langsung pada,

private

property

lain

dalam class yang sama.

Coupling

from below: spesialisasi class

menunjukkan secara

langsung

pada

private

property

dalam

super class.

Sideways coupling

sebuah

class

menunjukkan

secara

langsung kepada

private

property

pada class yang lain.

b) Cohesion

Cohesion

merupakan ukuran seberapa kuatnya keterikatan dari

suatu

class

atau

komponen.

Cohesion

tersebut

bersifat

positif

dan

jika

kita

memisahkan

hubungan

cohesion

tersebut

antara

class

atau komponen maka akan meningkatkan hubungan coupling.

Berikut 3 bentuk hubungan

Cohesion yaitu :

a. Class aggregation

Dalam class

tersebut

terdapat definisi

yang

dapat

dipakai

untuk membentuk struktur aggregation

tersebut, serta digunakan

ketika definisi class

ada

komponen

lain, seperti digambarkan

dibawah ini :

<<component>>

Function

Account

Manager

1..*

<<component>>

Model

Account

Position

Gambar

2.18 Connection by class aggregation

Class specialization

Dalam

public

class

yang

berasal

dari

komponen lain

digunakan

untuk

menjelaskan class

baru

yang

melalui

spesialisasi. Dimana

semua

sifat

super

class

diturunkan ke

subclass.

<<component>>

User interface

Person

Session W

<<component>>

UI Library

Window

Gambar

2.19 Connection by class specialization

Operation Call

Operation

call

merupakan suatu

hubungan

antara

dua

komponen

yang dapat

dibuat dengan

operation

call.

Operation

call

yaitu object di dalam komponen yang satu

memanggil

operasi dari object komponen yang lain.

<<component>>

Model

<<component>>

System interface

Engine

Throttle

throttle position

Throttle

setting

Read

<<call>>

Gambar 2.20 Connection by calling an operation

Didalam

Connecting

component

terdapat

beberapa

subaktivitas, yaitu seperti yang digambarkan di bawah ini:

Connect

classes

Class diagram and

Class diagrams and

Component specifications

Explore

pattern

Evaluate

connections

Gambar 2.21 Subactivities in designing the connections between

component

a) Connect class.

Dibagi

dalam tiga

bentuk

hubungan

(Mathiassen,

Madsen, Nielsen dan Stage,

2000, p275), yaitu:

Meng-aggregasikan komponen class yang lain

Menspesialisasikan komponen public class yang lain

Memanggil

operasi

public

dalam

komponen

object

yang

lain

(menghubungkan class

dengan

memanggil

operasi

adalah secara umum berdasar pada coupling yang rendah).

Explore Pattern.

Komponen

yang

saling

berhubungan

satu

contoh

yang

utama di dalam fakta ialah contoh untuk meneliti. Dan contoh

penelitian

tersebut

dapat

digunakan ketika

beberapa

object

tergantung pada satu object yang dapat merubah state. Ketika

state berubah, object yang dependent dapat diberitahukan dan

diupdate secara otomatis.

Evaluate connections

Mengevaluasi

hubungan

yang ada

selama

pemeriksaan

terhadap

komponen design yang detail.

2.4 Unified Modelling Languange

2.4.1 Definisi Unified Modelling Languange

Unified

Modelling Languange

adalah

suatu

bahasa

visual

serba

guna

yang

digunakan

untuk

menjelaskan,

memvisualisasikan, membangun,

dan

mendokumentasikan suatu

sistem.

UML

digunakan

untuk

memahami,

merancang,

mengkonfigurasi, memaintance,

dan

mengontrol

informasi

tentang

suatu

sistem(Boach et al, 1999, p13)

UML

terdiri

dari

beberapa

elemen

yang

membentuk diagram dengan

aturan

tertentu.

Diagram

ini

bertujuan

untuk

mengambarkan sistem

dari

berbagai

sudut

pandang.

2.4.2 Relasi Unified Modelling Languange

Relasi menggambarkan hubungan antara objek di dalam suatu sistem

Beberapa relasi dalam UML yaitu:

1. Dependency : Suatu relasi dimana suatu objek tergantung pada objek

yang lain.

Perubahan

pada

objek

tersebut

berpengaruh terhadap

objek

lain.

Relasi digambarkan sebagai garis terputus-putus yang

memiliki arah

menunjuk pada suatu objek.

Relasi dependency

(Boach et al,1999,p24)

Gambar 2.22 Relasi Dependency

Generalization

Relasi

antara

objek

yang

umum

(parent)

dengan

sesuatu

yang

lebih

spesifik (child)

dimana objek

yang

lebih

khusus

dapat

digantikan

demgan

objek

yang

lebih

umum.

Generalisasi

digambarkan

sebagai

garis dengan

arah

menunjuk ke objek

yang

lebih umum (parent).

Relasi Genaralization

(Boach et al,1999,p24)

Gambar 2.23 Relasi Generalization

Association

Relasi

hubungan structural

yang

menggambarkan

sekumpulan

link,

dimana

link

adalah

hubungan antar

objek.

Association

digambarkan

sebagai

garis,

kadang

disertai

dengan

keterangan

dan sering mengandung multiciplity dan role names.

(Boach et al,1999,p24)

Relasi Association

Gambar 2.24 Relasi Association

4. Realization:

Hubungan semantic antara classifiers, dimana satu classifiers

mengspesifikasikan

sebuah

kontrak

sedangkan

classifiers

lain

menyelesaikannya. Kita akan menemukan hubungan realization pada 2

tempat

yaitu diantara interface

dan

class/komponen

yang tercakup di

dalamnya, juga diantara use case dan kolaborasi yang mengerjakannya.

Secara

grafik

hubungan

realization dinyatakan

sebagai

gabungan

antara generalization dan dependency.

Relasi Realization

(Boach et al,1999,p24)

Gambar 2.25 Relasi Realization

2.4.3 Diagram

Unified Modelling Languange

Beberapa diagram antara lain:

A. Rich Picture

Gambar yang digunakan selama pemilihan sistem untuk menyatakan suatu

keseluruhan persepsi tugas proyek pengembangan sistem

B. Class Diagram

Suatu

diagram

yang

menguraikan suatu

kumpulan

kelas

dan

hubungan

struktural dari kumpulan class tersebut. Diagram class dibawah ini menjelaskan

pesanan pelanggan dari sebuah katalog. Kelas pada pusat adalah kelas ‘Order’.

Dihubungkan dengan

Customer

(pelanggan)

yang

melakukan pembayaran

dalam

Payment.

Payment

sendiri

terdiri dari 3 macam

: Cash, Check

atau

Credit.

Pesanan

terdiri atas

‘OrderDetails’,

yang

masing-masing

berhubungan

dengan ‘Item’.

Gambar 2.26 Class Diagram

Object Diagram

mirip dengan Class Ddiagram, tetapi tidak menggambarkan

kelas-kelas objek, diagram ini menggambarkan instance-instance objek yang aktual,

menunjukkan nilai sekarang dari atribut instance-instance.

C. Use Case Diagram

Adalah

diagram

yang

secara

grafis

menggambarkan siapa

yang

akan

menggunakan sistem

dan

dengan

cara

apa

pengguna

dapat

berinteraksi

dengan

sistem. Dibawah

ini

adalah ‘membuat perjanjian” dalam sebuah diagram use

case

yang melibatkan actor ‘Pasien’, ‘Dokter’, ‘Kasir’, dan ‘Resepsionis’.

Gambar 2.27 use case diagram

D. Activity Diagram

Digunakan untuk

menggambarkan secara grafis

urutan dari aliran aktivitas

dari

proses

bisnis

atau

use

case,

juga

menggambarkan aksi-aksi

yang

akan

dilakukan ketika suatu operasi dikerjakan dan juga

hasil

dari aksi tersebut. Di

bawah ini adalah contoh activity diagram

dalam pengambilan ATM,

macam

class yang terlibat dalam hal ini adalah Customer, ‘ATM’ dan ‘Bank’.

Gambar 2.28 activity diagram

E. Sequence Diagram

Menggambarkan secara

grafis

bagaimana

objek-objek

berinteraksi

satu

dengan

yang

lainnya

melalui

message-message

yang dilakukan dari

suatu

use

case atau operasi.

Dibawah ini adalah contoh dari sequence diagram, yaitu pemesan

an hotel.

Gambar

2.29 sequence diagram

Statechart Diagram

Digunakan untuk

memodelkan behavior

yang dinamis dari objek

tertentu,

menggambarkan siklus

hidup objek-objek, macam-macam state dari objek dan

kejadian

yang

mengakibatkan

suatu objek

berpindah

dari

satu

state ke

state

yang lain. Di bawah ini adalah statechart diagram dari online banking.

Gambar 2.30 statechart diagram

G. Collaboration

Diagram

Mirip

dengan

sequence

diagram tetapi

tidak

terfokus

kepada

waktu

atau

“urutan”

dari

message-message,

menggambarkan interaksi objek-objek

dalam

format jaringan.

Gambar 2.31 Collaboration

Diagram

H. Component Diagram

Digunakan

untuk

menggambarkan secara

grafis

arsitektur

sistem

secara

fisik, juga digunakan untuk menunjukkan bagaimana kode pemrograman dibagi

menjadi modul-modul.

Deployment Diagram

Menggambarkan

arsitektur

fisik

dari

hardware dan

software

dari sistem,

dan alat-alat yang membentuk arsitektur sistem.

Berikut

contoh

deployment diagram

yang

menunjukan

hubungan

software

–

hardware yang melibatkan transaksi di sebuah real estate.

Gambar 2.32 component dan deployment diagram

2.5 Pembelian

2.5.1 Pengertian

Pembelian

Pembelian adalah “ kemampuan perusahaan untuk mengadakan barang dan jasa

dengan biaya rendah, dan sesuai dengan tujuan yang dicapai seperti kualitas,

penyerahan, dan pelayanan yang diinginkan.” (Assaouri, 1993, p205)

Untuk mempersiapkan pembelian, ada 3 hal yang perlu ditetapkan dan dipikirkan oleh

bagian pembelian sebagai berikut:

1. Barang apa yang akan dibeli.

2. Berapa banyak yang harus dibeli.

3. Kapan pembelian tersebut dilakukan.

Dari definisi diatas, dapat disimpulkan bahwa pembelian adalah usaha pengadaan

barang atau jasa mulai dari proses penerimaan sampai proses pembayarannya

kepemasok atau penjual.

2.5.2 Fungsi

yang

Terkait Dengan Sistem Informasi

Pembelian

Fungsi

yang terkait

dalam sistem pembelian

menurut Mulyadi (2001,

299-

300), adalah

1. Fungsi gudang

Dalam sistem pembelian, fungsi

gudang bertanggung jawab untuk

mengajukan permintaan pembelian sesuai dengan posisi persedian

yang ada digudang dan

untuk

menyimpan barang

yang

telah diterima

oleh fungsi penerima.

2. Fungsi pembelian

Fungsi

ini

bertanggung jawab

untuk

memperoleh

informasi

mengenai

harga

barang,

menentukan pemasok

yang

dipilih

dalam

pengadaan barang, dan mengeluarkan order pembelian kepada

pemasok yang dipilih.

3. Fungsi penerimaan

Dalam

sistem

pembelian,

fungsi

penerimaan

bertanggung jawab

untuk

melakukan

pemeriksaan terhadap

jenis,

mutu,

dan

kuantitas

barang

yang diterima dari pemasok guna

menetukan dapat atau

tidaknya barang tersebut diterima oleh perusahaan.

4. Fungsi akuntansi

Fungsi

akuntansi yang

terkait

dalam

transaksi

pembelian adalah

fungsi

pencatat

utang

dan

fungsi

pencatat

persediaan. Dalam

sistem

pembelian,

fungsi

pencatat

utang bertanggung

jawab

untuk

mencatat

transaksi pembelian ke dalam register bukti kas keluar.

2.5.3. Prosedur yang

Membentuk

Transaksi

Pembelian

Jaringan prosedur yang membentuk sistem pembelian menurut Mulyadi (2001,

pp301-303)

1. Prosedur permintaan pembelian

Dalam

prosedur

ini

fungsi

gudang

mengajukan permintaan

pembelian

dalam

formulir

surat permintaan pembelian

kepada

fungsi

pembelian.

2. Prosedur permintaan penawaran harga dan pemilihan pemasok

Dalam

prosedur

ini,

fungsi

pembelian

mengirimkan surat

permintaan penawaran harga

kepada

pemasok

untuk

memperoleh

informasi mengenai harga barang dan berbagai syarat pembelian

yang

lain,

untuk

memungkinkan pemilihan

pemasok

yang

akan

ditunjuk

sebagai pemasok barang yang diperlukan oleh perusahaan.

3. Prosedur order pembelian

Dalam

prosedur

ini

fungsi

pembelian

mengirim surat

order

pembelian kepada

pemasok

yang

dipilih

dan

memberitahukan kepada

unit-unit

organisasi

lain

dalam

perusahaan (misalnya

fungsi

penerimaan,

fungsi

yang

meminta barang, dan

fungsi pencatatan

utang)

mengenai

order

pembelian

yang

sudah

dikeluarkan oleh

perusahaan.

5. Prosedur penerimaan barang

Dalam

prosedur

ini

fungsi

penerimaan melakukan

pemeriksaan

mengenai

jenis,

kuantitas,

dan

mutu

barang

yang

diterima

dari

pemasok, dan

kemudian

membuat

laporan

penerimaan barang

untuk

menyatakan penerimaan barang dari pemasok tersebut.

6. Prosedur pencatatan utang

Dalam prosedur ini fungsi akuntansi memeriksa dokumen-

dokumen yang berhubungan dengan pembelian (surat order pembelian,

laporan

penerimaan barang,

dan

faktur

dari

pemasok)

dan

menyelenggarakan pencatatan

utang

atau

mengarsipkan

dokumen

sumber sebagai catatan utang.

7. Prosedur distribusi pembelian

Prosedur ini meliputi distribusi rekening yang didebit dari transaksi

pembelian untuk kepentingan pembuatan laporan manajemen.

Secara garis besar jaringan prosedur dalam sistem akuntansi pembelian menurut

Mulyadi (2001, p301) dapat disajikan pada gambar di bawah ini:

Fungsi Gudang

1. Permintaan Pembelian

2. Permintaan

Penawaran

Harga

Pemasok

Fungsi Pembelian

3. Penawaran

6. Penyimpanan

Harga

Barang

Fungsi Penerimaan

4. Order Pembelian

5. Penerimaan Barang dari Pemasok

Fungsi Akuntansi

7. Laporan

8. Penerimaan faktur dari

Penerimaan barang

pemasok

Gambar 2.33 Jaringan prosedur dalam sistem pembelian

2.6 Persediaan

2.6.1 Pengertian persediaan

Persediaan

ialah

perputaran

persediaan

bisa

ditingkatkan dengan

jalan

memperpendek lamanya suatu produksi. Dalam jalan memperpendek waktu produksi

tersebut,

dengan

cara

yakni

menyempurnakan teknik

baru

yang

ada.

Seperti

management

persediaan tepat

waktu

(JIT

Just

In Time). Cara

yang

lain

misalnya

dengan membeli bahan-bahan saja dan tidak membuatnya sendiri.

Persediaan

adalah

bahan

atau

barang

yang

berada

gudang,

baik

berupa

bahan jadi atau

bahan baku.Yang dimana digunakan untuk

melakukan produksi

dan

juga untuk memenuhi permintaan pelanggan. Schroeder (2000, p200).

2.6.2

Faktor-faktor

persediaan

Berikut faktor-faktor yang dapat mempengaruhi persediaan antara lain :

•

Daya tahan produksi akhir

•

Sifat teknis dan lamanya suatu produksi

•

Tingkat penjualan

Ada 5 alasan mengapa perlu dilakukannya pengadaan persediaan di dalam

perusahaan, yaitu :

•

Memungkinkan perusahaan mencapai skala ekonomis

•

Mengembangkan adanya persediaan dan permintaan

•

Memungkinkan spesialisasi produksi

•

Melindungi adanya ketidakpastian permintaan dan siklus pemesanan

•

Bertindak sebagai penyangga (buffer) diantara antar muka yang bersifat kritis

dalam rantai supply.

Penentukan

kebijakan

dalam

persediaan

yang

perlu

diperhatikan adalah

bagaimana

perusahaan

dapat

meminimalkan biaya

yang

dikeluarkan

tersebut

berkaitan dengan persediaan barang.

2.6.3 Kebijaksanaan dalam

Persediaan

Kebijaksanaan dalam persediaan menurut Assaouri (1993,p234-247) adalah :

1. Jumlah pesanan yang ekonomis

2. Stok minimum (Safety stock)

3. Stok maksimum (Optimal Stock)

4. Titik Pesan Kembali (Reorder Point)

2.6.4 Pengelolaan

Persediaan

Pengelolaan persediaan memiliki dua fungsi utama, yaitu :

1. Fungsi Perencanaan

Fungsi ini berkaitan dengan penentuan komposisi persediaan, penentuan waktu atau

penjadwalan, serta lokasi untuk memenuhi kebutuhan usaha yang telah diproyeksi.

2. Fungsi Pengendalian

Fungsi ini meliputi pengendalian, kuantitas dam jumlah dalam batas-batas yang

telah direncanakan dan perlindungan fisik persediaan

2.7 Penjualan Tunai

2.7.1. Pengertian Penjualan

Menurut

Smith dan Skousen

(1993,p123),

penjualan adalah

arus

masuk

atau

penambahan

lain

atas

aktiva

suatu

entitas

atau

penyelesaian kewajiban-kewajiban

lainnya

(

atau

kombinasi

keduanya)

yang

berasal

dari

penyerahan atau

produksi

barang, pemberian jasa dan aktiva-aktiva lainnya yang merupakan operasi utama atau

operasi inti yang berkelanjutan dari suatu entitas.

Menurut Mulyadi

(2001,p204), kegiatan

penjualan

terdiri dari transaksi

penjualan barang atau jasa, baik secara kredit atau tunai.

Dari

pengertian diatas penjualan adalah suatu aktivitas perusahaan yang

utama

dalam

memperoleh

pendapatan,

baik

untuk

perusahaan

besar

maupun

perusahaan

kecil. Penjualan merupakan sasaran akhir dari kegiatan pemasaran, karena pada

bagian

ini

ada

penetapan

harga,

diadakan

perundingan dan

perjanjian

serah

terima

barang, maupun perjanjian cara pembayaran yang disepakati oleh kedua belah pihak,

sehingga tercapai suatu titik kepuasan.

2.7.1.1. Pengertian Sistem

Penjualan

Sistem

penjualan

adalah

sistem

yang

melibatkan sumber

daya

dalam

suatu organisasi, prosedur, data,

serta sarana pendukung untuk

mengoperasikan

sistem penjualan,

sehingga

menghasilkan

informasi

yang

bermanfaat

bagi

pihak

manajemen

dalam

pengambilan

keputusan.

2.7.1.2. Pengertian Penjualan

Tunai

Penjualan

tunai

dilakukan

oleh

perusahaan yang

bersangkutan

dengan

cara

mewajibkan pembeli

melakukan

pembayaran

terlebih

dahulu

sebelum

barang

tersebut

diserahkan oleh

perusahaan. Barang

kemudian

diserahkan kepada

pembeli

dan

transaksi

penjualan

tunai

dicatat oleh perusahaan.

Menurut

Mulyadi

(2001,p474),

pembeli

diwajibkan untuk

melakukan pembayaran terlebih

dahulu

sebelum

barang

tersebut

diserahkan

oleh

perusahaan, kemudian

barang

diserahkan kepada

pembeli dan transaksi penjualan tunai dicatat oleh perusahaan.

Informasi yang diperlukan oleh manajemen dari kegiatan

penjualan tunai antara lain:

1. Jumlah pendapatan penjualan menurut jenis produk atau kelompok

produk selama jangka waktu tertentu.

2. Jumlah kas yang diterima dari penjualan tunai.

3. Jumlah harga pokok produk yang dijual selama jangka waktu

tertentu.

4. Nama dan alamat pembeli.

5. Kuantitas produk yang akan dijual.

6. Nama wiraniaga yang akan melakukan penjualan.

7. Otorisasi pejabat yang berwenang.

2.7.2. Fungsi-fungsi yang Terkait dengan

Penjualan Tunai

1. Fungsi Penjualan

Dalam transaksi ini,

fungsi

ini bertanggung jawab untuk menerima order dari pembeli,

mengisi faktur penjualan tunai, dan menyerahkan faktur tersebut kepada pembeli untuk

kepentingan pembayaran harga barang ke fungsi kas.

2. Fungsi Kas

Fungsi ini bertanggung jawab sebagai penerima kas dari pembeli.

3. Fungsi Gudang

Fungsi

ini

bertanggung

jawab

untuk

menyiapkan barang

yang

dipesan

oleh pembeli,

serta menyerahkan barang tersebut ke fungsi pengiriman.

4. Fungsi Akuntansi

Dalam transaksi penjualan,

fungsi

ini

bertanggung jawab

mencatat transaksi penjualan

dan penerimaan kas dan membuat laporan penjualan.

5. Fungsi Pengiriman

Fungsi ini bertanggung jawab

untuk

membungkus dan

menyerahkan barang yang

telah

dibayar harganya kepada pembeli.