MODUL

PRAKTIKUM

PROGRAM STUDI TEKNIK

INFORMATIKA UPN
VETERAN AWA TIMUR

SURABA
YA
201
5

MODUL PRAKTIKUM ANALISA DAN DESAIN SISTEM INFORMASI

LABORATORIUM DESAIN DAN BASIS DATA PRODI TEKNIK
INFORMATIKA UPNJATIM

BAB I ANALISA
SISTEM
Tujuan Instruksional Khusus :
- Praktikan mampu menjelaskan konsep analisis sistem dan menghubungkannya
dengan istilah fase definisi lingkup, analisis masalah, desain logis dan analisis keputusan
metodologi pengembangan sistem.
- Praktikan mampu mendeskripsikan sejumlah pendekatan analisis sistem
untuk memecahkan masalah-masalah sistem.
- Praktikan mampu mendeskripsikan fase definisi lingkup, analisis masalah,
analisis persyaratan, desain logis dan analisis keputusan dalam artian tujuan, input,
output, teknik dan langkah bahkan hingga artian blok-blok pembangun sistem.
1. 1.

Analisis Sistem

Analisis sistem adalah sebuah tehnik pemecahan masalah yang menguraikan sebuah
sistem menjadi bagian-bagian komponen dengan tujuan mempelajari seberapa bagus bagianbagian komponen tersebut bekerja dan berinteraksi untuk meraih tujuan. Analisis
sistem dikendalikan oleh kepedulian bisnis para pemilik sistem (system owners) dan
pengguna sistem (system users). Sedangkan para analis sistem berperan sebagai
fasilitator dalam analisis sistem. Terdapat lima fase dalam analisis sistem yang akan dibahas
yaitu :
- Fase Ruang Lingkup
- Fase Analisis Masalah
- Fase Analisis Kebutuhan
- Fase Desain
- Fase Analisis Keputusan
1. 1. 1. Fase Ruang Lingkup
Fase ruang lingkup bisa juga disebut dengan fase penyelidikan, fase studi awal atau
fase perencanaan. Fase ruang lingkup menetapkan kelayakan, skala, strategi pengembangan,
jadwal, sumber daya dan anggaran. Dalam fase ini terdiri dari beberapa pekerjaan lagi,
antara lain :
- Mengidentifikasi masalah-masalah dan kesempatan-kesempatan titik tolak.
Tugas ini menentukan titik tolak awal masalah-masalah, kesempatan-kesempatan
dan atau perintah yang memicu proyek. Contohnya urgensi, visibilitas,
keuntungan,
prioritas atau solusi-solusi yang mungkin.
- Menegosiasikan lingkup
Mendefinisikan batasan-batasan proyek, aspek-aspek bisnis yang akan atau tidak
dimasukkan dalam proyek. Contohnya seperti tipe-tipe data, proses-proses bisnis atau
bahkan antarmuka.
- Menilai kelayakan proyek
Menentukan apakah proyek ini layak dikerjakan, memecahkan masalah,
mengeksploitasi kesempatan atau minimal bisa mengembalikan nilai yang
dikeluarkan untuk proyek.
- Mengembangkan jadwal dan anggaran

Setelah dianggap layak, rencana proyek paling tidak harus terdiri dari rencana
induk pendahuluan yang tediri dari jadwal penugasan sumber daya untuk keseluruhan
dan rencana dan jadwal terinci untuk menyelesaikan fase selanjutnya yaitu fase analisis
masalah.
Mengkomunikasikan rencana proyek
Perlu adanya seseorang atau bagian yang menyetujui dan memonitor proyek dan
pengembangan. Para manajer sistem informasi berperan untuk
menjawab
pertanyaan- pertanyaan dan mengkomunikasikan prioritas-prioritas kepada para
pengembang dan manajer proyek.

1. 1. 2. Fase Analisis Masalah

Tujuan fase ini adalah mempelajari dan memahami bidang masalah dengan
cukup baik untuk secara menyeluruh menganalisis masalah, kesempatan dan batasannya.
Fase analisis masalah terdiri dari beberapa tugas, antara lain :
- Memahami bidang masalah
Beberapa pendekatan yang dapat digunakan sebagai kerangka untuk mendaftar
dan mendefinisikan bidang sistem antara lain pengetahuan, proses dan
komunikasi.
- Menganalisis masalah dan kesempatan
Pemahaman akan bidang masalah sangatlah krusial karena anggota tim
seharusnya tidak mencoba menganalisis masalah-masalah kecuali mereka memahami
bidang tempat masalah-masalah tersebut muncul. Produk dari tugas ini dapat
berupa pernyataan masalah dan analisis sebab-akibat yang diperbarui untuk tiap masalah
dan kesempatan.
- Menganalisis proses bisnis
Tugas ini hanya cocok untuk proyek business process redesign / desain ulang
proses bisnis atau proyek pengembangan sistem yang dibangun pada atau membutuhkan
desain ulang proses bisnis yang signifikan. Produk dari tugas ini adalah model proses
dan analisis proses yang sedang berjalan, yang dapat secara signifikan dilengkapi
dengan volume data yang mengalir selama proses, waktu respon tiap proses, dan
penundaan/ hambatan yang muncul dalam sistem.
- Menentukan tujuan-tujuan perbaikan sistem
Tujuan dari tugas ini adalah menentukan kriteria dimana semua perbaikan pada
sistem akan diukur dan untuk mengidentifikasi semua batasan yang membatasi
fleksibilitas semua perbaikan tersebut. Contoh dari perbaikan sistem yaitu
Kurangi pengurangan piutang sebesar 20% dengan cara mengenali sesegera mungkin
jumlah penunggak.
- Memperbarui atau mengasah proyek
Kemungkinan bahwa tidak semua sasaran dapat dipenuhi oleh sistem yang baru.
Tugas ini digerakkan oleh kelengkapan sasaran perbaikan sistem, rencana proyek dan
rencana proyek yang sudah diperbarui.
- Mengkomunikasikan penemuan-penemuan dan rekomendasi-rekomendasi
Tugas ini dipicu oleh penyelesaian rencana proyek yang sudah diperbarui dan
input informasi yang meliputi analisis masalah, model sistem, sasaran
peningkatan
sistem. Format dapat berupa sebuah laporan, presentasi verbal atau berupa pemeriksaan
oleh auditor atau peer group.
1. 1. 3. Fase Analisis Persyaratan
Fase analisis persyaratan menentukan persyaratan bisnis bagi sistem yang baru.
Sudut pandang yang digunakan dalam fase ini adalah beberapa alternatif solusi khususnya
solusi teknis. Fase ini mencakup beberapa tugas, antara lain :

Mengidentifikasi dan menyatakan persyaratan sistem

