LAPORAN PRAKTIKUM

REKAYASA PERANGKAT LUNAK

Oleh :

Arnita Fentrin Pratama 188320700017

A1

PROGRAM STUDI PENDIDIKAN TEKNOLOGI INFORMASI

FAKULTAS PSIKOLOGI DAN ILMU PENDIDIKAN
UNIVERSITAS MUHAMMADIYAH SIDOARJO
2021
 LABORATORIUM JARINGAN
PROGRAM STUDI PENDIDIKAN TEKNOLOGI INFORMASI
FAKULTAS PSIKOLOGI DAN ILMU PENDIDIKAN
UNIVERSITAS MUHAMMADIYAH SIDOARJO
2021

LEMBAR PENGESAHAN

Telah Diperiksa Isi Laporan Ini

LAPORAN PRAKTIKUM
REKAYASA PERANGKAT LUNAK

Disusun oleh:

Arnita Fentrin P 188320700017

A1

Sidoarjo, Januari 2021

Mengetahui,
Kaprodi PTI

Fitria Nur Hasanah, M.Pd

 KATA PENGANTAR

Puji syukur kami panjatkan kehadirat Tuhan Yang Maha Esa yang telah memberikan
rahmat dan karunia-Nya sehingga kami dapat melaksanakan sebuah praktikum dan
menyelesaikannya dengan baik hingga menjadi sebuah laporan praktikum. Laporan yang disusun
dengan baik ini bertujuan untuk memenuhi tugas kuliah Rekayasa Perangkat Lunak.
Dengan terselesainya laporan praktikum ini, maka tidak lupa kami mengucapkan banyak
terima kasih kepada semua pihak yang terlibat dalam penyusunan laporan ini, khususnya kepada:
1. Kepada selaku dosen pengampu Fitria Nur Hasanah, M.Pd yang telah membimbing dan
mengarahkan dalam menyusun laporan ini.
2. Kepada orang tua yang selalu mendoakan kelancaran kuliah kami.

Demikian laporan yang saya buat, mohon kritik dan sarannya atas kekurangan dalam
penyusunan laporan ini. Semoga laporan ini dapat bermanfaat bagi semua pihak.

Sidoarjo, 31 Oktober 2020

Penyusun
 LABORATORIUM JARINGAN
PROGRAM STUDI PENDIDIKAN TEKNOLOGI INFORMASI
FAKULTAS PSIKOLOGI DAN ILMU PENDIDIKAN
UNIVERSITAS MUHAMMADIYAH SIDOARJO

2021

LEMBAR ASISTENSI
REKAYASA PERANGKAT LUNAK
ERD (ENTITY RELATIONSHIP DIAGRAM)
PRAKTIKUM KE 3

Judul Praktikum : ERD

Nama/NIM : Arnita Fentrin P / 188320700017
Dilaksanakan pada : 31 Oktober 2020

Sidoarjo, 31 Oktober 2020

Mengetahui,
Dosen Pembimbing

Fitria Nur Hasanah, M.Pd

 PRAKTIKUM KE-3

ERD

A. PENDAHULUAN
Tujuan :

1. Mahasiswa mampu menerapkan ERD

2. Mahasiswa mampu menerapkan studi kasus ERD

B. DASAR TEORI
Pemodelan awal basis data yang paling banyak digunakan adalah Entity Relationship
Diagram (ERD). ERD digunakan untuk pemodelan basis data relational. Diagram relasi
entitas atau ERD adalah suatu diagram dalam bentuk gambar atau simbol yang
mengidentifikasi tipe dari entitas di dalam suatu sistem yang diuraikan dalam data dengan
atributnya, dan menjelaskan hubungan atau relasi diantara entitas tersebut. ERD merupakan
model jaringan yang menggunakan susunan data yang disimpan dalam sistem secara abstrak.
ERD berupa model data konseptual, yang merepresentasikan data dalam suatu organisasi.
ERD menekankan pada struktur dan relationship data.
Untuk dapat membuat entity relasional diagram, maka komponen yang harus terpenuhi
adalah:
1. Obyek Data, Atribut dan Hubungan.
Obyek Data Adalah representasi dari hampir semua informasi gabungan yang harus
dipahami oleh perangkat lunak. Objek data dapat berupa entitas eksternal (misalkan
semua yang menghasilkan informasi), suatu benda (misal laporan atau tampilan),
peristiwa (misalnya proses meminjam) atau event, peran (misalnya peminjam), unit
organisasi atau suatu struktur.
2. Kardinalitas dan Modalitas Kardinalitas
Model data harus dapat merepresentasikan jumlah peristiwa dari obyek di dalam
hubungan yang diberikan.
a. Satu ke satu (1:1) Misalnya: seorang suami hanya dapat memiliki satu istri,
dan seorang istri hanya mempunyai satu suami.
b. Satu ke banyak (1:N) Misalnya: seorang ibu kandung dapat memiliki banyak
 anak, tetapi seorang anak hanya dapat memiliki satu ibu kandung.
