Buku Analisa Perancangan Sistem Perangkat Lunak Menggunakan Kakas UML

Analisa Perancangan
Sistem Perangkat Lunak

menggunakan Kakas
UML
Digunakan sebagai Buku Ajar dalam Mata Kuliah IFN204
Pengembangan Sistem Perangkat Lunak
Dikompilasi oleh: Stanley Karouw dan Hans Wowor

Analisa Perancangan Sistem Perangkat Lunak menggunakan Kakas UML
Tujuan Pembelajaran:
1. Memahami teknik dasar analisa dan perancangan berorientasi obyek (OOAD).
2. Memahami konsep dasar pemodelan berorientasi obyek menggunakan UML.
3. Membuat dokumentasi pengembangan sistem perangkat lunak.
Bahan Ajar Pengembangan Sistem Perangkat Lunak

2
BAB I
PENGANTAR PARADIGMA BERORIENTASI OBYEK
A. Konsep Berorientasi Objek

Obyek adalah sesuatu berupa konsep (concept), benda (thing), dan sesuatu yang
membedakannya dengan lingkungannya. Contoh sederhana dari obyek adalah mobil,
manusia, alarm dan lain sebagainya. Akan tetapi, obyek dapat pula berupa abstrak
yang hidup di dalam sistem seperti tabel, database, event, dan system messages.
Obyek dikenali dari keadaannya dan juga operasinya. Sebagai contoh sebuah mobil
dikenali dari warnanya, bentuknya, sedangkan manusia dari suaranya. Ciri ini yang
akan membedakan obyek tersebut dari obyek lainnya.
Dua alasan utama mengapa pendekatan dalam pengembangan PL dengan object-
oriented sangat popular saat ini adalah sebagai berikut:
1. scalability dimana obyek lebih mudah dipakai untuk menggambarkan sistem
yang besar dan komplek.
2. dynamic modeling - dapat dipakai untuk permodelan sistem dinamis dan real
time.
B. Teknik Dasar Berorientasi Objek

Dalam dunia pemodelan, metodologi implementasi obyek walaupun terikat kaidah-
kaidah standar, namun teknik pemilihan obyek tidak terlepas pada subyektifitas
system analyst dan designer. Beberapa obyek akan diabaikan dan beberapa obyek
menjadi perhatian untuk diimplementasikan di dalam sistem. Hal ini dapat dilakukan
karena suatu permasalahan sudah tentu memiliki lebih dari satu solusi. Ada 3 (tiga)
teknik/konsep dasar dalam OOA/D, yaitu pemodulan (encapsulation), penurunan
(inheritance) dan polymorphism.
1) Enkapsulasi
Adalah proses menyembunyikan informasi tanpa harus tahu bagaimana proses itu
sebenarnya terjadi. Encapsulation berfungsi untuk mengamankan informasi dimana
informasi ini hanya dapat diakses dengan cara tertentu. Informasi yang
disembunyikan/diamankan berupa ciri obyek, obyek lain berupa data, hubungan antar
obyek isian. Adapun susunan/komposisi dari encapsulation sebagai berikut:
 obyek lain berupa akses ke obyek lain, hubungan antar obyek
 asosiasi
 fungsi atau prosedur
Contoh dari encapsulation:
Seorang ibu rumah tangga menanak nasi dengan menggunakan rice cooker. Ibu
tersebut menggunakannya hanya dengan menekan tombol yang sudah disediakan
pada rice cooker ini. Setelah memilih tombol yang tepat, maka beras ini dapat
dimasak menjadi nasi. Akan tetapi, sang ibu tidak perlu untuk mengetahui bagaimana
cara rice cooker ini mengolah beras menjadi nasi yang siap untuk disantap. Proses
penyembunyian informasi milik rice cooker merupakan contoh dari encapsulation.
2) Pewarisan
Adalah obyek-obyek memiliki banyak persamaan, namun ada sedikit perbedaan. Hal-
hal yang harus diperhatikan mengenai pewarisan adalah sebagai berikut:
 Mewarisi sifat-sifat orang-tuanya: data & fungsi/ prosedur.
 Kelas orang tua disebut juga base class atau superclass
 Kelas anak/turunan disebut juga derived class atau subclass.
 Umumnya obyek dari kelas anak memiliki kekhasan tertentu yang tidak
dimiliki sebelumnya oleh obyek dari kelas orang tuanya, kekhasan tersebut
= pengkhususan (specialization)
 Bila yang ditemukan terlebih dulu adalah kelas anak, maka kelas orang tua
adalah pengumuman dari anak (generalization).
Contoh dari inheritance:
Ada mobil bak terbuka seperti truk, bak tertutup seperti sedan dan minibus. Walaupun
demikian obyek-obyek ini memiliki kesamaan yaitu teridentifikasi sebagai obyek
mobil, obyek ini dapat dikatakan sebagai obyek induk (parent). Sedangkan minibus
dikatakan sebagai obyek anak (child), hal ini juga berarti semua operasi yang berlaku
pada mobil berlaku juga pada minibus.
3) Polymorphism
Adalah teknik atau konsep dasar lainnya adalah ruang lingkup/pembatasan. Artinya
setiap obyek mempunyai ruang lingkup kelas, atribut, dan metode yang dibatasi.
Menunjukkan bahwa ada obyek yang berasal dari kelas yang berbeda dapat bereaksi
pada pesan yang sama.

4
Contoh dari polymorphism:

Remote control digunakan untuk memudahkan user dalam memilih channel yang
diinginkan, mengatur besar kecil suara, dan lain sebagainya. Remote control ini dapat
dipakai untuk berbagai macam obyek, seperti televisi, tape, VCD player, dan lain-
lain. Cara kerja dari remote control ini sama walaupun obyek di mana remote tersebut
digunakan boleh berbeda-beda.
Contoh lain dari polymorphism dapat dilihat pada obyek WINDOW dan DOOR dalam
lingkungan anda. Kedua obyek ini memiliki behaviour umum yang dapat mereka
kerjakan; kedua-duanya dapat menutup. Bagaimana sebuah DOOR dapat
mengerjakan behaviour yang mungkin berbeda secara substansial dari cara sebuah
WINDOW melakukan hal serupa. DOOR “swing shut”; dan WINDOW “slide
downward”. Jadi behaviour menutup ini memakai cara berbeda untuk kelas obyek
tertentu.
C. Metode Berorientasi Obyek

Sejarah singkat mengenai pengembangan metode berorientasi obyek (Joos, 2007;
Silfianti, 2003)
 Metode-metode awal (akhir 80an- 1991)
- Sally Shaler/Stephen Mellor OOA/D
- Peter Coad/Edward Yourdon OOA/D
- James Rumbaugh‟s et al OMT (Object Modelling Technique)
- Rebecca Wirfs-Brock‟s et. al RDD (Responsibility Driven Design)
 Metode yang diperkaya (1991-awal 1995)
- Ivar Jacobson‟s et al. OOSE (Object Oriented Software Engineering)
- Ian Graham‟s SOMA (Semantic Object Modelling Approach)
- Brian Henderson-Sellers‟ MOSES (Methodology for Object Oriented
Software Engineering of System)
- Grady Booch‟s OOAD
- Derek Coleman‟s et al. Fusion
 Usaha pemersatuan metode
- Object Process and Environment Notation (OPEN)
- UML (bukan metode tetapi tools)
Coad dan Yourdon menguraikan 7 motivasi kunci dan keuntungan dari analisis dan
perancangan berorientasi obyek adalah sebagai berikut (Joos, 2007, hal 51-3):
1. Perancangan berorientasi obyek dibandingkan metode analisis tradisional
2. Menangani domain persoalan yang mungkin menantang
3. Meningkatkan interaksi antara system analyst dan expert dalam problems
domain
4. Secara eksplisit menyatakan kesamaan antara kelas dan obyek
5. Membuat spesifikasi yang lebih dapat beradaptasi terhadap perubahan
6. Menggunakan ulang hasil OOA, OOD dan OOP
7. Menyediakan representasi yang konsisten antara analisis, perancangan dan
pemrograman.
Hasil utamanya adalah mengurangi kompleksitas persoalan dan tanggung jawab
sistem didalamnya. Metode OOA/OOD didasarkan atas sejumlah prinsip umum
untuk mengatasi kompleksitas yang tidak dimiliki oleh metode lain (misalnya
Dekomposisi Fungsional, Data Flow, Information Modelling – basis dari E-R), yaitu:
1. Abstraksi
a. Procedural
b. Data
2. Encapsulation
3. Inheritance
4. Asosiasi
5. Komunikasi dengan pesan
a. Sebaran cara organisasi
b. Obyek dan Atribut
c. Whole & Parts
6. Kelas dan anggotanya beserta perbedaan di antara mereka
7. Skala
8. Kategori kelakuan
a. Penyebab langsung
b. Perubahan sejalan waktu
c. Kesamaan fungsi

6
Adapun implikasi dari metode ini adalah sebagai berikut:

a. Tidak ada perbedaan besar antara notasi analisis dan perancangan
b. Tidak ada transisi dari analisis ke perancangan
c. Tidak ada model waterfall yang harus diikuti; model spiral dan increment
juga dapat diterapkan.
d. Ada sejumlah keterampilan dan strategi yang diperlukan oleh analis dan
perancang sistem.
e. Adanya keseragaman representasi dari OOA ke OOD ke OOP
BAB II
Kakas Unified Modelling Language
Kakas Unified Modeling Language (disingkat UML) adalah:

1. sebuah "bahasa" yg telah menjadi standar dalam industri untuk melakukan
spesifikasi, visualisasi, konstruksi, dan dokumentasi dari komponen-
komponen perangkat lunak, dan digunakan untuk pemodelan bisnis
2. model yang siap pakai, bahasa pemodelan visual yang ekspresif untuk
mengembangkan dan saling tukar-menukar model dengan mudah dan
dimengerti secara umum.
3. menggunakan notasi grafis untuk menyatakan suatu desain
4. menggambarkan yang ada dalam dunia nyata ke dalam bentuk yang dapat
dipahami dengan menggunakan notasi standar UML
Dua yang harus diperhatikan agar dapat menguasai UML dengan baik, yaitu:
1. Menguasai pembuatan diagram UML. Sebagai sebuah ”bahasa pemodelan”
maka UML memiliki tata aturan dalam menggambar setiap diagram. Untuk
dapat mengoptimalkan manfaat UML, maka tentu saja, harus dikuasai tata
aturan penggambaran setiap diagram UML tersebut. Setiap diagram UML
memiliki notasi gambar dan cara untuk menggambar. Notasi dan cara untuk
menggambar harus dikuasai dengan baik, bagi mereka yang ingin
menggunakan UML.
2. Menguasai langkah-langkah dalam analisa dan perancangan dengan UML.
Proses analisa dan perancangan sistem perangkat lunak berorientasi obyek
dengan menggunakan UML merupakan sebuah proses integral dari tahapan
pengembangan sistem perangkat lunak. Langkah proses ini seperti ”memiliki
pasangan” diagram UML tertentu yang dapat mengabstraksikan salah satu
aspek dari sistem perangkat lunak.
Ada 8 diagram UML untuk memodelkan sistem perangkat lunak di mana masing-
masing diagram UML didesain untuk menunjukkan satu sisi dari bermacam-macam
sudut pandang (perspektif) dan terdiri dari tingkat abstraksi yang berbeda. 8 diagram
UML adalah sebagai berikut: Diagram Use Case, Diagram Kelas, Diagram Statechart,

8
Diagram Aktivitas, Diagram Sequence, Diagram Kolaborasi, Diagram Komponen,

Diagram Deployment.
Rangkuman dari UML (Dharwiyanti & Wahono, 2003) dapat dilihat pada Gambar 1
sebagai berikut
Gambar 1. Konsep Dasar UML
A. Proses Analisa dan Perancangan Menggunakan UML
Menggambar model perangkat lunak berorientasi obyek dengan menggunakan UML
memiliki banyak teknik pendekatan. Salah satu teknik pendekatan yang disarankan
dapat dilihat pada Gambar 2 dibawah.
Gambar 2 Proses Analisa Perancangan dengan UML
Penjelasan Gambar 2 adalah sebagai berikut:

1. Definisikan proses bisnis dari sistem perangkat lunak yang akan dibuat. Proses
bisnis dibuat dengan menggunakan Diagram Aktivitas atau BPMN.
Disarankan untuk membuat daftar proses business dari level tertinggi untuk
mendefinisikan aktivitas dan proses yang mungkin muncul.
2. Definisikan persyaratan pengguna dengan menggunakan teknik identifikasi
masalah – identifikasi kebutuhan – identifikasi fitur. Kemudian gunakan
Diagram use case untuk setiap kebutuhan pengguna. Lakukan cross check
dengan Diagram Aktivitas Proses Bisnis untuk setiap Diagram use Case yang
digambar. Petakan use case untuk tiap proses business untuk mendefinisikan
dengan tepat fungsionalitas yang harus disediakan oleh sistem. Kemudian
perhalus use case diagram dan lengkapi dengan requirement, constraints dan
catatan-catatan lain. Masing-masing Diagram Use Case yang dibuat, wajib
dilengkapi dengan Use Case Description atau Use Case Tabel. Lakukan

10
langkah ini dengan berhati-hati, berulang-ulang dan menyeluruh untuk semua

Diagram Use Case. Mulailah dari Diagram Use Case yang sederhana.
Definisikan requirement lain (non-fungsional, security dan sebagainya) yang
juga harus disediakan oleh sistem dengan mengisi use case table.
3. Setelah Diagram Aktivitas, Diagram Use Case dibuat, maka buatlah Diagram
Sequence. Namun, Diagram Sequence dapat juga dibuat bersamaan saat
mengerjakan langkah 4. Membuat Diagram Sequence diawali dengan
berpedoman pada Diagram Use Case dan Use Case Description. Jika sebuah
use case memiliki kemungkinan alir normal dan error, buatlah satu diagram
untuk masing-masing alir. Sedangkan untuk setip obyek yang saling
berinteraksi, dapat menggunakan Klasifikasi Obyek yang ada pada langkah
membuat Diagram Kelas.
4. Berdasarkan Use Case Description, garisbawahi semua potensial obyek.
Kemudian dari setiap potensial obyek, kelompokkanlah obyek yang dapat
dijadikan sebuah kelas. Proses identifikasi potensial obyek dan kelas dapat
menggunakan teknik identifikasi kata benda – kata kerja. Klasifikasikan
potensial obyek dan kelas dengan menggunakan Tabel. Kemudian, gambarkan
Diagram Kelas Diagram untuk high-level dan detailed Diagram Kelas. Setelah
Diagram Kelas dibuat, kita dapat melanjutkan dengan membuat Diagram
Komponen. Langkah ini dilakukan, jika sistem perangkat lunak yang akan
dibuat cukup besar.
5. Setelah Diagram Sequence dibuat, maka buatlah rancangan antar-muka
pengguna untuk setiap obyek yang berinteraksi dengan pengguna. Buatlah
rancangan user interface model yang menyediakan antarmuka bagi pengguna
untuk menjalankan skenario use case.
6. Langkah selanjutnya adalah membuat pemetaan Diagram Kelas kedalam
Diagram E-R untuk membuat rancangan basis data yang diperlukan.
7. Diagram Deployment dapat dibuat setelah semua diagram utama perangkat
lunak selesai dikerjakan. Detilkan kemampuan dan requirement piranti lunak,
sistem operasi, jaringan, dan sebagainya. Petakan komponen ke dalam node.\
8. Mulailah membangun sistem. Ada dua pendekatan yang dapat digunakan :
 Pendekatan use case, dengan meng-assign setiap use case kepada tim