Menerjemahkan sasaran-sasaran ke dalam functional requirement yaitu deskripsi
mengenai aktifitas dan layanan yang harus diberikan/ disediakan oleh sebuah sistem dan
nonfunctional requirement yaitu deskripsi mengenai fitur, karakteristik dan batasan
lainnya yang menentukan apakah sistem memuaskan atau tidak.
Membuat prioritas persyaratan sistem
Setelah persyaratan-persyaratan sistem dibuat maka perlu adanya sebuah
prioritas persyaratan
yang
difasilitasi
menggunakan
timeboxing
yaitu
sebuah teknik
menyampaikan fungsionalitas dan persyaratan sistem informasi melalui versi-versi. Tim
pengembangan memilih subset terkecil dari sistem tersebut, yang jika
diimplementasikan
secara penuh akan memberikan nilai yang berguna bagi pemilik dan pengguna sistem.
Subset tersebut dikembangkan idealnya dengan kerangka waktu 6 sampai 9 bulan atau
kurang. Dengan demikian, versi yang bernilai tambah dari sistem juga dikembangkan
dalam kerangka waktu yang sama.
Memperbarui atau memperhalus rencana proyek
Tim harus mempertimbangkan kemungkinan bahwa sistem baru mungkin lebih
besar daripada yang semula diharapkan. Tugas ini dipicu oleh selesainya kelengkapan
prioritas dan persyaratan dengan rencana proyek yang up-todate sebagai input kunci.
Mengkomunikasikan pernyataan persyaratan
Pada tugas ini analis harus mengkomunikasikan persyaratan dan prioritas kepada
komunitas bisnis secara terus menerus. Ketrampilan antarpersonal, komunikasi
dan
negoisasi sangatlah penting dalam tugas
ini.

1. 1. 4. Fase Desain Logis

Fase ini mendokumentasikan persyaratan bisnis dengan menggunakan model-model
sistem yang menggambarkan struktur data, proses bisnis, aliran data dan antarmuka
pengguna. Fase desain logis umumnya mencakup tugas-tugas lain, antara lain :
- Menstruktur persyaratan fungsional
Menggambar atau memperbarui satu atau lebih model sistem untuk
menggambarkan persyaratan fungsional yang mencakup kombinasi data, proses
dan
model objek yang secara akurat menggambarkan persyaratan bisnis dan persyaratan
pengguna.
- Prototipe persyaratan fungsional
Dengan prototipe dapat memberikan sebuah alternatif untuk pemodelan sistem
sehingga dapat membantu pengguna jika mengalami kesulitan untuk menyatakan faktafakta yang diperlukan untuk menggambar model sistem yang tepat.
- Validasi persyaratan fungsional
Model sistem dan prototipe memerlukan validasi dalam hal kelengkapan
dan kebenarannya. Analis sistem memfasilitasi tugas penyusunan prioritas dengan
secara
interaktif menyatukan pengguna sistem untuk mengidentifikasi kesalahan dan kelalaian
atau untuk membuat klarifikasi.
- Menentukan penerimaan test case
Test case digunakan untuk menguji program dalam hal kebenarannya. Hal ini
dilakukan dengan memvalidasi antara analis sistem dengan pengguna
sistem.
1. 1. 5. Fase Analisis Keputusan

Tujuan fase ini adalah untuk mengenali solusi kandidat, menganalisa solusi kandidat
tersebut dan merekomendasikan sebuah sistem target yang akan dirancang, dibangun dan
diimplementasikan. Hasil akhir dari fase ini adalah Proposal Sistem yang akan
memenuhi

persyaratan bisnis yang telah diidentifikasi pada fase sebelumnya. Fase analisis
keputusan umumnya mencakup tugas berikut :
- Mengidentifikasi solusi kandidat
Solusi kandidat akan diketahui melalui ide-ide dan berbagai opini tentang
perancangan dari pemilik sistem, pengguna sistem, desainer maupun konsultan teknis.
Tugas ini hanya untuk menentukan solusi kandidat yang mungkin dapat
dipertimbangkan.
- Menganalisa solusi kandidat
Analisis ini dapat dilakukan ketika masing-masing kandidat atau setelah semua
kandidat diidentifikasi. Analisis kelayakan seharusnya tidak terbatas biaya dan manfaat.
Terdapat empat kriteria ketika mengevaluasi solusi, antara lain; technical
feasibility, operational feasibility, economic feasibiliy dan schedule feasibility.
- Membandingkan solusi kandidat
Setelah analisis kelayakan telah dilengkapi maka dapat dibandingkan kandidat
- kandidat dan memilih satu atau lebih solusi untuk merekomendasikannya kepada
pemilik sistem dan pengguna sistem. Hasil akhir dari tugas ini adalah sebuah solusi
yang direkomendasikan, namun jika terdapat lebih dari satu solusi maka prioritas tetap
harus diterapkan.
- Memperbarui rencana proyek
Tugas ini dipicu oleh penyelesaian solusi untuk direkomendasikan. Jadwal proyek
dan penugasan sumber daya terbaru harus ditinjau kembali dan diperbarui dengan
output kunci adalah rencana proyek yang diperbarui.
- Merekomendasikan solusi sistem
Dalam tugas ini tim merekomendasikan solusi sistem kepada komunitas bisnis.
Analis sistem harus mampu menuliskan laporan bisnis tertulis dan membuat
sebuah presentasi bisnis tanpa harus masuk pada isu-isu teknis atau alternatif.
1. 2.

Penemuan Fakta

Untuk mengembangkan sistem yang efektif diperlukan teknik untuk

mengidentifikasi, menganalisis dan memahami persyaratan sistem yang disebut dengan
requirement discovery yang menghasilkan system requirements yang menentukan apa yang
seharusnya dikerjakan oleh sistem informasi atau properti serta kualitas apa yang harus
dimiliki oleh sistem. System requirement harus memiliki beberapa kriteria antara lain;
Konsisten, Komplet, Kelayakan, Dibutuhkan, Akurat, Dapat Dilacak dan Dapat Diuji.
Setelah system requirement dibuat, selanjutnya perlu adanya sebuah model proses yang
tidak dapat dibuat tanpa fakta dan informasi tepat yang dikirim oleh komunitas
pengguna. Fakta tersebut dapat dikumpulkan melalui sejumlah teknik seperti sampling
terhadap form dan file yang ada, riset terhadap sistem yang serupa, survei terhadap
pengguna dan manajemen, wawancara pengguna dan manajemen. Terdapat juga metode
tercepat dalam pengumpulan fakta dan informasi dan secara serempak membuat dan
menguji model proses disebut joint requirements planning.
1. 3.

Tugas 1

Lakukan proses analisis sistem terhadap studi kasus yang telah ditentukan, meliputi
fase ruang lingkup, fase analisis masalah, dan fase analisis persyaratan. Lengkap juga
dengan bisnis proses dan bisnis workflow.