c. Banyak ke banyak (M:N) Misalnya: seorang paman dapat memiliki banyak
keponakan, sementara itu seorang keponakan dapat memiliki banyak paman.
Entitas (Entity)
Entitas merupakan obyek yang mewakili sesuatu dalam dunia nyata dan dapat
dibedakan antara satu dengan lainnya (unique). Setiap entitas memiliki beberapa atribut yang
mendeskripsikan karakteristik dari objek tersebut. Atribut Dapat berupa:
1. Fisik (mobil, rumah, manusia, pegawai dsb)
2. Abstrak/konsep (department, pekerjaan, mata kuliah dsb)
3. Kejadian (pembelian, penjualan, peminjaman, dll)
Urutan langkah untuk menemukan atau mendefinisikan entitas dalam suatu sistem
adalah:
1. Buat ilustrasi/gambaran cerita tentang sistem yang akan dicari entitasnya
2. Tandai setiap objek yang diwakili oleh kata benda yang ada di dalam ilustrasi
tersebut
3. Untuk setiap objek tersebut yakinkan bahwa ia memiliki karakteristik yang nanti
disebut sebagai atribut
4. Tentukan objek yang merupakan entitas (Jika memang ia memiliki karakteristik
jadikan ia sebagai entitas)
5. Menggambarkan entitas beserta atributnya menggunakan notasi simbol yang
telah ditentukan.
Atribut
Atribut adalah sifat-sifat atau karakteristik pada suatu entitas. Nama atribut ini identik
dengan nama kolom atau field pada suatu tabeldalam basis data.Candidat Key adalah
merupakan superkey yang jumlah atributnya paling sedikit.
Primary key adalah suatu candidat key yang dipilih menjadi kunci utama karena
sering dijadikan acuan untuk mencari informasi, ringkas, menjadi keunikan suatu baris.
MisalnyakodeBuku antara buku yang satu dengan buku yang lain pasti berbeda, dalam hal
ini kodeBuku dapat digunakan sebagai suatu key.
Relasi (Relationship)
Relasi menyatakan hubungan antara dua atau beberapa entitas.Setiap relasi
mempunyai batasan (constraint) terhadap kemungkinan kombinasi entitas yang
berpartisipasi. Batasan tersebut ditentukan dari situasi yang diwakili relasi tersebut. Ragam
atau jenis relasi dibedakan menjadi beberapa macam antara lain adalah.
1. Relasi Binary. Relasi ini merupakan relasi antara 2 entitas. Relasi ini dibedakan menjadi
:
a. Relasi One-to-one (notasi 1:1)
b. Relasi One-to-many (notasi 1:N) atau many-to-one (notasi N:1)
c. Relasi Many-to-many (notasi M:N)
2. Relasi Ternary. Relasi ini merupakan relasi antara 3 entitas atau lebih.
Dalam Relasi One-to-one (1:1) setiap atribute dari satu entitas berpasangan dengan satu
attribute dari entitas yang direlasikan.Dalam relasi One-to-many (1:N) atau many-to- one
(N:1) satu atribute berelasi dengan beberapa atribute dari entitas yang direlasikan. Dalam
Many-to-many (M:N) satu atribute berelasi dengan beberapa atribute dari entitas yang
direlasikan, begitu pula sebaliknya.

C. KEGIATAN PRAKTIKUM
Langkah 1. Deskripsi tentang gambaran system informasi

Industry INTAKO Tanggulangin, yang merupakan industry kerajinan kulit tas dan koper
yang memiliki banyak cabang industri rumahan dengan setiap cabang memiliki admin yang
berbeda beda , industry ini masih menerapkan sistem transaksi yang manual. Dimana pemilik
cabang industry adalah admin dari transaksi transaksi penjualan yang terjadi. Pelanggan
melakukan transaksi jual beli barang yang tersedia di showroom. Admin mengelola proses
transaksi yang berlangsung. Kegiatan jual beli ini akan tetap berlangsung dan diproses selagi
barang yang diinginkan masih tersdia . Jika stok barang ditoko sudah mulai menipis maka
admin akan memesan barang tersebut pada supplier yang sudah ditentukan..

Langkah 2. Tandai setiap objek yang diwakili oleh kata benda yang ada di dalam ilustrasi
tersebut.

Industry INTAKO Tanggulangin, yang merupakan industry kerajinan kulit tas dan koper
yang memiliki banyak cabang industri rumahan dengan setiap cabang memiliki admin yang
berbeda beda , industry ini masih menerapkan sistem transaksi yang manual. Dimana pemilik
cabang industry adalah admin dari transaksi transaksi penjualan yang terjadi. Pelanggan
melakukan transaksi jual beli barang yang tersedia di showroom. Admin mengelola proses
transaksi
 yang berlangsung. Kegiatan jual beli ini akan tetap berlangsung dan diproses selagi barang
yang diinginkan masih tersdia stok. Jika stok barang ditoko sudah mulai menipis maka admin
akan melakukan pembelian barang tersebut pada supplier yang sudah ditentukan.

Langkah 3. Untuk setiap objek tersebut yakinkan bahwa ia memiliki karakteristik yang nanti
disebut sebagai atribut

Admin : Id_Admin, Nama, username, password

Pelanggan: kd_pelanggan, no_telp, nama_pelanggan, alamat, jenis_kelamin, foto

Barang : kd_barang, kategori, nama_barang, satuan, harga_beli, harga_jual, stok

Transaksi : kd_penjualan, id_Admin, kd_pelanggan, no_jual, tgl_jual, kd_barang,

harga_jual, jumlah_jual, total

Supplier : kd_supplier, nama_supplier, no_telp

Pembelian: kd_beli, id_Admin, kd_supplier , tgl_beli, kd_barang, harga_beli, jumlah_beli,

total

Langkah 4. Tentukan setiap hubungan yang diwakili oleh kata kerja yang ada di dalam
ilustrasi dan entitas yang berhubungan. Identifikasi hubungan antara entitas

ENTITAS 1 HUBUNGAN ENTITAS 2

Admin Mengelola Transaksi, pembelian
Pelanggan Melakukan Transaksi
Barang Memiliki Transaksi
Supplier Melayani Pembelian

