Final Modul 2-KB 1 (Fathahillah) PDF

Modul 2, Rekayasa Perangkat Lunak
KB 1, Konsep OOAD Dalam Perancangan Aplikasi/Sistem 1

Infomasi
KEGIATAN BELAJAR 1
KONSEP OBJECT ORIENTED ANALYSIS DESIGN DALAM
PERANCANGAN APLIKASI/SISTEM INFOMASI
A. Pendahuluan
1. Deskripsi Singkat
Object oriented merupakan suatu pendekatan baru dari rekayasa perangkat
lunak untuk memecahkan beberapa masalah klasik dari pengembangan perangkat
lunak. Konsep yang mendasari teknik objek ini adalah bahwa seluruh objek
software sebaiknya dibangun melebihi standar dan komponen-komponen dapat
digunakan kembali apabila dimungkinkan.
Analisis dan desain berorientasi objek adalah cara baru dalam memikirkan
suatu masalah dengan menggunakan model yang dibuat menurut konsep dunia
nyata. Dasar pembuatan adalah objek yang merupakan kombinasi antara struktur
data dan perilaku dalam satu entitas. Model berorientasi objek bermanfaat untuk
memahami masalah, komunikasi dengan ahli, pemodelan suatu organisasi,
menyiapkan dokumentasi serta perancangan program dan basis data.
Pada Kegiatan belajar ini Anda akan mempelajari konsep pemrograman
Object Oriented Analysis and Design (OOAD) dalam pengembangan apikasi atau
sistem informasi. Materi pokok pada kegitan belajar ini adalah:
a. Metode pengembangan sistem berorientasi objek
b. Tahapan pengembangan sistem berorientasi objek
c. Tools dalam pengembangan sistem berorientasi objek
d. Dokumentasi pengembangan sistem berorientasi objek
2. Relevansi
Rekayasa Perangkat Lunak (RPL) perlu dipandang melalui tiga dimensi
besar literasi sains (scientific literacy) yaitu konten sains, proses sains, dan konteks
aplikasi sains. Konten sains merujuk pada konsep-konsep kunci dari sains yang
diperlukan untuk memahami fenomena alam dan perubahan yang dilakukan
2 KB 1, Konsep OOAD Dalam Perancangan Aplikasi/Sistem Infomasi

terhadap alam melalui aktivitas manusia. Proses sains mengembangkan

kemampuan memahami hakikat sains, prosedur sains, serta kekuatan dan
kelemahan sains. Konteks aplikasi sains lebih pada kehidupan sehari-hari daripada
kelas atau laboratorium. Kegiatan Belajar 1 ini dibagi menjadi empat bahan kajian
atau pokok bahasan yang mengacu pada dimensi literasi sains (sains liyteracy).
Tujuan pembelajaran yang diharapkan Anda capai pada kegiatan
pembelajaran ini adalah: (1) Mampu menganalisis metode pengembangan sistem
berorientasi objek; (2) mampu menjabarkan tahapan pengembangan sistem
berorientasi objek; (3) mampu memilih tools pengembangan sistem berorientasi
objek; dan (4) mampu membuat dokumentasi pengembangan sistem berorientasi
objek.
3. Petunjuk Belajar
Modul ini dirancang untuk memfasilitasi Anda dalam melakukan kegiatan
belajar secara mandiri, jangan lupa berdoa sebelum mempelajarinya. Bacalah
modul dengan seksama, terutama bagian instruksi.
a. Pahami dulu tentang capaian pembelajaran mata kegiatan, sub capaian
pembelajaran mata kegiatan, dan pokok-pokok materi pada setiap Kegiatan
Belajar sebelum Anda mempelajari uraian materi
b. Lakukan kajian terhadap uraian materi pada setiap Kegiatan Belajar dan
lengkapi informasi Anda dengan melihat berbagai media dan sumber belajar
yang telah disediakan serta menganalisis contoh penelitian atau kasus nyata
pada setiap topik materi.
c. Anda diharapkan juga dapat menguasai prinsip, teknik, dan aplikasi integrasi
pengetahuan keilmuan sains, pedagogi dan teknologi (technology pedagogy
and content knowledge/TPCK). Oleh karena itu, lakukan kajian terhadap
metode membelajaran yang telah disediakan pada setiap kegiatan Belajar ini.
Anda juga dapat menambahkan cara alternatif lain ketika Anda membelajarkan
topik tersebut pada peserta didik di sekolah
d. Keberhasilan proses pembelajaran pada PPG Dalam Jabatan ini sangat
tergantung pada kesungguhan Anda dalam mengerjakan tugas dan tes yang

Infomasi
telah disediakan pada setiap Kegiatan Belajar Kerjakanlah tugas dan latihan
yang terdapat di dalamnya dengan jujur tanpa melihat kunci jawaban sebelum
Anda mengerjakannya.
e. Gunakan teknik membaca cepat dalam mempelajari modul.
f. Pelajari media dan sumber belajar lain yang relevan dengan materi
g. Anda diperbolehkan bertanya kepada instruktur jika dianggap perlu.
h. Usahakan menyelesaikan setiap modul lebih cepat dari waktu yang ditetapkan.
Jika ada bagian yang belum anda pahami, cobalah terlebih dahulu
mendiskusikan dengan teman yang sedan gmengerjakan bagian yang sama,
sebelum Anda bertanya pada instruktur. Jika perlu, berusahalah mencari tahu
jawabannya pada sumber yang lain.
Kegiatan Belajar 1 ini menggunakan beberapa dukungan perangkat yang
yang harus disediakan. Peserta dapat menggunakan perangkat yang dimiliki tetapi
harus memenuhi standar spesifikasi yang telah ditetapkan. Hal ini bertujuan agar
setiap kegiatan pembelajaran yang dilakukan dapat berjalan dengan semestinya.
Perangkat-perangkat yang digunakan dalam kegiatan pembelajaran modul ini
adalah:
a. Personal Computer/Laptop yang sudah terinstal minimal OS Windows 7.
b. Aplikasi pengolah kata
c. Aplikasi (tool) StarUML
B. Inti
1. Capaian Pembelajaran
Peserta mampu menganalisis prinsip-prinsip Rekayasa Perangkat Lunak beserta
aplikasi terkait dalam pembelajaran bidang studi Teknik Komputer dan
Informatika
2. Pokok-Pokok Materi
a. Metode pengembangan sistem berorientasi objek
b. Tahapan pengembangan sistem berorientasi objek
c. Tools dalam pengembangan sistem berorientasi objek

d. Membuat dokumentasi pengembangan sistem berorientasi objek
3. Uraian Materi
a. Metodologi Berorientasi Objek
Metodologi merupakan cara kerja yang sistematis untuk memudahkan
pelaksanaan pembuatan perangkat lunak guna mencapai tujuan tertentu.
Metodologi juga bermakna proses untuk menghasilkan perangkat lunak yang
terorganisir dengan menggunakan sejumlah teknik dan konvensi notasi yang
terdefinisi.
Metodologi berorientasi objek merupakan suatu strategi pembangunan
perangkat lunak yang mengorganisasikan perangkat lunak sebagai kumpulan objek
yang berisi data dan operasi yang diberlakukan terhadapnya. Metodologi
berorientasi objek adalah suatu cara bagaimana sistem perangkat lunak dibangun
melalui pendekatan objek secara sistematis. Metode berorientasi objek didasarkan
pada penerapan prinsip-prinsip pengelolaan kompleksitas.
Metode berorientasi objek melipui rangkaian aktivitas analisis berorientasi
objek, perancangan berorientasi objek, pemrograman berorientasi objek, dan
pengujian berorientasi objek. Ada teknik yang digunakan, produk yang dihasilkan,
prosedur verifikasi, dan kriteria untuk setiap aktivitas yang dikerjakan. Ada alat
bantu untuk memodelkan (mendokumentasikan) hasil dari setiap aktivitas.
Karakteristik metode berorientasi objek adalah:
1) Cara kerja yang sistematis untuk mengerjakan tahap analisis berdasarkan
pendekatan objek.
2) Ada kumpulan aturan-aturan tertentu yang harus diikuti untuk menyelesaikan
pekerjaan analisis tersebut.
3) Mempunyai urut-urutan aktivitas, teknik, dan alat bantu (tools) tertentu untuk
memodelkan (mendokumentasikan) hasil dari setiap aktivitas.
Analisis berorientasi objek merupakan investigasi masalah untuk
menemukan (mengidentifikasikan) dan mendefinisikan objek-objek atau konsep-
konsep yang ada di ruang masalah. Analisis ini merupakan proses untuk
menentukan objek-objek potensial yang ada dalam sistem dan mendeskripsikan

Infomasi
karakterisitik dan hubungannya dalam sebuah notasi formal. Aplikasi konsep

berorientasi objek untuk memodelkan permasalahan dan sistem, baik untuk lingkup
perangkat lunak maupun non-perangkat lunak.
Analisis bertujuan untuk:
1) Memahami permasalahan secara menyeluruh.
2) Mengungkapkan apa yang harus dikerjakan oleh sistem untuk memenuhi
kebutuhan pemakai.
3) Mengetahui ruang lingkup produk (product space) dan pemakai yang
akan menggunakan produk tersebut.
Berikut ini adalah tahapan analisis berorientasi objek:
1) Mempelajari permasalahan
2) Menentukan kebutuhan pemakai
3) Mengubah kebutuhan yang belum terstruktur menjadi model-model atau
gambar-gambar dengan memanfaatkan metode dan teknik analisis
tertentu.
4) Mendokumentasikan hasil analisis, misalnya Software Requirement
Specification (SRS).
Terdapat beberapa metode yang dapat digunakan untuk melakukan
analisis berorientasi objek, dan diantaranya adalah sebagai berikut:
1) Metode Coad & Yourdan
a) Diperkenalkan oleh Peter Coad dan Edward Yourdan pada tahun 1990.
b) Disebut juga dengan nama Object Oriented Analysis (OOA), dan
dipandang sebagai salah satu teknik yang mudah untuk dipelajari.
c) Notasi model relatif sederhana karena didasarkan pada struktur
fisik dunia nyata, dan petunjuk untuk melakukan analisis cukup
jelas.
d) Tahap atau skema pelaksanaan:
i) Mengidentifikasi kelas dan objek
ii) Mengidentifikasi struktur
• Struktur "generalization-specification”
• Struktur “whole-part” atau “a-part-of”