BAB II
DATA FLOW DIAGRAM
Tujuan Instruksional Khusus :
Mahasiswa mampu mendesain dan memodelkan seluruh arsitektur aplikasi sistem informasi
yang berfokus kepada model proses fisik dengan memanfaatkan diagram alir data fisik.
2. 1.

Konsep Sistem untuk Pemodelan Proses

Sebagian besar teknik analisis sistem berasal dari aplikasi teori sistem formal
dan konsep terhadap pemecahan persoalan sistem yang biasa dikenal dengan system
thinking.
2. 1. 1. Konsep Proses
Proses sistem informasi merespons kejadian dan kondisi bisnis dan
mentransformasi data menjadi informasi yang berguna.
Sistem adalah proses
Dalam analisis sistem, model digunakan untuk menampilkan dan menyajikan
sistem. Beberapa simbol model proses dapat dilihat pada Gambar 1. Proses adalah
kerja yang dilakukan pada atau sebagai respons terhadap aliran data masuk atau kondisi.

Nama Proses

Nama Proses

Nama Proses

De Marco/ Yurdon

Gane & Sarson

(yang digunakan)

SSADM / IDEF (0)

Gambar 1. Beberapa notasi proses

Dekomposisi proses adalah kegiatan menguraikan sistem menjadi subsistem,

proses dan subproses komponennya. Dengan dekomposisi memungkinkan mempartisi
sistem menjadi subsistem logika dari proses untuk peningkatan komunikasi, analisis dan
desain. Beberapa aturan dalam melakukan dekomposisi sistem, antara lain :
Tiap proses dalam diagram dekomposisi merupakan proses induk dan proses anak
atau keduanya.
Induk harus memiliki dua anak atau lebih satu anak tunggal tidak masuk akal
karena tidak akan menunjukkan detail tambahan mengenai sistem tersebut.
Dalam sebagian besar standar pendiagraman dekomposisi satu anak dapat
hanya memiliki satu induk.
Anak dari satu induk dapat menjadi induk dari anak-anaknya sendiri
Selain itu terdapat batasan pada proses logika:
Hanya kata kerja perintah kuat yang dapat digunakan
Hanya nama yang telah didefinisikan dalam istilah proyek yang dapat digunakan
Rumusan harus dinyatakan secara jelas dengan menggunakan notasi matematis yang
tepat
Kata sifat dan kata keterangan yang tidak terdefinisikan tidak diperbolehkan,
kecuali jika didefinisikan secara jelas dalam istilah proyek
Jika mengalami keraguan, maka kemudahan baca bagi pengguna harus
diprioritaskan daripada preferensi programer

2. 1. 2. Aliran data
Aliran data adalah komunikasi antara proses dan lingkungan sistem yang
menunjukkan input data ke proses atau output data dari proses. Disimbolkan seperti
pada Gambar 2.
Nama aliran data

Gambar 2. Simbol Aliran Data

Terdapat beberapa aturan mengenai aliran data baik itu dengan proses
maupun dengan data store, yang ditunjukkan seperti pada Tabel 1.
Aliran Data Ilegal
P1

Tabel 1. Aliran Data Ilegal

Aliram Data Legal
P1

P1

P1

P1

Data Store

Data Store

Data Store

Sebuah proses
dibutuhkan untuk
mengubah aliran data
di antara agen
eksternal

Sebuah proses
dibutuhkan untuk
menggunakan sebuah
data store

P1

Data Store

Sebuah proses

P1
Data Store

dibutuhkan untuk
menyajikan data dari
sebuah data store

Data Store

Sebuah proses
dibutuhkan untuk
memindahkan data
dari data store ke data
store lain

P1

Data Store

Data Store

2. 1. 3. Agen Eksternal
Agen eksternal yang termasuk dalam lingkungan sistem membentuk batasan
sistem dan mendefinisikan tempat di mana sistem berhadapan dengan lingkungannya.
Hal ini bisa berupa orang, unit organisasi, sistem lain atau organisasi lain, yang berada di
luar lingkup proyek tetapi berinteraksi dengan sistem yang sedang dikembangkan atau
dipelajari. Contohnya adalah departemen, pengguna akhir atau sistem informasi
lain. Gambar 3 adalah simbol dari agen eksternal.
Agen
AgenEksternal
Eksternal

Agen
Eksternal

Gambar 3. Simbol Agen Eksternal

Agen eksternal sebaiknya dinamai dengan kata benda tunggal yang deskriptif
seperti supplier, financial system atau pengguna.
2. 1. 4. Data Store
Data store digunakan sebagai penyimpanan data yang ditujukan
untuk penggunaan selanjutnya. Simbol untuk data store dapat dilihat pada Gambar 4.

Data Store

Gambar 4. Simbol Data Store

2. 2.

Model Proses

Analis sistem harus mempelajari bagaimana menggambarkan diagram dekomposisi

dan aliran data untuk memodelkan persyaratan proses bisnis.
2. 2. 1. Diagram Aliran Data Konteks
Untuk membuat diagram aliran data konteks diperlukan adanya lingkup proyek yang
mendefinisikan aspek bisnis yang harus didukung oleh sistem atau aplikasi dan bagaimana
sistem yang dimodelkan berinteraksi dengan sistem lain dan bisnis lain secara keseluruhan.
Selanjutnya, disarankan untuk tidak menunjukkan semua input dan output antara sistem dan
bisnis dan dunia luar. Cukup dengan menunjukkan aliran data yang menyatakan tujuan
utama atau input output yang paling penting dari sistem tersebut.
Terdapat beberapa strategi yang harus dipertimbangkan dalam membuat
diagram aliran data konteks, yaitu :
- Pikirkan sistem sebagai kontainer untuk dapat membedakan antara bagian dalam
dan bagian luarnya.
- Tanyalah pengguna akhir sistem anda, transaksi bisnis seperti apa yang harus
direspon oleh sistem.
- Tanyalah pengguna akhir anda, respons apa yang harus dihasilkan sistem.
- Identifikasi tiap data store eksternal.
- Gambar diagram konteks dari semua informasi sebelumnya.
2. 2. 2. Diagram Sistem
Diagram sistem menyajikan konteks yang berarti bagi pengguna untuk mensahkan
akurasi tiap kejadian yang harus direspons sistem. Kejadian tersebut secara kolektif
mendefinisikan sistem dan subsistem.
2. 3.

Tugas 2

Buatlah model proses beserta aliran data (DFD / Data Flow Diagram) sedetail
mungkin terhadap studi kasus sistem yang telah ditentukan dan sesuaikan dengan
analisis yang telah dilakukan pada tugas sebelumnya.

MODUL 3
DETAIL DATA FLOW DIAGRAM
Tujuan Instruksional Khusus :
1. Mahasiswa mengetahui konsep dasar Kamus Data dan Isi Kamus Data
2. Mahasiswa diharapkan dapat menggunakan masing-masing Kamus Data dan