Langkah 5. Buka aplikasi power designer. Buatlah model baru dan beri nama misalnya:
ERD_penjualan
Langkah 5. Membuat CDM dan PDM dan mengubah ke bentuk SQL
1. Buatlah entitas-entitas pada Workspace besert atributya.
2. Buatlah relasi antar entitas dan ubah properties cardinallitas sesuai yang dibutuhkan,
misalnya seperti berikut:

3. Setelah semua entitas dan aribut sudah terrelasi semua. Selanjutnya generate ke dalam
CDM dengan pilih menu Tools > Generate Conceptual Data Model. Selanjutnya cek
model dengan pilih menu Tools > Check Model atau (F4).
4. Generate juga ke dalam PDM dengan pilih menu Tools > Generate Physical Data
Model. Selanjutnya cek model dengan pilih menu Tools > Check Model atau
(F4).

Contreng semua folder kemudian klik OK. Jika jumlah error = 0 dan warning = 0 maka
pembuatan CDM sudah benar.
5. Setelah selesai membuat CDM dan PDM kita dapat merubah database ke dalam bentuk
.sql dengan klik Database > Geerate Database. Pilih directory penyimpanan dan rename
dengan menambahkan ekstensi .sql.

6. Lalu pada tools Options teptnya pada “Create Primary Key” pilih outside dan uncheck
Drop primary key.
 D. KESIMPULAN
Pemodelan awal basis data yang paling banyak digunakan adalah Entity Relationship
Diagram (ERD). ERD digunakan untuk pemodelan basis data relational. Untuk dapat membuat
entity relasional diagram, maka komponen yang harus terpenuhi adalah:
1. Obyek Data, Atribut dan Hubungan.
2. Kardinalitas dan Modalitas Kardinalitas
a. Satu ke satu (1:1)
b. Satu ke banyak (1:N)
c. Banyak ke banyak (M:N)
Entitas (Entity)
Entitas merupakan obyek yang mewakili sesuatu dalam dunia nyata dan dapat dibedakan
antara satu dengan lainnya (unique).
Atribut
Atribut adalah sifat-sifat atau karakteristik pada suatu entitas. Nama atribut ini identik
dengan nama kolom atau field pada suatu tabeldalam basis data. Candidat Key adalah
merupakan superkey yang jumlah atributnya paling sedikit. Primary key adalah suatu candidat
key yang dipilih menjadi kunci utama karena sering dijadikan acuan untuk mencari informasi,
ringkas, menjadi keunikan suatu baris.
Relasi (Relationship)
Relasi menyatakan hubungan antara dua atau beberapa entitas.Setiap relasi mempunyai
batasan (constraint) terhadap kemungkinan kombinasi entitas yang berpartisipasi.

E. DAFTAR PUSTAKA
Hasanah, Fitri Nur & Untari, Rahmania Sri. 2020. Modul Rekayasa Perangkat Lunak.
Sidoarjo : UMSIDA PRESS.
Hasanah, Fitri Nur & Untari, Rahmania Sri. 2020. Buku Ajar Basis Data MySQL. Sidoarjo :
UMSIDA PRESS.
Iqbal, Ahmad. 2018. Penerapan Entity Relationship Diagram (ERD) Perancangan Sisem Basis
Data Terhadap Produk Indihome. Repository Institut Teknologi Telkom Purwokerto.
 LABORATORIUM JARINGAN
PROGRAM STUDI PENDIDIKAN TEKNOLOGI INFORMASI
FAKULTAS PSIKOLOGI DAN ILMU PENDIDIKAN UNIVERSITAS
MUHAMMADIYAH SIDOARJO
2021

LEMBAR ASISTENSI
REKAYASA PERANGKAT LUNAK
DFD (DATA FLOW DIAGRAM)
PRAKTIKUM KE 4

Judul Praktikum : DFD (Data Flow Diagram)

Nama/NIM : Arnita Fentrin Pratama / 188320700017
Dilaksanakan pada : 03 November 2020

Sidoarjo, 05 November 2020

Mengetahui,
Dosen Pembimbing

Fitria Nur Hasanah, M.Pd

 PRAKTIKUM KE-4
DFD (DATA FLOW DIAGRAM)

A. PENDAHULUAN
Tujuan :

1. Mahasiswa mampu menerapkan tingkatan level DFD

2. Mahasiswa mampu menerapkan tahapan pembuatan DFD
3. Mahasiswa mampu menerapkan studi kasus DFD

B. DASAR TEORI
Data Flow Diagram (DFD) merupakan suatu cara atau metode untuk membuat rancangan
sebuah sistem yang mana berorientasi pada alur data yang bergerak pada sebuah sistem nantinya.
Dalam pembuatan Sistem Informasi, DFD sering digunakan. DFD dibuat oleh para analis untuk
membuat sebuah sistem yang baik. Dimana DFD ini nantinya diberikan kepada para programmer
untuk melakukan proses coding. Dimana para programmer melakukan sebuah coding sesuai
dengan DFD yang dibuat oleh para analis sebelumnya.
1. Komponen DFD
Terdapat beberapa notasi atau simbol yang digunakan dalam DFD. Notasi tersebut merupakan
karakteristik dari suatu system. Notasi dan simbol-simbol yang sering dipakai antara lain yaitu
:
a. Terminator atau External Entity.
Terminator disimbolkan dalam bentuk persegi panjang, yang mewakili entity luar dimana
sistem berkomunikasi. sebagai contoh adalah entity: pegawai, mahasiswa, peserta didik
dll. Gambar dibawah ini menjelaskan notasi atau simbol Terminator (External Entity).
b. Proses
Komponen proses menggambarkan suatu transformasi input menjadi output. Penamaan
proses disesuaikan dgn proses atau kegiatan yang sedang dilakukan Pemberian nama suatu
proses menggunakan kata kerja transistif yaitu kata kerja yang membutuhkan objek.
Komponen Proses disimbolkan dalam bentuk lingkaran dengan nama proses ditulis
didalam lingkaran.
c. Penyimpanan Data (Data Store)
Data store digunakan untuk memodelkan kumpulan data atau paket data. Penyimpanan
data kadangkala didefinisikan sebagai suatu mekanisme diantara dua proses yang dibatasi
oleh jangka waktu tertentu. Data store dapat berupa fie atau basis data yang tersimpan
 dalam unit penyimpanan seperti disket, harddisk. Data store disimbolkan dengan garis