pengembang tertentu untuk mengembangkan unit code yang lengkap
dengan tes.
 Pendekatan komponen, yaitu meng-assign setiap komponen kepada
tim pengembang tertentu.
9. Proses pengujian merupakan bagian terkait langsung dari proses penulisan
kode. Lakukan uji unit dan uji integrasi serta perbaiki model berserta codenya.
Model harus selalu sesuai dengan code yang aktual.
10. Implementasi sistem perangkat lunak pada lingkungan sebenarnya dapat
dilakukan.
Gambar 3 memetakan langkah, proses dan diagram UML pada fase pengembangan
sistem perangkat lunak.
Gambar 3. Pemetaan Langkah, Proses dan Diagram UML

12
B. Teknik Menggambar Diagram UML

1) Use Case Diagram
Diagram Use Case biasanya digunakan untuk menggambarkan fungsionalitas yang
diharapkan dari sebuah sistem; menekankan “apa” yang diperbuat sistem, dan bukan
“bagaimana”; merepresentasikan sebuah interaksi antara aktor dengan sistem; sangat
membantu bila kita sedang menyusun requirement sebuah sistem,
mengkomunikasikan rancangan dengan klien, dan merancang test case untuk semua
feature yang ada pada sistem.
Notasi Diagram Use Case dapat dilihat pada Gambar 4 berikut ini:
Gambar 4 Notasi Diagram Use Case
-End1 -End2
Aktor Relasi antara aktor
(Receiver or Sender) * *
dan use case
Actor1 Dependency
(include or extend)
UseCase1 Use Case
Obyek entiti
Note
Obyek antarmuka
Package Obyek kontrol

Package1 (Kumpulan dari
use case/proses)
Cara menggambarkan use case diagram:

1. Buatlah FDD, Diagram Aktivitas ataupun BPMN terlebih dahulu agar mudah
terlihat setiap proses yang terjadi dalam sistem tersebut. Setiap proses ini akan
menjadi sebuah use case.
2. Daftarkan aktor yang berhubungan dengan use case, baik sebagai sender
maupun receiver.
Table 1.1 Contoh Daftar Istilah Use Case
Pelaku yang
Nama Use Case Deskripsi Use Case Berpartisipasi dan
Perannya
Manajemen Data Proses Manajemen - Head Admin
Data berupa Tambah (sender)
Data, hapus Data dan - Data (receiver)
Ubah Data
Gambar 5 Diagram Use Case versi Awal
3. Tambahkan dependency yang mendemonstrasikan hubungan semantik antara

dua use case. Jika use case “A” berubah dapat mengakibatkan use case “B”
akan berubah pula. Ada 2 macam dependency yang perlu diperhatikan yaitu
include dan extend.

14
Include:
Sebuah use case dapat meng-include fungsionalitas use case lain sebagai bagian
dari proses dalam dirinya. Secara umum diasumsikan bahwa use case yang di-
include akan dipanggil setiap kali use case yang meng-include dieksekusi secara
normal. Sebuah use case dapat di-include oleh lebih dari satu use case lain,
sehingga duplikasi fungsionalitas dapat dihindari dengan cara menarik keluar
fungsionalitas yang common.
Contoh dari include (lihat Gambar 5):
Head Admin dapat melakukan Proses Manajemen Data secara simultan yakni
proses Tambah, Ubah dan Hapus. Namun Head Admin harus terlebih dahulu
diidentifikasi sebagai Akun Obyek Head Admin sebelum melakukan proses
“Manajemen Data”. Use Case “Managemen Data” meng-include fungsionalitas
dari use case “Tambah Data”, ”Ubah Data” dan “Hapus Data” sebagai bagian
dari proses saat dieksekusi.
Extend:
Sebuah use case juga dapat meng-extend use case lain dengan behaviour-nya
sendiri. Sementara hubungan generalisasi antar use case menunjukkan bahwa use
case yang satu merupakan spesialisasi dari yang lain.
Contoh dari Extend (lihat Gambar 6):
Setelah pasien membuat temu janji dengan dokter, pasien ini tiba-tiba mendapat
halangan sehingga tidak dapat memenuhi janjinya. Oleh karena itu, pasien ini
membatalkan janji yang sudah dibuat. Ini merupakan contoh dari kasus extend
dimana “Make Appointment” adalah base use case dan “Cancel Appointment”
merupakan extended use case.
4. Ada 2 macam interaksi yang dapat digambarkan dengan menggunakan use
case diagram, yaitu:
a. interaksi antara aktor dan system
b. interaksi use case dan use case lainnya.
5. Mengisi use case description (harus dibuat untuk setiap use case)
6. Untuk memperhalus model use case, maka perlu dilakukan pemodelan
interaksi dan behaviour obyek yang mendukung scenario use case. Pemodelan
ini terdiri dari 5 langkah berikut ini (Whitten et. al, 2004):
a. mengidentifikasi dan mengelompokkan obyek desain use case
b. mengidentifikasi atribut obyek
c. memodelkan interaksi obyek tingkat tinggi untuk sebuah use case
d. mengenali state, behaviour, dan tanggung jawab obyek
e. memodelkan interaksi obyek detil untuk sebuah use case (lihat
sequence diagram).
Contoh berikut (Gambar 6) ini akan menggambarkan interaksi antara aktor dan
sistem. Selain itu, gambar ini juga mendemonstrasikan penggunaan include dan
extend.
Gambar 6 Contoh Interaksi Antara Aktor dan Sistem (Use Case)

16
Gambar 7 memberikan contoh penulisan Use Case Description (atau disebut juga Use
Case Table)
Gambar 7 Use Case Description
Nama Use Make Appointment
Case:
Aktor: Patient dan scheduler
Deskripsi: Membuat temu janji untuk berobat
Normal 1. Patient menginisialisasi proses ini dengan
Course: membuat temu janji untuk berobat dengan
mendatangi tempat praktek.
2. Hal ini kemudian dicatat oleh scheduler.
Alternate 1a. Patient dapat membuat janji lewat telpon.
Course: 2a. Scheduler dapat menuliskan temu janji berdasarkan informasi yang diberikan oleh
patient.
Pre- Patient sakit
Condition:
Post- Cancel appointment, check patient‟s record, request medication
Condition:
Assumption: -
Keterangan dari Gambar 7 adalah sebagai berikut:

Normal course: Rangkaian kejadian yang terjadi sesuai harapan
Alternate course: Mendokumentasikan kelakuan use case jika terjadi exception
Pre-condition: Kondisi yang harus dipenuhi sebelum use case ini dijalankan. Hal ini dapat dilakukan
dengan memberikan penjelasan singkat atau dapat pula berupa nama use case.
Post-condition: Batasan pada keadaan sistem setelah use case ini diesksekusi dengan baik. Dapat
berupa nama use case.
Pemodelan interaksi dan behaviour obyek yang mendukung scenario use case.
Pemodelan ini terdiri dari 4 langkah berikut ini (Whitten et. al, 2004):
1. mengidentifikasi dan mengelompokkan obyek desain use case
2. mengidentifikasi atribut obyek
3. memodelkan interaksi obyek tingkat tinggi untuk sebuah use case
4. mengenali state, behaviour, dan tanggung jawab obyek
Berikut penjelasan dari langkah-langkah pemodelan:

1. Mengidentifikasi dan mengelompokkan obyek desain use case
Struktur sebuah sistem berbasis obyek ke dalam 3 tipe obyek mencerminkan fakta
bahwa tanggung jawab dan behaviour yang dibutuhkan untuk mendukung sebuah
fungsionalitas sistem didistribusikan melewati 3 tipe obyek tersebut, yang bekerja
bersama untuk melakukan layanan. 3 tipe obyek ini adalah obyek entity, obyek
antarmuka, dan obyek control.
a. Obyek entity
Obyek yang menggambarkan data actual dalam domain bisnis. Obyek ini berisikan
informasi, biasa disebut atribut, yang menjelaskan contoh-contoh berbeda dari
entity. Contoh nama pasien, alamat, telepon, dan lainnya. Obyek entiti juga
mengenkapsulasi behaviour-behaviour dari obyek tersebut (disebut metode) yang
menyimpan informasi dan atribut dari obyek entiti.
b. Obyek antarmuka
Peralatan yang akan dipakai pengguna untuk berantarmuka dengan sistem.
Tanggung jawab dari obyek antarmuka mencakup 2 hal berikut ini menerjemahkan
input pengguna ke dalam informasi yang dapat dipahami oleh system dan
digunakan untuk memproses peristiwa bisnis; mengambil data yang berkaitan
dengan peristiwa bisnis dan menerjemahkan data tersebut untuk memberikan
presentasi yang tepat pada pengguna.
Contoh dari obyek antarmuka adalah form appointment, form patient, form login,
dan lain-lain.
c. Obyek control
Obyek yang menyimpan aplikasi atau logika aturan bisnis. Dengan mengelola atau
mngarahkan interaksi antara obyek, maka obyek control memperbolehkan scenario
untuk menjadi tanggung dan menyederhanakan tugas pemeliharaan proses. Sebuah
obyek control harus digabungkan dengan hanya sebuah actor.
2. Mengidentifikasi atribut obyek
Identifikasi atribut obyek dilakukan dengan membuat dalam bentuk tabel.
Contohnya sebagai berikut:
Tabel Obyek Antarmuka, Kontrol, dan Entiti
Interface Objects Controller Objects Entity Objects
Form appointment appointment appointmentId
manager
appointmentDate
patientId

18
3. Memodelkan interaksi obyek tingkat tinggi untuk sebuah use case. Contohnya
dapat dilihat pada ilustrasi gambar berikut:
Form Appointment
AppointmentId
Appointment Manager
*
AppointmentDate
* **
Actor2
PatientId
4. Mengenali state, behaviour, dan tanggung jawab obyek. Langkah ini dapat
dilakukan dengan membuat Tabel, seperti yang dicontohkan berikut ini:
Tabel State, Behaviour, dan Tanggung Jawab Obyek
Behaviour Otomatis/Manual Tipe Obyek
Make appointment Otomatis Entiti
Cancel appointment Manual
Check patient record Manual/Otomatis Kontrol
Pay bill Manual
Menampilkan form Otomatis Antarmuka
appointment
2) Diagram Aktivitas
Tujuan penggunaan Diagram Aktivitas adalah untuk menggambarkan berbagai alir
aktivitas dalam sistem yang sedang dirancang, bagaimana masing-masing alir
berawal, decision yang mungkin terjadi, dan bagaimana mereka berakhir; juga untuk
menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi.
Perbedaan antara use case diagram dan activity diagram:
Sebuah aktivitas dapat direalisasikan oleh satu use case atau lebih. Aktivitas
menggambarkan proses yang berjalan, sementara use case menggambarkan
bagaimana aktor menggunakan sistem untuk melakukan aktivitas.
Notasi Diagram Aktivitas dapat dilihat pada Gambar 8 berikut ini.
Gambar 8 Notasi Diagram Aktivitas
Activity
<no receive action> Signal Receive

Fork
Control Flow
Condition
<no send action> Signal Send
Note
Cara menggambarkan activity diagram:

1. Penggambaran Diagram Aktivitas diawali dengan melihat terlebih dahulu
proses bisnis organisasi (misalnya dengan menggunakan FDD) ataupun
dokumen terkait lainnya yang dapat menggambarkan tugas dan fungsi kerja
dalam organisasi. Struktur organisasi dan Dokumen SOP kadang bisa menjadi
masukan dalam membuat Diagram Aktivitas.
2. Aktivitas atau proses kerja digambarkan dengan menggunakan segiempat
dengan sudut membulat. Decision digunakan untuk menggambarkan
behaviour pada kondisi tertentu.
3. Untuk mengilustrasikan proses-proses paralel (fork dan join) digunakan titik
sinkronisasi yang dapat berupa titik, garis horizontal atau vertikal.
4. Activity diagram dapat dibagi menjadi beberapa object swimlane untuk
menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu.
5. Untuk dapat menggambarkan activity diagram dengan baik, disarankan agar
membuat daftar sejumlah aktivitas beserta dengan kondisinya. Tools FDD
dapat menjadi sangat berguna untuk mengecek proses-proses serta jalur
aktivitas, baik dari level atas maupun level rincinya.

20
Gambar 9 adalah Diagram Aktivitas dari proses Ibadah Anak Sekolah Minggu.
Gambar 9 Diagram Aktivitas Proses Sekolah Minggu
3) Diagram Kelas
Diagram Kelas biasanya digunakan untuk menggambarkan keadaan (atribut/properti)
suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut
(metoda/fungsi); juga untuk menggambarkan struktur dan deskripsi class, package
dan objek beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi,
dan lain-lain
Dalam konsep berorientasi obyek, maka entitas Class memiliki tiga area pokok, yaitu
Nama (dan stereotype); Atribut dan Operasi/metode (lihat Gambar 10 dan Gambar
11)
Gambar 10 Diagram Kelas
Nama Class
-atribut
+operation()
Apabila atribut dan operasi digabungkan maka ini disebut function. Atribut dan
operasi dapat memiliki salah satu sifat berikut :
 Private, tidak dapat dipanggil dari luar class yang bersangkutan. Notasi: “-“
 Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak
yang mewarisinya. Notasi: “#”
 Public, dapat dipanggil oleh siapa saja. Notasi: “+”
Gambar 11 Notasi Class Diagram
- Private
Package
+ Public
# Protected «interface»
Interface
0..1 Zero-to-one
1..* One-to-many
1 1..*
Association
Patient Treatment
Generalization
Realization
Dharwiyanti dan Wahono (2003) menjelaskan bahwa Class dapat merupakan

implementasi dari sebuah interface, yaitu class abstrak yang hanya memiliki metoda.
Interface tidak dapat langsung diinstansiasikan, tetapi harus diimplementasikan
dahulu menjadi sebuah class. Dengan demikian interface mendukung resolusi metoda
pada saat run-time.

22
Entitas Kelas dapat memiliki relasi sebagai berikut:

1. Asosiasi, yaitu hubungan statis antar class. Sebuah association adalah hubungan
antar benda struktural yang terhubung diantara obyek. Kesatuan obyek yang
terhubung merupakan hubungan khusus, yang menggambarkan sebuah hubungan
struktural diantara seluruh atau sebagian. Umumnya assosiation digambarkan
dengan sebuah garis yang dilengkapi dengan sebuah label, nama, dan status
hubungannya
2. Agregasi, yaitu hubungan yang menyatakan bagian (“terdiri atas..”).
3. Pewarisan, yaitu hubungan hirarkis antar class. Class dapat diturunkan dari class
lain dan mewarisi semua atribut dan metoda class asalnya dan menambahkan
fungsionalitas baru, sehingga ia disebut anak dari class yang diwarisinya.
Kebalikan dari pewarisan adalah generalisasi. Sebuah generalization adalah
menggambarkan hubungan khusus dalam obyek anak/child yang menggantikan
obyek parent / induk . Dalam hal ini, obyek anak memberikan pengaruhnya dalam
hal struktur dan tingkah lakunya kepada obyek induk.
4. Hubungan dinamis, yaitu rangkaian pesan (message) yang di-passing dari satu
class kepada class lain. Hubungan dinamis dapat digambarkan dengan
menggunakan sequence diagram yang akan dijelaskan kemudian.
Cara menggambarkan class diagram:

1. Gunakan use case table yang sudah dibuat sebelumnya dengan memberikan
highlight semua kata benda yang dapat menjadi potensial obyek.
2. Bedakan tipe-tipe obyek tersebut karena mereka dapat berupa interface,
package, dan lainnya. Apabila obyek tersebut berupa nama atribut dari sebuah
class, maka obyek ini harus ditolak.
3. Setelah mendapatkan daftar class, maka gambarkan high level class diagram
beserta dengan kardinalitas serta deskripsi relasinya.
4. Kemudian gambarkan detailed class diagram di mana hubungan antar class
sudah ditambahkan. Jangan lupa untuk menuliskan semua atribut dan operasi
beserta dengan sifat mereka. Pada umumnya sifat atribut pada sebuah tabel
adalah private (tidak dapat dipanggil dari luar class yang bersangkutan).
Sedangkan sifat dari operasi yaitu public (dapat dipanggil oleh siapa saja).
5. Jangan lupa untuk melakukan normalisasi terhadap class jika belum dibuat
sebelumnya.
Berikut ini (Gambar 12) adalah contoh Diagram Kelas beserta dengan hubungan antar
kelas.
Gambar 12 Contoh Hubungan Antar Kelas
4) Diagram Sequence
Diagram sequence biasanya ditujukan untuk menggambarkan interaksi antar objek di
dalam dan di sekitar sistem (termasuk pengguna, display, dan sebagainya) berupa
message yang digambarkan terhadap waktu; juga untuk menggambarkan skenario

24
atau rangkaian langkah-langkah yang dilakukan sebagai respons dari sebuah event
untuk menghasilkan output tertentu (lihat Gambar 13 untuk notasi Diagram Sequence)
Gambar 13 Notasi Sequence Diagram
Object1
Object Lifeline
Activation Bar
Simple Message
Lifeline
Assynchronous Message
Synchronous Message
Message Return
Note
Loop
Cara menggambarkan sequence diagram:

1. Sequence diagram terdiri atas dimensi vertikal (waktu) dan dimensi horizontal
(obyek-obyek yang terkait).
2. Diawali dari apa yang men-trigger aktivitas tersebut, proses dan perubahan
apa saja yang terjadi secara internal dan output apa yang dihasilkan.
3. Masing-masing objek, termasuk aktor, memiliki lifeline vertikal.
4. Message digambarkan sebagai garis berpanah dari satu objek ke objek lainnya.
Pada fase desain berikutnya, message akan dipetakan menjadi operasi/metode
dari class.
5. Activation bar menunjukkan lamanya eksekusi sebuah proses, biasanya
diawali dengan diterimanya sebuah message.
6. Untuk objek-objek yang memiliki sifat khusus, standar UML mendefinisikan
icon khusus untuk objek boundary, controller dan persistent entity.
Gambar 19 Contoh Sequence Diagram
Contoh lain dari sequence diagram dapat dilihat pada ilustrasi Gambar 20 – 22
berikut (Sumber: Schmuller, 1999). Sequence diagram ini yang menggambarkan
proses pembelian minuman yang dilakukan oleh seorang actor lewat vending
machine. Agar penggambaran proses pembelian mudah untuk dimengerti, maka
proses ini dibagi menjadi 3 bagian dengan scenario yang berbeda-beda.Front adalah
interface, register adalah controller untuk pembayaran, dan dispenser adalah
controller untuk pilihan minuman.
Scenario pertama mendemonstrasikan proses pembelian dimana:
1. Actor mengisi uang (insert input) sesuai dengan harga minuman.
2. Input ini diteruskan ke bagian register control. Oleh karena jumlah uang yang
dimasukkan sama persis dengan harga minuman, maka dari itu proses ini
berhenti disini saja.
3. Selain uang, actor juga menyeleksi minuman yang diinginkan (select
selection). Dispenser controller mengirim minuman tersebut ke front.
Gambar 20 Contoh ke-2 Sequence Diagram (Membeli Minuman – Part 1)
Scenario kedua:
1. Ada 2 kondisi untuk input yaitu input = price dan input > price.
2. Jika input=price dan pilihan minuman tersedia,maka dispenser akan langsung
mengirim minuman tersebut. (Prosesnya sama dengan gambar sequence
diagram di atas).
3. Perbedaan antara kedua sequence diagram ini yaitu diagram kedua
menambahkan sebuah kondisi jika input > price.
4. Ada 2 hal yang akan divalidasi di sini yaitu:
a. Jika tidak ada uang kembalian tersedia di register controller, maka
register akan mengembalikan input (uang) dan transaksi berakhir.
b. Jika ada uang kembalian, maka register akan meneruskan transaksi ini
dengan mengirimkan message ke dispenser controller. Kemudian,
register akan mengembalikan uang kembalian tersebut. Setelah itu,
dispenser controller akan mengirimkan minuman sesuai pilihan si
actor.
Gambar 21. Contoh ke-2 Sequence Diagram (Membeli Minuman – Part 2)
Scenario ketiga:
1. Proses ketiga ini adalah lanjutan dari proses sebelumnya.
2. Perbedaannya terletak pada pilihan minuman.
3. Ada 2 hal mengenai pilihan minuman yang akan divalidasi di sini yaitu:
c. Jika minuman yang diinginkan tidak tersedia di dispenser controller,
maka dispenser akan menampilkan message untuk memberitahukan
hal tersebut ke actor.
d. Jika pilihan minuman tersedia, maka dispenser controller akan
mengirimkan minuman sesuai pilihan si actor lewat front interface.
Gambar 22 Contoh ke-2 Sequence Diagram (Membeli Minuman – Part 3)
5) Diagram Component
Tujuan penggunaaan Diagram Komponen adalah untuk menggambarkan struktur dan
hubungan antar komponen piranti lunak, termasuk ketergantungan (dependency)
diantaranya; dan untuk menunjukkan bagaimana kode pemrograman dibagi ke dalam
modul-modul (komponen).
Komponen piranti lunak adalah modul berisi code, baik berisi source code maupun
binary code, baik library maupun executable, baik yang muncul pada compile time,
link time, maupun run time. Umumnya komponen terbentuk dari beberapa class
dan/atau package, tetapi dapat juga dari komponen-komponen yang lebih kecil.
Komponen dapat juga berupa interface, yaitu kumpulan layanan yang disediakan
sebuah komponen untuk komponen lain. Dengan kata lain, component diagram ini
terdiri dari kumpulan komponen, interfaces, dan relasinya. (untuk notasi Diagram
Komponen dapat dilihat pada Gambar 23)
Gambar 23 Notasi Diagram Komponen
Dependency relationship
Package
Interface
Note
Cara menggambarkan component diagram:

1. Untuk dapat menggambarkan arsitektur fisik dari sebuah PL, maka perlu
ditentukan komponen-komponen yang terdapat pada PL ini.
2. Komponen ini dapat berupa modul berisi code, interface, dan class.
3. Setelah itu, hal berikut yang perlu dilakukan adalah menggambarkan relasinya
yang menunjukkan bagaimana komponen-komponen ini berkomunikasi satu
sama lain.
4. Package dapat digunakan untuk mengelompokkan komponen-komponen ini.
Gambar 24 Contoh Component Diagram (Vending Machine)
Vending Machine
Front Vending Machine Interface
Register Dispenser
Classes: Classes:
InputValidator BeverageSelection
CheckForChange CheckBeverage
DeliverChange DeliverBeverage
6) Diagram Deployment
Tujuan penggunaan Diagram Deployment adalah: menggambarkan detail bagaimana
komponen di-deploy dalam infrastruktur sistem, di mana komponen akan terletak
(pada mesin, server atau piranti keras apa), bagaimana kemampuan jaringan pada
lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisikal; juga
digunakan untuk menggambarkan arsitektur fisik dari perangkat keras dan PL pada
suatu sistem.
Sebuah node adalah server, workstation, atau piranti keras lain yang digunakan untuk
men-deploy komponen dalam lingkungan sebenarnya. Sebuah node juga merupakan
fisik dari elemen-elemen yang ada pada saat dijalankannya sebuah sistem, contohnya
adalah sebuah komputer, umumnya mempunyai sedikitnya memory dan processor.
Hubungan antar node (misalnya TCP/IP) dan requirement dapat juga didefinisikan
dalam diagram ini.
Cara menggambarkan deployment diagram:
1. Tentukan node-node yang akan digunakan untuk mengimplementasikan
komponen dalam lingkungan sebenarnya.
2. Pada setiap node tersebut harus diisikan dengan component-component yang
dapat berupa code, interface, dan class.
3. Kemudian, gunakan garis untuk menghubungkan node-node untuk
mengindikasikan jalur komunikasi di antara peralatan.
Notasi Diagram Deployment dapat dilihat pada gambar 25, sedangkan untuk contoh
penggunaan dapat dilihat pada Gambar 26
Gambar 25 Notasi Deployment Diagram
Gambar 26 Contoh Deployment Diagram

BAB III
TUTORIAL KAKAS RATIONAL ROSE
Rational Rose merupakan sebuah perangkat pemodelan secara visual yang

memiliki banyak kemampuan (powerful) untuk pembentukan sistem berorientasi
obyek yang menggunakan Unified Modeling Language (UML). UML merupakan
bahasa pemodelan yang dapat digunakan secara luas dalam pemodelan bisnis,
pemodelan perangkat lunak dari semua fase pembentukan dan semua tipe sistem, dan
pemodelan secara umum dari berbagai pembentukan / konstruksi yang memiliki dua
perilaku yaitu baik statis maupun dinamis.
Tutorial ini akan membahas cara pemakaian Rasional Rose dengan mengambil
sebuah kasus untuk mempermudah pemahaman. Namun demikian tutorial ini bersifat
sangat sederhana karena pemakaian perangkat lunak ini sangat ditentukan pada
system yang akan dibangun dan variasinya. Tutorial ini dapat dianalogkan dengan
kursus privat mengendarai mobil. Mobil merupakan sebuah sarana transportasi yang
dapat digunakan untuk berbagai keperluan, dalam kursus privat hanya diajarkan
bagaimana cara mengoperasikan, perpindahan gigi, gas, rem, light sign, klakson, dsb.
Kemahiran mengendarai ditentukan banyak jam pakai dengan berbagai kasus di jalan
dan hal itu tidak diberikan dalam kursus privat tersebut.
Untuk mempermudah dalam memahami penggunaan rasional rose dalam
tutorial ini disusun dengan urutan sebagai berikut:
1. Pendahuluan
2. Penjelasan bagian-bagian dari rasional rose
3. Penjelasan cara menggunakan
Dalam UML, bagian-bagian yang digunakan yaitu: views, diagram, dan elemen
model.
a. View. View menunjukkan perbedaan dari berbagai aspek-aspek suatu
sistem yang dimodelkan. View bukan sebuah graph, tetapi sebuah
abstraksi yang terdiri dari beberapa diagram. Hanya dengan
mendefinisikan sejumlah view, dimana setiap view menunjukkan aspek
yang berbeda dan saling terpisah dari sistem, maka gambaran sebuah
sistem secara komplit dapat dibentuk. Rational rose memiliki empat view
yaitu: Use case View, Logical View, Component View, dan Deployment
View.
b. Diagram. Diagram merupakan graph yang menjelaskan tentang isi dari
sebuah view. UML memiliki beberapa tipe diagram yang berbeda yang
dapat digunakan untuk mengkombinasi dalam menyusun semua dari
sebuah sistem. Rational Rose 2000, memiliki delapan diagram yaitu: Use
case diagram, Sequence diagram, Collaboration diagram, Activity
Diagram, Class Diagram, Statechart Diagram, Component Diagram dan
Deployment Diagram.
c. Elemen Model. Konsep-konsep yang digunakan dalam diagram
merupakan elemen-elemen model yang menyatakan konsep-konsep
berorientasi obyek secara umum , seperti class, object, dan message, serta
hubungan antar konsep-konsep tersebut termasuk association, dependency,
dan generelization. Sebuah elemen model digunakan dalam beberapa
diagram yang berbeda tetapi selalu memiliki simbol dan arti yang sama.
A. Membuat Use Case Diagram
Komponen utama dari sebuah Model Use-case
Actor Use Case Relationship
Langkah-langkah:
1. Pertama-tama perhatian arahkan ke Browser
2. Menyiapkan use case diagram window: - Klick kanan Use case view
new uses case diagram memberi nama dobel klick
3. Membuat Actor:
● Klick kanan Use case view new Actor memberi nama
● Mengisi dokumentasi aktor: Pindahkan kursor di Window Document.
Ketikkan keterangan secukupnya, misalnya: “mahasiswa yang terdaftar
dalam semester”.
● Menempatkan aktor ke dalam use case diagram: Drag dan Drop Icon
Aktor ke dalam use case window.
● Lakukan beberapa kali sesuai jumlah Actor yang diinginkan
4. Membuat Use case:
● Klick kanan Use case view new Use case memberi nama
● Mengisi dokumentasi use case: Pindahkan kursor di Window
Document. Ketikkan keterangan secukupnya, misalnya: “Use ini
dimulai dari Mahasiswa. Digunakan untuk membuat dan atau melihat
jadwal mahasiswa yang terdaftar dalam semester”.
● Menempatkan Use case ke dalam use case diagram: Drag dan Drop
Icon use case ke dalam use case window.
5. Membuat komunikasi Association (Communicates Associations)
● Click icon Unidirectional Association dari diagram toolbar.

● Click pada pada Actor (yang berbperan sebagai pemula komunikasi),
dan drag garis association ke use yang dituju.
6. Membuat Include Relationships

● Tambahkan satu use case dan beri nama (misal: Validasi ueser)

● Click pada uses case utama dan drag Unidirectional Association icon
ke include use case ( misal: dari Form pendaftaran kuliah ke valiase
user)
● Click dobel pada garis panah Unidirectional Association untuk
menampilkan Specification.
● Click pada Stereotype untuk membuat menu drop-down tampil dan
pilih include.
● Click tombol OK untuk menutup Specification.
● Click kanan pada garis panah Unidirectional Association untuk
membuat menu shortcut muncul.
● Jika dekat garis panah tidak muncul <<include>>, maka dapat
dimunculkan tulisan tersebut dengan Click kanan check Stereotype
Label.
7. Membuat Extended Relationships