Struktur

Data sesuai dengan sistem yang sedang mereka kembangkan

3.1 Kamus Data
Kamus data (KD) atau data dictionary (DD) atau disebut juga dengan ist
ilah systems data dictionary adalah katalog fakta tentang data dan kebutuhan
kebutuhan informasi dari suatu sistem informasi. Dengan menggunakan KD, analis
sistem dapat mendefinisikan data yang mengalir di sistem dengan lengkap. KD
dibuat pada tahap analisis sistem dan digunakan
baik
pada
tahap
analisis
maupun
pada
tahap perancangan sistem. Pada tahap analisis, KD dapat digunakan
sebagai alat komunikasi antara analis sistem dengan pemakai sistem tentang data yang
mengalir di sistem, yaitu tentang data yang masuk ke sistem dan tentang
informasi yang dibutuhkan oleh pemakai sistem. Pada tahap perancangan sistem,
KD digunakan untuk merancang input, merancang laporan-laporan dan database. KD
dibuat berdasarkan arus data yang ada di DFD. Arus data di DFD sifatnya adalah
global, hanya ditunjukkan nama arus datanya saja. Keterangan lebih lanjut tentang
struktur dari suatu arus data di DFD secara lebih terinci dapat dilihat di KD. Kamus
data perlu ditambahkan pada data flow dan data store, untuk menjelaskan detail dari elemen
data agar semua stakeholder memiliki persepsi yang sama. Gambar 3.1 menunjukkan
hubungan antara DFD dengan KD. Serta contoh penambahan kamus data untuk data flow
(Gambar 3.2) dan data store (Gambar 3.3).
Data Dictionary (kamus data) untuk Data Flow meliputi
komponen: Nama
: Nama dari Data Flow di DFD
Deskripsi
: Penjelasan rinci (apa maksudnya)
Aliran
: Sumber dan tujuan (darimana dan kemana)
Periode
: Kapan terjadinya (waktu atau kejadian lain yang
memicu) Struktur
: Komposisi data, contoh:
Pelanggan = nama_pel + alamat_pel
nama_pel = karakter huruf = [A-Z | a-z]
alamat_pel = nama_jalan + nomor_rumah + nama_kota + (kode_pos)
nama_jalan = karakter huruf = [A-Z | a-z]
nomor_rumah = karakter angka + (karakter huruf) = [0-9] + (A-Z)
nama_kota = karakter huruf = [A-Z | a-z]
kode_pos = 5 digit karakter angka

Gambar 3.1 Hubungan antara Data Flow Diagram dan Kamus Data

Gambar 3.2 Kamus data untuk data flow.

Data Dictionary untuk Data Store, meliputi

komponen: Nama
: Nama dari Data Store di
DFD Deskripsi
: Penjelasan rinci (apa
maksudnya) Struktur
: Komposisi Tabel pada
DBMS, contoh:

Gambar 3.3 Contoh Kamus data untuk data store.

3.2 Spesifikasi Proses
Spesifikasi proses ditambahkan pada DFD level terendah. Spesifikasi proses digunakan
untuk menjelaskan detail prosedur elemen proses pada DFD level terendah agar semua
stakeholder memiliki persepsi yang sama. Selain itu, spesifikasi proses memudahkan
Programmer untuk membuat kode-kode program sesuai dengan yang dimaksud oleh System
Analyst. Komponen spesifikasi proses antara
lain: Nomor
: Nomor Proses
Nama
: Nama Proses
Deskripsi
: Penjelasan rinci (apa maksudnya)
Input
: Data Flow Input dan Asalnya Output
: Data Flow Output dan Tujuannya Struktur
:
Algoritma / prosedur detail dari Proses

Bentuk spesifikasi proses:

1. Common Style, bentuk umum / bebas yang mudah dipahami (bisa
menggunakan bahasa apapun).
2. Pseudocode, bentuk yang mirip dengan kode program, menggunakan bahasa
inggris yang terstruktur (Structured English).
3. Program Flowchart, bentuk diagram yang menggambarkan alur program (bagan alur).
Contoh spesifikasi proses bentuk common style
Mencatat Nama Mahasiswa
Mencatat NRP Mahasiswa
Untuk setiap mata kuliah yang diambil
Tampilkan nama dan sks mata kuliah
Hitung total sks sampai saat ini
Tampilkan Total Sks
Jika total sks lebih besar dari 18
Maka Tampilkan peringatan
Selainnya
Tampilkan persetujuan

Contoh spesifikasi proses bentuk Pseudocode

Read Nama Mahasiswa
Read NRP Mahasiswa
For each mata kuliah yang diambil
Print nama dan sks mata kuliah
total_sks = total_sks + sks
Print total sks
If total sks > 18
Then Print Peringatan
Else
Print Persetujuan

Contoh spesifikasi proses dapat dilihat pada Gambar 3.4.

Gambar 3.4 Contoh spesifikasi proses dengan bentuk flowchart.

MODUL 4
USE CASE DIAGRAM
Use Case Diagram menyajikan interaksi antara use case dan aktor. Dimana aktor dapat
berupa orang, peralatan atau sistem lain yang beinteraksi dengan sistem yang dibangun. Use
case menggambarkan fungsionalitas sistem atau persyaratan-persyaratan yang harus
dipenuhi sistem dari pandangan pemakai. Jika Business Use Case Diagram tidak
memperhatikan apakah proses dilakukan secara otomasi terkomputerisasi, maka Use Case
Diagram berfokus hanya pada proses otomatisasi saja.
Dalam bagian ini akan membahas tentang konsep dasar pemodelan use case
meliputi:
use case, actor dan relasi. Jika sudah memahami pemodelan bisnis, ada kemiripan
antara
pemodelan bisnis dan pemodelan use case. Perbedaanya adalah jika pada pemodelan bisnis
memfokuskan pada organisasi, sedangkan pemodelan sistem berfokus pada sistem yang
sedang dibangun. Perbedaan antara pemodelan bisnis dan pemodelan sistem :
Tabel 4.1. Perbedaan Pemodelan Bisnis dengan Pemodelan
Sistem
Pemodelan Bisnis (Business
Pemodelan Sistem (Use
Item
Use Case)
Case)
Menjelaskan apa yang
Menjelaskan apa yang
Use Case
bisnis kerjakan
sistem lakukan di bisnis
Eksternal terhadap sistem
Eksternal terhadap
(mungkin internal terhadap
Aktor
organisasi
sistem)
Pekerja Bisnis Internal terhadap organisasi Tidak digunakan
4.1. Use Case
Use Case adalah bagian tingkat tinggi dari fungsionalitas yang disediakan oleh
sistem. Dengan kata lain, use case menggambarkan bagaimana seseoarang menggunakan
sistem.
Untuk mengidentifikasi use case, kita menjawab pertanyaan : apa yang sistem
lakukan terhadap dunia sekelilingnya?. Dalam UML, use case dimodelkan dengan
menggunakan
ikon:

Gambar 4.1. Notasi Use Case

Use case adalah independen terhadap implementasinya dan pandangan tingkat
tinggi apa yang pemakai harapkan dari sistem. Dengan penjelasan sebagai berikut :
1. Use case adalah independen terhadap implementasinya. Selama membuat use case,
asumsikan bahwa anda sedang membangun sebuah sistem manual. Use case anada harus
mampu dibangun dalam Java, Visual Basic, C++, atau kertas. Use case berkonsentrasi
pada apa yang system harus kerjakan, bukan bagaimana sistem mengerjakannya.
2. Use case adalah pandangan tingkat tinggi apa yang pemakai harapkan dari sistem.
Use case yang sudah dikelompokkan memudahkan pelanggan memahaminya, pada level
yang sangat tinggi dari sustu sistem.
3. Use case difokuskan pada apa yang pengguna dapatkan dari sistem. Masing-masing use
case mempresentasikan transaksi lengkap antara pemakai dan sistem yang
menghasilkan manfaat terhadap pemakai.

Use case diberikan nama dalam termoniologi pemakai, bukan terminologi teknikal,
dan harus bermakna terhadap pelanggan. Nama sebuah use case adalah kata kerja atau frase
kata

kerja dengan format <kata kerja><kata benda> , dan menjelaskan apa yang
pelanggan
perhatikan
sebagai
hasil
akhir.
2.2. Actor
Actor adalah seseorang atau apa saja yang berhubungan dengan sistem yang
sedang
dibangun. Use Case menggambarkan semua yang ada dalam ruang lingkup sistem. Actor
merupakan semua yang ada di luar ruang lingkup sistem. Dalam UML, actor dimodelkan
dengan menggunakan ikon :

Gambar 4.2. Notasi Actor

Ada 3 tipe actor, yaitu :
1. Pengguna sistem
Actor secara fisik atau seotang pengguna. Ini adalah gambaran actor secara umum,
dan selalu ada pada setiap sistem. Untuk sistem sirkulasi perpustakaan, actor-nya adalah
orang-orang yang secara langsung menggunakan sistem. Ketika menamakan actor,
gunakan nama peranan dan jangan gunakan nama posisi. Posisi dapat berubah, tetapi
peranan dapat digantikan oleh siapa saja dan relatif tetap.
2.
Sistem lain yang berhubungan dengan sistem yang
dibangun
3. Waktu
Waktu dapat menjadi suatu actor ketika melalui sejumlah waktu tertentu memicu
beberapa kejadian dalam sistem.
Misalnya, bagian promosi memberikan
kesempatan pada pelanggan untuk memenangkan tiket gratis. Setiap hari pada pukul
03.00 dini hari, sistem secara otomatis menyeleksi secara acak pelanggan-pelanggan
untuk mendapatkan tiket gratis tersebut. Sebab waktu adalah di luar kendali kita, maka ia
dapat menjadi actor.
2.3. Relasi
Kita telah membahas use case dan actor, sekarang akan dibahas relasi antar use
case untuk mendapatkan sistem secara utuh.
Relasi asosiasi digunakan untuk menunjukkan relasi antara use case dan actor. Ada
tiga tipe relasi antara use case : relasi include, relasi extend, dan relasi generalisasi.
Sedangkan
relasi antara actor hanya digunakan satu relasi yaitu
generalisasi.

Relasi Assosiasi
Relasi antara actor dan use case adalah relasi assosiasi. Dalam UML, relasi assosiasi
digambarkan dengan menggunakan anak
panah.

Gambar 4.3. Relasi Assosiasi

Dalam contoh, use case mengawali komunikasi dengan actor sistem kredit. Selama
use case Purchase Ticket berjalan, sistem reservasi mengawali komunikasi dengan
sistem kredit untuk mengecek kartu dan melengkapi transaksi. Meskipun aliran informasi
terjadi dalam dua arah, dari reservasi sistem ke kartu kredit dan bolak-balik, arah panah
mengindikasikan siapa yang mengawali komunikasi. Dengan mengecualikan use case dalam
relasi include dan relasi extend, setiap use case harus diinisialisasi oleh actor.

Gambar 4.4. Relasi assosiasi dua actor

Relasi Include
Relasi include memungkinkan satu use case menggunakan fungsionalitas
yang
disediakan oleh use case lainnya. Relasi ini dapat digunakan dengan alasan salah satu
dari dua hal, yaitu :
1. Jika dua atau lebih use case mempunyai bagian besar fungsionalitas yang identik,
maka fungsionalitas ini dapat dipecah ke dalam use case tersendiri. Masing-masing
use case
kemudian menggunakan relasi include terhadap use case baru dibuat tersebut.
2. Relasi include bermanfaat untuk situasi jika sebuah use case mempunyai fungsionalitas
besar yang tidak umum. Relasi include digunakan untuk memodelkan dua buah use
case yang lebih kecil tersebut.
Relasi include meyatakan bahwa satu use case selalu menggunakan fungsionalitas
yang disediakan oleh use case lainnya.

Gambar 4.5. Relasi include

Relasi Extend
Relasi extend memungkinkan satu use case secara opsional menggunakan
fungsionalitas yang disediakan oleh use case lainnya. Dalam UML, relasi extend
digambarkan sebagai
berikut :

Gambar 4.6. Relasi extend

Relasi Extend
Relasi generalisasi digunakan untuk menunjukkan bahwa beberapa actor atau use
case
mempunyai beberapa persamaan. Sebagai contoh, ada dua tipe pelanggan : pelanggan
perusahaan dan pelanggan individu. Hal ini dapat dimodelkan dengan relasi ini
menggunakan notasi :

Gambar 4.7. Relasi generalisasi

Tutorial Use Case Diagram
1. Expand Use Case view. Double klik pada Main.

2. Gunakan toolbar untuk menambahkan Actor, Use Case ke dalam use case diagram.

3. Tambahkan relasi antara use case dan actor.

4. Untuk melihat Class Specification, double klik pada use case.

LATIHAN MODUL 4
1. Buatlah Business Use Case Diagram dari soal yang diberikan !

MODUL 5
ACTIVITY DIAGRAM
Activity diagram adalah cara lainnya untuk memodelkan aliran kejadian.
Menggunakan teks adalah bermanfaat, tetapi akan kesulitan membaca dan memahami jika
logika aliran kejadian sudah komplek.
Activity diagram menunjukkan informasi yang sama sebagaimana dalam aliran kejadian
dengan teks. Kita menggunakan Activity diagram dalam pemodelan bisnis
untuk menggambarkan aliran kerja (workflow) yang ada dalam proses bisnis.
Beberapa simbol yang digunakan antara lain :
Activity
Activity secara sederhana dapat diartikan sebagai langkah dalam proses. Dalam UML,
activity digambarkan sebagai berikut :
Menampilkan Form
Pinj am Buku

