ANALISIS DESAIN SISTEM INFORMASI E-PROCUREMENT BERORIENTASI OBYEK MENGGUNAKAN UML PADA BIRO UMUM UPN ”VETERAN” JATIM.

ANALISIS DESAIN SISTEM INFORMASI E-PROCUREMENT
BERORIENTASI OBYEK MENGGUNAKAN UML
PADA BIRO UMUM UPN ”VETERAN” J ATIM

SKRIPSI

Diajukan Untuk Memenuhi Sebagai Per syar atan
Dalam Memper oleh Gelar Sar jana Komputer
Pr ogr am Studi Sistem Infor masi

Disusun Oleh :

RIZA RAMADHANI NOOR
NPM. 0735010016

PROGRAM STUDI SISTEM INFORMASI
FAKULTAS TEKNOLOGI INDUSTRI
UNIVERSITAS PEMBANGUNAN NASIONAL “VETERAN”
J AWA TIMUR
SURABAYA
2011

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

KATA PENGANTAR
Dengan segala puja dan puji syukur atas kehadirat ALLAH SWT, yang
maha pengasih lagi maha penyayang yang telah membuka pintu kemudahan, serta
membimbing saya untuk menyelesaikan program SKRIPSI dengan judul
ANALISIS

DESAIN

SISTEM

INFORMASI

E-PROCUREMENT

BERORIENTASI OBYEK MENGGUNAKAN UML PADA BIRO UMUM UPN
“VETERAN” JATIM. Dalam pelaksanaan survey pada Biro Umum saya

mendapatkan sambutan yang kooperatif, sehingga proses penggalian data dapat
dilakukan dengan sebaik mungkin. Tak lupa, saya ingin mengucapkan terimakasih
yang sebanyak-banyaknya kepada pihak- pihak yang membantu saya dalam
mencari pencerahan materi dan spiritual.
1. Kepada Ayah dan Ibu saya yang sangat saya cintai, yang selalu
memperhatikan saya, selalu menanyakan kondisi kesehatan saya pada saat
mengerjakan skripsi dan selalu mendoakan saya. Sungguh besar kasih
sayang yang kalian curahkan, dan selalu menanyakan “kapan skripsi kamu
selesai..?” selalu membuat saya bersemangat.
2. Kepada Bpk. Moh. Irwan Afandi, ST, MSc. selaku dosen pembimbing
satu Skripsi saya, yang sabar dan murah senyum, saran, dorongan, serta
dukungan yang diberikan beliau apabila saya kesulitan dan putus asa
membuat saya terus berusaha, dan bersemangat dalam menyelesaikan
skripsi ini.
3. Kepada Ibu Eka Dyar Wahyuni, S.Kom. selaku dosen pembimbing dua
Skripsi yang juga memberikan banyak saran, serta dukungan untuk
menyelesaikan program ini. Sunggu besar kesabaran beliau dalam
membimbing saya, setiap hari senin, selasa, dan kamis selalu menemani
saya dan kawan-kawan yang juga satu tema skripsi dengan saya dari siang
sampai sore.

4. Kepada Bpk. Nur Cahyo Wibowo, S.Kom, M.Kom. selaku Ketua Program
Studi Sistem Informasi yang selalu memberikan dukungan moril kepada
saya dan kawan-kawan yang satu teman dalam mengerjakan skripsi.
v

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

vi

5. Kepada seseorang yang sangat spesial dalam hati dan kehidupan saya,
Ruliana Pangestuningrum yang selalu ada disamping saya memberikan
semangat. Orang yang sangat cerewet dalam memperhatikan kesehatan
saya selama pengerjaan skripsi. Terima kasih banyak atas perhatian yang
kau berikan pada saat itu.
6. Kepada ibu Waldy Permana Agastya, S.Kom, MM. terima kasih saran dan
dorongan morillnya. Beliau juga selalu berkata “Gimana rama, kapan
lisan?”. Terima kasih untuk selalu mengingatkan saya dan terima kasih
untuk saran dan strategi menghadapi ujian lisan yang diberikan pada
malam sebelum Lisan.

7. Kepada ibu Syurfah Ayu Ithriah, S.Kom. terima kasih atas dorongan
semangat yang ibu berikan selama ini. Selalu bersedia mendengarkan
curhat saya apabila saya lagi ada permasalahan dalam pengerjaan skripsi.
8. Kepada teman satu perjuangan saya dalam mengerjakan skripsi, Avid
Pradahana Dekhoma dan Dany Safriansyah yang selalu menyemangati
saya dan selalu “menggesek” saya apabila lagi down. Terima kasih kawan,
saya tidak akan melupakan kata-kata di sms yang selalu kita kirimkan ke
masing-masing handphone “Gimana progresmu Sob? Udah sampai
mana?”. Kalian sahabat terbaik saya.
9. Tidak lupa saya mengucapkan terima kasih kepada Dwi Enggal Prayoga
atas bantuannya, dan kepada rekan- rekan mahasiswa karena dengan
dorongan semangat, kritik dan saran serta dukungan merekalah yang
membuat saya untuk tetap bersemangat untuk menyelesaikan skripsi ini.
Walaupun seringkali saya menemui persoalan yang menghalangi. Namun,
dorongan serta dukungan dari orang- orang disekitar, yang membuat saya tetap
berdiri dan terus berlari menuju keberhasilan. Terima kasih semuanya...
Surabaya, 7 November 2011

( Riza Ramadhani Noor )

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

Judul

Pembimbing I
Pembimbing II

: ANALISIS DESAIN SISTEM INFORMASI EPROCUREMENT BERORIENTASI OBJEK
MENGGUNAKAN UML PADA BIRO UMUM UPN
“VETERAN” JATIM
: Moh. Irwan Afandi, ST, MSc
: Eka Dyar Wahyuni, S.Kom

ABSTRAK

Pengadaan barang dan jasa merupakan hal yang perlu mendapatkan
penanganan administrasi yang tertib, tertata, dan transparan terkait untuk
memperlancar proses penawaran barang dan jasa (tender) dan dapat
mengurangi dan menghilangkan praktek KKN dalam bidang pengadaan barang