iii) Mengidentifikasi subjek

iv) Mendefinisikan atribut
• Atribut implisi objek
• Koneksi instan (instance connection)
v) Mendefinisikan layanan
• Layanan implisit objek
• Layanan yang berasosiasi dengan atribut
• Layanan yang berasosiasi dengan “message-connection”
2) Metode Rumbaugh
a) Diperkenalkan oleh James Rumbaugh, Michael Blaha, William
Premerlan, Frederick Eddy dan William Lorensen pada tahun 1991.
b) Lebih dikenal dengan Object Modeling Technique (OMT) yang dapat
digunakan baik untuk analisis maupun desain.
c) Selain model-model fisik dari objek, pendekatan analisis dilkukan juga
untuk model-model dinamik dan model fungsional.
i) Menentukan ruang lingkup masalah
ii) Membuat model objek
• Mengidentifikasi kelas yang relevan dengan permasalahan
• Mendefinisikan atribut dan asosiasi
• Mendefinisikan keterkaitan (link) antar kelas dan objek
• Mengorganisasikan kelas objek dengan menggunakan pewarisan
iii) Membuat model dinamik
• Menyiapkan skenario
• Mendefinisikan kejadian (event) dan buat penelusurannya untuk setiap
skenario
• Membangun diagram aliran kejadian (event flow diagram)
• Membuat diagram keadaan (state diagram)
iv) Membuat model fungsional sistem
• Mengidentifikasi masukan dan keluaran

Infomasi
• Menggunakan diagram aliran data untuk merepresentasikan aliran

transformasi
• Membuat spesifikasi proses untuk setiap fungsi
3) Metode Jacobson
a) Diperkenalkan oleh Ivar Jacobson dengan nama Object Oriented
Software Engineering (OOSE) pada tahun 1992.
b) Merupakan versi yang juga sederhana dari metode berorientasi objek.
c) Sudut pandang atau fokus analisis ditekankan pada “use case”, yaitu
deskripsi atau skenario yang menggambarkan bagaimana pemakai
berinteraksi dengan produk atau sistem yang akan dikembangkan.
i) Mengidentifikasi pemakai sistem dan semua tanggung jawabnya
ii) Membuat model kebutuhan
• Mendefinisikan aktor dan tanggung jawabnya
• Mengidentifikasi use-case untuk setiap actor
• Menginisialisasi gambaran sistem objek dan hubungannya
iii) Buat model analisis
• Mengidentifakasi antarmuka objek
• Membuat gambaran struktural dari antarmuka objek
• Merepresentasikan perilaku objek
• Mengisolasi sub-sistem dan buat masing-masing modelnya
4) Metode Booch
a) Diperkenalkan oleh Grady Booch pada tahun 1994.
b) Meliputi proses pengembangan makro dan mikro, dengan anggapan
bahwa analisis dan desain merupakan rangkaian kesatuan aktivitas yang
tidak dipisahkan.
c) Tahap atau skema pelaksanaan:
i) Mengidentifikasi kelas dan objek
• Mengidentifikasi kandidat objek
• Mengidentifikasi skenario yang relevan

• Mendefinisikan atribut dan layanan untuk setiap kelas

ii) Mengidentifikasi Semantik dari kelas dan objek
• Memilih skenario kemudian analisis
• Memilih objek dan daftar peran serta tanggung jawabnya
• Mencari colaborasi diantara objek-objek
iii) Mengidentifikasi hubungan diantara kelas dan objek
• Mendefinisikan ketergantungan yang ada diantara objek
• Menjelaskan peran dari setiap objek
• Memvalidasi berdasarkan skenario
iv) Membuat diagram yang berhubungan dengan langkah-langkah di
atas
v) Mengimplementasikan kelas dan objek
5) Metode Wirfs-Brock
Metode ini disebut juga dengan metode Responsibility Driven Design/Class
Responsibility Collaboration (RDD/CFC). Metode ini diarahkan pada desain, tetapi
sangat berguna untuk memunculkan ide dalam tahap analisis. Keunggulannya
adalah mudah digunakan, metode ini juga mengidentifikasikan hirarki kelas dan
subsistem-subsistem.
a) Mengevalusi spesifikasi pelanggan
b) Menggunakan uraian gramatikal untuk mengekstrak kelas calon dari
spesifikasi
c) Mengelompokkan kelas dengan tujuan untuk mengidentifikasi superkelas
d) Menentukan tanggung jawab untuk masing-masing kelas
6) Metode Shlair-Mellor atau Object Oriented Analysis/Design (OOA/D)
Metode yang menggunakan teknik pemodelan informasi tradisional yang
menjelaskan entitas dalam sistem, menggunakan state diagram untuk memodelkan
keadaan (state) entitas, menggunakan data flow diagram untuk memodelkan alur
data dalam sistem. Metode ini menghasilkan tiga jenis model yaitu: information
model, state model dan process model. Keunggulan metode ini adalah dalam
memandang masalah dari sudut pandang yang berbeda, mudah dibuat (dikonversi)
dari metode struktural.

Infomasi

b. Metode Analisis Secara Umum

Pada prinsipnya semua metode analisis berorientasi objek adalah
sama, perbedaan hanya terletak pada sudut pandang dan teknis
pelaksanaannya. Secara umum, metode analisis berorientasi objek mencakup
representasi kelas dan hirarki kelas, model hubungan objek, dan model
perilaku objek.
Tahap atau skema pelaksanaan analisis berorientasi objek :
1) Menentukan Kebutuhan Pemakai untuk Sistem Berorientasi Objek
Mengidentifikasikan proses-proses bisnis dan kebutuhan pemakai dan
mengekspresikan dengan ‘use-case”. Sebenarnya bukan merupakan aktivitas
analisis berorientasi objek, karena tidak membicarakan pembahasan tentang
objek. Diperlukan karena dapat menjelaskan aktivitas-aktivitas apa saja yang
harus dikerjakan oleh sistem, dan menjelaskan juga perilaku dari komponen-
komponen sistem. Ada diagram tertentu yang dapat merepresentasikan model
kebutuhan dari “use-case” yang diperoleh.
2) Identifikasi Kelas dan Objek

a) Mengidentifikasi kelas-kelas dan objek-objek yang ada dalam lingkup
aplikasi:
i) Eksplisit pada pernyataan masalah
ii) Implisit pada lingkup aplikasi atau pengetahuan atas lingkup aplikasi
Kelas dan objek dapat diidentifikasi dari:
i) Entitas eksternal yang memproduksi dan memakai informasi yang
akan digunakan oleh sistem berbasis computer
ii) Sesuatu yang merupakan bagian dari wilayah informasi dari
permasalahan
iii) Kejadian, misalnya prosedur operasional, yang muncul dalam lingkup
operasional sistem
iv) Peran yang dimainkan oleh orang-orang yang berinteraksi dengan
system
v) Unit organisasi yang relevan dengan aplikasi

Infomasi
vi) Tempat yang menentukan ruang lingkup masalah dan seluruh fungsi
dari sitem
vii) Struktur yang mendefinisikan kelas dari objek atau yang
menghubungkan kelas-kelas objek.
viii) Mengabaikan kelas dan objek yang tidak tepat karena redunden, tidak
relevan, lebih tepat berupa atribut, lebih tepat berupa operasi, lebih
tepat berupa peran dan lebih merupakan konstruksi implementasi.
3) Mengidentifikasi Atribut dan Layanan
a) Mengidentifikasi atribut dan layanan yang terkait untuk setiap atribut
tersebut.
b) Mengidentifikasi atribut dari elemen-elemen data yang dapat
menggambarkan (mencirikan) sebuah objek secara utuh.
c) Mengidentifikasi layanan dari perilaku spesifik yang dapat
menunjukkan peran dan tanggung jawab suatu objek.
d) Mengabaikan atribut yang tidak tepat karena berupa objek, berupa
qualifier, berupa nama, berupa identifier pada implementasi,
menyatakan status internal objek, merupakan atribut yang sangat kecil
(minor) dan bertentangan dengan atribut lain.
4) Mendefinisikan Struktur dan Hirarki
a) Mendefinisikan struktur dan hierarki dari objek yang akan
mengorganisasikan kelas objek.
b) Mengatur dan menyederhanakan objek-objek menjadi kelas-kelas
objek melalui konsep agregasi dan pewarisan.
c) Mendefinisikan struktur dan hirarki yang mungkin didefinisikan
5) Membuat Model Hubungan Objek
a) Mendefinisikan hubungan (asosiasi atau koneksi) antar kelas, yaitu
ketergantungan antar satu kelas atau lebih dengan kelas lainnya.
b) Asosiasi dapat berbentuk:
i) Lokasi fisik atau penempatan (next, to, part, of contained in)
ii) Aksi terarah (drive)
iii) Komunikasi (transmit to, acquires from)

iv) Kepemilikan (incorporated by, is composed of)

v) Pemenuhan kondisi (manages, coordinates, controls)
c) Jenis-jenis asosiasi:
i) Asosiasi 1 – 1 (one-to-one association)
ii) Asosiasi 1 – m (one-to-many association)
iii) Asosiasi M – 1 (many –to-one association)
iv) iASI M – M (many-to-many association)
v) Ternary Assosiation
vi) Kualifikasi, hubungan asosiatif berkualifikasi antara 2 kelas objek
vii) Ordering, hubungan berdasarkan urutan kejadian
d) Nama hubungan dan garis atau anak panah digunakan untuk
menyatakan hubungan antar kelas-kelas tersebut.
e) Mengabaikan asosiasi yang tidak tepat karena:
i) Asosiasi antara kelas yang diabaikan
ii) Asosiasi implementatif atau tidak relevan
iii) Asosiasi yang berupa aksi
iv) Asosiasi ternary
v) Asosiasi turunan
6) Membuat Model Perilaku Objek
a) Menyatakan bagaimana sistem berorientasi objek akan menanggapi
kejadian atau stimuli eksternal (memunculkan sifat dinamis objek).
b) Tahap-tahap untuk membuat model perilaku objek:
i) Mengevaluasi semua “use-case” untuk memahami urutan
interaksi yang ada dalam system
ii) Mengidentifikasi kejadian yang menggerakkan urutan
interaksi, dan pahami bagaimana kejadian-kejadian tersebut
berhubungan dengan objek tertentu
iii) Membuat penelusuran kejadian untuk setiap “use-case”
iv) Membuat diagram transisi keadaan untuk system
v) Meninjau ulang model perilaku objek untuk verifikasi
keakuratan dan konsistensi.