Gambar 5.1. Activity

Kita dapat menambahkan langkah-langkah detil ke dalam activity dengan
menggunakan aksi-aksi. Aksi-aksi adalah langkah-langkah lebih kecil dalam activity.
Mereka mungkin salah satu dari empat hal berikut ini :
1. Saat sedang memasuki activity. Aksi Entry (entry action) terjadi segera saat
activity
ini dimulai dan ditandai dengan kata entry.
2. Ketika sedang meninggalkan activity. Aksi exit (exit action) terjadi pada saat
meninggalkan activity dan ditandai dengan kata exit.
3. Ketika sedang berada dalam sebuah activity. Aksi ini terjadi saat di dalam
activity
dan selau terjadi hingga meninggalkan activity. Aksi ini ditandai dengan kata
do
4. Kejadian spesifik (specific event). Aksi ini terjadi jika dan hanya jika kejadian
spesifik terjadi. Aksi ini ditandai dengan kata event
Aksi-aksi tersebut opsional, tapi dapat memberikan informasi rinci yang
akan membantu untuk melengkapi rancangan sistem di kegiatan berikutnya.
Start dan End State
Start dan End state sebagaimana yang kita ketahui adalah untuk memulai
dan
mengakhiri flow. Setiap activity diagram harus mempunyai start state dan diakhiri
dengan end state. End state adalah opsional dan bisa lebih dari satu dalam satu Activity
diagram. Dalam UML, digambarkan sebagai berikut :
Start state

End state

Gambar 5.2. Notasi Start state dan End state

Obyek dan Aliran Obyek
Obyek adalah entitas yang digunakan dalam aliran. Obyek mungkin digunakan
atau
dirubah oleh activity dalam aliran. Pada Activity diagram, kita dapat menampilkan obyek
dan kondisinya, sehingga kita dapat memahami di mana dan bagaimana kondisi obyek
tersebut berubah.
Obyek dihubungkan ke activity menggunakan aliran obyek (object flow). Aliran
obyek

digambarkan dengan garis panah putus-putus. Jika garis panah mempunyai arah dari activity
ke obyek berarti ia memperbarui nilai obyek tersebut, dan jika arah panah dari obyek ke
activity berarti ia sedang menggunakan obyek.

Transisi
Transisi menunjukkan bagaimana aliran kontrol bergerak dari satu activity ke activity
lainnya. Transisi digambarkan menggunakan anak panah dengan nama transisi
menunjukkan nama kejadiannya.
Kejadian (event) memicu terjadinya transisi, kondisi (guard condition) mengontrol
ada atau tidak ada transisi yang terjadi, sebuah kondisi harus benar agar transisi dapat terjadi.
Sinkronisasi
Sinkronisasi adalah suatu cara untuk menunjukkan bahwa dua atau lebih cabang
dari aliran terjadi secara paralel.
Tutorial Activity diagram
1. Untuk membuat activity diagram, ditempatkan pada Use Case View. Klik kanan pada Use
Case View folder, pilih yang New / Activity diagram.

2. Atau juga bisa melalui, klik kanan pada Use Case, pilih yang Sub Diagram / New
Activity diagram.

3. Untuk menambahkan Guard Condition. Double klik pada Transisi, pilih tab detail
dan inputkan kondisinya.

LATIHAN MODUL 5
1. Buatlah Activity Diagram dari soal yang diberikan !

MODUL 6
SEQUENCE & COLLABORATION DIAGRAM
Dua tipe diagram interaksi yang akan dibahas dalam modul ini, yaitu sequence
diagram dan collboration diagram. Kedua diagram tersebut menunjukkan patisipasi
obyek-obyek dalam aliran yang melalui use case dan pesan tersebut akan dikirim antar
obyek-obyek. Dua tipe diagram interaksi yang dikenal dengan nama sequence diagram dan
collaboration diagram. Sequence diagram disusun berdasarkan urutan waktu, sedangkan
collaboration diagram diorganisasikan seputar obyek itu sendiri.
Langkah-langkah yang dilakukan untuk membuat sequence diagram dan collaboration
diagram adalah :
a) Menemukan obyek-obyek
b) Menemukan aktor
a. Menemukan obyek-obyek
Sebuah cara untuk menemukan obyek adalah dengan memeriksa kata benda
dalam aliran kejadian. Cara lainnya adalah dengan melihat dokumen skenario. Kebanyakan
use case
memiliki sejumlah sequence diagram atau collaboration diagram, satu untuk masingmasing skenario pada aliran kejadian. Diagram ini dapat dibangun dengan abstraksi
level tinggi,
untuk menampilkan bagaimana sistem berkomunikasi, atau pada level tinggi,
untuk menampilkan bagaimana sistem berkomunikasi, atau pada level yang sangat
rinci, untuk
menunjukkan kelas-kelas apa saja yang berpartisipasi salam skenario
tertentu.
Tidak semua obyek didapatkan dari aliran kejadian. Form misalnya, mungkin tidak
nampak dalam aliran kejadian, tapi akan nampak dalam diagram yang memungkinkan aktor
dapat memsukkan atau menampilkan informasi ke/dari sistem. Obyek lain yang
mungkin tidak nampak dalam aliran kejadian adalah obyek-obyek kontrol. Obyek-obyek
dapat dikategorikan sebgai berikut :
Obyek Entitas. Ini adalah obyek yang menangani informasi.. Mereka
mungkin memetakan beberapa tabel dan field ke dalam basis data. Beberapa kata dalam
aliran kejadian akan menjadi obyek entitas.
Obyek Pembatas (Boundary). Obyek yang terletak dalam sebuah pembatas antara
sistem dan lingkungannya.
Obyek kontrol. Obyek opitonal yang mengontrol aliran dalam use case.
Mereka mengkoordinasikan obyek-obyek dan kontrol keseluruhan logika aliran.
b. Menemukan aktor
Satu aktor dalam diagram interaksi adalah sebuah pemicu luar yang memulai
aliran kerja untuk aliran kejadian. Kita dapat mengidentifikasi sebuah aktor dengan
melihat pada
aliran kejadian dan menentukan siapa atau apa yang memulai
proses.
Sequence Diagram
Sequence diagram adalah diagram interaksi yang disusun berdasarkan urutan waktu.
Kita membaca Sequence diagram dari atas ke bawah. Setiap use case memiliki sebuah
aliran alternafit. Setiap sequence diagram mepresentasikan satu aliran dari beberapa
aliran di dalam use case.
Kita dapat membaca diagram ini dengan memperhatikan obyek-obyek dan pesan-pesan
yang ada di diagram. Obyek yang terlibat dalam aliran ditunjukkan dengan bujur
sangkar yang ada diatas diagram.
Collaboration Diagram