atau jasa.
Tugas Akhir ini membahas tentang bagaimana melakukan Analisa dan
Desain pada Aplikasi Sistem Informasi E-Procurement Biro Umum.
Pengembangan Aplikasi diawali dengan melakukan tinjauan pustaka,
mengumpulkan data kebutuhan user sistem yaitu menggunakan metode interview
dan penggalian dokumen, melakukan analisa kebutuhan, dan melakukan desain
sistem
Hasil dari tugas akhir ini berupa Dokumen yang menggambarkan analisa
kebutuhan perangkat lunak serta desain perangkat lunak yang dilengkapi dengan
teknik pendiagraman UML ( diagram yang digunakan yaitu usecase diagram,
usecase description, activity diagram, class diagram dan sequence diagram).
Dokumen hasil akhir tugas akhir ini akan menjadi dasar bagi pogrammer untuk
melanjutkan tahap implementasi.

Kata kunci: Aplikasi Sistem Informasi E-Procurement, UML

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

DAFTAR ISI

Halaman
ABSTRAK………………………………………………………………………..iv
KATA PENGANTAR ......................................................................................... v
DAFTAR ISI .................................................................................................... viii
DAFTAR GAMBAR .......................................................................................... ix
DAFTAR TABEL .............................................................................................. xi
BAB I PENDAHULUAN.................................................................................. 1
1.1.

Latar Belakang ....................................................................................... 1

1.2.

Perumusan Masalah................................................................................ 3

1.3.

Batasan Masalah .................................................................................... 3

1.4.

Tujuan.................................................................................................... 4

1.5.

Manfaat Penelitian ................................................................................. 4

1.6.

Sistematika Penulisan............................................................................. 4

BAB II TINJAUAN PUSTAKA ........................................................................ 6
2.1.

Pengadaan Barang / Jasa ........................................................................ 6

2.2.

Pengadaan Barang / Jasa Melalui Internet .............................................. 6

2.3.

Sistem .................................................................................................... 7

2.4.

Sistem Informasi .................................................................................... 8

2.5.

Analisa dan Desain Berorientasi Objek................................................... 9

2.6.

Unified Modelling Language................................................................ 13

2.7.

2.6.1.

Usecase Diagram .................................................................. 16

2.6.2.

Usecase Description.............................................................. 18

2.6.3.

Activity Diagram .................................................................. 24

2.6.4.

Sequence Diagram ................................................................ 25

2.6.5.

Class Diagram....................................................................... 30

2.6.6.

Method Specification ............................................................ 32

Rational Rose ....................................................................................... 33

BAB III METODOLOGI ................................................................................... 35

viii
Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

3.1.

Studi Literatur ...................................................................................... 36

3.2.

Identifikasi dan Perumusan Masalah..................................................... 36

3.3.

Membuat Desain Sistem....................................................................... 36

3.4.

Review................................................................................................. 38

3.5.

Penyusunan Dokumentasi (Buku Tugas Akhir) .................................... 38

BAB IV ANALISA DAN DESAIN.................................................................... 39
4.1.

Sistem Pengadaan Barang dan Jasa Saat Ini.......................................... 39
4.1.1.

Hasil Analisa Dokumen Peraturan Materiil Badan Pelaksana
Pendidikan ............................................................................ 39

4.1.2.

Proses Pengadaan Barang dan Jasa Saat Ini........................... 45

4.2.

Permasalahan Saat Ini .......................................................................... 48

4.3.

Analisa Kebutuhan ............................................................................... 50

4.4.

4.3.1.

Usecase Diagram (Diagram Usecase) .................................... 52

4.3.2.

Usecase Description (Deskripsi Usecase) .............................. 54

Desain Sistem....................................................................................... 59
4.4.1.

Activity Diagram .................................................................. 59

4.4.2.

Sequence Diagram ................................................................ 63

4.4.3.

Class Diagram....................................................................... 66

4.4.4.

Desain Database.................................................................... 66

4.4.5.

Desain Antarmuka ................................................................ 66

BAB V PENUTUP ........................................................................................... 70
5.1.

Kesimpulan .......................................................................................... 71

5.2.

Saran.................................................................................................... 71

DAFTAR PUSTAKA ........................................................................................ 72
LAMPIRAN ...................................................................................................... 73
LAMPIRAN A Dokumentasi Hasil Wawancara ..................................... 73

ix
Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

DAFTAR GAMBAR
Gambar 2.1

Siklus Pengolahan Data................................................................. 9

Gambar 2.2

Penggolongan Diagram UML...................................................... 14

Gambar 2.3

Contoh Use Case Diagram .......................................................... 17

Gambar 2.4

Template Use Case Description................................................... 20

Gambar 2.5

Contoh Extend Relationship ........................................................ 22

Gambar 2.6

Contoh Include Relationship ....................................................... 22

Gambar 2.7

Contoh Generalization Relationship ............................................ 23

Gambar 2.8

Contoh Activity Diagram ............................................................ 25

Gambar 2.9

Contoh Sequence Diagram .......................................................... 26

Gambar 2.10 Aturan Penggunaan Class Aktor dalam Sequence Diagram. ........ 28
Gambar 2.11 Aturan Penggunaan Class Boundary dalam Sequence Diagram ... 29
Gambar 2.12 Aturan Penggunaan Class Control dalam Sequence Diagram....... 29
Gambar 2.13 Aturan Penggunaan Class Entity dalam Sequence Diagram ......... 29
Gambar 2.14 Contoh Class Diagram................................................................. 32
Gambar 2.15 Template Use Case Description................................................... 33
Gambar 3.1

Metodologi yang digunakan dalam penelitian.............................. 35

Gambar 4.1

Generalisasi Aktor dalam Aplikasi SIEPROC ............................. 53

Gambar 4.2

Contoh Use Case description ‘Mengelola Data User’ .................. 58

Gambar 4.3

Contoh Activity Diagram ‘Mendaftar Paket Pekerjaan’ ............... 63

Gambar 4.4

Contoh Sequence Diagram ‘Lihat Daftar Peserta Lelang’ ............ 65

Gambar A.1 Pelelangan Dengan Pascakualifikasi............................................ 75
Gambar A.2 Proses Pelelangan Barang dan Jasa UPN “Veteran” JATIM ........ 76

x
Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

DAFTAR TABEL
Tabel 2.1

Perbedaan Diagram UML Versi 2.0 ............................................ 15

Tabel 2.1

Notasi Use Case Diagram............................................................ 18

Tabel 2.3

Notasi Sequence Diagram ........................................................... 26