● Tambahkan satu use case dan beri nama (misal: Semester tidak ada)

● Click pada uses case utama dan drag icon Unidirectional Association
ke include use case ( misal: dari Form pendaftaran kuliah ke valiase
user)
● Click dobel pada garis panah ( )Unidirectional Association untuk
menampilkan Specification.
● Click Stereotype untuk membuat menu drop-down tampil dan pilih
exclude.
● Click tombol OK untuk menutup Specification.
● Click kanan pada garis panah Unidirectional Association untuk
membuat menu shortcut muncul.
● Jika dekat garis panah tidak muncul <<exclude>>, maka dapat
dimunculkan tulisan tersebut dengan : Click kanan pada garis panah
Unidirectional Association Click kanan check Stereotype Label.
B. Membuat Diagram Sequence

Sequence diagram merupakan diagram Interaksi yang dinyatakan dengan waktu, atau
dapat dikatakan dengan diagram dari atas (top) ke bawah (bottom). Setiap Sequence
diagram menyatakan salah satu dari beberapa aliran yang melalui sebuah use case.
Membuat window sequence diagram

1. Click kanan pada use case dalam model browser New Sequence diagram.
2. Selanjutnya beri nama untuk sequence diagram tersebut.
3. Click ganda pada sequence diagram untuk memulai pembuatan sequence diagram.
Menambahkan aktor dan obyek
Selanjutnya adalah membuat sequence diagramnya, sequence diagram berisi actors dan
objects:
1. Click pada Actor yang akan dibuatkan sequence diagramnya
2. Click pada tempat paling kiri dari window sequence diagram
3. Click icon object dari toolbar

4. Click di window sequence diagram beri nama
5. Lakukan penambahan obyek sesuai yang diinginkan
Penambahan Messages ke Sequence Diagram

Penambahan pesan (message) ke sequence diagram:
1. Pilih icon Object Message dari toolbar.
2. Drag dengan mouse dari object atau actor yang mengirim pesan ke object atau
actor yang menerima pesan.
3. Ketik teks pesan (message).
Membuat Sequence Diagram dari Collaboration Diagram

Dengan Rational Rose, hal ini sangat mudah untuk membuat sequence diagram dari
collaboration diagram, atau sebaliknya. Sekali sudah memiliki keduanya yaitu sebuah
sequence dan sebuah collaboration diagram untuk sebuah rancangan, maka hal ini
akan mudah untuk melakukan pertukaran antara keduanya.
Langkah membuat sequence diagram dari collaboration diagram:
1. Buka collaboration diagram.
2. Pilih Browse Create Sequence diagram, atau tekan F5.
3. Hasilnya akan dibuatkan sequence diagram nama yang sama seperti membuka
collaboration diagram.
Perpindahan antara sequence dan collaboration diagram:

1. Buka sequence atau collaboration diagram.
2. Pilih Browse pilih (Sequence atau Collaboration) Diagram, atau tekan F5.
3. Hasilnya akan kelihatan seperti sequence atau collaboration diagram dengan nama
yang sama seperti yang sedang diagram yang dibuka.
Menambah reflexive message ke sequence diagram
1. pilih icon Self dari toolbar.
2. Click pada garis object yang mengikirm dan yang menerima pesan (message),
lihat gambar dibawah.
3. Dengan pesan (message) baru yang masih terpilih, ketik teks pesan (message).
Memperbaiki Messages dalam Sequence Diagram
1. Pilih message untuk digeser.
2. Drag pesan (message) aarah naik atau turun dalam diagram. Hasilnya akan
dilakukan penomoran ulang secara otomatis.
Pemetaan Pesan (Message) ke sebuah Operasi (Operation)

Sebelum membentuk code, setiap pesan (message) dalam sequence dan colaboration
diagram harus dipertakan ke operasi dari kelas:
Memetakan pesan ke sebuah operasi yang sudah ada:
1. Yakinkan bahwa obyek yang menerima telah dipetakan ke sebauh class.
2. Click kanan pesan (message) dalam sequence atau collaboration diagram.
3. Sebuah daftar dari penyumbang operasi akan diperlihatkan.
4. Pilih operasi dari daftar. Lihat gambar dibawah.
Menghapus sebuah pesan dari operasi pemetaan:

1. Click dobel dari pesan dalam sequence atau collaboration diagram.
2. Dalam field Name, hapus nama operasi dan masukkan nams pesan baru.
Membuat operasi baru dari pesan:

1. Yakinkan bahwa obyek yang menerima telah dipetakan ke sebuah Class.
2. Click kanan pesan (message) dalam sequence atau collaboration diagram.
3. Pilih <new operation>
4. Masukkan nama operasi baru dan detailnya
5. Click OK untuk menutup operasi windows specification dan tambahkan operasi
baru.
6. Click kanan pada message
7. Pilih operasi baru dari daftar yang tampak.
Mencek setiap pesan telah dipetakan ke sebauh operasi:

1. Pilih Report Show Unresolved Messages
Hasilnya akan ditampilkan sebauh daftar dari semua pesan yang belum dipetakan ke
operasi.
C. Membuat Collaboration Diagram
Collaboration diagram digunakan untuk menunjukkan aliran melalui skenario khusus
dari sebuah use case. Fokus yang dikerjakan adalah relasi antar obyek.
Membuat Collaboration Diagram

Gambar dibawah menggambarkan bagaimana untuk membuat sebuah Collaboration
Diagram baru. Berikut urutan yang digunakan untuk membuat Collaboration Diagram
baru:
1. Click kanan pada use case dalam browser
2. Dari menu shortcut, pilih New Collaboration Diagram
3. Ketikkan nama Collaboration Diagram yang baru
4. Click dobel Collaboration Diagram baru dalam browser untuk membukanya.
Menghapus Collaboration Diagram

Ketika membuat model, mungkin akan ditemui beberapa collaboration diagram yang
dibuat tidak akurat atau dapat digunakan. Untuk memmbersihkan model dapat
dihapus beberapa collaboration Diagram dengan menggunakan browser. Berikut
langkah untuk menghapus collaboration diagram:
1. Click kanan collaboration diagram dalam browser
2. Pilih Delete dari menu shortcut.
Menambahkan beberapa file dan URL ke Collaboration Diagram

Dalam Rational Rose, dapat dilakukan penambahan sebuah file atau URL ke bagian
dari collaboration Diagram. Sebagai contoh, ada sebuah dokumen yang menerangkan
skenario tentang interkasi model-model diagram. Dengan menambahkan file yang
berisi beberapa code yang mengimplementasikan logika dalam diagram. Atau
mungkin menambahkan sebuah file kebutuhan yang berisi tentang beberapa
kebutuhan tentang ciri-ciri dari diagram. Berikut langkah untuk mengaitkan file ke
collaboration diagram:
2. Pilih New file
3. Gunakan dialog box Open pilih file yang ingin dikaitkan.
4. Pilih Open untuk mengaitkan file.
Mengkaitkan URL ke collaboration diagram:

2. Pilih New URL
3. Ketik nama URL yang ingin dikaitkan
Membuka file yang dikaitkan:
Click dobel file dalam browser. Rational Rose akan membuka aplikasi yang
diperlukan dan memanggil file.
Atau
1. Click kanan pada file dalam browser open.
Membuka URL yang terkait:

1. Click dobel pada nama URL di browser. Rational Rose akan otomatis membuka
web browser dan membuka alamat URL.
Atau
1. Click kanan pada URL dalam browser Open
Rational Rose akan otomatis membuka web browser dan membuka alamat URL.
Menghapus URL yang terkait:

1. Click kanan file atau URL dalam browser
2. Pilih Delete dari menu.
Menambah Actor ke Collaboration Diagram

Obyek Actor merupakan stimulus luar yang menyatakan sistem menjalankan
beberapa fungsi. Obyek Actor untuk Collaboration Diagram akan termasuk actor-
actor yang berhubungan dengan use case pada Use Case diagram. Untuk membuat
actor obyek pada collaboration diagram:
1. Buka collaboration diagram
2. Pilih actor dalam browser
3. Drag actor dari brower untuk membuak diagram
Menghapus Actor Obyek dari Collaboration diagram:

1. Pilih Actor pada collaboration diagram
2. Pilih Edit Hapus dari Model atau tekan Ctrl+D
Perlu diingat, menghapus sebuah obyek dari hubungan antar diagram tidak
menghapus hubungan class dari model.
Menambah obyek ke Collaboration Diagram
Jika obyek Actor telah ditambahkan ke diagram, maka tahap berikutnya adalah
menambakan ke obyek lainnya. Untuk menambahkan obyek ke collaboration
diagram:
1. Pilih icon obyek pada toolbar.

2. Click dilokasi mana dalam diagram untuk meletakkan obyek. Dalam collaboration
diagram, obyek dapat diletakkan dimana saja.
3. Tuliskan nama dari obyek tersebut.
Menghapus obyek dari collaboration diagram

Ketika menghapus obyek dari collaboration diagram, Rational Rose akan secara
otomatis menghapus beberapa pesan (message) yang memulai atau mengakhiri dari
obyek tersebut. Disamping itu, juga akan secara otomatis dilakukan penomoran ulang
semua message yang tersisa. Ketika sebuah obyek dihapus dari collaboration diagram,
rational rose akan menghapusnya dari sequence diagram. Langkah untuk menghapus
sebagai berikut:
1. Pilih ibyek daladm sequence atau collaboration diagram.
2. Pilih Edit Delete dari Model atau press Ctrl+D.
Sama dengan penghapusan Actor dari diagram, bahwa penghapusan obyek dari
diagram tidak menghapus hubungan class dari model.
Menampilkan icon stereotype dalam Collaboration Diagram

Menampakkan icon stereotype dari sebuah obyek dalam collaboration diagram:
1. Tentukan stereotype dari class yang akan diatur.
2. Cick kanan pada Class dalam Class diagram yang akan dikerjakan.
3. Pilih Options Stereotype Display Icon. Secara otomatis akan diubah tampilan
dari class untuk icon hubungan dari stereotype yang dipilih. Pilih Obyek yang
diinginkan dan click kanan dalam collaboration diagram
4. Dari menu shortcut, pilih Open Specification. Hasilnya dapat dilihat pada gambar
dibawah:
5. Tentukan class dimana obyek pilih dalam window Open Specification dan click
OK. Jika class yang dipilih telah diset untuk menampilkan icon stereotype, maka
tampilan di collaboration diagram akan berubah seperti gambar dibawah:
Menambah Message ke Collaboration Diagram
Sebelum menambahkan message ke collaboration diagram, harus dipastikan terlebih
dahulu bagian persambungan dari komunikasi antar dua obyek. Persambungan disebut
Link, dan dibuat menggunakan Object Link pada toolbar. Jika link telah ditambahkan,
maka message dapat dtambahkan diantara dua obyek tadi. Berikut urutan
menambahkan message:
1. Pilih icon Object Link pada toolbar.

2. Drag dari satu obyek ke obyek lain untuk membuat Link.
3. Pilih icon Link Message atau Reverse Link Message pada toolbar.
4. Click Link antara dua object. Hasilnya akan ditampilkan arah message, seperti
pada gambar dibawah.
5. Dengan pesan yang dipilih, ketikkan tipe teks dari message.
Menambahkan reflexive message ke collaboration diagram:
1. Pilih icon Link to Self pada toolbar

2. Click obyek pengirim dan penerima pesan. Hasilnya akan digambarkan reflexive
link pada obyek berupa garis setengah lingkar.
3. Pilih icon Link Message
4. Click Link Message pada obyek, maka akan ditambahkan arah message. Lihat
gambar dibawah.
5. Dengan pesan baru yang masihg terpilih, maka tuliskan teks pesan.
Jika menambahkan lebih dari satu reflexive message dari obyek dalam collaboration
diagram, maka lewati saja langkah 1 dan 2 untuk setiap penambahan pesan.
Menghapus pesan (message) dari Collaboration Diagram

1. Pilih message yang akan dihapus.
2. Pilih Edit Delete From Model. Atau tekan Ctrl+D.
Jika menghapus message dari collaboration diagram, maka secara otomatis akan
dilakukan penomoran ulang dari pesan yang tersisa.
Penomoran pesan (message) dalam collaboration Diagram

Penomoran pesan (message) bagi collaboration diagram sangat penting untuk
dilakukan, hal ini terjadi setelah tidak dilakukannya pembacaan dari atas ke bawah.
Sehingga jika penomoran pesan dihapus, maka collaboration diagram kehilangan
urutan informasi.
Pengaktifan dan penonaktifan penomoran pesan sesungguhnya tidak
direkomendasikan secara tertulis dalam rational rose, namun dapat dilakukan dengan
urutan sebagai berikut:
1. Pilih tools Options.
2. Pilih Diagram
3. Lakukan menset dalam Collaboration Numbering pada check box untuk on atau
off.
Menambahkan aliran data (Data Flow) pada Collaboration Diagram
Aliran data (Data flow)digunakan untuk menunjukkan informasi yang di pakai ketika
sebuah obyek mengirim pesan ke obyek yang lain. Seperti aturan pada umumnya,
tidak perlu memakan waktu banyak untuk kebingungan tentang aliran data saat ini
sebelum memetakan setiap pesan ke sebuah operasi dari Class. Tambahkan aliran data
ke diagram jika dipertimbangkan sangat signifikan dapat menolong bagi perancang.
Jika tidak membantu maka tinggalkan saja. Langkah menambahkan aliran dataa
dalam collaboration diagram sebagi berikut:
1. Pilih icon Data Flow atau icon Reverse Data Flow .

2. Click pada message yang akan ditambah data. Hasilnya secara otomatis akan
ditambah panah data flow ke diagram, lihat gambar dibawah.
3. Dengan data flow baru yang masih dipilih, ketikkan data yang akan dimasukkan.
D. Membuat Class Diagram
Class diagram memperlihatkan keberadaan dari class-class dan hubungannya dari
sistem dalam logical view. Class diperoleh dengan melakukan pengetesan pada
sequence dan collaboratin diagram.
Komponen Utama dari Class Diagram

Class Generalisation Aggregation
Membuat Main Class Diagram

Klick kanan Logical view new class diagram memberi nama(misal: Utama)
dobel klick
Membuat Class
1. Klick kanan Logical view new class memberi nama
2. Buatlah class tersebut dalam Class Diagram: Drag class ke dalam class diagram
yang terbuka.
atau
1. Memunculkan Class dari toolbar: pilih icon Class pada toolbar click
sekali pada Class diagram yang terbuka.
2. Memberi nama: Click dobel pada class tersebut pilih General tab dalam
window specification tuliskan nama yang diinginkan dalam kolom name.
Membuat Stereotype untuk Class (jika diperlukan)

1. Click kanan pada Class dalam browser Specification General pilih nama
Stereotype atau diketik tekan OK.
Dokumentasi Class
1. Menentukan Class yang akan diberi dokumentasi: Lihat daftar Class dalam
browser Click pada Class yang dipilih.
2. Menuliskan dokumentasi: Pindahkan kursor pada documentation window
tuliskan keterangan secukupnya. (misal: Seseorang yang terdaftar dalam semester
ini.)
atau
1. Lihat daftar Class dalam browser atau pada windows Class Diagram.
2. Click Dobel pada Class yang dipilih pilih General tab dalam window Class
specification tuliskan dokumentasi..
Membuat Relasi Association
1. Click icon Association pada toolbar.