Sebagaimana Sequence diagram, collaboration diagram digunakan untuk

menampilkan aliran skenario tertentu dalam use case. Jika Sequence diagram disusun
berdasarkan waktu, collaboration diagram lebih konsentrasi pada hubungan antara obyekobyek.
Untuk alasan tertentu, kita dapat membuat Sequence diagram dan collaboration
diagram untuk sebuah skenario. Maskipun mereka mempunyai maksud dan menampilkan
informasi yang sama, masing-masing memberikan sedikit perbedaan dalam penampilannya.
Dalam tool Rational Rose, kedua diagram ini dapat saling dibangkitkan.
Tutorial Sequence Diagram
1. Klik kanan pada Package pilih New / Sequence Diagram

Tutorial Collaboration diagram

1. Untuk membuat collaboration diagram dapat secara otomatis dibuat jika sudah ada
Sequence diagram-nya. Klik Browse pada Menu kemudian Create collaboration diagram
atau dengan menekan tombol F5 dari keyboard.

LATIHAN MODUL 6
1. Buatlah Sequence Diagram dari soal yang diberikan !

MODUL 7
CLASS DIAGRAM
Class diagram digunakan untuk menampilkan kelas-kelas dan paket-paket di dalam
sistem. Class diagram memberikan gambaran sistem secara statis dan relasi anatar mereka.
Biasanya, dibuat beberapa class diagram untuk sistem tunggal. Beberapa diagram
akan menampilkan subset dari kelas-kelas dan relasinya. Dpaat dibuat beberapa diagram
sesuai dengan yang diinginkan untuk mendapatkan gambaran lengkap terhadap sistem yang
dibangun.
Class diagram adalah alat perancangan terbaik untuk tim pengembang. Diagram
tersebut membantu pengembang mendapatkan struktur sistem sebelum kode
ditulis, membantu untuk memastikan bahwa sistem adalah desain terbaik.
Kelas

Kelas adalah sesuatu yang membungkus informasi dan perilaku. Secara

tradisional,
sistem dibangun dengan ide dasar bahwa akan meyimpan informasi pada sisi basis data dan
data perilaku pengolahnya pada sisi aplikasi. Salah satu perbedaan terstruktur dengan
pendekatan berorientasi obyek adalah pada berorientasi obyek menggabungkan informasi
dan perilaku pengolah informasi dan menyembunyikan semuanya ke dalam sesuatu yang
disebut kelas. Dalam UML, kelas ditunjukkan menggunakan notasi sebagai berikut :

Gambar 7.1. Notasi Class

Bagian paling atas pada notasi Class digunakan sebagai nama kelas, dan secara
opsional juga digunakan stereotype-nya. Bagian tengah digunakan untuk menyimpan atribut,
dan bagian paling bawah digunakan menyimpan operasi.
Menemukan Kelas
Cara yang baik untuk menemukan kelas-kelas adalah dimulai dari
memperhatikan aliran kejadian (flow of event) dari suatu use case. Perhatikan kata benda
di dalam aliran
kejadian, mungkin merupakan salah satu dari empat hal
berikut:
Aktor
Kelas
Attribut dari kelas

Ekspresi, bukan aktor, bukan kelas, dan bukan

attribut.
Dengan melakukan seleksi kata benda dalam aliran kejadian, dapat ditemukan kelaskelas dalam sistem. Alternatif lainnya, dapat diuji obyek-obyek dalam sequence diagram
atau
collaboration diagram.
Ada dua cara yang biasa dilakukan berkaitan dengan urutan pendefinisian antar
kelaskelas dalam class diagram dan sequence diagram atau collaboration diagram. Yang pertama,
dengan membuat sequence diagram atau collaboration diagram lebih dulu kemudian
melanjutkannya dengan membuat class diagram. Sebaliknya, yang kedua, yaitu dengan
menemukan kelas-kelas dan membuat class diagram terlebih dulu, kemudian menggunakan
kelas-kelas tersebut sebagai kamus obyek-obyek dan relasinya untuk membuat sequence
diagram atau collaboration diagram.

Stereotype pada Kelas

Stereotype adalah sebuah mekanisme yang digunakan untuk mengkategorikan
kelas- kelas. Misalnya, dapat dibuat stereotype form lebih dulu, kemudian menentukan
kelas-kelas
di langkah selanjutnya. Fitur ini membantu untuk lebih memahami tanggung jawab
terhadap masing-masing kelas dalam model. Kelas-kelas dengan stereotype form
bertanggung jawab
menampilkan informasi ke pemakai dan menerima informasi dari pemakai.
Stereotype juga membantu dalam proses pembangkkitan kode. Ketika proses
pembangkitan kode, stereotype kelas menentukan tipe kelas yang akan dibawa ke
bahasa pemrograman.
Beberapa stereotype dapat digunakan sejak pada tahap proses analisis, pada saat
belum ditentukan bahasa pemrograman tertentu untuk membangkitkan kode. Stereotype
juga bisa
tergantung pada bahasa pemrograman yang dipilih dan digunakan pada tahap proses desain.
Ketika analisis, kelas-kelas dapat dikategorikan menurut fungsi yang mereka lakukan.
Ada 3 tipe stereotype kelas dalam UML yang digunakan pada analisis, yaitu : pembatas
(boundary), entitas (entity), dan kontrol.
a. Kelas-kelas pembatas
Kelas-kelas pembatas adalah kelas-kelas yang teletak di antara sistem dengan dunia
sekelilingnya. Semua form, laporan-laporan, antar muka (interfaces) ke perangkat lunak
seperti printer atau scanner, dan antar muka (interfaces) ke sistem lainnya adalah
termasuk dalam kategori ini. UML mepresentasikan kelas pembatas sebagai berikut :

BoundaryCl ass

Gambar 7.2. Notasi Kelas Pembatas

Untuk menemukan dan mengidentifikasi kelas-kelas pembatas dapat dilakukan
dengan menguji diagram use case. Minimal harus ada satu kelas pembatas untuk setiap
interaksi antara actor-use case. Kelas pembatas adalah apa saja yang
memungkinkan aktor berinteraksi dengan sistem.
Tidak perlu membuat kelas pembatas untuk setiap pasangan actor-use case. Sebagai
contoh, bila mempunyai dua aktor yang sama-sama menginisialisasi use case yang sama
untuk berkomunikasi dengan sistem.
b. Kelas-kelas entitas
Kelas-kelas entitas menangai informasi yang disimpan dalam peyimpanan
tetap.
Kelas entitas biasanya ditemukan dalam aliran kejadian (flow of event) pada diagram
interaksi. Mereka adalah kelas-kelas yang sebagian besar bermakna terhadap pemakai
dan secara tipikal diberikan nama menggunakan termonologi domain bisnisnya.
Perhatikan kata benda dalam aliran kejadian. Beberapa kata benda akan
menjadi
kelas entitas dalam sistem. Cara lainnya adalah dengan memperhatikan struktur
basis data. Jika rancangan basis data telah dibuat, perhatikan nama-nama tabel. Tabeltabel menangani beberapa record informasi secara permanen, sementara kelas entitas,
menangani informasi di dalam memori komputer saat komputer sedang
dihidupkan. Dalam UML, notasi kelas entitas digambarkan sebagai berikut :

