LAPORAN PRAKTIKUM

REKAYASA PERANGKAT LUNAK

Oleh :

Dini Nurul Hidayah 188320700016

Kelas

A1

PROGRAM STUDI PENDIDIKAN TEKNOLOGI INFORMASI

FAKULTAS PSIKOLOGI DAN ILMU PENDIDIKAN

UNIVERSITAS MUHAMMADIYAH SIDOARJO

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

LEMBAR PENGESAHAN

Telah Diperiksa Isi Laporan Ini

LAPORAN PRAKTIKUM
REKAYASA PERANGKAT LUNAK

Disusun oleh:

Dini Nurul Hidayah 188320700016

A1

Sidoarjo, Januari 2021

Mengetahui,
Kepala Laboran FPIP Kaprodi

Hengki Setiawan, A. Md 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 praktiku. 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, Januari 2021

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

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

Judul Praktikum : Entity Relationship Diagram (ERD)

Nama/NIM : Dini Nurul Hidayah / 188320700016
Dilaksanakan pada : 27 Oktober 2020

Dosen Pembimbing

Fitria Nur Hasanah, M.Pd

 PRAKTIKUM KE-3
BASIS DATA

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

Outlet Kopi.ntar ini dijalankan oleh ownernya sendiri. Menu yang tersedia di outlet Kopi.ntar
ada berbagai jenis minuman. Pelanggan bisa melakukan proses pemesanan sekaligus
transaksi ke owner dengan memilih menu yang diinginkan, meyebutkan nama untuk
dipanggil saat pesanan sudah selesai dan melakukan proses pembayaran dengan membayar
sesuai total harga yang dipesan.

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

Outlet Kopi.ntar ini dijalankan oleh ownernya sendiri. Menu yang tersedia di outlet
Kopi.ntar ada berbagai jenis minuman. Pelanggan bisa melakukan proses pemesanan
sekaligus transaksi ke owner dengan memilih menu yang diinginkan, meyebutkan nama
untuk dipanggil saat pesanan sudah selesai dan melakukan proses pembayaran dengan
membayar sesuai total harga yang dipesan.
Langkah 3. Untuk setiap objek tersebut yakinkan bahwa ia memiliki karakteristik yang
nanti disebut sebagai atribut

Owner : ID_Owner, Nama, Nomor_Telp, Alamat

Jenis_Minuman : Kode_Jenis, Nama_Jenis, Nama_Minuman
Pelanggan : Nama_Unik
Transaksi : No_Struk, ID_Owner, Kode_Jenis, No_Pemesanan, Nama_Unik, Total_Bayar,
Tgl_Pemesanan

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

Pelanggan Memilih Jenis_Miuman
Owner Mengolah Transaksi
Pelanggan Melakukan Transaksi
Langkah 4. Buka aplikasi power designer. Buatlah model baru dan beri nama misalnya:
ERD_Kopi.ntar

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 LDM dengan pilih menu Tools > Generate Logical Data
Model. Selanjutnya cek model dengan pilih menu Tools > Check Model atau (F4).
5. Generate juga ke dalam PDM dengan pilih menu Tools > Generate Physical Data
Model. Selanjutnya cek model dengan pilih menu Tools > Check Model atau (F4).

6. 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.
 7. Lalu pada tools Options teptnya pada “Create Primary Key” pilih outside dan uncheck
Drop primary key.

8. Import database ke phpMyAdmin

A. 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.

B. 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
2020

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

Judul Praktikum : DFD (Data Flow Diagram)

Nama/NIM : Dini Nurul Hidayah / 188320700016
Dilaksanakan pada : 03 November 2020

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 Konteks
 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
2020

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

Judul Praktikum : Pemodelan UML (Use Case)

Nama/NIM : Dini Nurul Hidayah / 188320700016
Dilaksanakan pada : 30 November 2020

Dosen Pembimbing

Fitria Nur Hasanah, M.Pd

 PRAKTIKUM KE-5
PEMODELAN UML (Use Case)

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. Definisi aktor dan Use Case pada Sistem Kopi.ntar
 Owner dapat memasukkan semua data jenis minuman yang tersedia.
 Owner dapat memasukkan data jenis minuman yang dipesan pelanggan.
 Owner dapat memasukkan data transaksi sesuai pesanan pelanggan.
 Owner dapat menampilkan semua data transaksi yang telah dimasukkan.
 2. Relasi
Dalam Use Case Sistem Kopi.ntar menggunakan relasi Include dan Extend
3. Diagram Use Case

Deskripsi Actor pada system penjualan :

a. Owner/Admin: orang yang memegang penuh kendali system.
Melakukan updating pada setiap data barang maupun data yang lain, mengelola
data penjualan minuman pada pelanggan, melayani penjualan hingga membuat
laporan pada setiap transaksi.

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
2020

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

Judul Praktikum : Pemodelan UML (Activity Diagram)

Nama/NIM : Dini Nurul Hidayah / 188320700016
Dilaksanakan pada : 08 Desember 2020

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 :
d. 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.
e. 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.
f. 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
f. 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.
g. 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.
h. 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.
i. Use Case Diagram
Use Case Diagrm adalah gambaran graphical dari beberapa atau semua actor, use
case, dan interaksi diantaranya yang memperkenalkan suatu sistem.
j. Batasan Sistem (System Boundary)
Dalam batasan sistem hal-hal yang penting yaitu:
5) System boundary.
6) Mendefinisikan batas antara actor dan sistem.
7) Dinotasikan bujur sangkar/persegi.
8) 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 5. Sistem menerima input data anggota
pendaftaran 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
2. Menunjukkan kartu anggkota peminjaman
3. Pegawai meinput data anggota dan 5. Sistem menerima input data
buku dalam menu peminjaman peminjaman

b. Diagram Aktivitas : Peminjaman buku

3. Pengembalian buku
1. 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 6. sistem menampilkan form
telah dipinjam kepada pegawai pengembalian
2. Anggota menyerahkan kartu 7. Sistem menerima input data
anggota pengembalian
3. Pegawai memeriksa data-data 8. Sistem memvalidasi data meliputi data
anggota yang meminjam buku, masa waktu pengembalian.
4. Pegawai mengecek buku yang
dipinjam
5. Pegawai mengupdate data anggota
Alternative Course
9. jika melewati masa pengembalian maka anggota wajib membayar denda

2. Diagram Aktivitas : Pengembalian buku

D. TUGAS PRAKTIKUM
1. Proses Pemesanan Pelanggan
Saat pelanggan ingin memesan minuman 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 Minuman
Typical Course of Events
Actor Action System Response
1. Owner harus menginput jenis 3. Sistem menampilkan input data
minuman yang dipesan oleh pelanggan pesanan.
dengan memasukkan kode jenis 4. Sistem menampilkan hasil transaksi
minuman, nama jenis minuman, dan
nama minuman.
2. Owner memproses transaksi
pembayaran pelanggan dengan
menginputkan data sesuai pesanan.

3. Diagram Aktivitas : Pemesanan Minuman

E. KESIMPULAN
4. 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.
5. 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.
6. 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.