Infomasi
c. Tahapan Pengembangan Sistem Berorientasi Objek

Pendekatan object oriented dapat menggunakan metodologi
apapun, termasuk yang terstruktur, tetapi umumnya lebih berhubungan
dengan metodologi yang bersifat RAD. Yang harus diperhatikan dalam
OOSAD adalah pemodelan dunia nyata, yang berarti memodelkan data
dan proses yang susah dipisahkan. UML bersifat use-case drive,
architecture-centric, iterative dan incremental.
Use-Case Drive merupakan perangkat pemodelan yang bagian
utamanya adalah use case yang digunakan untuk menjelaskan tingkah laku
dari sistem. Architecture centric yang akan dibuat haruslah mengikuti dan
menghasilkan standar yang meliputi spesifikasi, konstruksi, dan
dokumentasi. Itterative dan incremental berkaitan dengan pengembangan
yang dilakukan secara iteratif dan bertingkat, dimana setiap pengulangan
akan mendekatkan produk pada spesifikasi pengguna akhir. Unified
process mengunakan metoodologi yang secara khusus memetakan
bagaimana menggunakan perangkat methodoly yang dimiliki oleh UML.
Jika UML memiliki struktur untuk menjelaskan hubungan struktural dan
behaviour dari sebuah sistem informasi, RUPS menyediakan dukungan
metodologi penggunaan notasi UML.
Unified process adalah proses pengembangan sistem yang
dijelaskan melalui tahapan-tahapan dan alur kerja (workflows).
Tahapannya adalah:
1) Inception
Merupakan tahapan perencanaan. Business case dibuat dalam tahapan ini.
2) Elaboration
Merupakan tahapan dimana dilakukan analisis dan perancangan sistem
secara mendalam. Pada tahapan ini dilakukan analisis mengenai
bagaimana sistem yang akan dibuat, vision document, penyelesaian
business case, revisi penilaian risiko, dan menyelesaikan project plan
secara terinci agar pihak-pihak yang berkepentingan menyetujui

rancangan sistem. Deliverablesnya meliputi notasi-notasi structure dan

behaviour, executable of baseline version. Baseline harus ditetapkan
dengan baik pada tahapAn ini karena merupakan dasar bagi pekerjaan
lanjutan untuk membuat sistem yang jadi.
3) Construction
Tahapan ini terfokus pada pemrograman dan pekerjaan teknis untuk
membuat sistem. Tahapan ini merupakan implementasi diagram kerja ke
dalam kode program (coding). Deliverables yang utama adalah versi alpha
maupun beta sistem yang dibuat.
4) Transition.
Tahapan ini merupakan pemasangan dan implementasi sistem yang telah
dikembangkan. Deliverables tahapan ini adalah sistem yang sudah jadi,
berikut dokument-dokumen pendukung termasuk di dalamnya manual,
support plan, dan upgrading plan.
Sedangkan workflowsnya meliputi :
1) Business modelling, digunakan untuk menemukan permasalahan dan dapat
mengidentifikasi proyek yang mungkin dikerjakan
2) Requirements, digunakan untuk melakukan elisitasi kebutuhan baik secara
fungsional dan nonfungsional.
3) Analysis, merupakan pekerjaan yang meliputi analisis dari problem/business
domain.
4) Design, meupakan pekerjaan yang mentransformasikan analisi model ke
dalam bentuk yang daat digunakan untuk implementasi sistem yaitu desain
model.
5) Implementation, merupakan pekerjaan pembangunan sistem. Contoh
aktifitas yang dilakukan adalah coding.
6) Test atau pengujian bertujuan agar produk yang dibuat memenuhi kriteria
kualitas yang telah ditentukan untuk sistem yang dibuat.
7) Deployment, bagian ini berhubungan dengan tahapan transisi pada RUP.
Aktifitasnya meliputi packaging, distribution, beta testing, dan pada
akhirnya adalah sistem yang telah jadi.

Infomasi
8) Project management, merupakan cross-phase flow. Contoh dari aktifitas

yang dilakukan dalam tahap ini adalah: risk identification & management,
scope management, time estimation, cost estimation, dan tracking progress.
9) Configuration and change management, bertujuan untuk menjejaki sampai
sejauh mana sistem yang sedang dibangun.
10) Environment, merupakan dukungan perangkat yang digunakan.
Environmental workflows adalah kelompok perkerjaan yang berhubungan
dengan penyediaan perangkat untuk pembuatan system
Pengembangan perangkat lunak yang mendasari pembangunan sistem
adalah System Development Life Cycle (SDLC) atau siklus hidup pengembangan
sistem. Dalam rekayasa sistem dan rekayasa perangkat lunak, SDLC adalah proses
pembuatan dan pengubahan sistem serta model dan metodologi yang digunakan
untuk mengembangkan sistem-sistem tersebut (Muslihudin & Oktafianto, 2016).
Nugroho (2010) mendefinisikan SDLC adalah pengembangan atau
rekayasa sistem informasi perangkat lunak dapat berarti menyusun sistem atau
perangkat lunak yang benar-benar baru atau yang lebih sering terjadi
menyempurnakan yang telah ada sebelumnya. Sedangkan menurut A.S. &
Shalahuddin (2019), SDLC adalah proses mengembangkan atau mengubah suatu
sistem perangkat lunak dengan menggunakan model-model dan metodologi yang
digunakan orang untuk mengembangkan sistem-sitem perangkat lunak sebelumnya
(berdasarkan best practice atau cara-cara yang sudah teruji baik).
Tahapan-tahapan yang ada pada SDLC secara global menurut A.S. &
Shalahuddin (2019) adalah sebagai berikut :
1) Inisiasi (initiation), tahap ini biasanya ditandai dengan pembuatan hasil proyek
perangkat lunak.

2) Pengembangan konsep sistem (system concept development), mendefinisikan
lingkup konsep termasuk dokumen lingkup sistem, analisis manfaat biaya,
manajemen rencana, dan pembelajaran kemudahan sistem.
3) Perencanaan (planning), mengembangkan rencana manajemen proyek dan
dokumen perencanaan lainnya. Menyediakan dasar untuk mendapatkan
sumber daya (resources) yang dibutuhkan untuk memperoleh solusi.
4) Analsis kebutuhan (requirements analysis), menganalisis kebutuhan pemakai
sistem perangkat lunak (user) dan mengembangkan kebutuhan user, serta
membuat dokumen kebutuhan fungsional.
5) Desain (design), mentransformasikan kebutuhan detail menjadi kebutuhan
yang sudah lengkap, dokumen desain sistem fokus pada bagaimana dapat
memenuhi fungsi yang dibutuhkan.
6) Pengembangan (development), mengonversi desain ke sistem informasi yang
lengkap termasuk bagaimana memperoleh dan melakukan instalasi lingkungan
sistem yang dibutuhkan; membuat basis data dan mempersiapkan prosedur
kasus pengujian; mempersiapkan berkas atau file pengujian, pengodean,
pengompilasian, memperbaiki dan membersihkan program; peninjauan, dan
pengujian.
7) Integrasi dan pengujian (integration and test), mendemonstrasikan sistem
perangkat lunak bahwa telah memenuhi kebutuhan yang dispesifikasikan pada
dokumen kebutuhan fungsional. Dengan diarahkan oleh staf penjamin kualitas
(quality assurance) dan user. Menghasilkan laporan analisis pengujian.

Infomasi
8) Implementasi (implementation), termasuk pada persiapan implementasi,
implementasi perangkat lunak pada lingkungan produksi (lingkungan pada
user) dan menjalankan resolusi dari permasalahan yang teridentifikasi dari fase
integrasi dan pengujian.
9) Operasi dan pemeliharaan (operations and maintetance), mendeskripsikan
pekerjaan untuk mengoperasikan dan memelihara sistem informasi pada
lingkungan produksi (lingkungan pada user), termasuk implementasi akhir dan
masuk pada proses peninjauan.
10) Disposisi (dispotition), mendeskripsikan aktifitas akhir dari pengembangan
sistem dan membangun data yang sebenarnya sesuai dengan aktifitas user.
Menurut A.S. & Shalahuddin (2019), SDLC memiliki beberapa model
pengembangan perangkat lunak antara lain sebagai berikut :
1) Model Waterfall
Model SDLC air terjun (waterfall) sering juga disebut model sekuensial
linier (sequential linier) atau alur hidup klasik (classic life cycle). Model air terjun
menyediakan pendekatan alur hidup perangkat lunak secara sekuensial atau terurut
dimulai dari analisis, desain, pengodean, pengujian, dan tahap pendukung
(support). Berikut adalah gambar model waterfall:

Gambar 1.1 Ilustrasi model waterfall (A.S. & Shalahuddin, 2019)
Tahapan-tahapan yang dilakukan dalam model waterfall adalah sebagai
berikut :
a) Analisis kebutuhan perangkat lunak. Proses pengumpulan kebutuhan
dilakukan secara intensif untuk menspesifikasikan kebutuhan perangkat lunak
agar dapat dipahami perangkat lunak apa yang dibutuhkan oleh user.
Spesifikasi kebutuhan perangkat lunak pada tahap ini perlu untuk
didokumentasikan.
b) Desain. Desain perangkat lunak adalah proses multi langkah yang fokus pada
desain pembuatan program perangkat lunak termasuk struktur data, arsitektur
perangkat lunak, representasi antarmuka, dan prosedur pengodean. Tahap ini
mentranslasi kebutuhan perangkat lunak dari tahap analisis kebutuhan ke
representasi desain agar dapat diimplementasikan menjadi program pada tahap
selanjutnya. Desain perangkat lunak yang dihasilkan pada tahap ini juga perlu
didokumentasikan.
c) Pembuatan kode program. Desain harus ditranslasikan ke dalam program
perangkat lunak. Hasil dari tahap ini adalah program komputer sesuai dengan
desain yang telah dibuat pada tahap desain.