Tabel 2.4

Format Multiplicity ..................................................................... 31

Tabel 4.1

Form Masukan ............................................................................ 66

Tabel 4.2

Form Keluaran ............................................................................ 68

xi
Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

BAB I
PENDAHULUAN

1.1

Latar Belakang
Universitas Pembangunan Nasional (UPN) merupakan sebuah institusi

yang bergerak di bidang pendidikan. UPN merupakan salah satu Universitas
terbaik di Jawa Timur dan menempati peringkat kedua (Pusat Data dan Analisis
Tempo, 2010).
Seiring dengan perkembangannya dalam mencapai misi menjadi
universitas yang terdepan, maka di butuhkan sebuah teknologi atau sistem
informasi yang mendukung segala aktivitas akademis maupun non-akademis.
Walaupun saat ini UPN telah menerapkan sistem yang berjalan sesuai peraturan
yang ada, beberapa permasalahan masih terjadi terutama pada bagian pelelangan
pekerjaan barang atau jasa. Proses lelang yang masih dilakukan secara manual
sangat kurang efisien dan memakan waktu. Hal tersebut dikarenakan

belum

tersedianya sistem lelang pekerjaan barang dan jasa (E-Procurement).
Oleh sebab itu, dalam rangka meningkatkan manajemen operasional UPN
diperlukan sebuah sistem informasi. Untuk membuat suatu sistem informasi,
diperlukan desain sistem yang yang mampu menggambarkan proses bisnis
berserta komponen yang terlibat di dalam dan harus mudah dimengerti serta
dipelajari. Sehingga jika terjadi suatu permasalahan pada saat sistem sudah
diimplementasikan, pihak pengembang dengan mudah memperbaikinya tanpa
membuat kesalahan yang baru.
Desain sistem yang tepat digunakan untuk pembuatan sistem ini adalah
desain sistem berorientasi obyek. Menurut Suhendar dan Gunadi (2002), object
1

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

2

oriented memandang software bagian per bagian dan menggambarkan satu bagian
tersebut dalam satu obyek. Satu obyek dalam sebuah model merupakan suatu
fokus selama dalam proses analisis, desain, dan implementasi dengen
menekankan pada state, perilaku (behavior), dan interaksi obyek-obyek dalam
model tersebut.
Berdasarkan uraian di atas maka dibuatlah suatu desain sistem informasi eprocurement dengan dengan menggunakan object oriented. Obyek-obyek
dimodelkan dengan bahasa Unified Modelling Language (UML). Menurut Sholiq
(2006), UML adalah notasi pemodelan standar industri untuk sistem berorientasi
obyek. Dimana UML dapat memberikan suatu model yang siap pakai dan
mendukung perbaikan desain system karena memiliki notasi untuk menjelaskan
secara visual mengenai elemen-elemen pemodelan.
Dengan adanya desain sistem informasi e-procurement ini, kedepannya
dapat diimplementasikan ke dalam pembuatan aplikasi dan memudahkan
perbaikan sistem untuk mendukung proses kemudahan dalam proses pelelangan.
1.2

Perumusan Masalah
Berdasarkan uraian latar belakang permasalahan, maka secara garis besar

perumusan masalah yang terdapat dalam tugas akhir ini adalah:
1. Bagaimana menganalisa dan mendesain Sistem Informasi E-Procurement
yang bisa menangani kegiatan operasional pengadaan barang dan jasa di
Biro Umum dengan menggunakan UML sebagai bahasa pemodelannya.
1.3

Batasan Masalah

Batasan pembuatan Desain Sistem Informasi ini adalah :

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

3

1. Sistem ini berpedoman pada Peraturan Materiil Badan Pelaksana
Pendidikan nomor: KEP/12/YKPP/III/2008 Tanggal 5 Maret 2008 dan
Keppres Nomor 80 Tahun 2003 tentang Pedoman Pengadaan Barang/Jasa
Pemerintah yang telah diubah ke-empat kalinya dengan Perpres Nomor 8
Tahun 2006
2. Data/proposal yang masuk dirapatkan terlebih dahulu dengan PPK yaitu
Rektor, kemudian hasilnya diumumkan oleh Admin melalui web.
3. Data yang digunakan merupakan data dari sub bagian Biro Umum
Universitas Pembangunan Nasional (UPN) “Veteran” Jawa Timur.
4. Desain sistem yang dibangun hanya membahas lingkup Lelang Online (EProcurement), dan Progres Pekerjaan.
5. Desain pemodelan menggunakan UML dan Relational Rose sebagai
toolnya
6. Dalam pembuatan desain sistem ini tidak membahas tentang registrasi
pengguna baru.
7. Desain sistem ini mereferensikan entity pegawai dari Sistem Informasi
Kepegawaian.
1.4

Tujuan

Tujuan pembuatan Desain Sistem Informasi ini adalah :
1. Membuat desain Sistem Informasi E-Procurement yang bisa menangani
kegiatan operasional pengadaan barang dan jasa yang dapat digunakan
pihak Biro Umum sebagai dasar dalam pembuatan sistem dengan
menggunakan

UML

sebagai

bahasa

pemodelannya.

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

Yang

4

didokumentasikan dalam Syarat Kelengkapan Perangkat Lunak (SKPL)
dan Deskripsi Perancangan Perangkat Lunak (DPPL).
1.5

Manfaat Penelitian

Manfaat yang diberikan dari tugas akhir ini adalah sebagai berikut :
1. Memberikan identifikasi kebutuhan pengguna Aplikasi Sistem Informasi
E-Procurement Biro Umum
2. Memberikan desain Aplikasi Sistem Informasi E-Procurement Biro
Umum.
3. Membantu programmer dengan menyediakan visualiasi elemen-elemen
pemodelan dan code generation

sehingga dapat

memudahkan

programmer dalam pembuatan aplikasi.
1.6

Sistematika Penulisan

Sistematika pembahasan penulisan tugas akhir ini tersusun atas:
BAB I : PENDAHULUAN
Berisi tentang latar balakang penulisan tugas akhir, perumusan
masalah, batasan masalah, tujuan penelitian, manfaat penelitian,
dasar hukum, metodologi penulisan dan sistematika penulisan.
BAB II : TINJ AUAN PUSTAKA
Berisi tentang teori-teori penunjang pembuatan desain sistem
yang