sejajar.
d. Aliran Data (flow)
Alur data digunakan untuk menerangkan perpindahan data atau paket data dari satu
bagian ke bagian lainnya. Alur data menunjukkan aliran data yang dapat berupa masukkan
untuk sistem atau hasil proses system.
2. Tingkatan atau Level DFD
Dalam penerapannya tidak ada aturan yang baku tentang tingkatan atau level DFD. Secara
umum terdapat beberapa tingkatan yang sering digunakan antara laian adalah sebagai berikut :
a. Diagram Konteks. Diagram konteks menggambarkan secara global aliran informasi dan
data yang akan dilakukan oleh system. Diagram konteks ini merupakan level tertinggi (top
level) yang menggambarkan hubungan antar system dengan entitas diluar system dan
merupakan gambaran system secara keseluruhan. Komponen yang ada dalam diagram ini
biasanya komponen proses, external entity dan alur data.
b. Diagram Nol (Zero). Diagram ini menjelaskan lebih detail dari diagram konteks. Diagram
ini merupakan dekomposisi diagram konteks. Beberapa proses dalam diagram konteks
dapat dijelaskan lebih rinci.
c. Diagram Level Satu. Diagram ini merupakan dekomposisi dari diagram level zero.
d. Diagram level dua. Diagram ini merupakan dekomposisi dari diagram level zero.

C. KEGIATAN PRAKTIKUM
Kembangkan DFD sesuai dengan analisis kebutuhan yang telah dilakukan pada praktikum
sebelumnya.
 Level 1

D. KESIMPULAN
Data Flow Diagram (DFD) merupakan suatu cara atau metode untuk membuat rancangan
sebuah sistem yang mana berorientasi pada alur data yang bergerak pada sebuah sistem nantinya.
1. Komponen DFD
a. Terminator atau External Entity.
b. Proses
c. Penyimpanan Data (Data Store)
d. Aliran Data (flow)
2. Tingkatan atau Level DFD
a. Diagram Konteks.
b. Diagram Nol (Zero).
c. Diagram Level Satu.
d. Diagram level dua.

E. DAFTAR PUSTAKA
Hasanah, Fitri Nur & Untari, Rahmania Sri. 2020. Modul Rekayasa Perangkat Lunak. Sidoarjo :
UMSIDA PRESS.
 LABORATORIUM JARINGAN
PROGRAM STUDI PENDIDIKAN TEKNOLOGI INFORMASI
FAKULTAS PSIKOLOGI DAN ILMU PENDIDIKAN
UNIVERSITAS MUHAMMADIYAH SIDOARJO

2021

LEMBAR ASISTENSI
REKAYASA PERANGKAT LUNAK
PEMODELAN UML (USE CASE)
PRAKTIKUM KE 5

Judul Praktikum : Pemodelan UML

Nama/NIM : Arnita Fentrin P / 188320700017
Dilaksanakan pada : 30 November 2020

Sidoarjo, 06 Desember 2020

Mengetahui,
Dosen Pembimbing

Fitria Nur Hasanah, M.Pd

 PRAKTIKUM KE-5

PEMODELAN UML

A. PENDAHULUAN
Tujuan :

1. Mahasiswa mampu menerapkan UML

2. Mahasiswa mampu menerapkan Use Case Diagram
3. Mahasiswa mampu menerapkan Activity Diagram

B. DASAR TEORI
1. Pemodelan Perangkat Lunak
Pemodelan dalam suatu rekayasa perangkat lunak merupakan suatu hal yang
dilakukan di tahapan awal. Di dalam suatu rekayasa dalam perangkat lunak sebenarnya
masih memungkinkan tanpa melakukan suatu pemodelan. Namun hal itu tidak dapat lagi
dilakukan dalam suatu industri perangkat lunak. Pemodelan delam perangkat lunak
merupakan suatu yang harus dikerjakan di bagian awal dari rekayasa, dan pemodelan ini
akan mempengaruhi perkerjaan-pekerjaan dalam rekayasa perangkat lunak tersebut.
Pada rekayasa perangkat lunak, banyak model yang telah dikembangkan untuk
membantu proses pengembangan perangkat lunak. Model-model ini pada umumnya
mengacu pada model proses pengembangan sistem yang disebut System Development
Life Cycle (SDLC) seperti yang telah dibahas dibab sebelumnya. Pemodelan perangkat
lunak digunakan untuk mempermudah langkah berikutnya dari pengembangan sebuah
sistem informasi sehingga lebih terencana. Salah satu perangkat pemodelan adalah
Unified Modelling Language (UML).
2. UML
UML adalah sebuah bahasa yang berdasarkan grafik/gambar untuk
memvisualisasi, menspesifikasikan, membangun, dan pendokumentasian dari sebuah
sistem pengembangan software berbasis OO (Object-Oriented). UML sendiri juga
memberikan standar penulisan sebuah sistem blue print, yang meliputi konsep bisnis
proses, penulisan kelas-kelas dalam bahasa program yang spesifik, skema database, dan
komponen- komponen yang diperlukan dalam sistem softwar. Pendekatan analisa &
 rancangan dengan menggunakan model OO mulai diperkenalkan sekitar pertengahan