Infomasi
d) Pengujian. Pengujian fokus pada perangkat lunak secara dari segi lojik dan
fungsional dan memastikan bahwa semua bagian sudah diuji. Hal ini dilakukan
untuk meminimalisir kesalahan (error) dan memastikan keluaran yang
dihasilkan sesuai dengan yang diinginkan.
e) Pendukung (support) atau pemeliharaan (maintanance). Tidak menutup
kemungkinan sebuah perangkat lunak mengalami perubahan ketika sudah
dikirimkan ke user. Perubahan bisa terjadi karena adanya kesalahan yang
muncul dan tidak terdeteksi saat pengujian atau perangkat lunak harus
beradaptasi dengan lingkungan baru. Tahap pendukung atau pemeliharaan
dapat mengulangi proses pengembangan mulai dari analisis spesifikasi untuk
perubahan perangkat lunak yang sudah ada, tapi tidak untuk membuat
perangkat lunak baru.
2) Model Prototipe (Prototyping)
Model prototipe dapat digunakan untuk menyambungkan
ketidakpahaman pelanggan mengenai hal teknis dan memperjelas spesifikasi
kebutuhan yang diinginkan pelanggan kepada pengembang perangkat lunak.
Model prototipe (prototyping model) dimulai dari mengumpulkan kebutuhan
pelanggan terhadap perangkat lunak yang akan dibuat. Kemudian dibuatkan
program prototipe agar pelanggan lebih terbayang dengan apa yang sebenarnya
diinginkan. Program prototipe biasanya menyediakan tampilan dengan
simulasi alur perangkat lunak sehingga tampak seperti perangkat lunak yang
sudah jadi. Program prototipe ini dievaluasi oleh pelanggan atau user sampai

ditemukan spesifikasi yang sesuai dengan keinginan pelanggan atau user
tersebut. Berikut adalah gambar dari model prototipe:
Gambar 1.2 Ilustrasi model prototipe (A.S. & Shalahuddin, 2019)
Mock-up adalah sesuatu yang digunakan sebagai model desain yang
digunakan untuk mengajar, demonstrasi, evaluasi desain, promosi, atau
keperluan lain. Sebuah mock-up disebut juga sebagai prototipe perangkat lunak
jika menyediakan atau mampu mendemonstrasikan sebagian besar fungsi
sistem perangkat lunak dan memungkinkan pengujian desain sistem perangkat
lunak.
Seiring dengan menggunakan prototipe maka sistem perangkat lunak
yang sebenarnya dikembangkan juga sehingga sesuai dengan kebutuhan
pelanggan (customer) atau user. Model prototipe memiliki kelemahan yaitu :
a) Pelanggan dapat sering mengubah-ubah atau menambah spesifikasi
kebutuhan karena menganggap aplikasi sudah dengan cepat
dikembangkan, karena adanya iterasi ini dapat menyebabkan pengembang

Infomasi
banyak mengalah dengan pelanggan karena perubahan atau penambahan
spesifikasi kebutuhan perangkat lunak.
b) Pengembang lebih sering mengambil kompromi dengan pelanggan untuk
mendapatkan prototipe dengan waktu yang cepat sehingga pengembang
lebih sering melakukan segala cara (tanpa idealis) guna menghasilkan
prototipe untuk didemonstrasikan. Hal ini dapat menyebabkan perangkat
lunak yang kurang baik atau bahkan menyebabkan iteratif tanpa akhir.
Permasalahan yang terjadi pada model prototipe dapat diatasi dengan
melakukan perjanjian antara pengembang perangkat lunak dengan pelanggan
(customer) atau user agar model prototipe hanya digunakan untuk
mendefinisikan spesifikasi kebutuhan perangkat lunak, tapi tidak untuk seluruh
proses pengembangan seluruh sistem perangkat lunak.
Model prototipe cocok digunakan untuk menjabarkan kebutuhan
pelanggan secara lebih detail karena pelanggan sering kesulitan menyampaikan
kebutuhannya secara detail tanpa melihat gambaran yang jelas. Untuk
mengantisipasi agar proyek dapat berjalan sesuai dengan target waktu dan
biaya awal, maka sebaiknya spesifikasi kebutuhan sistem harus sudah
disepakati oleh pengembang dengan pelanggan secara tertulis. Dokumen
tersebut akan menjadi patokan agar spesifikasi kebutuhan sistem masih dalam
ruang lingkup proyek.
Model prototipe kurang cocok untuk aplikasi dengan skala besar karena
membuat prototipe untuk aplikasi sekala besar akan sangat memakan waktu

dan tenaga. Model prototipe cocok digunakan untuk menggali spesifikasi
kebutuhan pelanggan secara lebih detail tetapi beresiko tinggi terhadap
membengkaknya biaya dan waktu proyek.
3) Model Rapid Application Development (RAD)
RAD merupakan model proses pengembangan perangkat lunak yang
bersifat inkremental terutama untuk waktu pengerjaan yang pendek. Model RAD
adalah adaptasi dari model air terjun versi kecepatan tinggi dengan menggunakan
model air terjun untuk pengembangan setiap komponen perangkat lunak (A.S. &
Shalahuddin, 2019). Berikut ini adalah gambar dari model RAD:
Gambar 1.3 Ilustrasi model RAD (A.S. & Shalahuddin, 2019)

Jika kebutuhan perangkat lunak dipahami dengan baik dan lingkup
perangkat lunak dibatasi dengan baik sehingga tim dapat menyelesaikan pembuatan

Infomasi
perangkat lunak dengan waktu yang pendek. Model RAD membagi tim
pengembang menjadi beberapa tim untuk mengerjakan beberapa komponen
masing-masing tim pengerjaan dapat dilakukan secara paralel.
Tahapan-tahapan yang dilakukan dalam model RAD berdasarkan gambar
adalah sebagai berikut :
a) Pemodelan bisnis. Pemodelan yang dilakukan untuk memodelkan fungsi bisnis
untuk mengetahui informasi apa saja yang terkait proses bisnis, informasi apa
saja yang harus dibuat, siapa yang harus membuat informasi itu, bagaimana
alur informasi itu, dan proses apa saja yang terkait informasi itu.
b) Pemodelan data. Memodelkan data apa saja yang dibutuhkan berdasarkan
pemodelan bisnis dan mendefinisikan atribut-atribut beserta relasinya dengan
dengan data-data yang lain.
c) Pemodelan proses. Mengimplementasikan fungsi bisnis yang sudah
didefinisikan terkait dengan pendefinisian data.
d) Pembuatan aplikasi. Mengimplementasikan pemodelan proses dan data
menjadi program, model RAD sangat menganjurkan pemakaian komponen
yang sudah ada jika dimungkinkan.
e) Pengujian dan pergantian. Menguji komponen-komponen yang dibuat, jika
sudah teruji maka tim pengembang komponen dapat beranjak untuk
mengembangkan komponen berikutnya.
4) Model Iteratif
Model iteraif (iterative model) mengkombinasikan proses-proses pada
model air terjun dan iteratif pada model prototipe. Model inkremental akan

menghasilkan versi-versi perangkat lunak yang sudah mengalami penambahan
fungsi untuk setiap pertambahannya (A.S. & Shalahuddin, 2019). Berikut adalah
gambar dari model iteratif:
Gambar 1.4 Ilustrasi model iteratif (A.S. & Shalahuddin, 2019)
Model inkremental dibuat untuk mengatasi kelemahan dari model air terjun
yang tidak mengakomodasikan iterasi, dan mengatasi kelemahan dari prototipe
yang memiliki proses terlalu pendek dan setiap iteratif prosesnya tidak selalu
menghasilkan produk (bisa jadi hanya prototipe). Model inkremental menghasilkan
produk/aplikasi untuk setiap tahapan inkremen.
Model inkremental sangat cocok digunakan jika staf yang dimiliki memiliki
pergantian (turnover) yang tinggi sehingga staf tidak dapat terus ikut dalam
pengembangan perangkat lunak. Mekanisme tahapan inkremental perlu
direncanakan terlebih dahulu agar hasil produk dan pengerjaan setiap tahapan
inkremen menjadi lebih baik.
5) Model Spiral

Infomasi
Model spiral (spiral model) memasangkan iteratif pada model prototipe
dengan kontrol dan aspek sistematik yang diambil dari model air terjun. Model
spiral menyediakan pengembangan dengan cara cepat dengan perangkat lunak
dengan memiliki versi yang terus bertambah fungsinya (A.S. & Shalahuddin,
2019).
Pada iterasi awal maka yang dihasilkan adalah prototipe sedangkan pada
iterasi akhir yang dihasilkan adalah perangkat lunak yang sudah lengkap. Model
spiral dibagi menjadi beberapa kerangka aktifitas atau disebut juga wilayah kerja
(task region). Banyaknya wilayah kerja biasanya di antara tiga sampai enam
wilayah yaitu sebagai gambar berikut:
Gambar 1.5 Ilustasi model spiral (A.S. & Shalahuddin, 2019)