membahas

tentang

Sistem

Informasi

Pengadaan

Barang/Jasa.
BAB III: METODOLOGI
Bab ini menerangkan mengenai metodologi yang digunakan
dalam pengerjaan tugas akhir. Mulai dari Melakukan Tinjauan

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

5

pustaka, Mendapatkan Requirement dari user, melakukan
Analisa kebutuhan berdasarkan Requirement yang didapatkan,
Melakukan desain Sistem, hingga penyusunan Buku Tugas
Akhir
BAB IV : ANALISA DAN PERANCANGAN SISTEM
Bab ini akan menjelaskan lebih detil mengenai tahap Analisa
dan Desain Sistem Informasi E-Procurement di mana dalam
melakukan analisa dan desain tersebut digunakan beberapa
diagram dari tool UML untuk memudahkan bagi pengguna
Rancangan ini untuk memahami. Perincian diagram yang
digunakan yaitu: Use Case diagram, Use Case Description,
activity diagram, sequence diagram, class diagram, dan desain
Antar muka.
BAB V : PENUTUP
Berisi tentang kesimpulan dan saran-saran mengenai Tugas
Akhir yang disusun.

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

BAB II
TINJ AUAN PUSTAKA

Pada bab ini akan dibahas teori-teori yang mendukung pembuatan tugas akhir
ini, yaitu teori Pengadaan Barang / Jasa, Pengadaan Barang / Jasa Melalui
Internet (E-Procurement), Sistem, Sistem Informasi, SDLC (System
Development Life Cycle), Analisa dan Desain Berorientasi Obyek, UML
(Unified Modelling Languange), serta Reational Rose.
2.1 Pengadaan Barang / J asa
Pengadaan barang / jasa adalah sebuah aktivitas untuk memperoleh
barang atau jasa, dalam studi kasus ini biayanya didukung dari anggaran BP
Dik, UPN “Veteran” atau LPTTN. Pengadaan barang/jasa pada dasarnya
adalah

perolehan

atau

penambahan

barang/jasa

berupa

peralatan,

perlengkapan, jasa konsultasi dan lain-lain. Yang prosesnya dimulai dari
perencanaan kebutuhan sampai sampai diselesaikannya seluruh kegiatan
hokum memperoleh barang / jasa.
2.2 Pengadaan Barang / J asa Melalui Internet (E-Procurement)
Pengadaan barang / jasa melalui internet (E-procurement) adalah
pembelian business-to-business (B2B) dan penjualan barang dan jasa melalui
internet. E-Procurement merupakan mekanisme pembelian masa kini atau
dapat dikatakan sebagai aplikasi berbasis internet dan perangkat teknologi
lainnya sebagai penghubung dalam proses tesebut. E-procurement juga
berguna dalam rangka melakukan pengawasan terhadap prosedur penawaran
yang dilakukan dalam pengadaan barang atau jasa secara elektronik.
6

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

7

Dalam konsep ini, dikenal sejumlah istilah yang kerap dipergunakan oleh
para praktisi bisnis dan teknologi informasi.
1. Aplikasi e-Procurement merupakan perangkat lunak atau software yang
dipergunakan untuk mengaplikasikan konsep e-Procurement dalam
institusi.
2. Sistem e-Procurement merupakan kumpulan dari sejumlah komponen
komponen atau entitas-entitas di dalam institusi, yang saling terkait satu
dengan yang lainnya, yang memiliki fungsi untuk menjalankan konsep
e-Procurement di dalam sebuah institusi. Adapun yang dimaksud dengan
konsep komponen terkait misalnya: perangkat keras (hardware),
perangkat lunak (software), seumber daya manusia (brainware) dan
pemakain atau pengguna (user), kebijakan (policy), tata kelola
(governance), proses (business process), dan infrastruktur institusi.
3. Sistem Aplikasi e-Procurement merupakan kumpulan dari sejumlah
komponen atau modul-modul aplikasi (sejumlah –subprogram dan
database), yang saling terkait satu dengan yang lainnya untuk
membentuk suatu aplikasi holistic (utuh) dan terintegrasi dengan fungsi
utama mengaplikasikan konsep e-Procurement dalam institusi.
2.3 Sistem
Dalam mendefinisikan sebuah sistem terdapat dua kelompok
pendekatan (Jogiyanto, 2003). Pertama, lebih menekankan pada prosedur yang
digunakan dalam dalam sistem dan mendefinisikannya sebagai kumpulan dari
prosedur-prosedur yang mempunyai tujuan tertentu. Kedua, lebih menekankan
pada elemen atau komponen penyusun sistem dan mendefinisikannya sebagai

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

8

kumpulan dari komponen yang saling berhubungan satu dengan yang lainnya
membentuk satu kesatuan untuk mencapai tujuan tertantu.
Kedua definisi tersebut sama benarnya dan tidak saling bertentangan.
Yang membedakan hanyalah cara pendekatan yang dilakukan pada sistem.
Untuk sistem yang lebih menekankan pada prosesnya, pendekatan prosedur
akan lebih mengena untuk menggambarkan sistem tersebut. Untuk sistem
yang fisiknya lebih terlihat, pendekatan komponen akan lebih jelas digunakan
untuk menggambarkan sistemnya.
2.4 Sistem Infor masi
Tujuan dari sistem informasi adalah menghasilkan informasi.
Informasi tersebut didapatkan dari pengolahan data. Kebanyakan orang
mengartikan data dan informasi dengan pengertian yang sama (Jogiyanto,
2003). Namun dua pengertian ini sebenarnya memiliki perbedaan yang
mendasar. Data merujuk kepada fakta-fakta berupa angka-angka, teks,
dokumen, gambar, bagan, suara yang mewakili deskripsi verbal atau kode
tertentu semacamnya. Apabila data tersebut disaring dan diolah melalui suatu
sistem pengelolaan sehingga berubah fungsi menjadi informasi.
Sistem informasi adalah suatu sistem suatu sistem di dalam suatu
organisasi yang mempertemukan kebutuhan pengolahan transaksi harian,
mendukung operasi, bersifat manajerial dan kegiatan strategi daru suatu
organisasi dan menyediakan pihak luar tertentu dengan laporan-laporan yang
diperlukan. Tugas dari sistem informasi adalah untuk melakukan siklus

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

9

