BAB
2
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
di
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.
7
|
8
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.
|
9
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
|
10
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
|
11
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
|
12
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
ke
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
|
13
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
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.
4.
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.
|
14
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.
2.
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.
|
![]() 15
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
G
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
|
![]() 16
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:
1.
User
Interfaces yang
mencakup monitor
dengan
text
dan
grafik,
hasil printouts, dan
fasilitas
lain
yang
mengizinkan
user mengaktifkan fungsi sistem.
2.
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
|
![]() 17
|
![]() 18
Specifications
of
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.
|
![]() 19
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
ke
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
di
dalam Problem
Domain
Analysis. Dalam
class
activity
kita
memilih
class
untuk
model
problem domain dan
setiap
class dibuat
dikarakteristikkan oleh
|
![]() 20
eventnya. Dan
di
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
Sub class
Gambar 2.6 Generalization structure
|
![]() 21
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
|
![]() 22
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 :
|
![]() 23
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
|
![]() 24
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.
a
T1
b
Tn
z
z
Gambar 2.10 Sequence
b. Selection
|
![]() 25
Hanya
satu dari sekumpulan
event
yang
terjadi.
Selection
digambarkan
dengan
membuat
semua
kemungkinan event keluar dari state yang sama.
T
a
b
z
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.
T
a
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
|
![]() 26
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
|
![]() 27
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.
Di
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
|
![]() 28
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
|
29
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
|
30
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-
|
![]() 31
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
|
32
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
ke
tugas
user.
Fleksibilitas dan
koprehensif
membantu
memudahkan pekerjaan
design
dan
implementasi.
Criteria mempunyai beberapa hal yang harus diperhatikan, yaitu:
|
33
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
|
34
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:
1)
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
|
35
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.
2)
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.
3)
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
|
36
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
et
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
|
![]() 37
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.
|
38
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
|
![]() 39
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:
|
40
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.
|
![]() 41
-
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
di
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
di
komponen
lain, seperti digambarkan
dibawah ini :
<<component>>
Function
Account
Manager
1
1..*
<<component>>
Model
Account
|
![]() ![]() 42
Position
Gambar
2.18 Connection by class aggregation
b.
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
W
Session W
<<component>>
UI Library
Window
Gambar
2.19 Connection by class specialization
c.
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
|
![]() 43
<<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
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).
b)
Explore Pattern.
|
44
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.
c)
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:
|
![]() 45
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
2.
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
3.
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
|
![]() 46
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’.
|
![]() 47
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’.
|
![]() 48
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,
3
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.
|
![]() 49
Gambar
2.29 sequence diagram
F.
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
|
![]() 50
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.
I.
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.
|
![]() 51
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
|
52
Fungsi
yang terkait
dalam sistem pembelian
menurut Mulyadi (2001,
p
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
|
53
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.
|
![]() 54
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
|
55
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
di
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 :
|
56
•
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
|
57
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
|
58
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.
|
59
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.
|