Tahapan-tahapan yang dilakukan dalam model spiral berdasarkan gambar
adalah sebagai berikut:
a) Komunikasi dengan pelanggan (costumer communication), aktifitas ini
diperlukan untuk membangun komunikasi yang efektif antara pengembang
(developer) dan pelanggan (customer).
b) Perencanaan (planning), aktifitas ini diperlukan untuk mendefinisikan sumber
daya, waktu, dan informasi yang terkait dengan proyek.
c) Analisis resiko (risk analysis), aktifitas ini diperlukan untuk memperkirakan
resiko dari segi teknis maupun manajemen.
d) Rekayasa (engineering), aktifitas ini diperlukan untuk membangun satu atau
lebih representasi dari aplikasi perangkat lunak (dapat juga berupa prototipe).
e) Konstruksi dan peluncuran (construction and release), aktifitas ini dibutuhkan
untuk mengonstruksi, menguji, melakukan instalasi, dan menyediakan
dukungan terhadap user (misalnya dari segi dokumentasi dan pelatihan).
f) Evaluasi pelanggan (customer evaluation), aktifitas ini dibutuhkan untuk
mendapatkan umpan balik berdasarkan evaluasi representasi perangkat lunak
yang dihasilkan dari proses rekayasa dan diimplementasikan pada tahap
instalasi.
Model spiral dilakukan searah dengan jarum jam dimulai dari sumbu proyek.
Sumbu proyek dapat digunakan sebagai awal iterasi ataupun evaluasi dari iterasi yang
sudah dilakukan. Pada gambar di atas setiap wilayah kerja dibedakan dengan warna
wilayah, di mana setiap wilayah berputar dengan urutan kerja tertentu.

Infomasi
Pada model spiral, hasil akhir dan evaluasi dari sebuah wilayah kerja akan
menjadi inisiasi dari wilayah kerja berikutnya. Model spiral cocok digunakan untuk
mengembangkan sistem perangkat lunak yang bersekala besar karena memiliki
proses analisis risiko yang dapat sangat meminimalisir risiko yang mungkin terjadi.
Model spiral memungkinkan pengembang untuk menggunakan prototipe pada
setiap tahap untuk mengurangi risiko.
d. Alur Kerja Sistem Berorientasi Objek

Siklus pemodelan atau langkah-langkah pemodelan dalam mengembangkan
suatu sistem adalah:
1) Rekayasa pemodelan sistem
Yaitu menyangkut pengumpulan kebutuhan (requirement gathering) pada level
sistem dengan sejumlah analisis serta top desain.
2) Analisis
Yaitu kebutuhan perangkat lunak, proses requirement gathering difokuskan,
khususnya pada Perangkat lunak. Untuk memahami sifat program yang
dibangun, analis harus memahami domain informasi, tingkah laku, unjuk kerja,
dan interface yang diperlukan. Kebutuhan sistem maupun Perangkat Lunak
didokumentasikan dan direview bersama user.
3) Desain
Memiliki fokus terhadap 4 hal, yaitu:
i) Desain database
ii) Arsitektur perangkat lunak
iii) Arsitektur interface
iv) Algoritma prosedural.
e. Pemodelan
Dalam banyak aplikasi engineering, model didefinisikan sebagai
representasi dari sistem yang disederhanakan. Representasi ini pun juga bermacam-

macam mulai dari yang bersifat physical, pictorial, verbal, schematic dan symbolic
dimana:
1) Physical yaitu dengan membuat scaleddown version dari sistem yang dipelajari
(model pesawat, model kereta api).
2) Pictorial, yaitu representasi dengan gambar untuk menggambarkan kontur
permukaan bumi seperti peta topografi dan bola dunia.
3) Verbal, yaitu representasi suatu sistem ke dalam kalimat verbal yang
mengambarkan ukuran, bentuk dan karakteristik.
4) Schematic, yaitu representasi dalam bentuk skema figuratif misalnya model
rangkaian listrik, model Atom Bohr dan lain-lain.
5) Symbolic, yaitu representasi ke dalam simbol-simbol matematik dimana
variable hasil karakterisasi proses atau sistem ke dalam variable formulasi
menggunakan simbol-simbol matematik.
Jadi Pemodelan merupakan suatu proses dalam representasi abstrak suatu
model. Proses pemodelan menampilkan deskripsi suatu proses dari beberapa
perspektif tertentu. Proses pemodelan perangkat lunak merupakan aktifitas yang
saling terkait (koheren) untuk menspesifikasikan, merancang, implementasi dan
pengujian sistem perangkat lunak. (www.ilmukomputer.com, Pemodelan Data,
2005).
Proses pemodelan analisis memiliki atribut dan karakteristik seperti:
1) Understandability, yaitu sejauh mana proses secara eksplisit ditentukan dan
bagaimana kemudahan definisi proses itu dimengerti.
2) Visibility, apakah aktivitas-aktivitas proses mencapai titik akhir dalam hasil
yang jelas sehingga kemajuan dari proses Tersebut dapat terlihat nyata/jelas.
3) Supportability, yaitu sejauh mana aktivitas proses dapat didukung oleh CASE
4) Acceptability, apakah proses yang telah ditentukan oleh insinyur dapat diterima
dan digunakan dan mampu bertanggung jawab selama pembuatan produk
perangkat lunak
5) Reliability, apakah proses didesain sedikian rupa sehingga kesalahan proses
dapat dihindari sebelum terjadi kesalahan pada produk. Robustness, dapatkah
proses terus berjalan walaupun terjadi masalah yang tak diduga.

Infomasi
6) Maintainability, Dapatkah proses berkembang untuk mengikuti kebutuhan atau

perbaikan.
7) Rapidity, bagaimana kecepatan proses pengiriman sistem dapat secara lengkap
memenuhi spesifikasi.
Teknik pemodelan objek menggunakan tiga macam model untuk
menggambarkan sistem, diantaranya adalah sebagai berikut :
1) Model objek
a) Model objek menggambarkan struktur statis dari suatu objek dalam sistem
dan relasinya.
b) Model objek berisi diagram objek. Diagram objek adalah graph dimana
nodenya adalah kelas yang mempunyai relasi antar kelas.
2) Model dinamik
a) Model dinamik menggambarkan aspek dari sistem yang berubah setiap
saat.
b) Model dinamik dipergunakan untuk menyatakan aspek kontrol dari sistem.
c) Model dinamik berisi state diagram. State diagram adalah graph dimana
nodenya adalah state dan arc adalah transisi antara state yang disebabkan
oleh event.
3) Model fungsional
a) Model fungsional menggambrakan transformasi nilai data dalam sistem.
b) Model fungsional berisi data flow diagram. DFD adalah suatu graph
dimana nodenya menyatakan proses dan arcnya adalah aliran data.
f. Unified Modeling Language (UML)

Unified Modeling Language (UML) adalah bahasa pemodelan untuk sistem
atau perangkat lunak yang berparadigma berorientasi objek” (Nogroho, 2010).
Unified Modeling Language (UML) disebut bahasa pemodelan bukan metode.
Bahasa pemodelan (sebagaian besar grafik) merupakan notasi dari metode yang
digunakan untuk mendesain secara cepat. Bahasa pemodelan merupakan bagian
terpenting dari metode. Ini merupakan bagian kunci untuk komunikasi. Pemodelan

ini merupakan bahasa standar untuk digunakan dalam visualisasi, spesifikasi,

pembentukan dan pendokumentasian alat – alat dari sistem perangkat lunak.
4) UML sebagai bahasa pemodelan

Unified Modeling Language (UML) merupakan bahasa pemodelan yang
memiliki pembendaharan kata dan cara untuk mempresentasikan secara fokus pada
konseptual dan fisik dari suatu sistem. Contoh untuk sistem software yang intensif
membutuhkan bahasa yang menunjukkan pandangan yang berbeda dari arsitektur
sistem, ini sama seperti menyusun atau mengembangkan sistem development life
cycle. Dengan Unified Modeling Language (UML) akan memberitahukan kita
bagaimana untuk membuat dan membaca bentuk model yang baik, tetapi Unified
Modeling Language (UML) tidak dapat memberitahukan model apa yang akan
dibangun dan kapan akan membangun model tersebut.
5) UML sebagai bahasa untuk mengambarkan sistem
UML tidak hanya merupakan rangkain simbol grafikal, cukup dengan setiap
simbol pada notasi UML merupakan penerapan semantik yang baik. UML
menggambarkan model yang dapat dimengerti dan dipresentasikan ke dalam model
tekstual bahasa pemrograman. Contohnya kita dapat menduga suatu model dari
sistem yang berbasis web tetapi tidak secara langsung dipegang dengan
mempelajari kode dari sistem.
6) UML sebagai bahasa untuk menspesifikasikan sistem
UML membangun model yang sesuai dan lengkap. Pada faktanya UML
menunjukan semua spesifikasi keputusan analisis, desain dan implementasi yang
penting yang harus dibuat pada saat pengembangan dan penyebaran dari sistem
software intensif.
7) UML sebagai bahasa untuk pendokumentasian sistem
UML menunjukan dokumentasi dari arsitektur sistem dan detail dari
semuanya. Tujuan Unified Modeling Language (UML) diantaranya adalah.
a) Memberikan model yang siap pakai, bahasa pemodelan visual yang
ekspresif untuk mengembangkan sistem dan yang dapat saling menukar
model dengan mudah dan dimengerti secara umum.

Infomasi
b) Memberikan bahasa pemodelan yang bebas dari berbagai bahasa

pemrograman dan proses rekayasa.
c) Menyatukan praktek-praktek terbaik yang terdapat dalam pemodelan.
UML (Unified Modeling Language) versi 2 mendefinisikan sehimpunan notasi

yang terdiri dari 14 technique pembuatan diagram yang digunakan untuk memodelkan
sistem. Diagram dikelompokkan menjadi 2 yaitu :
1) Structure Modelling Diagram yang digunakan untuk memodelkan struktur

sistem, yang terdiri atas: class diagaram, object diagram, package diagram,
deployment diagram, component diagram dan composite struktur diagram.
2) Behaviour Modelling Diagram yang digunakan memodelkan tingkah laku
sistem, yang terdiri atas: activity diagram, sequence diagram, communication
diagram, interaction overview diagram, timing diagram, behavioral state
machine, protocol state machine dan use case diagram
Saat ini banyak sekali tool desain UML, baik itu tool komersial maupun
open source. Beberapa diantaranya adalah:
a) StarUML (http://staruml.io/)
b) Rational Rose (www.rational.com)
c) Together (www.togethersoft.com)
d) Object Domain (www.objectdomain.com)
e) Jvision (www.object-insight.com)
f) Objecteering (www.objecteering.com)
g) MagicDraw (www.nomagic.com/magicdrawuml)
h) Visual Object Modeller (www.visualobject.com)
b. Desain UML dengan aplikasi StarUML