1970 hingga akhir 1980 dikarenakan pada saat itu aplikasi software sudah meningkat dan
mulai komplek.
UML sebagai sebuah bahasa yang memberikan vocabulary dan tatanan penulisan
kata-kata dalam ‘MS Word’ untuk kegunaan komunikasi. Sebuah bahasa model adalah
sebuah bahasa yang mempunyai vocabulary dan konsep tatanan / aturan penulisan serta
secara fisik mempresentasikan dari sebuah sistem. Seperti halnya UML adalah sebuah
bahasa standard untuk pengembangan sebuah software yang dapat menyampaikan
bagaimana membuat dan membentuk model-model, tetapi tidak menyampaikan apa dan
kapan model yang seharusnya dibuat yang merupakan salah satu proses implementasi
pengembangan software.
a. Building Blocks
3 (tiga) macam yang terdapat dalam building block adalah katagori benda/Things,
hubungan, dan diagram. Benda/things adalah abstraksi yang pertama dalam sebuah
model, hubungan sebagai alat komunikasi dari bendabenda, dan diagram sebagai
kumpulan / group dari benda-benda/things.
3. Use Case Diagram
Use case diagram adalah teknik untuk merekam persyaratan fungsional sebuah
system, menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Use case
diagram menekankan kepada “apa” yang diperbuat oleh sistem, dan bukan “bagaimana”.
Sebuah use case merepresentasikan sebuah interaksi antara aktor dengan sistem.
Use case merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, meng-create
sebuah daftar belanja, dan sebagainya. Seorang atau sebuah aktor adalah sebuah entitas
dapat berupa manusia atau mesin yang berinteraksi dengan system untuk melakukan
pekerjaan-pekerjaan tertentu.
Manfaat Use Diagram
Use case diagram akan sangat membantu kita dalam menyusun kebutuhan-
kebutuhan (requirement analisis) sebuah sistem. Use case diagram akan di gunakan
untuk mengkomunikasikan rancangan sistem dengan klien, dan merancang test case
untuk semua feature yang ada pada sistem.
Relationship dalam Use Case Diagram
 Didalam use case diagram terdapat dua komponen penting yang saling
berinterakasi dan berkomunikasi. Komponen tersebut adalah aktor dan use case. Ragam
relasi yang terjadi diantara komponen-komponen tersebut adalah :
a. Assosiations
Relasi ini diigunakan untuk menghubungkan para actor dan case di dalam suatu
diagram. asosiasi ini dapat digambar dalam dua arah, tergantung dari kedudukan
aktornya. jika aktornya adalah sebagai aktor utama (primery actor) maka arah relasi
adalah dari actor menuju case. Jika aktornya adalah sebagai aktor tambahan
(secondary actor) maka arah relasi dari case menuju actor.
b. Dependency
Relasi ini menyatakan suatu hubungan semantik antara dua unsur-unsur modeling
yang mana perubahan satu elemen atau unsur model (unsur yang mengalir masuk)
dapat mempengaruhi unsur modeling yang lain (unsur yang dependent). Relasi ini
menghubungkan antara use case satu dengan use case yang lain.
c. Generalization/inheritance
Relasi ini menyatakan hubungan hirarkis, turunan atau menyatakan suatu bagian
dalam satu komponen. Sehingga aktor dapat diturunkan menjadi aktor-aktor yang lain
atau use case dapat didekomposisi atau diturunkan menjadi use case yang lain. Relasi
ini menunjukkan bahwa actor yang satu merupakan spesialisasi dari actor yang lain.
Demikian juga use case satu merupakan spesialisasi dari usecase yang lain.
Komponen yang terlibat dalam Use Case Diagram
a. Aktor
Pada dasarnya actor bukanlah bagian dari use case diagram, namun untuk dapat
terciptanya suatu use case diagram diperlukan beberapa actor. Actor tersebut
mempresentasikan seseorang atau sesuatu (seperti perangkat, sistem lain) yang
berinteraksi dengan sistem. Sebuah actor mungkin hanya memberikan informasi
inputan pada sistem, hanya menerima informasi dari sistem atau keduanya menerima,
dan memberi informasi pada sistem.
b. Use Case
Use case adalah gambaran fungsionalitas dari suatu sistem, sehingga customer atau
pengguna sistem paham dan mengerti mengenai kegunaan sistem yang akan
 dibangun.
Catatan : Use case diagram adalah penggambaran sistem dari sudut pandang
pengguna sistem tersebut (user), sehingga pembuatan use case lebih dititikberatkan
pada fungsionalitas yang ada pada sistem, bukan berdasarkan alur atau urutan
kejadian.
c. Relasi dalam Use Case
Ada beberapa relasi yang mungkin terjadi pada use case diagram:
 <<include>> , yaitu kelakuan yang harus terpenuhi agar sebuah event dapat
terjadi, dimana pada kondisi ini sebuah use case adalah bagian dari use case
lainnya.
 <<extends>>, kelakuan yang hanya berjalan di bawah kondisi tertentu seperti