pengelolaan data (data processing cycles) atau bisa juga disebut dengan siklus
informasi.

INPUT

PROSES

OUTPUT

Data berupa fakta

Pengolahan data

Informasi

Gambar 2.1 Siklus pengolahan data.
2.5 Analisa dan desain berorientasi obyek
Analisa berorientasi obyek (Object Oriented Analysis) adalah metode
analisis yang memeriksa requirements (syarat/keperluan yang harus dipenuhi
sistem) daris sudut pandang kelas-kelas dan obyek-obyek yang ditemui dalam
ruang lingkup permasalahan (Suhendar dan Gunadi, 2002). Sedangkan Desain
Berorientasi Obyek (Object Oriented Desain) adalah metode untuk
mengarahkan arsitektur software yang didasarkan pada manipulasi obyekobyek sistem atau sub sistem (Suhendar dan Gunadi, 2002).
Analisa dan Desain Berorientasi Obyek memiliki beberapa konsep
dasar, antara lain:
a. Obyek (object)
Obyek (object) merupakan “benda”, yang secara fisik atau konseptual
dapat kita temui disekeliling kita. Misalnya hardware, software, dokumen,
manusia, dan bahkan konsep semuanya adalah obyek. Sebagai contoh, seorang
pengguna personal komputer, akan memandang CPU (Central Processing

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

10

Unit) , penggerak kursor (mouse), dan papan ketik (keyboard) sebagai obyek
dan salah satu keadaan computer baik itu hidup atau tidak merupakan state
dari obyek computer tersebut. State adalah kondisi obyek tersebut atau
himpunan yang menggambarkan obyek tersebut. State dari obyek merupakan
nilai dari atribut (attribute) obyeknya. Atribut adalah cerminan nilai internal
suatu obyek. Nilai-nilai tersebut antara lain, karakteristik obyek, kondisi
sesaat, koneksi dengan obyek lain, dan identitas. Obyek juga memiliki
perilaku (behavior),

hal ini dapat dicerminkan dari perubahan state yang

terjadi pada object tersebut.
Perilaku sebuah obyek dapat didefinisikan sebagai sebuah kondisi
obyek saat bertindak (beraksi) dan memberi reaksi, yang ditentukan oleh
semua himpunan atau beberapa operasi yang dapat dilakukan oleh obyek itu
sendiri. Perilaku dari sebuah obyek dicerminkan oleh interface, service, dan
method dari obyek tersebut. Interface merupakan pintu untuk mengakses
service obyek, Service adalah fungsi yang bisa diemban obyek. Method adalah
mekasnisme internal obyek yang mencerminkan perilaku (behavior) obyek
tersebut.
b. Kelas (Class)
Secara umum, kelas (class) dapat didefinisikan sebagai himpunan
obyek sejenis. Spesifikasi dari perilaku (behavior) dan informasi (attribute)
obyek-obyek ditetapkan oleh kelas. Jadi dapat diartikan, class adalah sesuatu
yang membungkus (encapsulate) informasi dan perilaku.

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

11

c. Abstraksi (Abstraction)
Abstraksi atau abstracti secara sederhana dikatakan sebagai proses
memilah beberapa attribut dan beberapa operasi suatu obyek hanya sampai
pada saat yang benar-benar di perlukan saja. Nilai informasi yang dibutuhkan
pada tiap tipe permasalahan adalah berbeda, sehingga hanya atribut-atribut
dan operasi-operasi yang diperlukan saja yang didefinisikan. Metode ini
dikenal dengan isitilah abstraksi suatu obyek.
d. Pewarisan (Inheritance)
Inheritance atau pewarisan adalah turunan sifat kelas, dari kelas induk
kepada kelas turunannya. Attribut dan operasi yang ditentukan dalam kelas
dapat diwariskan ke masing-masing obyek dalam kelas tersebut. Kelas dapat
juga mewarisi sifat-sifat kelas lainnya.
e. Banyak bentuk (Polymorphism)
Polimorfisme (polymorphism) erat kaitannya dengan Pewarisan.
Polimorfisme adalah pemikiran bahwa obyek dinamis suatu kelas dasar dapat
berperilaku seperti kelas turunan. Ketika obyek tersebut menunjuk kelas dasar,
obyek tersebut berperilaku seperti kelas dasar, tetapi ketika obyek tersebut
menunjuk kelas turunan, obyek tersebut berperilaku seperti kelas turunan.
Dalam hal ini obyek dapat memiliki beberapa bentuk, tergantung pada saat itu
kelas mana yang ditunjuk. Yang perlu menjadi catatan, bahwa perubahan
perilaku ini dari kelas dasar kepada kelas turunan, tidak dapat obyek kelas
turunan menunjuk kelas dasar.

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

12

Polimorfisme dimungkinkan karena adanya mekanisme ikatan dinamis
(dynamic binding). Ikatan dinamis adalah ikatan yang terjadi pada saat
program dijalankan (run-time). Ikatan yang terjadi pada saat kompile disebut
ikatan statis. Ikatan dinamis hanya dapat terjadi antara suatu obyek dinamis
dengan metode yang dinamis juga, dalam hal ini metode virtualnya (maya).
f. Pembungkusan ( Encapsulation)
Encapsulation adalah proses proses menyembunyikan data, dimana
tidak ada data yang akan diberikan akses langsung. Satu-satunya cara untuk
mengakses data obyek tersebut adalah melalui interface obyek produk
tersebut. Interface melindungi data sebuah obyek dari “campur tangan” pihak
luar. Dalam obyek oriented programming kode dan data disatukan dalam
sebuah “benda” yang tersembunyi isinya, yaitu obyek. Pengguna obyek tidak
perlu mengetahui isi dalam obyek. Data diperoleh melalui interaksi yang
melewati interface obyek yang bertanggung jawab atas data tersebut. Untuk
membaca data, pesan dikirim ke interface obyek tersebut, kemudian interface
akan akan membaca pesan dan mengirim pesan balasan.
g. Message Sending
Message didefinisikan sebagai permintaan untuk obyek penerima
(receive object) untuk membawa metode atau perilaku yang ditunjukan dan
mengembalikan hasil dari aksi terssbut kepada obyek pengirim (sender
object). Untuk melakukan sebuah operasi, suatu dapat mengirim pesan ke
obyek lainnya untuk melakukan operasi dan dapat menerima pesan untuk
melakukan operasi yang lain.

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