Pemodelan merupakan suatu hal yang tidak bisa dilepaskan dari
pembangunan aplikasi. Sebagai cikal-bakal dari suatu aplikasi, proses memodelkan
tentu bukan hal yang mudah. Namun seiring berkembangnya teknologi, pemodelan

yang notabene memakan banyak waktu bisa diselesaikan lebih cepat dan
terorganisasi. Hal tersebut bisa terjadi dengan bantuan aplikasi pemodelan.
StarUML adalah software permodelan yang mendukung UML (Unified
Modeling Language). Berdasarkan pada UML version 1.4 dan dilengkapi 11
macam diagram yang berbeda, mendukung notasi UML 2.0 dan juga mendukung
pendekatan MDA (Model Driven Architecture) dengan dukungan konsep UML.
StarUML dapat memaksimalkan produktivitas dan kualitas dari suatu software
project.
Silakan Download StarUML dari website resminya , link resmi dapat diakses di
https://staruml.io/download.
Instalasilah StarUML di komputer Anda, sebelum melanjutkan ke materi
berikut.
Jika dikomputer Anda telah terpasang StarUML, maka silakan melanjutkan ke

bahasan berikut.
2) Use Case Diagram

Use Case diagram merupakan suatu diagram yang menggambarkan
fungsionalitas yang diharapkan dari sebuah sistem. Sebuah use case dapat
memrepresentasikan interaksi antara aktor dengan sistem. Use Case Diagram
adalah abstraksi dari interaksi antara sistem dan aktor. Use case bekerja dengan cara
mendeskripsikan tipe interaksi antara user sebuah sistem dengan systemnya sendiri
melalui sebuah cerita bagaimana sebuah sistem dipakai. Use case merupakan
kontruksi untk mendeskripsikan bagaimana system akan terlihat di mata user,
sedangkn use case diagram memfalisitasi komunikasi di antara analis dan pengguna
serta analis dan klien.
Penjelasan bagian bagian use case diagram, ada 6 tool yang terpenting pada
use case diagram :
a. System
Menyatakan batasan sistem dalam relasi dengan aktor-aktor yang
menggunakannya (di luar sistem) dan fitur-fitur yang harus disediakan (dalam
sistem). Digambarkan dengan segi empat yang membatasi semua use case dalam

Infomasi
sistem terhadap pihak mana sistem akan berinteraksi. Sistem disertai label yang
menyebutkan nama dari sistem, tapi umumnya tidak digambarkan karena tidak
terlalu memberi arti tambahan pada diagram.
b. Actor
Actor adalah segala hal diluar sistem yang akan menggunakan sistem
tersebut untuk melakukan sesuatu. Bisa merupakan manusia, sistem, atau device
yang memiliki peranan dalam keberhasilan operasi dari sistem. Cara mudah untuk
menemukan aktor adalah dengan bertanya hal-hal berikut: siapa yang akan
menggunakan sistem? Aakah sistem tersebut akan memberikan nilai bagi aktor?
c. Use case
Mengidentifikasi fitur kunci dari sistem. Tanpa fitur ini, sistem tidak akan
memenuhi permintaan user/actor. Setiap use case mengekspresikan goal dari
sistem yang harus dicapai. Diberi nama sesuai dengan goal-nya dan digambarkan
dengan elips dengan nama di dalamnya. Fokus tetap pada goal bukan bagaimana
mengimplementasikannya walaupun use case berimplikasi pada prosesnya nanti.
Setiap use case biasanya memiliki trigger/pemicu yang menyebabkan use case
memulai (misalnya, pasien mendaftar dan membuat janji baru atau meminta untuk
membatalkan atau mengubah janji yang sudah ada). Terdapat 2 triger, pertama
triger eksternal, seperti pelanggan memesan atau alarm kebakaran berbunyi, kedua
triger temporal, seperti tanggal pengembalian buku terlewati di perpustakaan atau
keterlambatan bayar sewa.
d. Assosiation
Mengidentifikasikan interaksi antara setiap aktor tertentu dengan setiap use
case tertentu. Digambarkan sebagai garis antara aktor terhadap use case yang
bersangkutan. Asosiasi bisa berarah (garis dengan anak panah) jika komunikasi satu
arah, namun umumnya terjadi kedua arah (tanpa anak panah) karena selalu
diperlukan demikian.
e. Dependency
Dependensi <<include>>
i) Mengidentifikasi hubungan antar dua use case di mana yang satu memanggil
yang lain.

ii) Jika pada beberapa use case terdapat bagian yang memiliki aktivitas yang
sama maka bagian aktivitas tersebut biasanya dijadikan use case tersendiri
dengan relasi dependensi setiap use case semula ke use case yang baru ini
sehingga memudahkan pemeliharaan.
iii) Digambarkan dengan garis putus-putus bermata panah dengan notasi
<<include>> pada garis.
iv) Arah mata panah sesuai dengan arah pemanggilan.
Dependensi <<extend>>
i) Jika pemanggilan memerlukan adanya kondisi tertentu maka berlaku
dependensi <<extend>>.
ii) Note: konsep “extend” ini berbeda dengan “extend” dalam Java!
iii) Digambarkan serupa dengan dependensi <<include>> kecuali arah panah
berlawanan
e) Generalization
Mendefinisikan relasi antara dua actor atau dua use case yang mana salah
satunya meng-inherit dan menambahkan atau override sifat dari yang lainnya.
Penggambaran menggunakan garis bermata panah kosong dari yang meng-inherit
mengarah ke yang di-inherit.
Use case diagram

Berikut ialah contoh sederhana cara membuat use case diagram dengan
StarUML:
1) Buka aplikasi starUML
2) Pada tampilan awal, pilih model yang terletak pada toolbar, lalu Add
Diagram dan pilih Use Case Diagram

Infomasi
Gambar 1. 1. Memulai Use Case Diagram

3) Maka tampilan toolbox pada sebelah kiri akan berubah menjadi gambar di
bawah ini.
Gambar 1. 2. Toolbox use case diagram

4) Klik pada gambar aktor dan taruh kursor pada samping toolbox. Maka akan
muncul gambar orang yang disebut dengan actor dan beri nama actor.

Gambar 1. 3. Pemberian nama actor

5) Selanjutnya pilih usecase pada menu toolbox, tekan tiga kali pada lembar
kerja untuk membuat tiga use case dan beri nama pada setiap use case.
Gambar 1. 4. Objek Use Case

6) Untuk membuat garis hubung antara actor dan use case pilih directed
association tekan kursor pada gambar actor lalu arahkan pada usecase dan
lepas, maka garis akan terhubung.
7) Pastikan pada model explorer akan tersimpan nama dan use case diagram
yang telah dibuat.
8) Jika telah selesai simpan file dengan cara pilih file → save as.
Activity Diagram
Activity diagram menggambarkan berbagai alur aktivitas dalam sistem yang
sedang dirancang, bagaimana masing-masing alur berawal, decision yang mungkin
terjadi, dan bagaimana mereka berakhir. Activity diagram juga dapat
menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi.
Activity diagram merupakan state diagram khusus, di mana sebagian besar state
adalah action dan sebagian besar transisi di-trigger oleh selesainya state
sebelumnya (internal processing). Oleh karena itu activity diagram tidak
menggambarkan behaviour internal sebuah sistem (dan interaksi antar subsistem)
secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas
dari level atas secara umum.

Infomasi
Berikut ini adalah simbol-simbol dari activity diagram.

Tabel 1. 1. Simbol Activity Diagram
Berikut contoh activity diagram dengan actor mahasiswa dan petugas

perpustakaan.
Gambar 1. 5. Contoh activity diagram Sistem Informasi Perpustakaan

Activity diagram memodelkan workflow proses bisnis dan urutan aktivitas

dalam sebuah proses. Diagram ini sangat mirip dengan flowchart karena
memodelkan workflow dari satu aktivitas ke aktivitas lainnya atau dari aktivitas ke
status. Menguntungkan untuk membuat activity diagram pada awal pemodelan
proses untuk membantu memahami keseluruhan proses. Activity diagram juga
bermanfaat untuk menggambarkan parallel behaviour atau menggambarkan
interaksi antara beberapa use case.
Untuk membuat membuat activity diagram menggunakan starUML,
berikut akan diuraikan secara tahap-demi tahap :
1) Pilih model -> add diagram -> activitiy diagram.
2) Selanjutnya akan muncul toolbox yang berisikan gambar atau simbol yang
menjelaskan alur activity diagram.
3) Untuk membuat activity diagram diawali dengan memasukkan simbol
initial state yang menunjukkan awal dari sebuah alur activity.
4) Setelah memasukkan simbol initial state pilih simbol action state, beri nama
dengan cara klik dua kali pada simbol action.
5) Selanjutnya untuk menghubungkan antara simbol, menggunakan garis
transition yang terletak pada toolbox.
6) Setelah membuat garis pada activity diagram terdapat simbol decision yang
menjelaskan terjadi dua hasil dari sebuah alur.
7) Terakhir setelah alur selesai dalam activity wajib menggunakan simbol
finalstate yang menjelaskan alur diagram telah selesai.
8) Untuk cara penyimpanan pilih File → save as dan tentukan tempat
penyimpanan file.
Sequence Diagram
Sequence diagram menggambarkan interaksi antar objek di dalam dan di
sekitar sistem (termasuk pengguna, display, dan sebagainya) berupa message yang
digambarkan terhadap waktu. Sequence diagram terdiri atar dimensi vertikal
(waktu) dan dimensi horizontal (objek-objek yang terkait). Sequence diagram dapat
digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah yang