menggerakkan alarm.
 <<communicates>>, mungkin ditambahkan untuk asosiasi yang menunjukkan
asosiasinya adalah communicates association . Ini merupakan pilihan selama
asosiasi hanya tipe relationship yang dibolehkan antara actor dan use case.
d. Use Case Diagram
Use Case Diagrm adalah gambaran graphical dari beberapa atau semua actor, use
case, dan interaksi diantaranya yang memperkenalkan suatu sistem.
e. Batasan Sistem (System Boundary)
Dalam batasan sistem hal-hal yang penting yaitu:
1) System boundary.
2) Mendefinisikan batas antara actor dan sistem.
3) Dinotasikan bujur sangkar/persegi.
4) Semua use case tercakup di dalamnya.

C. KEGIATAN PRAKTIKUM

1. sistem perbankan adalah suatu sistem yang menyangkut tentang bank, mencakup kelembagaan,
kegiataan usaha, sertya cara dan proses melaksanakan kegiatan usahanya secara keseluruhan.
Definisi Aktor dan Use Case :

1. Nasabah mendaftar menuju Customer Service.

2. Customer Service menjelaskan Syarat dan Ketentuan pembuatan tabungan.
3. Customer Service menyerahkan Form Pendaftaran.
4. Nasabah lalu menyerahkan Berkas dan Form Pendaftaran yang sudah diisi ke Customer
Service.
5. Customer Service memberikan Bukti Pendaftaran dan menyuruh Nasabah Untuk ke
Teller untuk mengambil Buku Tabungan.
6. Nasabah menuju teller dengan membawa Butki Pendaftaran untuk di serahkan ke
 Teller.
7. Teller memberikan Rekening Tabungan(Buku Tabungan) ke Nasabah.

8. Nasabah dapat melakukan tramsaksi apapun seperti ganti pin,

pembayaran,informasi saldo,Tarik tunai dan transfer di teller

2. Terdapat
-Include
-Extend
-Generalization

3
.

D. KESIMPULAN
1. Pemodelan Perangkat Lunak
Pemodelan dalam suatu rekayasa perangkat lunak merupakan suatu hal yang
dilakukan di tahapan awal. Di dalam suatu rekayasa dalam perangkat lunak sebenarnya
masih memungkinkan tanpa melakukan suatu pemodelan. Namun hal itu tidak dapat lagi
dilakukan dalam suatu industri perangkat lunak.
2. UML
UML adalah sebuah bahasa yang berdasarkan grafik/gambar untuk
memvisualisasi, menspesifikasikan, membangun, dan pendokumentasian dari sebuah
sistem pengembangan software berbasis OO (Object-Oriented). UML sendiri juga
memberikan standar penulisan sebuah sistem blue print, yang meliputi konsep bisnis
 proses, penulisan kelas-kelas dalam bahasa program yang spesifik, skema database, dan
komponen-komponen yang diperlukan dalam sistem softwar.
3. Use Case Diagram
Use case diagram adalah teknik untuk merekam persyaratan fungsional sebuah
system, menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Use case
diagram menekankan kepada “apa” yang diperbuat oleh sistem, dan bukan
“bagaimana”.

E. DAFTAR PUSTAKA
Hasanah, Fitri Nur & Untari, Rahmania Sri. 2020. Modul Rekayasa Perangkat Lunak.
Sidoarjo : UMSIDA PRESS.
 LABORATORIUM JARINGAN
PROGRAM STUDI PENDIDIKAN TEKNOLOGI INFORMASI
FAKULTAS PSIKOLOGI DAN ILMU PENDIDIKAN
UNIVERSITAS MUHAMMADIYAH SIDOARJO

2021

LEMBAR ASISTENSI
REKAYASA PERANGKAT LUNAK
PEMODELAN UML (ACTIVITY DIAGRAM)
PRAKTIKUM KE 6

Judul Praktikum : Pemodelan Uml (Activity Diagram)

Nama/NIM : Arnita Fentrin P / 188320700017
Dilaksanakan pada : 08 Desember 2020

Sidoarjo, 09 Desember 2020

Mengetahui,
Dosen Pembimbing

Fitria Nur Hasanah, M.Pd

 PRAKTIKUM KE-6
PEMODELAN UML (ACTIVITY DIAGRAM)

A. PENDAHULUAN
Tujuan :

1. Mahasiswa mampu menerapkan UML

2. Mahasiswa mampu menerapkan Use Case Diagram
3. Mahasiswa mampu menerapkan Activity Diagram

B. DASAR TEORI
1. Pemodelan Perangkat Lunak
Pemodelan dalam suatu rekayasa perangkat lunak merupakan suatu hal yang
dilakukan di tahapan awal. Di dalam suatu rekayasa dalam perangkat lunak sebenarnya
masih memungkinkan tanpa melakukan suatu pemodelan. Namun hal itu tidak dapat lagi
dilakukan dalam suatu industri perangkat lunak. Pemodelan delam perangkat lunak
merupakan suatu yang harus dikerjakan di bagian awal dari rekayasa, dan pemodelan ini
akan mempengaruhi perkerjaan-pekerjaan dalam rekayasa perangkat lunak tersebut.
Pada rekayasa perangkat lunak, banyak model yang telah dikembangkan untuk
membantu proses pengembangan perangkat lunak. Model-model ini pada umumnya
mengacu pada model proses pengembangan sistem yang disebut System Development
Life Cycle (SDLC) seperti yang telah dibahas dibab sebelumnya. Pemodelan perangkat
lunak digunakan untuk mempermudah langkah berikutnya dari pengembangan sebuah
sistem informasi sehingga lebih terencana. Salah satu perangkat pemodelan adalah
Unified Modelling Language (UML).
2. UML
UML adalah sebuah bahasa yang berdasarkan grafik/gambar untuk
memvisualisasi, menspesifikasikan, membangun, dan pendokumentasian dari sebuah
sistem pengembangan software berbasis OO (Object-Oriented). UML sendiri juga
memberikan standar penulisan sebuah sistem blue print, yang meliputi konsep bisnis
proses, penulisan kelas-kelas dalam bahasa program yang spesifik, skema database, dan
komponen-komponen yang diperlukan dalam sistem softwar. Pendekatan analisa &
 rancangan dengan menggunakan model OO mulai diperkenalkan sekitar pertengahan