2. Click pada salah satu Class yang akan diasosiasikan dalam Class Diagram
3. Drag garis Association ke Class yang diasosiasikan lainnya.
Membuat Relasi Aggregation
1. Pilih icon Aggregation dari toolbar

2. Click pada class yang memainkan peran secara keseluruhan dalam Class
Diagram dan drag garis aggregation ke Class yang memainkan peranan
sebagian.
Membuat Relasi Composition Aggregation

1. Pilih icon Aggregation dari toolbar
2. Click pada Class yang memerankan keseluruhan dalam Class Diagram dan Drag
garis aggregation ke Class yang memerankan secara sebagian.
3. Click kanan pada garis aggregation containment of … pilih Value
Memberi nama Relasi

1. Click garis relasi pada Class Diagram
2. Tuliskan nama relasi yang diinginkan
Membuat nama Peran
1. Menampilkan shortcut yang akan dimodifikasi: Click kanan pada garis relasi
dekat Class yang akan dimodifikasi.
2. Pilih Menu Role Name
3. Tuliskan nama peran yang inginkan
Membuat multiplicity
1. Click dobel pada garis relasi untuk memunculkan Specification
2. Pilih Menu Detail pada peran yang akan dimodifikasi (Detail Role A atau Role B)
3. Tentukan multiplicity yang diinginkan
Membuat Relasi Unary

1. Pilih icon Association (atau Aggregation) dari toolbar
2. Click pada Class dan drag garis Association (atau Aggregation) bagian luar dari
Class.
3. Click sekali Arahkan mouse ke Class asal click sekali
4. Tuliskan nama peran dan multiplicity untuk setiap akhir dari unary association
Membuat Association Class

Association class merupakan Class di sambungkan ke sebuah Association dengan
loop.
1. Click icon Class dari toolbar
2. Click pada diagram untuk menempatkan Class tuliskan namanya
3. Tambahkan attribut Class: Click kanan pada Class new attribut ketik nama
attribut
4. Menambahkan operasi Class: Click kanan pada Class new operation ketik nama
operasi
5. Click icon Link Attribut dari toolbar
6. Click pada association Class dan drag garis Link Attribut ke association yang akan
disambungkan.
Membuat Relasi Generalisation
1. Click icon Generalisation

2. Click pada satu subclass dan drag garis Generalisation ke superclass
3. Untuk setiap subclass yang merupakan bagian dari Generalisation: pilih icon
Generalisation dari toolbar click pada subclass dan drag garis Generalisation
ke ujung generali yang sudah terbentuk.
Menambahkan attribute ke suatu Class
1. Memilih Class pada Browser: Click sekali pada tanda plus (+) pada Logical View
agar terurai isinya. (jika Logical View sedang bertanda +, atau tidak terurai).
2. Pilih Class yang akan ditambahi attribute.
3. Membuka menu attribute: Click kanan dari class yang telah dipilih
4. Pilih New Attribute, dan Ketikkan attribute yang diinginkan.
5. Memberi tipe attribute: Click pada attribute yang baru saja ditambahkan.
6. Click kanan dan pilih menu open Specification.
7. Arahkan kursor ke tipe. Pilih tipe attribute yang diinginkan dengan membuka
menu option.
Menambahkan Operasi ke sebuah Class

1. Click kanan untuk memilih Class dalam Browser.
2. Pilih New Operation ketikkan operasi yang diinginkan.
E. Membuat Paket (Package)
Package digunakan untuk membuat grup dari class-class yang memiliki beberapa
kesamaan. Ada beberapa pendeketan berdasarkan kesamaan untuk membuat paket
class. Salah satu pendekatan yang digunakan adalah berdasarkan stererotype. Dengan
pendekatan ini, satu paket dapat berisi Entity Class, Boundary class, Control class,
dan sebagainya. Pendekatan yang lain yaitu berdasarkan fungsi. Sebagai contoh
sebuah paket bernama sekuriti, yang digrupkan dengan paket lain misal Employee
Maintenance, Reporting, atau Error Handling. Keuntungan dengan pendekatan ini
yakni dapat digunakan secara berulang.
Menambah paket
Paket (package) dibuat dalam Logocal View dari browser. Untuk menambahkan
sebuah paket yang sudah ada untuk Class diagram, pindahkan dengan men-drag
paket dari browser ke dalam Class Diagram.
Menambahkan paket yang baru ke Class diagram:
1. Pilih icon Package dalam toolbar

2. Click dimana saja dalam Class diagram untuk menempatkan paket.
3. Ketik nama Paket (package).
Menambahkan Paket ke Browser:

1. Click kanan Logical View dalam browser New Package ketik nama paket
Untuk menambahan paket dalam sebuah paket maka Click kanan pada paket yang
sudah ada dan ikuti langkah seperti diatas.
Menghapus Paket
Menghapus paket dari Class diagram:
1. Pilih paket pada Class diagram.
2. Tekan tombol Delete
Catatan:
Menghapus paket dari sebuah Class diagram, tidak otomatis menghapus paket pada
browser dan dalam class diagram yang lain.
Menghapus paket dari model:
1. Click kanan pada paket di browser Delete
Atau
1. Pilih paket pada Class diagram.
2. Pilih Edit Delete from Model, atau tekan Ctrl+D.
Membuat paket yang memiliki ketergantungan (Package Dependencies)
Sifat dependency merupakan tipe relasi yang hanya terjadi dalam menggambarkan
antar paket. Sebuah package dependency, seperti sebuah class dependency yang
digambarkan dengan panah bergari putus-putus. Sebuah package dependency dari
paket A ke paket B memberikan gambaran bahwa beberapa class dalmapaket A
memiliki unidirectional relationship ke beberapaclass dalam paket B.
Dengan kata lain, beberapa class dalam A ingin mengetahui beberapa class dalam B.
Membuat package dependency pada Class diagram:
1. Pilih icon Dependency dari toolbar.

2. Drag garis dependency dari paket yang terikat (dependent package) ke paket yang
lain.
Atau
1. Pilih Tools Create Dependency.
2. Drag garis dependency line dari dependent package ke yang lain.
Menghapus Package Dependencies

1. Pilih package dependency yang ingin dihapus
2. Tekan tombol Delete.
Atau
1. Pilih package dependency yang ingin dihapus
2. Pilih Edit Delete.
F. Membuat Component diagram
Komponen dari Component Diagram yaitu:
paket Komopnen
Dependency relasi
Component diagram merupakan gambaran secara fisik dari model yang sedang
dibangun.
Componen Diagram menunjukkan dari organisasi dan keterikatan dari komponen-
komponen perangkat lunak, meliputi komponen-komponen source code, komponen-
komponen code biner, dan komponen-komponen executable. Keterikatan antar
komponen merupakan ikatan hubungan antara komponen-komponen dengan
interface terhadap komponen-kompone yang lain.
Membuat Componen diagram

1. Klik kanan pada package New Component Diagram beri nama pada component
diagram yang baru dibuat. Maka akan muncul icon di browser.

Menambahkan Paket
1. Pilih icon paket dalam toobar
2. Click pada Component Diagram dimana paket diinginkan.
Penambahan elemen model yang lain dapat dilakukan dengan cara sama seperti diatas
seperti menggunakan:
● icon untuk component
● icon untuk paket body
● icon untuk task body
● icon untukmain program
● icon untuk subprogram.
G. Membuat Deployment diagram

Komponen deployment diagram
Processor Device Connection
Deployment diagram menampilkan processors, devices, and connections. Setiap

model berisi deployment diagram tunggal yang menunjukkan hubungan antara
processor and device dan penempatan dari processe to processor.
Processor merupakan komponen perangkat keras yang mampu mengeksekusi

program.
Device merupakan perangkat keras yang tidak memiliki kemampuan untuk
memproses. Setiap device memiliki nama yang dapat bersifat umum seperti: modem,
terminal, dll.
Sebuah connection menunjukkan sebuah bagian komunikasi antara dua prosesor, dua
device, atau sebuah prosesor dan sebauh device. Sebuah connection biasanya
menyatakan penggandengan hardware secara langsung, seperti kabel RS232, dan
dapat juga menyatakan penggandengan yang tidak langsung.
Membuat deployment diagram :

1. Membuat deployment diagram: click dobel pada deployment view dalam browser
model.
2. Untuk membuat node: Click icon processor pada toolbar Click di

deployment diagram untuk menempatkan node beri nama pada node yang baru
dibuat.
3. Untuk membuat koneksi : Click icon connection pada toolbar Click Node
yang merupakan „client‟ drag (connectin line) ke node yang merupakan
„supplier‟ Click dobel tuliskan nama koneksi tekan OK.
Mengatur sifat dan hubungan dari prosesor dalam model:

1. Pilih icon processor pada deployment diagram atau pada browser Click dobel
Dengan langkah seperti diatas dapat dibuat 5 buah node yaitu : Registration,
Database, Main Building, Dorm, Library. Kelima node ini terkoneksi sebagai berikut :
Node Connected to Node

Registration Database
Registration Main Building
Registration Dorm
Registration Library
Hasilnya seperti pada gambar berikut :
H. Pembuatan Database Diagram dan Generate Script SQL

Salah satu fasilitas dari Rational Rose adalah menyediakan suatu database
diagram serta menyediakan fitur generate ke script SQL.
Berikut ini adalah langkah-langkah yang harus dilakukan untuk membuat
database diagram dan script SQL:
1. Pada Package Component view klik kanan kemudian Data Modeler
kemudian New Database.
2. Setelah database dibuat pada component view akan ada suatu database
dengan default name DB_0. Kemudian klik kanan DB_) kemudian rename
menjadi Oracle kemudian klik Open Spesification dan ubah target databasenya
menjadi Oracle 8x dan klik Ok.
3. Setelah membuat dan mengatur properties dari database. Langkah

selanjutnya adalah membuat shcema database dengan cara klik kanan pada
package schema yang ada pada logical view kemudian pilih Data Modeler 
New  Schema (lihat pada Gambar dibawah). Setelah itu klik kanan pada
schema baru yang telah dibuat kemudian ubah namanya menjadi Oracle dan
Target databasenya menjadi Oracle juga (lihat Gambar dibawah)
4. Ketika Schema sudah dibuat dan propertiesnya sudah diatur, langkah
selanjutnya adalah melakukan transform ke data model. Tapi sebelumnya clas-
clas yang bersifat entity yang akan ditransform diubah datanya terlebih dahulu
dengan cara klik kanan pada class entity yang bersangkutan kemudian open
standar spesification  Class Specification for Dosen kemudian masuk ke Tab
Detail dan ubah persistance dari transient ke Persistent (lihat Gambar dibawah)
5.Setelah mengubah class specification class-class yang bersifat entity maka
klik kanan pada package design model kemudian Data Modeler dan Transform
to Data Model sehingga akan muncul properties untuk Transfor Object Model
to Data Model (lihat Gambar dibawah). Setelah itu ubah properties Destination
Schema ke Oracle dan Target database ke Oracle juga. Kemudian klik Ok.
6. Untuk memeriksa apakah transformasi model berhasil bisa dicek pada
schema Oracle, jika berhasil maka Schema Oracle akan berisi tabel-tabel:
T_Dosen, T_Mahasiswa, T_Perkuliahan (lihat Gambar)
7. Setelah proses transformasi ke data model, langkah selanjutnya adalah
membuat database diagram yaitu dengan cara klik kanan pada packages
schemas kemudian pilih Data Modeler  New  Data Model Diagram.
Setelah Data Model Diagram dibuat klik data model diagram kemudian
masing-masing tabel di drag ke Data Model Diagram (lihat gambar)
8. Langkah terakhir setelah database diagram dibuat adalah generate script

SQL. Caranya yaitu klik kanan pada schema kemudian Forward Engineer
sehingga muncul Forward Engineering Wizard seperti berikut:
Setelah itu klik Next:
Kemudian pilih directory penyimpanan file script SQL:
Klik Next
Kemudian klik Next Lagi dan Finish:
Script SQL yang telah dibuat adalah seperti dibawah ini:
I. Generate Data Model ke Visual Basic Tool

Untuk melakukan generating code ke Visual Basic code, ada beberapa langkah
yang harus dilakukan yaitu:
1. Melakukan Component Assignment Tool
Component Assignment tool berfungsi untuk mengubah unsigned class ke
dalam bentuk class-class yang termasuk dalam suatu bahasa Visual Basic.
Untuk melakukan Component Assignment tool klik Tool kemudian Visual
Basic  Component Assignment Tool (lihat gambar)
Setelah klik Component Assignment tool maka akan muncul pengaturan seperti
Langkah selanjutnya adalah klik unsigned class kemudian akan terlihat class-
clas yang belum diassignment. Setelah klik pada class tersebut dan drag ke
visual basic yang ada di sebelah kiri, lakukan hal ini untuk semua class-class
yang ada pada unsigned class. Setelah class di drag maka pada menu visual
basic kiri akan keluar menu project 1, pastikan bahwa class-class lainnya di
drag pada project 1 bukan pada visual basic karena akan menghasilkan project
baru (lihat gambar)
Setelah semua class di-assign ke project1, kemudian klik Ok.
2. Langkah setelah melakukan assignment tool adalah mengubah stereotype

pada properties class spesification menjadi Form jika class tersebut akan
dijadikan suatu form, atau jika suatu class akan dijadikan class module maka
ubah stereotype class-nya menjadi class module. (lihat gambar)
3. Langkah terakhir dari generating code ini adalah melakukan update code,
berikut inia dalah langkah-langkah untuk melakukan update code:
Klik pada tools  Visual Basic kemudian update code
Setelah orm code update tool muncul, kemudian klik next, setelah itu akan
muncul project visual basic yang akan digenerate, beri tanda check pada project
1 kemudian klik Next
Langkah update code yang terakhir adalah FINISH, klik finish maka code
visual basic akan langsung digenerate
4. Setelah tombol Finish di klik maka code visual basic akan langsung
digenerate tapi sebelumnya Rational Rose akan meminta konfirmasi
penyimpanan file. Simpanlah file rational yang baru dengan nama baru
kemudian close form update code. Contoh hasil code visual basic dapat dilihat
BAB IV CONTOH KASUS PENGGUNAAN UML
Studi Kasus sebuah Perguruan tinggi ingin menerapkan komputerisasi sistem

pendaftaran dengan persyaratan sebagai berikut:
● Petugas pendaftaran mengatur kurikulum pada suatu semester. (Satu
matakuliah dapat ditwarkan beberapa kali, One course may have multiple
course offerings)
● Mahasiswa memilih 4 mata kuliah wajib dan 2 pilihan
● Sekali terdaftar untuk suatu semeter, maka sistem pembayaran akan mencatat
mahasiswa sehingga mahasiswa sudah tercatat dalam semeseter tersebut.
● Mahasiswa dapat menggunakan sistem untuk menambah atau membatalkan
mata kuliah pada waktu tertesntu setelah pendaftaran
● Dosen menggunakan sistem untuk menerima daftar matakuliah yang
ditawarkan dalam semester tersebut.
● Pengguna Sistem Pendaftaran diamankan dengan password pada saat login.
Langkah-langkah merancang model