13

2.6 Unified Modelling Language
Menurut Sholiq (2006) Unified Modelling Language (UML) adalah
sebuah bahasa yg telah menjadi standar dalam industri untuk visualisasi,
merancang dan mendokumentasikan sistem piranti lunak.
UML merupakan sistem arsitektur yang bekerja dalam Object Oriented
Analysis and Design (OOAD). UML adalah bahasa pemodelan yang paling
sukses dari tiga metode Object oriented yang telah ada sebelumnya, yaitu
Booch, Object Modelling Technique(OMT), dan Object Oriented software
Engeneering (OOSE). UML merupakan pengembangan dari ketiga pemodelan
yang sudah ada terdahulu yang dibangun dalam satu kesatuan.
Menurut Suhendar dab Gunadi (2002) Tujuan UML diantaranya adalah:
1. Memberikan model yang siap pakai, bahasa pemodelan visual ekspresif
untuk mengembangkan dan saling menukar model dengan mudah dan
dimengerti secara umum.
2. Memberikan bahasa pemodelan yang bebas dari berbagai bahasa
pemrograman proses rekayasa.
3. Menyatukan praktek-praktek terbaik yang terdapat dalam pemodelan.
Secara lebih mendalam, UML lebih dari sekedar sebuahn standart dan
penemuan dari berbagai notasi yang telah ada sebelumnya yang kemudian
disatukan. Tetapi UML mempunyai konsep-konsep lain yaitu, konsep baru
yang menarik yang tidak di temukan secara umum dalam komunitas object
oriented.

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

14

Dalam membangun sebuah model perangkat lunak menggunakan
UML, digunakan berbagai sudut pandang yang divisualisasikan dalam
bentuk-bentuk diagram atau simbol untuk merepresentasikan elemen-elemen
dalam sistem. Karena ini merupakan sebuah bahasa, UML mempunyai
sejumlah aturan untuk menggabungkan kombinasi elemen-elemen tersebut.
Di bawah ini digambarkan penggolongan dari 14 diagram UML versi 2.0.
Class Diagram

Object
Diagram
Package
St ruct ured

Diagram

Diagram

Deployment
Diagram
Component
Diagram
Composit e
St ruct ure Diagram

Diagra
m UM L
2.0

Act ivity
Diagram
Int eract ion
Diagram
Sequence Diagram
Behaviour
Diagram

Comm unication
Diagram
Int eract ion Overview
Diagram

St ate
M achines
Prot ocol St ate
M achines
Behaviour St ate
M achines

Gambar 2.2 Penggolongan Diagr am UML

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

15

Table di bawah ini menjelaskan perbedaan tujuan tiap diagram UML
versi 2.0 serta berada pada fase apa diagram ini digunakan.
Tabel 2.1. Per bedaan Diagr am UML versi 2.0
(Dennis, Wixon, dan Tegar den, 2005)

Diagr am

Digunakan Untuk

Pada Fase

Structure diagram (Diagr am Stuktur )
Class

Menggambarkan hubungan antar Analisa,
kelas yang dimodelkan dalam sistem Desain

Object

Menggambarkan hubungan antar
Analisa,
obyek yang dimodelkan dalam
Desain
sistem

Package

Mengelompokkan diagram UML
yang lain dan digunakan bersama
untuk membuat konsep dengan level
yang lebih tinggi

Deployment

Menunjukkan arsitektur fisik sistem.
Dapat juga digunakan untuk
Desain fisik,
menunjukkan komponen software
Implementasi
yang dikembangkan pada arsitektur
fisiknya.

Component

Menggambarkan hubungan fisik di
antara komponen software

Composite
Structure

Menggambarkan struktur internal
Analisa,
dari kelas (hubungan antar bagian
Desain
dalam kelas)

Analisa,
Desain,
Implementasi

Desain fisik,
Implementasi

Behaviour diagram (Diagr am per ilaku)

Activity

Menggambarkan aliran bisnis dari
sebuah kelas, aliran aktifitas dalam Analisa,
sebuah usecase, atai desai detin dari Desain
sebuah method

Sequence

Memodelkan perilaku obyek dalam
sebuah use case. Lebih menekankan Analisa,
pada urutan berdasarkan waktu dari Desain
sebuah activity / aktifitas

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

16

Communication

Memodelkan perilaku obyek dalam
sebuah use case. Lebih menekankan
Analisa,
pada
komunikasi
di
antara
Desain
sekumpulan
obyek
yang
berkolaborasi dalam sebuah activity

Interaction
Overview

Mengilustrasikan sebuah gambaran
Analisa,
umum dari aliran control sebuah
Desain
proses.

Timing

Menggambarkan interaksi yang
terjadi antara sekumpulan obyek dan Analisa,
perubaha penyataan atau state yang Desain
terjadi berdasarkan waktu tertentu

Behavioural
State Machine

Memeriksa perilaku dari sebuah Analisa,
kelas
Desain

Protocol State
Machine

Menggambarkan
hubungan
Analisa,
antarmuka yang berbeda dari sebuah
Desain
kelas

Use Case

Menangkap kebutuhan bisnis dari
sistem dan menggambarkan interaksi Analisa
antara sistem dan lingkungan sistem.

2.6.1. Use-Case Diagram
Menurut Dennis, Wixon, dan Tegarden (2005) Use Case diagram
merupakan diagram yang menggambarkan fungsionalitas aplikasi yang akan
diterapkan. Use case diagram menjelaskan manfaat sistem jika dilihat
menurut pandangan orang yang berada diluar sistem. Dalam merancang
sebuah use case, penekanannya adalah “apa” yang dilakukan sistem dan
bukan “bagaimana” sistem melakukan. Sebuah use case merepresentasikan
interaksi yang terjadi antara pelaku atau (actor) dengan sistem.
Use case diagram sangat membantu dalam merancang sebuah sistem
karena dapat memberikan requirement software yang menggambarkan

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

17

fungsionalitas yang penting secara arsitektural dari software yang akan
dibuat. Contoh dari use case diagram, dapat dilihat pada Gambar 2.3

Membuat PR
Review PR

Membuat dokumen PO
Bagian Pembelian


Manajer

Posting ke Stok

Mencetak dokumen PO