Infomasi
dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu.
Diawali dari apa yang mentrigger aktivitas tersebut, proses dan perubahan apa saja
yang terjadi secara internal dan output apa yang dihasilkan. Masing-masing objek,
termasuk aktor, memiliki lifeline vertikal. Message digambarkan sebagai garis
berpanah dari satu objek ke objek lainnya. Pada fase desain berikutnya, message
akan dipetakan menjadi operasi/metoda dari class.
Sequence diagram merupakan suatu penyajian perilaku yang tersusun
sebagai rangkaian langkah-langkah percontohan dari waktu ke waktu. Sequence
diagram digunakan untuk menggambarkan arus pekerjaan, pesan yang sampaikan
dan bagaimana elemen-elemen di dalamnya bekerja sama dari waktu ke waktu
untuk mencapai suatu hasil.
Tabel 1. 2. Simbol sequence diagram
Berikut contoh sederhana membuat sequence diagram dengan starUML:

1) Pertama pilih model -> add diagram -> Sequence Diagram.

Gambar 1. 6. Menu squence diagram

2) Selanjutnya pada toolbox sequence diagram terdapat simbol untuk membuat
alur diagram.
Gambar 1. 7. Toolbox squence diagram

3) Berikut adalah contoh dari sequence diagram

Infomasi
Gambar 1. 8. Contoh squence diagram

4) Cara membuat alur di atas adalah sebagai berikut:
a) Pembeli dalam alur diagram di atas menggunakan simbol object yang
terletak pada toolbox.
b) Sedangkan untuk membuat garis yang menghubungkan antara object
menggunakan stimulasi yang terletak pada toolbox.
c) Untuk memberikan nama pada garis klik dua kali pada garis maka akan
muncul tempat untuk mengetik.
d) Dalam objek kasir terdapat garis melengkung kebawah yang menunjukkan
suatu proses yang disebut setstimulasion.
5) Untuk menyimpan pilih file → save as dan pilih lokasi penyimpanan
Statechart diagram
Statechart diagram menunjukkan siklus hidup dari objek tunggal, dari saat
dibuat sampai objek tersebut dihapus. Diagram ini adalah cara tepat untuk
memodelkan perilaku dinamis sebuah kelas. Statechart diagram tidak dibuat untuk
setiap kelas, bahkan kadang-kadang untuk suatu proyek system informasi tidak
menggunakan sama sekali. Berikut ini adalah simbol-simbol dari statechart
diagram.

Tabel 1. 3. Simbol-simbol statechart diagram
Untuk menjalankan statechart diagram, dilakukan melalui menu model →

statechart diagram, seperti yang ditujukan pada gambar di bawah ini.
Gambar 1. 9. Menjalankan statechart diagram

Berikut ini contoh dari statechart diagram penyewaan kendaraan

Infomasi
Gambar 1. 10. Contoh statechart diagram
1) Seorang peminjam yang akan meminjam akan mengisi form peminjaman.

2) Sistem akan megecek keadaan barang. Barang tersebut tersedia apa tidak, atau
barang tersebut dapat di pinjam atau tidak.
3) Setelah barang tersedia, sistem akan memvalidasi persetujuan peminjaman
barang dan menyerahkan barang kepada peminjam.
4) Sistem juga akan mencari informasi tentang barang yang akan dipinjam, maka
akan dilakukan permintaan akan informasi barang.
5) Jika informasi yang diterima masih kurang, akan dilakukan permintaan ulang
sampai seluruh informasi yang dibutuhkan didapatkan.
6) Saat informasi sudah cukup, informasi tersebut akan diserahkan kepada
peminjam barang tersebut.
Deployment diagram
Deployment diagram merupakan gambaran proses-proses berbeda pada
suatu sistem yang berjalan dan bagaimana relasi di dalamnya. Hal inilah yang
mempermudah user dalam pemakaian sistem yang telah dibuat dan diagram
tersebut merupakan diagram yang statis. Misalnya untuk mendeskripsikan sebuah
situs web, deployment diagram menunjukkan komponen perangkat keras ("node")
apa yang digunakan (misalnya, web server, server aplikasi, dan database server),
komponen perangkat lunak ("artefak") apa yang berjalan pada setiap node

(misalnya, aplikasi web, database), dan bagaimana bagian-bagian yang berbeda

terhubung (misalnya JDBC, REST, RMI).
Node digambarkan sebagai kotak, dan artefak yang dialokasikan ke setiap
node digambarkan sebagai persegi panjang di dalam kotak. Node mungkin
memiliki subnodes, yang digambarkan sebagai kotak nested. Sebuah node tunggal
secara konseptual dapat mewakili banyak node fisik, seperti sekelompok database
server. Simbol dari deployment diagram dapat dilihat pada gambar di bawah ini:
Tabel 1. 4. Simbol deployment diagram
Untuk menjalankan deployment diagram, dilakukan melalui menu model →

deployment diagram pada starUML, seperti yang ditunjukkan pada Gambar di
bawah ini.

Infomasi
Gambar 1. 11. Memulai Deployment Diagram

Contoh deployment diagram
Gambar 1. 12. Contoh deployment diagram
Collaboration Diagram
Kolaborasi diagram atau collaboration diagram adalah suatu diagram yang
memperlihatkan/menampilkan pengorganisasian interaksi yang terdapat disekitar
objek (seperti halnya sequence diagram) dan hubungannya terhadap yang lainnya.
Berikut ini simbol-simbol yang ada pada kolaborasi diagram.

Tabel 1. 5. Simbol-simbol collaboration diagram
Contoh dari collaboration diagram
Gambar 1. 13. Contoh collaboration diagram

Infomasi
Componen Diagram
Komponen adalah bagian fisik atau replaceable dari sistem yang
bersesuaian dan menyediakan realisasi dari sekumpulan interface. Component
diagram menunjukkan organisasi dan ketergantungan antar komponen Component
diagram tidak hanya penting untuk visualisasi, spesifikasi, dan dokumentasi, tapi
juga mengembangkan executable system.
Berikut ini adalah simbol-simbol yang terdapat dalam component diagram
Tabel 1. 6. Simbol component diagram

Untuk menjalankan dari starUML, dapat diakses melalui menu Model → componen
diagram, seperti yang ditunjukkan dalam gambar di bawah ini.
Gambar 1. 14. Memulai component diagram

Infomasi
Contoh dari componen diagram
Gambar 1. 15. Contoh component diagram
c. Dokumentasi Pengembangan Sistem Berorientasi Objek

Dokumentasi berisi penjelasan rinci tentang inti teknis dari rekayasa
perangkat lunak yang meliputi struktur data, arsitektur program, interface dan detail
prosedural
Bagian I Berisi ruang lingkup dari kerja desain.
Bagian II Berisi desain data, struktur file. Struktur dokumen adalah:ksternal dan
referensi silang yang menghubungkan objek data dengan file tertentu.
Bagian III Berisi desain arsitektur.
Bagian IV dan V, berisi desain interface dan procedural
Bagian VI, berisi referensi silang yang bertujuan utnuk menetapkan bahwa semua
persyaratan dipenuhi oleh desain perangkat lunak dan menunjukkan modul mana
yang krites terhadap implementasi persyaratan spesifik.
Bagian VII berisi tahap pertama dari pembuatan dokumentasi pengujian.
Bagian VIII dan IX berisi data tambahan meliputi deskripsi algoritma, prosedur
alternatif, data dalam bentuk tabel, kutipan dari dokumen lain, dan informasi
relevan lainnya.
4. Forum Diskusi
Dalam rekayasa perangkat lunak dikenal dua metode pengembangan, yaitu
metode prosedural dan metode berorientasi objek. Perbedaan mendasar antara OOP

dan pemrograman terstruktur adalah dengan menggunakan OOP maka dalam

melakukan pemecahan suatu masalah kita tidak melihat bagaimana cara
menyelesaikan suatu masalah tersebut (terstruktur) tetapi objek-objek apa yang
dapat melakukan pemecahan masalah tersebut, sedangkan untuk pemrograman
terstruktur, menggunakan prosedur/tata cara yang teratur untuk mengoperasikan
data struktur.
Diskusikan pernyataan di atas, pernyataan disertai dengan contoh dan
ilustrasi.
C. Penutup
1. Rangkuman
Untuk mengetahui kebutuhan sistem berorientasi objek, maka dibutuhkan
analisis dengan menggunakan salah satu metode berikut: metode Boch, Metode
Rumbaugh (Object Modelling Technique - OMT), Metode Jacobson (Object
Oriented Software Engineering - OOSE), Metode Coad dan Yourdon, Metode
Wirfs-Brock, atau Metode Shlair-Mellor Object Oriented Analysis/Design
(OOA/D).
Tahap atau skema pelaksanaan analisis berorientasi objek , yaitu mentukan
kebutuhan pemakai untuk sistem berorientasi objek, mengidentifikasi kelas dan
objek, mengidentifikasi atribut dan layanan untuk setiap objek, mendefinisikan
efinisikan struktur dan hirarki, mebuat uat model hubungan objek dan membuat
model perilaku objek.
Unified Modeling Language (UML) adalah bahasa pemodelan untuk sistem
atau perangkat lunak yang berparadigma berorientasi objek. Unified Modeling
Language (UML) disebut bahasa pemodelan bukan metode. Bahasa pemodelan
(sebagaian besar grafik) merupakan notasi dari metode yang digunakan untuk
mendesain secara cepat. Bahasa pemodelan merupakan bagian terpenting dari
metode. Ini merupakan bagian kunci untuk komunikasi. Pemodelan ini merupakan
bahasa standar untuk digunakan dalam visualisasi, spesifikasi, pembentukan dan
pendokumentasian alat – alat dari sistem perangkat lunak. Dengan demkian UM
sebagai bahasa pemodelan, sebagai bahasa untuk menggambarkan sistem, sebagai

Infomasi
bahasa untuk menspesifikasi sistem, dan sebagai bahasa untuk pendokumentasian