1) Memahami suatu sistem meliputi: jenis-jenis dan aliran kegiatan yang terjadi di
dalam sistem. Tahap ini untuk identifikasi jenis-jenis kejadian, aktor, use case dan
hubungannya. Misalnya untuk studi kasus diatas, user story berdasarkan hasil
observasi, wawancara dan kuesioner adalah sebagai berikut:
Petugas Pendaftaran mengatur kurikulum pada suatu semester
Mahasiswa memilih 4 mata kuliah wajib dan 2 pilihan
Sekali terdaftar untuk suatu semeter, maka sistem pembayaran akan mencatat
mahasiswa sehingga mahasiswa sudah tercatat dalam semeseter tersebut.
Mahasiswa dapat menggunakan sistem untuk menambah atau membatalkan mata
kuliah pada waktu tertentu setelah pendaftaran
Dosen menggunakan sistem untuk mengajar sesuai daftar matakuliah yang
ditawarkan dalam semester tersebut.
Pengguna Sistem Pendaftaran diamankan dengan password pada saat login.
2) Menentukan seseorang Actor dan Use case.
Actor: berupa orang atau sesuatu yang harus atau selalu berinteraksi dengan
sistem yang dibangun. Actor: Petugas pendaftaran, Dosen, Mahasiswa, Sistem
Pembayaran.
Use Case: adalah pola atau bentuk terhadap perilaku atau yang menunjukkan
sistem. Setiap Use case merupakan sebuauh deretan dari transaksi-transaksi yang
terkait dari sebuah actor dan sistem dalam sebuah dialog. Actor dapat digunakan
untuk menentukan kebutuhannya:
Petugas Pendaftaran mengatur kurikulum
Dosen mengajar sesuai daftar kuliah
Mahasiswa mengatur jadwal (memilih matakuliah)
Sistem pembayaran menerima informasi pembayaran dari pendaftaran
3) Menuliskan dokumentasi uses case.

Sebuah dokumen menunjukkan urutan kejadian yang terbentuk dari setiap uses
case dan didapat berdasarkan catatan penting dari setiap Actor. Dokumen
merupakan rincian dari sistem untuk melayani Actor ketika Use Case dieksekusi.
Isi dokumen dapat berisi beberapa bentuk antara lain:
Bagaimana Use Case mulai dan berakhir
Aliran normal dari kejadian (event)
Aliran alternatif dari kejadian
Aliran pengecualian dari kejadian
Dokumentasi use case mengatur jadwal:
Berdasarkan daftar matakuliah yang ditawarkan pada suatu semester, mahasiswa
diberi kesempatan untuk memilih 4 matakuliah wajib dan 2 matakuliah pilihan
sesuai yang minatnya. Dari matakuliah yang dipilih mahasiswa dapat mengatur
jadweal agar tidak ada kuliah yang bersamaan. Jika ada yang tidak cocok selama
kuliah mahasiswa dapat melakukan perubahan pada waktu yang ditentukan.
Dokumentasi use case Mengajar sesuai jadwal:
Dosen menerima daftar matakuliah yang harus diajarkan, dan memenuhi
kewajiban mengajar sesuai jadwal yang sudah ditentukan oleh kabag pendaftaran.
Dokumentasi use case Mengatur kurikulum:
Kabag pendaftaran membuka arsip matakuliah yang akan diselenggarakan pada
semester tertentu dan menawarkan kepada dosen untuk menambah atau
mengurangi kuliah yang diselenggarakan.
4) Menganalisa aliran kejadian dalam use case.

Use case dimulai ketika Petugas login ke sistem pendafaran dan memasukkan
password. Sistem akan selalu mencek sampai password betul dan akan meminta
Petugas untuk memilih menu semester yang sedang berlangsung atau yang akan
datang. Petugas memasukkan pilihan semester yang diinginkan.
Sistem meminta kepada Dosen untuk menentukan pilihan aktivitas yang
diinginkan yaitu: Tambah, Hapus, Lihat, atau Keluar.
Jika aktivitas Tambah dipilih, P-1: Sub-aliran Tambah Kuliah tampil
Jika aktivitas Hapus dipilih, P-2: Sub-aliran Hapus Kuliah tampil
Jika aktivitas Lihat dipilih, P-3: Sub-aliran Lihat Kuliah tampil
Jika aktivitas Keluar dipilih: Use case selesai.
Membuat use case diagram yang berisi uses case dan actor, serta hubungan antara
uses-case dangan use-case atau use case dengan actor.
5) Merealisasikan interaction diagram sequence: sequence diagram dan collaboration
diagram.
a. Sequence diagram : menggambarkan interaksi obyek yang disusun dalam suatu
deretan waktu. Obyek disni berupa: Aactor dan Class. Untuk menggambarkan
sequence diagram setiap aktor didefinisikan aktifitasnya urut berdasarkan waktu.
Aktor Mahasiswa untuk memilih matakuliah melakukan proses:
Mengisi semua isian yang terdapat pada lembar pendaftaran
Menyerahkan lembar pendaftaran tersebut
Kabag pendaftaran menerima pendaftaran,dan menambahkan data mahasiswa dan
matakuliah yang diambil.
Message yang dibentuk dari aktivitas tersebut :
Mahasiswa form pendaftaran, message: menulis isian
Mahasiswa form pendaftaran, message: menyerahkan
Form pendaftaran kabag pendaftaran, message: daftar kuliah(nama,kuliah)
Kabag pendaftaran matakuliah, message: apakah diadakan?
Kabag pendftaran matakuliah, message: daftar (nama,kuliah)
Aktor Dosen melakukan aktivitas:
Membaca daftar kuliah yang ditawarkan
Melakukan modifikasi kuliah jika diperlukan
Mengajar sesuai matakuliah yang ditawarkan sesuai tugasnya
Aktor Sistem Pembayaran melakukan aktivitas:
Menerima informasi dari sistem pendaftaran tentang mahasiswa
Mencatat daftar matakuliah yang diambil
Menghitung besar biaya yang harus dibayar oleh mahasiswa
Aktor Kabag Pendaftaran melakukan aktivitas:
Login ke sistem
Menentukan pilihan semester
Menawarkan daftar matakuliah pada semseter tertentu ditawarkan ke dosen
b. Collaboration diagram: menggambarkan interaksi obyek yang diorganisasikan

di sekitar obyek-obyek dan hubungan antar mereka. Berdasarkan sequence
diagram maka dapat dibuat collaboration diagram sbb:
6) Membuat class diagram.
Yang perlu dilakukan dalam membuat class dengan langkahnya adalah:
Class merupakan sekumpulan dari obyek yang berupa: atrribut, perilaku, relasi,
dan semantik. Menentukan class dengan menguji keberadaannya dalam sequence
dan collaboration diagram.Nama domain diawali huruf Kapital dan ditentkan
berdasarkan domainnya.
a. Menentukan class:
FormPendaftaran; form yang mengandung informasi khusus tentang mata kuliah
yang ditawarkan.
Kabag_Pendaftaran, orang yang memiliki tanggungjawab untuk mendaftar
mahasiswa ke matakuliah tertentu.
Matakuliah, matakuliahyang diselenggarakan pada semester tertentu.
FormPilihanMengajar; form yang berisi pilihan semua mata kuliah yang tersedia
bagi aktor
Dosen.
Matakuliahpilihan, daftar matakuliah yang ditawarkan pada semeseter tertentu.
b. Menentukan operasi dari class:
FormPendaftaran : menulis isian, menyerahkan
Kabag_pendaftaran: daftar kuliah
Matakuliah: Apakah dilaksanakan, daftar(mahasiswa)
c. Menentukan attribut dari class:

Form Pendaftaran: NamaMHs,kuliahpilihan,sks,semester
Kabag Pendaftaran: Nama,NIP
Matakuliah: KodeMK,NamaMK, sks,Dosen
MatakuliahPilihan: Jumlah,KodeMK,NamaMK,Kelas,Hari,Jam
DaftarPilihanMengajar: Semester,kodeMK,namaMK, sks
d. Membuat Relasi
e. Membuat Multiplicity
Multiplicity mendefiniskan banyaknya obyek berpartisipasi dalam relasi
7) State transtition Diagram
State transition diagram menunjukkan: Sejarah yang diberikan oleh class,
Kejadian yang menyebabkan sebuah transisi terjadi dari satu state ke state yang
lain dan Sebuah aksi yang dihasilkan dari perubahan state.
8) Membuat Component Diagram
Component diagram menggambarkan pengorganisasian dan keterkatan dari
komponen perangkat lunak . component dapat berupa: source code component, run
time component dan executable component
9) Membuat Deployment Diagram
Deployment Diagram menggambarkan tentang konfigurasi dari elemen-elemen

pemroses yang „run-time‟ dan proses-proses perangkat lunak yang ada padanya.
BAB V DOKUMENTASI SISTEM PERANGKAT LUNAK
A. Dokumen Request For Proposal (RFP) Standard