Gambar 2.3 Contoh Use Case Diagram
Komponen dari usecase diagram, yaitu :
a. Actor (Aktor)
Aktor merupakan bagian luar sistem. Ia merupakan sebuah peran yang
dapat dimainkan oleh user ketika berinteraksi dengan sistem. Seorang aktor
dapat merepresentasikan orang atau sistem lain yang berinteraksi dengan
sistem yang berjalan. Sebuah aktor dapat memberikan input kepada sistem,
menerima output dari sistematau melakukan keduanya.
b. Association (Asosiasi)
Use case dan aktor dihubungkan melalui hubungan asosiasi yang
menunjukkan aktor akan berinteraksi dengan use case yang mana.
c. Usecase
Usecase merupakan proses utama yang akan dilakukan sistem dan ia
diberikan nama dengan menggunakan kata kerja

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

18

d. Subject Boundary (Batasan Sistem)
Merupakan sebuah kotak yang menjelaskan lingkup atau batasan sebuah
sistem dan menjelaskan mana yang merupakan bagian eksternal atau internal
sistem.Sebuah subject boundary dapat digunakan untuk memisahkan sebuah
sistem dengan lingkungannya, subsistem dengan subsistem yang lain, dalam
sebuah sistem software. Aktor digambarkan diluar subject boundary
Tabel 2.2. Notasi Usecase Diagr am
(Dennis, Wixon, dan Tegar den, 2005)

Akt or

Usecase

Subject boundary

Hubungan asosiasi

Hubungan include

Hubungan ext end

Hubungan generalisasi

2.6.2. Usecase Description
Usecase description merupakan penggerak utama dari semua teknik
pendiagraman UML. Usecase berbicara pada level tinggi, yaitu menjelaskan

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

19

apa yang perlu dilakukan sebuah sistem dan kemudian diagram lain dalam
UML akan membangun fungsionalitas sistem berdasarkan informasi yang
diberikan usecase dengan cara yang berbeda sesuai dengan tujuan masingmasing diagram.
Menurut Dennis, Wixon dan Tegarden (2005) Usecase description
berisi informasi detil apa yang perlu dilakukan sistem. Informasi dalam
usecase description diperlukan untuk membuat usecase diagram atau lebih
mendetilkan informasi dalam usecase diagram. Meskipun memungkinkan
untuk melewati tahap usecase description dan langsung menuju tahap use
case diagram. dan membangun diagram yang lain, namun user seringkali
mengalami kesulitan dalam menggambarkan proses bisnis mereka dengan
hanya menggunakan usecase diagram

Dengan menggunakan usecase

description, user dapat mendekripsikan kebutuhan detil dari masing-masing
usecase.
Mengenai diagram apakah yang terlebih dahulu dibuat, apakah
usecase diagram ataukah usecase description bukan menjadi masalah. Kedua
diagram perlu dibuat untuk mendeskripsikan secara utuh kebuthan fungsional
dari sistem informasi

Use Case name :

ID :

Importance level :

Primary actor :

Use case Type : Detil, Essent ial

St akeholders and int erest :
Brief description :
Trigger :

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

20

Type :
Relat ionships :
Associat ion :
Include : Extend : Generalizat ion : Condit ion:
Pre Condit ion:
Post Condit ion:
Normal flow of event s :

1.
2.
Subflows :

-Alt ernat e/ except ional flow s :

Gambar 2.4 Template Usecase descr iption

Elemen Usecase description, yaitu :
1. Overview Information
Informasi umum mengidentifikasi usecase dan informasi dasar mengenai
latar nbeakang sebuah usecase. Yaitu terdiri dari :
a. Usecase Name
Nama usecase, harus berbentuk frase yang terdiri darai kata kerja dan
kata benda (missal : membuat janji)
b. Usecase ID number

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

21

Nomor

ID

Usecase

merupakan

metode

penomoran

usecase.

Penomoran ini adalah cara untuk membuat usecase unik, serta
berfungsi agar tim dapat mencari sebuah desain yang dilakukan
berdasarkan usecase yang mana. Diisi dengan
c. Usecase Type
Tipe Usecase dapat berupa overview atau detail serta essential atau
real
d. Primary Actor
Aktor Primer merupakan orang atau benda yang memulai sebuah
eksekusi usecase. Tujuan utama usecase adalah untuk memenuhi
tujuan primary actor
e. Stakeholder and interest
Sebuah kalimat yang menggambarkan esensi usecase
f. Importence level
Level kepentingan digunakan untuk melakukan prioritas pada usecase.
Apabila menggunakan metode RAD, maka Importence level akan
menunjukkan prioritas fungsi bisnis mana yang paling utama dan akan
menjadi versi pertama dari sistem yang terlebih dahulu dibangun.
Level kepentingan dapat berupa high, medium dan low atau dapat
berupa angka 1-5 yang menunjukkan kepentingan.
g. Trigger
Trigger adalah kejadian yang menyebabkan usecase dimulai.

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

22

2. Relationship (Hubungan Antar Usecase)
Menjelaskan Bagaimana usecase yang terhubung dengan usecase lain atau
user. Tipe dasar relationship , yaitu :
a.

Extend relationship
Menampilkan perluasan fungsionalitas usecase terhadap pilihan

perilaku perusahaan, juga menggambarkan variasi dari perilaku normal.



Konsultasi FRS

Melebihi batas Jumlah SKS

Gambar 2.5 Contoh extend r elationship

Dalam gambar tersebut dapat diketahui bahwa usecase melebihi
batas jumlah SKS merupakan kejadian khusus atau variasi dari usecase
konsultasi FRS dan akan dieksekusi hanya ketika Mahasiswa melebihi
batas Jumlah SKS
b.

Include relationship
Merupakan perintah terhadap usecase lain. Misal usecase X include

usecase Y, maka usecase Y merupakan syarat untyuk melakukan usecase
X atau usecase Y harus dilakukan terlebih dahulu sebelum melakukan
usecase X.



Ambil uang

Validasi Customer

Gambar 2.6 Contoh Include Relationship

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

23

Dalam gambar dapat diketahui bahwa Usecase validasi Customer
harus dilakukan sebelum melakukan Usecase ambil uang.
c.

Generalization relationship
Mendukung inheritance, yaitu adanya usecase atau user khusus yang

mewarisi sifat usecase atau user umum, sebagai.

Tutup Buku

Tutup Buku Harian Tutup Buku Bulanan Tutup Buku Tahunan