1970 hingga akhir 1980 dikarenakan pada saat itu aplikasi software sudah meningkat dan
mulai komplek.
UML sebagai sebuah bahasa yang memberikan vocabulary dan tatanan penulisan
kata-kata dalam ‘MS Word’ untuk kegunaan komunikasi. Sebuah bahasa model adalah
sebuah bahasa yang mempunyai vocabulary dan konsep tatanan / aturan penulisan serta
secara fisik mempresentasikan dari sebuah sistem. Seperti halnya UML adalah sebuah
bahasa standard untuk pengembangan sebuah software yang dapat menyampaikan
bagaimana membuat dan membentuk model-model, tetapi tidak menyampaikan apa dan
kapan model yang seharusnya dibuat yang merupakan salah satu proses implementasi
pengembangan software.
a. Building Blocks
3 (tiga) macam yang terdapat dalam building block adalah katagori benda/Things,
hubungan, dan diagram. Benda/things adalah abstraksi yang pertama dalam sebuah
model, hubungan sebagai alat komunikasi dari bendabenda, dan diagram sebagai
kumpulan / group dari benda-benda/things.
3. Use Case Diagram
Use case diagram adalah teknik untuk merekam persyaratan fungsional sebuah
system, menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Use case
diagram menekankan kepada “apa” yang diperbuat oleh sistem, dan bukan “bagaimana”.
Sebuah use case merepresentasikan sebuah interaksi antara aktor dengan sistem.
Use case merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, meng-create
sebuah daftar belanja, dan sebagainya. Seorang atau sebuah aktor adalah sebuah entitas
dapat berupa manusia atau mesin yang berinteraksi dengan system untuk melakukan
pekerjaan-pekerjaan tertentu.
Manfaat Use Diagram
Use case diagram akan sangat membantu kita dalam menyusun kebutuhan-
kebutuhan (requirement analisis) sebuah sistem. Use case diagram akan di gunakan
untuk mengkomunikasikan rancangan sistem dengan klien, dan merancang test case
untuk semua feature yang ada pada sistem.
Relationship dalam Use Case Diagram
 Didalam use case diagram terdapat dua komponen penting yang saling
berinterakasi dan berkomunikasi. Komponen tersebut adalah aktor dan use case. Ragam
relasi yang terjadi diantara komponen-komponen tersebut adalah :
a. Assosiations
Relasi ini diigunakan untuk menghubungkan para actor dan case di dalam suatu
diagram. asosiasi ini dapat digambar dalam dua arah, tergantung dari kedudukan
aktornya. jika aktornya adalah sebagai aktor utama (primery actor) maka arah relasi
adalah dari actor menuju case. Jika aktornya adalah sebagai aktor tambahan
(secondary actor) maka arah relasi dari case menuju actor.
b. Dependency
Relasi ini menyatakan suatu hubungan semantik antara dua unsur-unsur modeling
yang mana perubahan satu elemen atau unsur model (unsur yang mengalir masuk)
dapat mempengaruhi unsur modeling yang lain (unsur yang dependent). Relasi ini
menghubungkan antara use case satu dengan use case yang lain.
c. Generalization/inheritance
Relasi ini menyatakan hubungan hirarkis, turunan atau menyatakan suatu bagian
dalam satu komponen. Sehingga aktor dapat diturunkan menjadi aktor-aktor yang lain
atau use case dapat didekomposisi atau diturunkan menjadi use case yang lain. Relasi
ini menunjukkan bahwa actor yang satu merupakan spesialisasi dari actor yang
lain. Demikian juga use case satu merupakan spesialisasi dari usecase yang lain.
Komponen yang terlibat dalam Use Case Diagram
a. Aktor
Pada dasarnya actor bukanlah bagian dari use case diagram, namun untuk dapat
terciptanya suatu use case diagram diperlukan beberapa actor. Actor tersebut
mempresentasikan seseorang atau sesuatu (seperti perangkat, sistem lain) yang
berinteraksi dengan sistem. Sebuah actor mungkin hanya memberikan informasi
inputan pada sistem, hanya menerima informasi dari sistem atau keduanya menerima,
dan memberi informasi pada sistem.
b. Use Case
Use case adalah gambaran fungsionalitas dari suatu sistem, sehingga customer atau
pengguna sistem paham dan mengerti mengenai kegunaan sistem yang akan
 dibangun.
Catatan : Use case diagram adalah penggambaran sistem dari sudut pandang
pengguna sistem tersebut (user), sehingga pembuatan use case lebih dititikberatkan
pada fungsionalitas yang ada pada sistem, bukan berdasarkan alur atau urutan
kejadian.
c. Relasi dalam Use Case
Ada beberapa relasi yang mungkin terjadi pada use case diagram:
 <<include>> , yaitu kelakuan yang harus terpenuhi agar sebuah event dapat