sistem.
2. Tes Formatif
Jawablah Soal-Soal berikut ini dengan memilih jawaban yang paling tepat!
1. Metode ini didasarkan pada pemodelan Object Oriented dan entity- relationship.
Metode ini mempunyai perancangan yang berfokus pada empat komponen yaitu
Problem domain componet, Human interaction componet, Data management
component dan Task management component
A. Metode Boch
B. Metode Rumbaugh
C. Metode Jacobson
D. Metode Coad dan Yourdon
E. Metode Wirfs-Brock
2. Responsibility Driven Design/-Class Responsibility Collaboration
(RDD/CFC). Metode ini diarahkan pada desain, tetapi sangat berguna untuk
memunculkan ide dalam tahap analisis. Keunggulannya adalah mudah
digunakan, metode ini juga mengidentifikasikan hirarki kelas dan subsistem-
subsistem.
A. Metode Boch
B. Metode Rumbaugh
C. Metode Jacobson
D. Metode Coad dan Yourdon
E. Metode Wirfs-Brock
3. Dalam alur kerja Sistem berorientasi objek, setidaknya terdiri atas tiga langkah-
langkah yaitu:
A. Rekayasa Pemodelan, Analisis, dan desain
B. Analisis, Desain dan pengembangan
C. Desain, pengembangan dan evaluasi
D. Pengembangan, Implementasi dan evaluasi
E. Desain, implementasi, evaluasi

4. Perhatikan gambar di bawah ini.
Gambar di atas adalah gambar:

A. Deployment diagram
B. Collaboration Diagram
C. Componen Diagram
D. Use Case Diagram
E. Statement Diagram
5. Untuk dapat memahami UML diperlukan pemahaman tentang konsep bahasa
pemodelan dan tiga elemen utama UML yaitu...
A. Objek, design, dan diagram
B. Objek, diagram, dan relationship
C. Analisa, diagram, dan relationship
D. Design, diagram, dan relationship
E. Analisa, design, dan implementasi
6. Dalam analisis berorientasi objek, digambarkan model objek, model dinamik
dan model prosedural. Ketiga model ini digunakan dalam ....
A. Object Modeling Technique
B. Object Oriented Software Engineering
C. Unified Modeling Language
D. Object Oriented Analysis
E. Object Oriented Design
7. Gambar di bawah ini merupakan diagram.....

Infomasi
A. Deployment diagram
B. Activity Diagram
C. Componen Diagram
D. Use Case Diagram
E. Statement Diagram
8. Untuk menggambarkan proses bisnis dan urutan aktivitas dalam sebuah proses
dapat menggunakan diagram...
A. Usecase diagram
B. Deployment diagram
C. Statechart diagram
D. Component diagram
E. Activity diagram
9. Dibawah ini adalah diagram-diagram yang termasuk dalam behavior diagram
adalah, kecuali
A. Activity diagram
B. Interaction diagram
C. State machine diagram
D. Class diagram
E. Use case diagram
10. Dam kasus Sistem Informasi Perpustakaan, terlibat Pustakawan sebagai
operator sistem. Prosedur dalam sistem informasi perpustakaan diantaranya:
▪ PendaftaranAnggota

▪ PendataanKoleksiBuku
▪ PeminjamanBuku
▪ PengembalianBuku
▪ PembuatanLaporan
Class (iagram yang dirancang diantaranya class anggota, buku, peminjaman
dan pengembalian.
Jika pustakawan akan menambah data koleksi buku, maka dalam Sequence
diagram perlu menampilkan beberapa simbol seperti
A. Aktor Pustakawan dan mahasiswa
B. Aktor ma!asiswa, boundary Form Buku, Control Buku dan Entitas
Buku
C. Boundary Form Buku dan Control Buku
D. Aktor Pustakawan, Boundary Form Buku, Control Buku dan Enntitas
Buku
E. Aktor Pustakawan, Boundary Form Buku dan Control Buku
Daftar Pustaka
Alan Denis, Barbara Haley Wixon, David Tagerden, 2005. System Analys and
Design : an Object – Oriented Approach with UML 2.0, John Willey and
Sons.
Edward V. Berard, Origins Objects Oriented Technology,
http://www.toa.com/pub/oobasics/oobasics.htm
Henry C. Lucas Jr., 1992. The Analysis,. , McGraw Hill,.
Kahate, Atul, 2004. Object Oriented Analysis & Design. New Delhi: Tata
McGraw-Hill Publishing Company Limited.
Kasmin Arif. Mengenal Pemodelan Unified Modeling Language (UML).
http://kasminarif.blogspot.co.id/2014/11/mengenal-pemodelan-unified-
modeling.html, Diakses 21 Agustus 2019.
Keyes, Jessica, 2002. Software Engineering Handbook, New York: Auerbach
Publication.
Matha, Mahesh P, 2008. Object Oriented Analysis and Design Using UML. New
Delhi: Prentice Hall of IndiaProvate Limited.
Nugroho, Adi., 2010. Rekayasa Perangkat Lunak Berbasis Objek dengan Metode
USDP. Yogyakarta: Penerbit Andi.

Infomasi
Verdi Yasin. 2012. Rekayasa Perangkat Lunak Berorientasi Obj ek. Mitra Wacana
Media. Jakarta
Satzinger, Jackson, Burd, 2005. Object-Oriented Analysis and Design with the
Unified Process, Course Technology,
Simon Bennet, Steve McRobb and Ray Farmer, 2006. Object Oriented Systems
Analysis and Design Using UML, Edisi 3. ; McGraw Hill,. (SB) 2.
Wendy and Michael Boggs, 2002. UML with Rational Rose, Sibex Inc.

Final Modul 2-KB 1 (Fathahillah) PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

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

Final Modul 2-KB 1 (Fathahillah) PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

Modul 2, Rekayasa Perangkat Lunak

KB 1, Konsep OOAD Dalam Perancangan Aplikasi/Sistem 1

2 KB 1, Konsep OOAD Dalam Perancangan Aplikasi/Sistem Infomasi

terhadap alam melalui aktivitas manusia. Proses sains mengembangkan

KB 1, Konsep OOAD Dalam Perancangan Aplikasi/Sistem 3

4 KB 1, Konsep OOAD Dalam Perancangan Aplikasi/Sistem Infomasi

d. Membuat dokumentasi pengembangan sistem berorientasi objek

KB 1, Konsep OOAD Dalam Perancangan Aplikasi/Sistem 5

karakterisitik dan hubungannya dalam sebuah notasi formal. Aplikasi konsep

6 KB 1, Konsep OOAD Dalam Perancangan Aplikasi/Sistem Infomasi

iii) Mengidentifikasi subjek

KB 1, Konsep OOAD Dalam Perancangan Aplikasi/Sistem 7

• Menggunakan diagram aliran data untuk merepresentasikan aliran

8 KB 1, Konsep OOAD Dalam Perancangan Aplikasi/Sistem Infomasi

• Mendefinisikan atribut dan layanan untuk setiap kelas

KB 1, Konsep OOAD Dalam Perancangan Aplikasi/Sistem 9

10 KB 1, Konsep OOAD Dalam Perancangan Aplikasi/Sistem Infomasi

b. Metode Analisis Secara Umum

2) Identifikasi Kelas dan Objek

KB 1, Konsep OOAD Dalam Perancangan Aplikasi/Sistem 11

12 KB 1, Konsep OOAD Dalam Perancangan Aplikasi/Sistem Infomasi

iv) Kepemilikan (incorporated by, is composed of)

KB 1, Konsep OOAD Dalam Perancangan Aplikasi/Sistem 13

c. Tahapan Pengembangan Sistem Berorientasi Objek

14 KB 1, Konsep OOAD Dalam Perancangan Aplikasi/Sistem Infomasi

rancangan sistem. Deliverablesnya meliputi notasi-notasi structure dan

KB 1, Konsep OOAD Dalam Perancangan Aplikasi/Sistem 15

8) Project management, merupakan cross-phase flow. Contoh dari aktifitas

Pengembangan perangkat lunak yang mendasari pembangunan sistem

untuk mengembangkan sistem-sistem tersebut (Muslihudin & Oktafianto, 2016).

Nugroho (2010) mendefinisikan SDLC adalah pengembangan atau

menyempurnakan yang telah ada sebelumnya. Sedangkan menurut A.S. &

Shalahuddin (2019), SDLC adalah proses mengembangkan atau mengubah suatu

sistem perangkat lunak dengan menggunakan model-model dan metodologi yang

digunakan orang untuk mengembangkan sistem-sitem perangkat lunak sebelumnya

(berdasarkan best practice atau cara-cara yang sudah teruji baik).

Shalahuddin (2019) adalah sebagai berikut :

16 KB 1, Konsep OOAD Dalam Perancangan Aplikasi/Sistem Infomasi

2) Pengembangan konsep sistem (system concept development), mendefinisikan

lingkup konsep termasuk dokumen lingkup sistem, analisis manfaat biaya,

manajemen rencana, dan pembelajaran kemudahan sistem.

3) Perencanaan (planning), mengembangkan rencana manajemen proyek dan

dokumen perencanaan lainnya. Menyediakan dasar untuk mendapatkan

sumber daya (resources) yang dibutuhkan untuk memperoleh solusi.

4) Analsis kebutuhan (requirements analysis), menganalisis kebutuhan pemakai

sistem perangkat lunak (user) dan mengembangkan kebutuhan user, serta

membuat dokumen kebutuhan fungsional.

5) Desain (design), mentransformasikan kebutuhan detail menjadi kebutuhan

memenuhi fungsi yang dibutuhkan.

6) Pengembangan (development), mengonversi desain ke sistem informasi yang

lengkap termasuk bagaimana memperoleh dan melakukan instalasi lingkungan

sistem yang dibutuhkan; membuat basis data dan mempersiapkan prosedur

kasus pengujian; mempersiapkan berkas atau file pengujian, pengodean,

pengompilasian, memperbaiki dan membersihkan program; peninjauan, dan

7) Integrasi dan pengujian (integration and test), mendemonstrasikan sistem

perangkat lunak bahwa telah memenuhi kebutuhan yang dispesifikasikan pada

dokumen kebutuhan fungsional. Dengan diarahkan oleh staf penjamin kualitas

(quality assurance) dan user. Menghasilkan laporan analisis pengujian.

KB 1, Konsep OOAD Dalam Perancangan Aplikasi/Sistem 17

8) Implementasi (implementation), termasuk pada persiapan implementasi,

implementasi perangkat lunak pada lingkungan produksi (lingkungan pada

integrasi dan pengujian.

9) Operasi dan pemeliharaan (operations and maintetance), mendeskripsikan