Gambar 2.7 Contoh Gener alization Relationship

Maka usecase Tutup Buku Harian, Bulanan, dan Tahunan
meruipakan Usecase specialized atau terspesialisasi dari usecase tutup
Buku dan memiliki sifat yang dimiliki oleh usecase Tutup Buku
3. Condition (Kondisi)
Merupakan suatu gambaran keadaan sebuah aktifitas proses yang terjadi
pada saat itu. Terdapat dua gambaran aktifitas :
a. Pre Condition
Merupakan sebuah gambaran keadaan sebuah aktitifitas pada saat
suatu proses belum dijalankan.
b. Post Condition
Merupakan sebuah gambaran keadaan sebuah aktifitas pada saat proses
telah dijalankan. Dalam hal ini, post condition merepresentasikan goal
atau tujuan yang dicapai.

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

24

4. Flow of events (Aliran Kejadian)
Merupakan langkah-langkah menggambarkan bisnis proses. Terdapat tiga
kategori berbeda dari langkah atau aliran yang dapat didokumentasikan :
a. Normal Flow of events (Aliran Kejadian Normal)
Merupakan langkah yang dieksekusi secara normal dalam sebuah
usecase
b. Subflow (Aliran Kejadian Bagian)
Dalam beberapa usecase disarankan untuk melakukan dekomposisi
dari normal flow ke dalam beberapa subflow. Hal ini bertujuan untuk
membuat normal flow sesederhana mungkin
c. Alternate/ exceptional flow (Aliran Kejadian Pengecualian)
Merupakan langkah-langkah yang mungkin terjadi namun bukan
menjadi aturan yang harus dilakukan.
2.6.3.

Activity diagram
Menurut Sholiq (2006) diagram aktivitas (activity diagram)

merupakan salah satu cara untuk memodelkan aliran kejadian yang terjadi
dalam suatu use case. Diagram aktivitas bisa digunakan dalam pemodelan
bisnis untuk menggambarkan (workflow) yang ada dalam proses bisnis
(business use case). Diagram aktivitas juga bisa digunakan dalam
memodelkan aliran kejadian dalam use case sistem yang. Contoh dari
diagram aktivitas dapat dilihat pada Gambar 2.8

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

25

Bagian Layanan Pelanggan

Manaj er Departemen Kredit

Menerima
kredit

Set Batas Credit

Menghimpun informasi
pelanggan

Pelanggan

do/ Cek histori kredit pelanggan

membuat account
kredit baru
Review Credit
history

Account
Buka
do/ Buka

Account
Membatalkan
Account

do/ BARU

Account Batal
do/ Dibatalkan

Menyetujui
Account

Account Disetujui

Menandatangani
Surat perjanjian

do/ Disetujui

Gambar 2.8 Contoh Activity Diagram
2.6.4.

Sequence diagram
Sequence diagram merupakan diagram merupakan diagram yang

menggambarkan bagaimana sistem melakukan fungsionalitasnya dalam
berinteraksi dengan obyek yang ditampilkan dalam urutan waktu. Interaksi
yang terjadi antara sistem dan obyek dapat berupa instruksi atau pesan yang
berurutan. Contoh sequence diagram dapat dilihat pada Gambar 2.9

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

26

Gambar 2.9 Contoh Sequence Diagram
Sequence diagram umumnya digunakan untuk menggambarkan suatu urutan
langkah-langkah yang dilakukan oleh actor maupun sistem yang merespon
dari sebuah perintah kejadian untuk mendapatkan hasil atau output.
Tabel 2.3. Notasi Sequence Diagr am

Aktor
Merupakan orang atau sistem yang
mendapatkan keuntungan dari sistem
Merupakan bagian luar sistem
Berpartisipasi dalam sequence diagram
dengan mengirimkan atau menerima
pesan
Diletakkan pada posisi paling atas dari
diagram
Apabila berupa sistem maka digambarkan
dengan bentuk persegi panjang dan
keterangan di dalamnya.
Sebuah Obyek
Berpartisipasi dalam diagram sequence
dengan menerima atau mengirimkan
pesan
Diletakkan pada bagian atas diagram

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

27

Stereotype Class, yaitu :
1. Control Class
Digunakan untuk memodelkan perilaku
perilaku control dari satu atau lebih
usecase
Di class inilah Aturan bisnis dan aturan
diletakkan
Contohnya yaitu error handlers
2. Boundary Class
Class Boundary digunakan untuk
memodelkan interaksi di antara
lingkungan sekitar
sistem dan lingkungan dalam sistem
Aktor hanya dapat berkomunikasi dengan
kelas boundary
Biasanya berupa Halaman window, Form
input, halaman menu
3. Entity Object
Berfungsi memetakan tabel database
Digunakan untuk menyimpan dan
mengelola informasi dalam sistem

Lifeline
Menunjukkan lama Hidup sebuah obyek
dalam sequence diagram
Apabila class tak lagi berinteraksi atau
digiunakan maka ditambahkan X di
bagian bawahnya
Execution Occurance
Diletakkan pada bagian atas lifeline
Menunjukkan bahwa obyek sedang
mengirimkan atau menerima pesan
Message
Menyampaikan informasi dari satu obyek
menuju obyek lain

aMessage()

Return Value

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

28

Object Destruction
Sebuah “X” diletakkan pada bagian bawah
lifeline obyek ketika keberadaan obyek
tersebut tidak lagi diperlukan
Frame
Cont ext

Menunjukkan konteks Sequence diagram

Hal lain yang perlu diperhatikan dalam membangun diagram sequence adalah
aturan dalam penggunaan Class yaitu ;
1. Seorang aktor hanya boleh berinterksi dengan boundary dan tidak boleh
berinteraksi dengan control class ataupun entity object

Gambar 2.10 Atur an Penggunaan Class Aktor dalam Sequence diagr am

2. Sebuah boundary class hanya dapat berinterksi dengan control class.
Boundary tak boleh berinteraksi dengan entity ataupun boundary class
yang lain

Hak Cipta © milik UPN "Veteran" Jatim :
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan dan menyebutkan sumber.

29

Gambar 2.11 Atur an Penggunaan class boundar y dalam sequence diagr am

3. Sebuah control class dapat berinteraksi dengan class yang lain

Gambar 2.12 Atur an Penggunaan class contr ol dal