RFP adalah set dokumen yang disiapkan oleh pihak Project Sponsor atau Pemilik
Proyek) untuk meminta proposal penawaran produk sistem aplikasi yang diinginkan
dari para pengembang. Dalam hal ini pengembang harus menyediakan data dan
informasi minimal seperti yang sudah dipersyaratkan dalam RFP tersebut.
Pengembang boleh saja menulis dalam format berbeda dari format yang disarankan di
RFP standard, sepanjang kandungan isi data dan informasinya mencukupi, sesuai
yang dibutuhkan.
Biasanya, sebuah dokumen RFP akan terdiri dari beberapa bagian dokumen sebagai
berikut:
a. Dokumen Pendahuluan yang berisi latar belakang, maksud dan tujuan, stakeholders
terkait, pemilik proyek dan penjelasan tentang sistem aplikasi perangkat lunak seperti
apa yang akan dibangun.
b. Dokumen Spesifikasi Teknis, yang biasanya berisi spesifikasi teknis dari sistem
aplikasi yang akan dikembangkan.
c. Dokumen Tim Tenaga Ahli (atau Experience List) yang berisi profile singkat mitra
pengembang dalam bentuk daftar pengalaman pengembang dalam membangun sistem
aplikasi, aplikasi apa saja yang sudah pernah dibangun dan sudah dipasang dimana
saja. Atau bisa juga berisi daftar sertifikasi kompetensi yang harus dimiliki oleh
pengembang, dimana koompetensi ini dibutuhkan dalam pengembangan sistem
perangkat lunak yang akan dibangun.
d. Dokumen Jadwal Pelaksanaan Pekerjaan; yang berisi jadwal yang harus disanggupi
mitra pengembang dalam membangun system aplikasi. Biasanya menggunakan
perhitungan kalender hari kerja.
e. Dokumen Anggaran Biaya (atau Schedule of Rate), yang berisi standar item
minimal penawaran yang diajukan
Bagian lain yang bersifat opsional dalam RFP adalah Dokumen Compliance Check
List) yang berisi matrik daftar pemenuhan kebutuhan antara spesifikasi/fitur yang
ditawatkan mitra pengembang dengan kebutuhan pengguna yang didokumentasikan
dalam dokumen Spesifikasi Kebutuhan.
Contoh Template Dokumen RFP
1. Halaman Cover
[Judul Dokumen]
Contoh: “Kerangka Acuan Kerja [nama sistem aplikasi] Organisasi [Nama
Organisasi]
Disiapkan Oleh: .....; Rev: ..................; Dok No:...........; Tanggal: dd-mm-yyyy
2. Daftar Isi
3. Daftar istilah/singkatan yang dipergunakan dalam dokumen tersebut
4. Daftar Gambar/tabel
5. Pendahuluan
a. Ulasan umum tentang sistem aplikasi e-Government
b. Konsep solusi
c. Konsep rancang bangun
d. Konsep security
Penjelasan: Deskripsi sistem meliputi fungsi umum, fitur unggulan, kemudahan/manfaat bagi
pengguna, keunggulan komparatif
6. Referensi
a. Peraturan dan perundangan
b. Buku Teks dan Paper Acuan
c. Acuan Website Resmi
Penjelasan: Rujukan ke peraturan dan perundang-undangan dan lainnya yang menjadi dasar rancangan
sistem aplikasi
7. Deskripsi Umum Sistem Aplikasi
a. Deskripsi Proses Bisnis
b. Deskripsi Fungsional Sistem Aplikasi
c. Deskripsi Arsitektur dan platform
Penjelasan: Deskripsi (biasanya dalam gambar model terkait). Deskripsi Proses Bisnis menggambarkan
proses bisnis organisasi pengguna sistem aplikasi. Deskripsi sistem meliputi arsitektur sistem aplikasi.
Platform basis data, platform komputer, bahasa pemrograman, presentasi user interface. Contoh:
Platform komputer misalnya desktop PC, PIII 800MHz, 256MB memori, CDRW, Multimedia,
Platform OS misalnya Windows 2000, Linux, IBM Unix; Platform Basis Data misalnya Oracle 9,
MsSQL, MySQL, DB2; Platform software server lain misalnya web server Apaceh, IIS; Bahasa
Pemrograman Microsoft.Net; Semua presentasi menu user interface dalam Bahasa Indonesia, Jika
arsitekturnya client/server atau distributed application/dbase, sebutkan juga spesifikasi server dan
clientnya
8. Spesifikasi Teknik
a. Spesifikasi Umum: Fungsional, Antarmuka, Basis Data, Adaptive;
b. Spesifikasi Non Fungsional: Reliability, Interoperability, Scalability, Flexibility,
User Friendlines;
c. Informasi lainnya, misalnya Jaminan operasional, Dukungan teknis, Pelatihan,
Pemeliharaan
9. Dokumen Pengalaman Pengembang
Penjelasan: Dokumen pengalaman pengembang bisanya terdiri dari dua bagian. Bagian Pertama berisi
tentang persyaratan sertifikasi kompetensi dan lama pengalaman yang diwajibkan dari setiap anggota
tim pengembang. Bagian kedua berisi daftar pengalaman pengembang dalam mengerjakan proyek
sistem aplikasi. Bagian kedua ini merupakan rangkuman dari pokok-pokok informasi sebagai berikut:
a. Pengalaman dalam membangun sistem aplikasi atau sistem aplikasi lainnya yang serupa / mirip /
sejenis dengan sistem aplikasi.
b. Tempat dipasangnya sistem aplikasi tersebut beroperasi di tempat pengguna, misalnya kapan tanggal
mulai diimplementasikannya sistem aplikasi tersebut di tempat penggunanya.
c. Sudah berapa lama sistem aplikasi tersebut beroperasi di tempat pengguna, misalnya kapan tanggal
mulai diimplementasikannya sistem aplikasi tersebut di tempat penggunanya
Ketiga kategori informasi tersebut dapat dirangkum dalam sebuah Tabel sebagai berikut:
Keterangan:
1. Jenis sistem aplikasi
eGov = eGovernment, sistem aplikasi e-Government; Sim = Similar, bukan sistem aplikasi e-Government, tetapi dianalogikan
serupa, sejenis dengan sistem aplikasi e-Government; Diff = Different, bukan sistem aplikasi e-Government, dan tidak dapat
dianalogikan/tidak serupa/tidak sejenis dengan sistem aplikasi e-Government
2. Status sistem aplikasi
COTS = Commercialy Off The Shelf; sudah dibangun dan sudah ada di pasaran, tinggal dibeli dan dipasang tanpa perlu usaha
modifikasi atau kustomisasi yang memerlukan kompilasi ulang source code dari sistem aplikasi tersebut; Mod = Modification;
basis/aplikasi dasar sudah ada, tetapi untuk dapat dipasang dan dipergunakan di tempat pengguna harus dilakukan modifikasi
atau kustomisasi sulu yang memerlukan kompilasi ulang source code dari sistem aplikasi tersebut; Dev = Development;
basis/aplikasi dasar belum ada, sehingga untuk dapat dipasang dan dipergunakan di tempat pengguna, sistem aplikasi tersebut
harus dikembangkan terlebih dahulu.
3. Modifikasi
- Pengaturan atau setting komputer, setting nilai default atau data awal atau pembuatan file konfigurasi atau pekerjaan sejenisnya
tidak termasuk atau tidak dianggap sebagai modifikasi
- Modifikasi dalam jumlah dan volume pekerjaan yang cukup besar dianggap sebagai pengembangan aplikasi baru
10. Dokumen Penjadwalan Proyek
Penjelasan: Dokumen ini menjelaskan jadwal pengembangan yang diusulkan oleh kontraktor/vendor
mitra pengembang/vendor, dimulai dari penandatanganan kontrak sampai dengan instalasi. Sedangkan
jadwal pelatihan, dapat diusulkan dulu, bersifat tentative. Pelaksanaan pelatihan nantinya harus
dikoordinasikan dengan pihak pengguna, kesiapan hari dan jadwal pengguna, fasilitas belajar-
mengajar, dan lain-lain. Dalam jadwal yang ditawarkan, kontraktor/mitra pengembang/vendor sangat
dianjurkan untuk memberikan opsi untuk pengiriman paket sistem aplikasi dalam beberapa kali
tahapan (incremental release). Misalnya sistem aplikasi dikirim dalam 2 tahapan. Pengiriman tahap
pertama mencakup seluruh fungsi utama sistem aplikasi sedangkan pengiriman kedua merupakan
tambahan-tamabahn rinci seperti onlie help, wizard, dan/atau fitur-fitur yang bersifat add-on lainnya.
Pengiriman secara bertahap dimaksudkan sebagai salah satu mekanisme untuk menyediakan prototype
sedemikian sehingga pengguna mendapat kesempatan untuk mengevaluasi sistem aplikasi tersebut
sebelum akhirnya diserahkan dan dipasang serta beroperasi penuh di tempat pengguna.
Jadwal minimal harus mencantumkan kegiatan/aktivitas penting seperti:
- Penandatanganan kontrak,
- Evaluasi awal sistem aplikasi (ditahap ini pengembang menyerahkan seluruh rancangan, termasuk
rancangan user interface untuk dievaluasi dan disetujui oleh pengguna);
- Audit (ditahap ini pengembang harus memebrikan kesempatan kepada pengguna minimal satu kali
untuk melakukan audit terhadap proses pengembangan yang dilakukan di tempat pengembang, terlepas
dari apakah audit tersebut nantinya benar-benar dilaksanakan atau tidak
- Evaluasi Akhir sistem aplikasi (ditahap ini pengembang harus menyerahkan dan memasang sistem
aplikasi versi beta di tempat pengguna untuk evaluasi dan mendapatkan masukan-masukan dari
pengguna)
- Pengujian Penerimaan (ditahap ini pengembang harus memberikan kesempatan kepada pengguna
minimal satu kali untuk melakukan audit terhadap kelengkapan produk yang akan diserahkan baik
kelengkapan fungsional ataupun kelengkapan fisik seperti dokumentasi, dan lain sebagainya)
- Dan lain-lain aktivitas/kegiatan yang menurut pengembang dianggap perlu dan penting untuk
diketahui, misalnya masa pengembangan, pengujian dan integrasi.
11. Dokumen Penawaran Harga (atau Anggaran)

Penjelasan: Dokumen ini berisi informasi tentang rincian pekerjaan yang ditawarkan oleh
kontraktor.mitra pengembang/vendor dalam ikut serta membangun sistem aplikasi untuk pengguna.
Dokumen Penawaran Harga berisi informasi-informasi sebagai berikut:
a. Identifikasi, berisi informasi tentang nama sistem aplikasi yang ditawarkan dan identifikasi proyek
jika ada
b. Daftar Harga, beriisi rincian daftar harga pekerjaan yang ditawarkan
c. Harga Penawaran, berisi rangkuman harga penawaran
Contoh formulir penawaran
Nama Proyek: .................
Nama Sistem Aplikasi: ..................
Daftar Harga
Item Uraian Satuan Harga Satuan (rp)
I Pengembangan sistem aplikasi Lumpsum
I.1 Pembuatan perangkat lunak
I.2 Instalasi dan Pengujian
I.3 Dokumen Pendukung Operasi
dan Pemeliharaan
II Pelatihan
II.1 Pelatihan Wajib (Operator dan Kelas
Administrasi)
II.2 Pelatihan Tambahan Kelas
III Jaminan Operasional Tahun
(termasuk koreksi bugs, re-
install, re-configure, dll)
IV Dukungan Teknis
IV.1 Dukungan teknis tahun pertama
IV.2 Dukungan teknis tahun kedua dst Tahun
Harga Penawaran:
Item Uraian QTY Satuan Harga (Rp)
I Pengembangan Aplikasi Lumpsum
II Pelatihan Wajib 1 Kelas
III. Jaminan Operasional 1 Tahun
IV. Dukungan Teknis 1 tahun
12. Penutup. Penutup berisi penjelasan tentang hal-hal yang belum sempat dijelaskan
pada bagian sebelumnya.
13. Bagian Optional yakni Dokumen Compliance Check List.
Penjelasan: Biasanya dokumen ini terdiri dari dua bagian. Yakni bagian dokumen referensi milik mitra
pengembang, dokumen referensi milik pemilik proyek dan Tabel Compliance.
1. Dokumen referensi milik mitra pengembang/vendor yang berisi (a) spesifikasi produk sistem
aplikasi, rev:...., tanggal: dd-mm-yyyy; (b) Dokumen-dokumen penunjang lainnya yang menerangkant
entang spesifikasi, fitur atau kemampuan sistem aplikasi
2. Dokumen refernsi milik proyek sponso yang berisi: (a) Spesifikasi kebutuhan pengembangan sistem
aplikasi; (b) Dokumen-dokumen lain yang menerangkan kebutuhan Pemda akan sistem aplikasi
tersebut berkaitan dengan spesifikasi, fitur atau kemampuan sistem aplikasi
3. Tabel Compliance
Berikut disajikan contoh table compliance yang disarankan:
Par : paragraph
C : comply/terpenuhi/sesuai
NC: Not Comply/tidak terpenuhi/tidak sesuai/tidak ada/belum diimplementasikan
B. Dokumen Spesifikasi Kebutuhan Pengembangan Sistem Aplikasi

User Specification Requirements Document (atau sering disingkat SRS) adalah
dokumen yang disiapkan oleh tim pengembang untuk mengidentifikasi,
mengelompokkan dan mencatat semua kebutuhan pengguna.
- Semua kebutuhan (fitur yang diinginkan) dapat dituliskan disini, termasuk
didalamnya adalah: - Masalah dan kendala yang ada saat ini, yang ingin
diselesaikan/diatasi dengan sistem aplikasi yang akan dibangun atau dibeli;
- Hubungan sistem aplikasi yang akan dibangun atau dibeli dengan sistem yang
sudah ada, bagaimana cara membangun sinergi (membangun komunikasi antar
sistem) diantara mereka;
- Laporan-laporan standar yang harus disediaakan oleh sistem aplikasi, baik
berdasarkan format dan isi pelaporan yang sudah ada saat ini atau format pelaporan
baru yang diinginkan. Termasuk disini adalah pelaporan-pelaporan khusus yang
dibutuhkan untuk keperluan sistem pendukung keputusan (DSS: Decision Support
System), publikasi data ke masyarakat (internet), press release atau keperluan
publikasi data internal;
- Tampilan user interface yang diinginkan (jika ada permintaan khusus) misalnya:
semua menu memakai Bahasa Indonesia, panduang bantuan online dalam Bahasa
Indonesia, tampilan yang lay outnya (atau themenya) dapat diubah-ubah, dan lain-
lain; Pemakaian basis data (jika ada permintaan khusus), misalnya: harus pakai,
tata cara akses ke basis data (DBA: Database Administrator) dan lain-lain;
- Kebutuhan-kebutuhan khusus lainnya, misalnya pengaturan nilai parameter sistem,
format jam dan tanggal yang bisa diubah-ubah dan lain-lain
Contoh template Spesifikasi Kebutuhan Pengembangan Sistem Aplikasi
1. Halaman Cover
Penjelasan:
[Judul Dokumen]
Contoh: “Spesifikasi Kebutuhan Pengembangan Sistem Aplikasi {nama sistem aplikasi}
2. Identifikasi Sistem
Penjelasan: Dokumen ini berisi daftar spesifikasi kebutuhan sistem aplikasi [nama sistem aplikasi yang
dikembangkan] dengan identifikasi berikut:
Nama Proyek: [nama proyek pengembangan software tsb]
Nama Produk: [nama/brand produk sistem aplikasi yang diinginkan]
ID Produk: [id produk, jika ada, sesuai aturan organisasi]
3. Deskripsi Sistem
Penjelasan: Deskripsi singkat tentang proses bisnis dari sistem perangkat lunak yang akan
dikembangkan. Proses bisnis yang dijelaskan berupa proses bisnis organisasi pengguna sistem
perangkat lunak, proses bisnis manual (as-is system) dan proses bisnis yang akan berubah (to be
system). Juga ditambahkan penjelasan singkat tentang manfaat fungsional dari sistem aplikasi yang
akan dikembangkan. (tambahan dari Bagian 2 ini adalah Lampiran Executive Summary)
4. Arsitektur [nama sistem aplikasi]
Penjelasan: Deskripsi singkat yang memuat hal-hal penitng tentang arsitektur sistem aplikasi yang akan
dibangun. Tujuan deskripsi ini untuk memberikan informasi awal bagi proses perancangan sistem
aplikasi. Bisa dilengkapi dengan gambar-gambar yang dapat mendukung deskripsi arsitektur sistem
aplikasi.
Contoh arsitektur yang diinginkan, misalnya sistem aplikasi harus dibangun berdasarkan client-server,
sistem aplikasi dibangun berbasis web, memungkinkan untuk dilakukan akses/login dari jaringan, dan
lain-lain
5. Ruang Lingkup Dokumen
Penjelasan: Ruang Lingkup dokumen, contoh: Dokumen ini hanya digunakan untuk keperluan
perancangan dan pembangunan [nama sistem aplikasi]
6. Daftar Kebutuhan Sistem Aplikasi
Penjelasan: Tuliskan semua deskripsi dari seluruh kebutuhan (fitur yang diinginkan) sistem aplikasi
disini yang terbagi dalam 4 kelompok kebutuhan yaitu: (a) kebutuhan fungsional; (b) kebutuhan
antarmuka; (c) kebutuhan basis data; (d) kebutuhan adaptif.
Daftar kebutuhan (fitur sistem aplikasi yang diperlukan) dapat ditulis dalam table atau dengan cara lain.
Untuk memudahkan pelacakan dan pembacaan, sangat disarankan untuk memberikan indeks
identifikasi (req_ID) terhadap setiap fitur. Daftar kebutuhan tersebut dapat disusun berjenjang dengan
tingkat kedalaman seperlunya, sesuai kebutuhan dan karakteristik khusus sistem aplikasi yang akan
dibangun. Secara umum, disarankan untuk tidak menulis kebutuhan lebih dari 3 jenjang,
Berikut disajikan contoh cara penulisan daftar kebutuhan dalam sebuah table. Contoh ini selanjutnya
akan dipakai dalam dokumen ini sebagai ilustrasi
Req_ID Prioritas Deskripsi
Keterangan:
Req_ID adalah indeks identifikasi fitur, Tingkat kedalaman jenjang suatu fitur dapat dikenali dari indeksnya. Contoh:
1. FItur Utama
1.1 Fitur lebih rinci (jenjang tingkat 2)
2. FItur Utama
2.1.1 Fitur sangat rinci (jenjang tingkat 3)
2.1.2 FItur sangat rinci (jenjang tingkat 3)
Prioritas adalah tipe prioritas kebutuhan tersebut, misalnya (M)andatory atau (o)psional. Di kolom ini cukup dituliskan satu saja,
misalnya huruf “O”, maka selain yang ditandai dengan “o” berarti Mandatory atau Wajib.
Deskripsi adalah penjelasan lengkap dari kebutuhan / fitur sistem aplikasi yang diinginkan
6.1 Kebutuhan Fungsional
Penjelasan: Tuliskan semua deskripsi dari kebutuhan fungsional disini. Kebutuhan fungsional merinci
semua fitur utama sistem aplikasi dan menjabarkannya kedalam fitur-fitur yang lebih kecil. Tataletak
penulisan kebutuhan ini biasanya merupakan terjemahan dari proses kerja sistem aplikasi tersebut,
yang dikelompokkan dalam modul-modul aplikasi.
Contoh penulisan daftar kebutuhan fungsional
1 M Sistem aplikasi harus mempunyai fungsi untuk proses pengajuan
anggaran
2 M Sistem aplikasi harus mempunyai fungsi untuk proses pengelolaan
anggaran
3 O dll
4 O dll

1 M Sistem aplikasi harus mempunyai fungsi untuk proses pengajuan
anggaran
1.1 M Sistem aplikasi harus mempunyai fungsi untuk proses pengelolaan
anggaran
1.2 O dll
1.3 O dll
1.4 O
2 Sistem aplikasi harus mempunyai fungsi untuk proses pengelolaan
anggaran
2.1
2.2
2.3
6.2 Kebutuhan Antarmuka Sistem

Penjelasan: Tuliskan semua deskripsi dari kebutuhan antarmuka sistem aplikasi disini, yaitu semua
komunikasi yang dilakukan oleh sistem aplikasi dengan dunia luar, yang terbadi dalam dua bagian:
Komunikasi dengan sistem aplikasi lain yang terkait yang sudah ada, bagaiman sinergi akan dilakukan
dan kerangka interoprebilitas seperti apa yang ingin dijaga. Komunikasi dengan pengguna. Termasuk
didalamnya adalah tampilan antarmuka yang diinginkan (jika ada permintaan khusus) misalnya: semua
menu memakai Bahasa Indoensia, panduan bantuan on-line dalam Bahasa Indonesia, tampilan yang
tataletaknya dan warna dasarnya dapat diubah-ubah, dan lain-lain
Contoh penulisan daftar kebutuhan antarmuka system
1 M Sistem aplikasi XYZ memberikan data-data anggaran ke sistem
aplikasi PQR
2 M Sistem aplikasi XYZ membutuhkan data-data account instansi dan
account personal dari sistem aplikasi ABC
3 O dll
4 O dll

1 M Sistem aplikasi XYZ memberikan data-data anggaran ke sistem
aplikasi PQR
1.1 M
1.2 O
1.3 O dll
2 Sistem aplikasi XYZ membutuhkan data-data account instansi dan
account personal dari sistem aplikasi ABC
2.1 Data account Instansi = (nama bank + nama account instansi)
2.2 Sistem aplikasi harus dapat mengakomodasikan: instansi yang
mempunyai account tersebar di beberapa bank, instansi yang
mempunyai beberapa account di sebuah bank
2.3 O Data account personal = (nama bank+nama account personal)
6.3 Kebutuhan Basis Data

Penjelasan: Tuliskan semua deskripsi dari kebutuhan basis data sistem apliasi disini. Deskripsi yang
dicantumkan disini minimal mengidentifikasi informasi apa saja yang perlu dimasukkan dalam basis
data sistem aplikasi. Selain itu juga dituliskan semua kemampuan/fungsi yang harus dimiliki oleh
sistem basis data seperti kebutuhan terhadap sinkronisasi data, update otomatis dan lain-lain.
Termasuk dalam kebutuhan ini adalah pemakaian jenis basis data dari vendor tertentu (jika ada
permintaan khusus) misalnya: harus pakai Oracle, bagaiman tatacara akses ke basis data, dan lain-lain.
Contoh penulisan daftar kebutuhan basis data
1 M Basis data harus dibuatkan E-Rnya, baik dalam bentuk fisikal
maupun logical
2 M Mekanisme (prosedur dan timing) sinkronisasi antar basis-data harus
dijelaskan dalam sebuah dokumen tertulis
3 O dll
4 O dll
6.4 Kebutuhan adaptif

Penjelasan: Tuliskan semua deskripsi dari kebutuhan adaptif sistem aplikasi disini, yaitu kebutuhan
yang menyangkut fitur-fitur atau setting nilai yang berbeda-beda untuk setiap penggunanya. Contoh
yang bersifat umum misalnya: format tanggal yang diinginkan, format jam dan lain-lain. Untuk contoh
kasus keuangan: symbol mata uang, akurasi angka dibelakang titik decimal, dan lain-lain
6.5 Kebutuhan Non Fungsional
Penjelasan: Tuliskan semua kebutuhan yang tidak terkait dengan fungsi atau fitur yang ada pada sistem
perangkat lunak. Contoh dari kebutuhan non fungsional ini misalnya bahasa yang akan digunakan,
ketentuan tentang keamanan sistem, aspek budaya dan politik yang terkait, batas waktu pengembangan
dan lain sebagainya.
7. Penutup
Penjelasan: Berisi tentang penjelasan tentang dokumen selanjutnya yang akan dikerjakan yakni
dokumen System Specification dan Daftar dokumen yang menjadi acuan dalam proses pengembangan
sistem aplikasi, termasuk acuan aturan yang digunakan.
8. Lampiran
8.1 Executive Summary (Ringkasan tentang Manfaat Bisnis Sistem Perangkat Lunak)
Bagian ini biasanya berisi alasan mengapa mengembangkan sistem aplikasi yang dimaksud. Juga
dijelaskan dengan singkat manfaat (tangible dan intangible) dari sistem aplikasi, termasuk keuntungan
yang dapat diperoleh.
8.1 Studi Kelayakan Finansial (ROI, NVP dan BEP)
Bagian ini berisi perhitungan secara terperinci dengan menggunakan ukuran ROI, NVP dan BEP
terhadap sistem aplikasi yang akan dikembangkan.
8.2 Estimasi Sistem Perangkat Lunak (Ukuran Besar, Waktu dan Jumlah Personil)
Bagian ini berisi penjelasan secara terperinci tentang besar ukuran sistem perangkat lunak yang
dibangun, estimasi waktu pengerjaan dan jumlah personil yang dibutuhkan.
C. Dokumen Pengujian Sistem Aplikasi

Dokumen Pengujian Sistem Aplikasi adalah dokumen yang disiapkan oleh
Pegembang untuk memverifikasi apakah semua kebutuhan pengguna akhir (fitur yang
diinginkan) sudah dapat dipenuhi oleh sistem aplikasi. Dokumen ini juga dapat
dijadikan ukuran bagi pemilik proyek untuk menilai apakah mitra pengembang dapat
menyelesaikan pekerjaannya dengan kriteria memuaskan. Pada prinsipnya dokumen
ini adalah dokumen user requirements yang dimodifikasi kegunaannya untuk
keperluan pengujian, verifikasi dan validasi. Pengujian dapat dilakukan dengan
metode:
- Demo software, untuk fungsi-fungsi yang langsung dapat diverifikasi melalui
tampilan atau keluaran sistem aplikasi lainnya, misalnya pelaporan
- Analisa Fungsi, untuk memverifikasi fung-si-fungsi yang tidak secara langsung
terlibat melalui tampilan atau keluaran sistem aplikasi misalnya formula pengolahan
data yang dipakai, logika perhitungan data dan lain-lain
- Pemeriksaan Fisik, misalnya untuk dokumentasi yang dibutuhkan
Contoh template Dokumen Pengujian Sistem Aplikasi

1. Halaman Cover
Penjelasan:
[Judul Dokumen]
Contoh: “Spesifikasi Kebutuhan Pengembangan Sistem Aplikasi {nama sistem aplikasi}
2. Identifikasi Sistem
Penjelasan: Dokumen ini berisi daftar spesifikasi kebutuhan sistem aplikasi [nama sistem aplikasi yang
dikembangkan] dengan identifikasi berikut:
Nama Proyek: [nama proyek pengembangan software tsb]
Nama Produk: [nama/brand produk sistem aplikasi yang diinginkan]
ID Produk: [id produk, jika ada, sesuai aturan organisasi]
3. Metode Pengujian
Penjelasan: metode pengujian melaporkan tentang metode dan teknis terperinci dari pengujian yang
dilakukan. Biasanya pengujian dilakukan pada level unit, level integrasi dan level pengguna.
Pelaksanaan pengujian biasanya dilakukan sesuai dokumen SRS yakni daftar kebutuhan spesifikasi
sistem perangkat lunak. Pengujian juga berdasarkan dokumen script code yang ada.
Laporan pelaksanaan pengujian biasanya dibagi atas
a. Pengujian Aplikasi Jadi dalam bentuk Demo Aplikasi
b. Pengujian Kebutuhan Fungsional dan Non Fungsional Aplikasi meliputi fitur utama, fitur tambahan,
antar-muka, basis data, keamanan dan ketahanan sistem aplikasi
c. Pengujian Dokumentasi Sistem Aplikasi, yakni berupa Pemeriksaaan Fisik Kelengkapan
Dokumentasi Sistem Perangkat Lunak, misalnya Dokumen Petunjuk Penggunaan, Dokumen Petunjuk
Instalasi, ataupun Dokumen SRS dan lainnya.
d. Kombinasi dari ketiganya, yakni pengujian yang dilakukan pada level unit, level integrasi dan level
pengguna.
4. Hasil Pengujian
Penjelasan: berisi daftar temuan eror yang ada pada setiap metode pengujian. Untuk kemudahan proses
identifikasi dan penulisan hasil pengujiannya, hasil pengujian kemudian disimbolkan dengan karakter
khusus yang unik, misalnya: P untuk PASS artinya 100% terpenuhi; F untuk FAIL artinya 100% tidak
terpenuhi; S artinya sebagian terpenuhi (dan sebagian lagi tidak terpenuhi). Untuk hasil yang sifatnya
S, dapat juga ditambahkan keterangan seperlunay sehingga lebih jelas.
Contoh #1 Penulisan Hasil Pengujian
Req_ID Deskripsi Metode UAD Hasil UAT Ket
(D/A/P/K) (P/F/S)
1. Sistem aplikasi XYZ memberikan data K P
anggaran ke sistem aplikasi PQR
1.1
1.2
2. Sistem aplikasi XYZ membutuhkan K S Note-1

data-data account instansi dan account
personal dari sistem aplikasi ABC
2.1 Data account instansi=(nama D S Note-2
bank+nama account instansi)
2.2 Sistem aplikasi harus dapat K P
mengakomodasikan: instansi yg
mempunyai account tersebar
dibeberapa bank
2.3 Data account personal = (nama bank + D F
nama account personal)
Contoh #2 Penulisan Hasil Pengujian ((tata cara penulisan digabung menjadi beberapa kebutuhan yang
lebih besar)
(D/A/P/K) (P/F/S)
1. Sistem aplikasi XYZ memberikan data A P
anggaran ke sistem aplikasi PQR
.....................dst
1.1 ....................dst
1.2
2. Sistem aplikasi XYZ membutuhkan D S Note-1
data-data account instansi dan account
personal dari sistem aplikasi ABC
Data account instansi=(nama
2.1 bank+nama account instansi)
Sistem aplikasi harus dapat
2.2 mengakomodasikan: instansi yg
mempunyai account tersebar
dibeberapa bank
Data account personal = (nama bank +
2.3 nama account personal)
Contoh #3 Penulisan Hasil Pengujian (tatacara penulisan digabung dengan cara tertentu berdasarkan
scenario kasus)
(D/A/P/K) (P/F/S)
Kasus: Penyiapan RASK D P
1. .....................dst
1.1 ....................dst
2
Kasus: Perubahan RASK D S Note-1
1.1 ..............................dst
2.1 .............................dst
2.6 .............................dst
3 .............................dst
3.2 ............................dst
5. Penutup
Penjelasan: Disini disajikan rangkuman hasil pengujian dan evaluasi/penilaian terhadap hasil tersebut
untuk menentukan apakah sistem aplikasi:
(a) Sudah dapat berfungsi seperti yang diharapkan, sehingga sistem aplikasi tersebut dinyatakan dapat
diterima
(b) Belum dapat berfungsi dengan penuh seperti yang diharapkan, sehingga sistem aplikasi tersebut
dinyatakan tidak dapat diterima tau diterima dengan catatan
Contoh Tabel Rangkuman Hasil Pengujian:
Kelompok Kebutuhan Jumlah Total Kebutuhan Hasil Pengujian
P F S
1. Kebutuhan Fungsional 55 50 2 3
2. Kebutuhan Interface 40 30 0 10
3. Kebutuhan Basis data 20 18 2 0
4. Kebutuhan Adaptif 10 10 0 0
Total 125 10814 13
Untuk hasil yang tidak memuaskan (tidak dapat diterima, atau diterima dengan catatan), maka beberapa
langkah dapat diambil, misalnya:
(a) Proyek sponsor menunda pembayaran, atau bahakn membatalkan pekerjaan pengembangan sistem
aplikasi tersebut
(b) Dilakukan addendum (atau perubahan) kontrak bertujuan untuk memberikan kesempatan kepada
mitra pengembang untuk menyelesaikan yang hasilnya belum memuaskan tersebut.
DAFTAR PUSTAKA