terjadi, dimana pada kondisi ini sebuah use case adalah bagian dari use case
lainnya.
 <<extends>>, kelakuan yang hanya berjalan di bawah kondisi tertentu seperti
menggerakkan alarm.
 <<communicates>>, mungkin ditambahkan untuk asosiasi yang menunjukkan
asosiasinya adalah communicates association . Ini merupakan pilihan selama
asosiasi hanya tipe relationship yang dibolehkan antara actor dan use case.
d. Use Case Diagram
Use Case Diagrm adalah gambaran graphical dari beberapa atau semua actor, use
case, dan interaksi diantaranya yang memperkenalkan suatu sistem.
e. Batasan Sistem (System Boundary)
Dalam batasan sistem hal-hal yang penting yaitu:
1) System boundary.
2) Mendefinisikan batas antara actor dan sistem.
3) Dinotasikan bujur sangkar/persegi.
4) Semua use case tercakup di dalamnya.
 C. KEGIATAN PRAKTIKUM
1. Pendaftaran Anggota
a. Skenario Pendaftaran Anggota
Name Pendaftaran
Aktor Pegawai, Pengunjung, Anggota
Purpose Melakukan pendaftaran anggota perpustakaan
Typical Course of Events
Actor Action System Response
1. Pengunjung pengunjung mendaftar 4. sistem menampilkan form pendaftaran
dengan mengisi blanko biodata anggota perpustakaan
2. Pegawai membuka menu pendaftaran 5. Sistem menerima input data anggota
anggota perpustakaan
3. Pegawai meregristrasi

b. Diagram Aktivitas : Pendaftaran Anggota

2. Peminjaman buku
a. Skenario Proses Peminjaman
Name Pendaftaran
Aktor Pegawai, Anggota
Purpose Melakukan peminjaman buku
Typical Course of Events
Actor Action System Response
1. Anggota mencari data buku 4. sistem menampilkan form peminjaman
2. Menunjukkan kartu anggkota 5. Sistem menerima input data peminjaman
3. Pegawai meinput data anggota
dan buku dalam menu
peminjaman

b. Diagram Aktivitas : Peminjaman buku

3. Pengembalian buku
a. Skenario Proses Pengembalian
Name Pendaftaran
Aktor Pegawai, Anggota
Purpose Melakukan pengembalian buku
Typical Course of Events
Actor Action System Response
1. Anggota membawa buku yang telah 6. sistem menampilkan form pengembalian
dipinjam kepada pegawai 7. Sistem menerima input data pengembalian
2. Anggota menyerahkan kartu anggota 8. Sistem memvalidasi data meliputi data
3. Pegawai memeriksa data-data anggota buku, masa waktu pengembalian.
yang meminjam
4. Pegawai mengecek buku yang
dipinjam
5. Pegawai mengupdate data anggota
Alternative Course
9. jika melewati masa pengembalian maka anggota wajib membayar denda

b. Diagram Aktivitas : Pengembalian buku

D. TUGAS PRAKTIKUM
1. Proses Pemesanan Pelanggan
Saat pelanggan ingin memesan Produk Kerajinan Kulit harus melalui owner agar
diproses oleh owner, kemudian owner menginputkan data pemesanan yang di pesan oleh
pelanggan, setelah itu owner memproses transaksi dan pelanggan membayar sesuai total
yang harus dibayar, jika pelanggan sudah melakukan proses transaksi, maka owner
mencetak bukti transaksi dan diserahkan ke pelanggan.
2. Skenario Proses Pemesanan
Name Pendaftaran
Aktor Owner
Purpose Melakukan Pemesanan Produk Kerajinan
Kulit
Typical Course of Events
Actor Action System Response
1. Owner harus menginput jenis Produk 3. Sistem menampilkan input data pesanan.
Kerajinan Kulit yang dipesan oleh 4. Sistem menampilkan hasil transaksi
pelanggan dengan memasukkan kode
jenis Produk, nama Produk, dan nama
Produk.
2. Owner memproses transaksi
pembayaran pelanggan dengan
menginputkan data sesuai pesanan.

3. Diagram Aktivitas : Pemesanan Produk Kerajinan Kulit

E. KESIMPULAN
1. Pemodelan Perangkat Lunak
Pemodelan dalam suatu rekayasa perangkat lunak merupakan suatu hal yang
dilakukan di tahapan awal. Di dalam suatu rekayasa dalam perangkat lunak sebenarnya
masih memungkinkan tanpa melakukan suatu pemodelan. Namun hal itu tidak dapat lagi
dilakukan dalam suatu industri perangkat lunak.
2. UML
UML adalah sebuah bahasa yang berdasarkan grafik/gambar untuk
memvisualisasi, menspesifikasikan, membangun, dan pendokumentasian dari sebuah
sistem pengembangan software berbasis OO (Object-Oriented). UML sendiri juga
memberikan standar penulisan sebuah sistem blue print, yang meliputi konsep bisnis
proses, penulisan kelas-kelas dalam bahasa program yang spesifik, skema database, dan
komponen-komponen yang diperlukan dalam sistem softwar.
3. Use Case Diagram
 Use case diagram adalah teknik untuk merekam persyaratan fungsional
sebuah system, menggambarkan fungsionalitas yang diharapkan dari sebuah
sistem. Use case diagram menekankan kepada “apa” yang diperbuat oleh sistem,
dan bukan “bagaimana”.

F. DAFTAR PUSTAKA
Hasanah, Fitri Nur & Untari, Rahmania Sri. 2020. Modul Rekayasa Perangkat Lunak.
Sidoarjo : UMSIDA PRESS.