Ent ity Clas

s

Gambar 7.3. Notasi Kelas Entitas

Dari rancangan basis data, dapat ditelusuri balik beberapa field pada basis data ke
kebutuhan sistem. Kebutuhan sistem menentukan aliran kejadian (flow of event), dan
aliran kejadian menentukan obyek-obyek, kelas-kelas, dan attribut-attribut dalam kelas.
Masing-masing attribut dalam kelas entitas mungkin akan menjadi field dalam basis
data.
c. Kelas-kelas Kontrol
Kelas kontrol bertanggung jawab untuk mengkoordinasikan kegiatan-kegiatan
terhadap kelas lainnya. Kelas ini bersifat opsional, tetapi jika kelas kontrol ini
digunakan, maka secara tipikal satu kelas kontrol untuk satu use case tersebut. Ada
kelas-kelas kontrol yang digunakan bersama oleh beberapa use case. Dalam UML,
notasi kelas entitas digambarkan sebagai berikut :

ControlCl ass

Gambar 7.4. Notasi Kelas Konrtol

Penamaan Kelas
Masing-masing kelas harus mempunyai nama yang unik. Sebagian besar
organisasi
mempunyai konvensi penamaan sendiri untuk menamakan kelas-kelas
yang dibuatnya.Umumnya, kelas-kelas dinamakan menggunakan kata benda tunggal.
Nama kelas tidak menggunakan spasi, ini dilakukan karena alasan praktis,
dimana beberapa bahasa pemrograman tidak membolehkan adanya spasi. Hal lainnya
yang perlu
diperhatikan adalah bahwa nama kelas hendaknya pendek, cukup untuk menjelaskan
apa yang akan kelas lakukan.
Jadi penamaan kelas sangat tergantung pada organisasi kita. Jika kita mempunyai
kelas yang digunakan dalam organisasi yang bersangkutan, tetapi yang jelas bahwa hal
tersebut
harus konsisten digunakan untuk keseluruhan kelas-kelas yang dibuatnya.
Visibilitas Kelas
Pilihan visibilitas menentukan dapat tidaknya sebuah kelas dilihat dari luar paket. Ada
3
pilihan visibilitas untuk sebuah kelas yaitu :
Public
Menyatakan bahwa sebuah kelas dapat dilihat dari kelas-kelas lainnya dalam sistem.
Protected atau Private
Menyatakan bahwa sebuah kelas dapat dilihat dari kelas-kelas majemuk (nested), friends,
atau dari kelas itu sendiri.
Package atau Implementation

Menyatakan bahwa sebuah kelas dapat dilihat hanya oleh kelas yang lain dalam
paket yang sama.

Multiplicity Kelas
Multiplicity memberikan gambaran sejumlah instan yang akan ditampung dalam keas.
Misalnya, dalam kelas Pegawai, kita mungkin mempunyai beberapa instan, satu untuk Ani,
satu untuk Ina, satu untuk Nana, dan seterusnya. Sehingga multiplicity untuk kelas Pegawai
diset n. Pada kelas kontrol, multiplicity diset 1 , karena pada saat aplikasi berjalan hanya satu
kelas.
Beberapa jenis multiplicity kelas :
Tabel 7.1. Notasi multiplicity untuk kelas
Multiplicity
Arti
n (default)
Banyak
0..0
Nol
0..1
Nol atau satu
0..n
Nol atau banyak
1..1
Tepat satu
1. . n
Satu atau banyak

Atau dapat digunakan format tertentu sebagai berikut :

Tabel 7.2. Notasi multiplicity menggunakan kustomisasi
Format
Arti
<Number>
Tepat
<Number1>.. <Number2>
Antara
<Numbern> ..
Atau Nol
<Number1> , <Number2>
<Number1> , <Number2> ..
Tepat <Number1> atau antara <Number2>
<Number3>
dan <Number3>
<Number1>.. <Number2> ,
Antara <Number1> dan <Number2> atau
<Number3>.. <Number4>
antara <Number1> dan <Number2>
Paket
Paket digunakan untuk mengelompokkan kelas-kelas yang mempunyai kesamaan.
Dalam UML, digambarkan sebagai berikut :

Package

Gambar 7.5. Notasi Paket

Ada
beberapa cara mengelompokkan kelas-kelas dalam paket, tetapi
bagaimanapun juga, kelas-kelas dapat dikelompokkan dalam paket yang sama tergantung
dari keinginan kita sendiri. Salah satu pendekatan yang dapat digunakan adalah
berdasarkan stereotype-nya. Dengan pendekatan ini, dapat dibuat satu paket untuk
kelas-kelas entitas, dan satu kelas untuk kelas-kelas kontrol.
Pendekatan lainnya yang dapat digunakan adalah dengan fungsionalitasnya.
Misalnya,
kita punya paket Security untuk kelas-kelas yang digunakan menangani keamanan sistem.

Akhirnya, dapat digunakan kombinasi dua pendekatan di atas. Paket dapat dibuat
bersarang, dimana satu paket mengandung beberapa paket lainnya. Pada level tertinggi,
dapat dikelompokkan berdasarkan fungsionalitasnya, kemudian diikuti dengan sub
fungsionalitas lainnya atau dengan stereotype-nya.
Tutorial Membuat Class Diagram
1. Expand pada Logical View, double klik pada Main. Lalu tambahkan notasi Class pada
toolbar, lalu tuliskan nama Class-nya

2. Untuk menambahkan attribute, klik kanan pada Class, lalu pilih New Attribute

3.

Untuk menambahkan attribute , bisa juga dengan membuka Specification, dengan

cara klik kanan, Open Specification lalu pilih tab Attributes. Pada tab Attributes, klik
kanan, lalu pilih insert.

4. Untuk menambahkan Operation atau method, bisa dilakukan seperti menambahkan

Attribute.
5. Untuk menambahkan tipe data dari attribute, double klik pada attribute lalu akan muncul
windows Class Attribute Specification.

6. Cara lain untuk memberi tipe data pada attribute. Double klik pada Type pada tab
Attributes.

7. Pada operasi atau method, kita juga bisa menambahkan parameter file. Buka
Specification untuk Circle, pada tab Operations double klik pada Return Value.

LATIHAN MODUL 7
1. Buatlah Class Diagram dari soal yang diberikan !