Buku Analisa Perancangan Sistem Perangkat Lunak Menggunakan Kakas UML

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Buku Analisa Perancangan Sistem Perangkat Lunak Menggunakan Kakas UML

Diunggah oleh

Hak Cipta:

Format Tersedia

Analisa Perancangan

Sistem Perangkat Lunak

Dikompilasi oleh: Stanley Karouw dan Hans Wowor

Bahan Ajar Pengembangan Sistem Perangkat Lunak

A. Konsep Berorientasi Objek

B. Teknik Dasar Berorientasi Objek

Bahan Ajar Pengembangan Sistem Perangkat Lunak

Contoh dari polymorphism:

C. Metode Berorientasi Obyek

Bahan Ajar Pengembangan Sistem Perangkat Lunak

Adapun implikasi dari metode ini adalah sebagai berikut:

Kakas Unified Modeling Language (disingkat UML) adalah:

Bahan Ajar Pengembangan Sistem Perangkat Lunak

Diagram Aktivitas, Diagram Sequence, Diagram Kolaborasi, Diagram Komponen,

Gambar 2 Proses Analisa Perancangan dengan UML

Penjelasan Gambar 2 adalah sebagai berikut:

Bahan Ajar Pengembangan Sistem Perangkat Lunak

langkah ini dengan berhati-hati, berulang-ulang dan menyeluruh untuk semua

Gambar 3. Pemetaan Langkah, Proses dan Diagram UML

Bahan Ajar Pengembangan Sistem Perangkat Lunak

B. Teknik Menggambar Diagram UML

Gambar 4 Notasi Diagram Use Case

Package Obyek kontrol

Cara menggambarkan use case diagram:

Gambar 5 Diagram Use Case versi Awal

3. Tambahkan dependency yang mendemonstrasikan hubungan semantik antara

Bahan Ajar Pengembangan Sistem Perangkat Lunak

Bahan Ajar Pengembangan Sistem Perangkat Lunak

Keterangan dari Gambar 7 adalah sebagai berikut:

Berikut penjelasan dari langkah-langkah pemodelan:

Bahan Ajar Pengembangan Sistem Perangkat Lunak

<no receive action> Signal Receive

Cara menggambarkan activity diagram:

Bahan Ajar Pengembangan Sistem Perangkat Lunak

Gambar 9 Diagram Aktivitas Proses Sekolah Minggu

Dharwiyanti dan Wahono (2003) menjelaskan bahwa Class dapat merupakan

Bahan Ajar Pengembangan Sistem Perangkat Lunak

Entitas Kelas dapat memiliki relasi sebagai berikut:

Cara menggambarkan class diagram:

Bahan Ajar Pengembangan Sistem Perangkat Lunak

Gambar 13 Notasi Sequence Diagram

Cara menggambarkan sequence diagram:

Gambar 20 Contoh ke-2 Sequence Diagram (Membeli Minuman – Part 1)

Cara menggambarkan component diagram:

Front Vending Machine Interface

Gambar 26 Contoh Deployment Diagram

Rational Rose merupakan sebuah perangkat pemodelan secara visual yang

A. Membuat Use Case Diagram

Komponen utama dari sebuah Model Use-case

Actor Use Case Relationship

● Click icon Unidirectional Association dari diagram toolbar.

6. Membuat Include Relationships

● Click icon Unidirectional Association dari diagram toolbar.

7. Membuat Extended Relationships

● Click icon Unidirectional Association dari diagram toolbar.

B. Membuat Diagram Sequence

Membuat window sequence diagram

3. Click icon object dari toolbar

Penambahan Messages ke Sequence Diagram

Membuat Sequence Diagram dari Collaboration Diagram

Perpindahan antara sequence dan collaboration diagram:

Pemetaan Pesan (Message) ke sebuah Operasi (Operation)

Menghapus sebuah pesan dari operasi pemetaan:

Membuat operasi baru dari pesan: