Dokumen tersebut merupakan laporan tentang pengembangan dan penerapan Service Oriented Architecture pada sistem SIMTA NG 2.0. Laporan tersebut menjelaskan proses desain SOA mulai dari identifikasi use case, dekomposisi proses bisnis, penentuan kandidat layanan dan sumber daya, hingga merancang arsitektur layanan akhir. Proses desain dilakukan secara sistematis melalui beberapa langkah seperti filtering tindakan, menentukan kandid

1. Pengembangan dan Penerapan Sistem SIMTA NG 2.0
Service Oriented Architecture Design
Disusun oleh :
Arief Sandi Destianto 6026221003
Dosen Pengampu :
Dr. Ir. Aris Tjahyanto, M.Kom
NIP 196503101991021001
DEPARTEMEN SISTEM INFORMASI
FAKULTAS TEKNOLOGI ELEKTRO DAN INFORMATIKA CERDAS
INSTITUT TEKNOLOGI SEPULUH NOPEMBER
SURABAYA
2022

2. DAFTAR ISI
DAFTAR ISI.................................................................................................................2
1. Ambil salah satu use case bagian anda yang paling kompleks. ................................4
2. Tunjukkan narrative use case description .................................................................4
3. Ubah menjadi flowchart atau diagram bisnis proses untuk use case tsb...................7
4. Lakukan dekomposisi Proses Bisnis (menjadi Granular Actions)............................8
STEP 1: Decompose Business Process (into Granular Actions) ..............................8
5. Tandai kegiatan atau action yang akan difilter, misalnya adalah proses manual
yang perlu dilakukan oleh manusia dan (2) logika otomasi bisnis dilakukan oleh
legacy systems yang tidak dapat diubah diskret menjadi layanan ................................8
STEP 2: Filter Out Unsuitable Actions.....................................................................8
6. Lanjutkan prosesnya, gunakan step atau tahap yang telah dijelaskan di kuliah. Ikuti
setiap tahap dan tunjukkan hasilnya..............................................................................9
STEP 3: Define Entity Service Candidates...............................................................9
STEP 4: Identify Process-Specific Logic................................................................11
STEP 5: Identify Resources ....................................................................................12
STEP 6: Associate Service Capabilities with Resources and Methods ..................12
STEP 7: Apply Service-Orientation........................................................................14
STEP 8: Identify Service Composition Candidates ................................................14
STEP 9: ANALYZE PROCESSING REQUIREMENTS ......................................14
STEP 10: Define Utility Service Candidates (and Associate Resources and
Methods) .................................................................................................................15
STEP 11: Define Microservice Candidates (and Associate Resources and Methods)
.................................................................................................................................16
STEP 12: Apply Service-Orientation......................................................................16
7. Tunjukkan arsitektur final.......................................................................................17
STEP 13: Revise Candidate Service Compositions................................................17
STEP 14: Revise Resource Definitions and Capability Candidate Grouping ........17

4. Tugas-6-[Individu]-Desain Service Oriented Architecture
Service-oriented architecture (SOA) adalah gaya arsitektur yang berfokus
pada layanan diskrit dari pada desain monolitik. SOA diterapkan di bidang desain
perangkat lunak di mana layanan disediakan untuk komponen lain oleh komponen
aplikasi, melalui protokol komunikasi pada jaringan komputer. Servis atau layanan
adalah unit diskret untuk fungsional tertentu yang dapat diakses dari jarak jauh dan
di-update secara independent.
1. Ambil salah satu use case bagian anda yang paling kompleks.
Usecase: Verifikasi Bebas Laboratorium
2. Tunjukkan narrative use case description
USE CASE NAME Melakukan Persetujuan
Berkas Bebas Lab
USE CASE TYPE
 Business Requirements
 System analysis
 System Design
USE CASE ID UCS012
PRIORITY High
SOURCE
PRIMARY BUSINESS
ACTOR
Admin Laboran
PRIMARY SYSTEM
ACTOR
Admin Laboran
OTHER INTERESTED
STAKEHOLDER
DESCRIPTION Usecase ini digunakan oleh Admin Laboran dalam
menyetujui persetujuan berkas bebas laboratorium.

5. PRE-CONDITION 1. Aktor telah memasuki SIMTA.
2. Mahasiswa telah mengunggah dokumen form
persetujuan bebas laboratorium.
3. Aktor melakukan Persetujuan Bebas Lab.
TRIGGER Admin laboran menyetujui berkas bebas laboratorium
berdasarkan berkas yang telah diunggah mahasiswa.
TYPICAL COURSE OF
EVENTS :
1. Actor melakukan
login pada system
SIM TA NG 2.0
2. Sistem akan
menampilkan halaman
dashboard Admin laboran
3. Actor membuka
menu persetujuan
berkas bebas
laboratorium.
4. System menampilkan
halaman persetujuan
berkas bebas
laboratorium.
5. System menampilkan
nama mahasiswa yang
berisikan notifikasi sudah
mengunggah berkas
bebas laboratorium.
6. Admin Laboran
memilih nama
mahasiswa dan
menyetujui berkas
bebas
laboratorium.
7. System memproses
persetujuan dan berkas
bebas laboratorium
berhasil disetujui.
8. System akan
menampilkan pada
dashboard mahasiswa
bahwa berkas bebas
laboratorium telah
disetujui.

6. ALTERNATE COURSE A1. Apabila admin laboran tidak menyetujui berkas
bebas laboratorium :
1. System menampilkan alert berkas bebas
laboratorium tidak disetujui.
CONCLUSION Admin laboran telah melakukan persetujuan berkas
bebas laboratorium.
POST-CONDITION 1. Admin laboran telah melakukan persetujuan
berkas bebas laboratorium.
BUSINESS RULES Admin laboran telah menyetujui berkas bebas
laboratorium, berkas yang sudah disetujui akan tampil di
dashboard mahasiswa.
IMPLEMENTATION
CONSTRAINTS AND
SPECIFICATION
Berkas yang telah disetujui akan disimpan dan tampil di
dashboard Mahasiswa.
ASSUMPTIONS Actor memiliki koneksi jaringan internet yang baik
OPEN ISSUES -

7. 3. Ubah menjadi flowchart atau diagram bisnis proses untuk use case tsb

8. 4. Lakukan dekomposisi Proses Bisnis (menjadi Granular Actions)
STEP 1: Decompose Business Process (into Granular Actions)
 Inisiasi verifikasi berkas laboratorium
 nput NRP dan Password
 Sistem verifikasi NRP & Password benar.
 Sistem menampilkan halaman dashboard SIMTA.
 Jika nrp & password salah, sistem akan kembali kehalaman login.
 User memilih fitur menu Verifikasi Berkas Laboratorium
 Get halaman verifikasi berkas laboratorium
 Jika sistem tidak menampilkan halaman penilaian, sistem akan kembali
halaman dashboard SIMTA.
 User memilih nama mahasiswa.
 Get halaman form berkas laboratorium mahasiswa.
 User melakukan validasi berkas yang di input oleh mahasiswa
 User melakukan verifikasi pada berkas mahasiswa
 Sistem menyimpan status yang terubah
 Jika data tidak dapat tersimpan karena adanya error, sistem akan
memberkikan feedback berupa alert
 Send alert notification if there’s an error
 Send success notification if data has been saved
5. Tandai kegiatan atau action yang akan difilter, misalnya adalah proses
manual yang perlu dilakukan oleh manusia dan (2) logika otomasi bisnis
dilakukan oleh legacy systems yang tidak dapat diubah diskret menjadi layanan
STEP 2: Filter Out Unsuitable Actions
 Inisiasi verifikasi berkas laboratorium
 nput NRP dan Password
 Sistem verifikasi NRP & Password benar.
 Sistem menampilkan halaman dashboard SIMTA.
 Jika nrp & password salah, sistem akan kembali kehalaman login.
 User memilih fitur menu Verifikasi Berkas Laboratorium
 Get halaman verifikasi berkas laboratorium
 Jika sistem tidak menampilkan halaman penilaian, sistem akan kembali
halaman dashboard SIMTA.
 User memilih nama mahasiswa.
 Get halaman form berkas laboratorium mahasiswa.

9.  Record form berkas laboratorium mahasiswa
 User melakukan validasi berkas yang di input oleh mahasiswa
 User melakukan verifikasi pada berkas mahasiswa
 Sistem menyimpan status yang terubah
 Jika data tidak dapat tersimpan karena adanya error, sistem akan
memberkikan feedback berupa alert
 Send alert notification if there’s an error
 Send success notification if data has been saved
6. Lanjutkan prosesnya, gunakan step atau tahap yang telah dijelaskan di
kuliah. Ikuti setiap tahap dan tunjukkan hasilnya.
STEP 3: Define Entity Service Candidates
a. Menentukan agnostic dan non-agnostic (Diberi bold unuk non-agnostic)
 Inisiasi verifikasi berkas laboratorium
 Sistem verifikasi NRP & Password benar.
 Sistem menampilkan halaman dashboard SIMTA.
 Jika nrp & password salah, sistem akan kembali kehalaman
login.
 Get halaman verifikasi berkas laboratorium
 Jika sistem tidak menampilkan halaman penilaian, sistem
akan kembali halaman dashboard SIMTA.
 Get halaman form berkas laboratorium mahasiswa.
 Record form berkas laboratorium mahasiswa
 Sistem menyimpan status yang terubah
 Jika data tidak dapat tersimpan karena adanya error, sistem
akan memberkikan feedback berupa alert
 Send alert notification if there’s an error
 Send success notification if data has been saved

10. b. Service Candidate
1. Berkas
 Get halaman verifikasi berkas laboratorium√
 Get halaman form berkas laboratorium mahasiswa.
 Record form berkas laboratorium mahasiswa Input data
 Sistem menyimpan status yang terubah Update data
 Send alert notification if there’s an error
 Send success notification if data has been saved
2. Admin Laboran
 Get halaman verifikasi berkas laboratorium√
 Get halaman form berkas laboratorium mahasiswa. √
 Record form berkas laboratorium mahasiswa Input data √
 Sistem menyimpan status yang terubah Update data √
 Send alert notification if there’s an error
 Send success notification if data has been saved

11. STEP 4: Identify Process-Specific Logic
 Inisiasi verifikasi berkas laboratorium
 Sistem verifikasi NRP & Password benar.
 Sistem menampilkan halaman dashboard SIMTA.
 Jika nrp & password salah, sistem akan kembali kehalaman
login.
 Jika sistem tidak menampilkan halaman penilaian, sistem
akan kembali halaman dashboard SIMTA.=
 Sistem menyimpan status yang terubah
 Jika data tidak dapat tersimpan karena adanya error, sistem
akan memberkikan feedback berupa alert
 Send alert notification if there’s an error
 Send success notification if data has been saved

12. STEP 5: Identify Resources
 /Process/ => /Proses verifikasi berkas laboratorium/
 /Application/ => /SIMTA/
 /Berkas/ => /Network/File/
 /Form Bebas Laboratorium/
 /Data Tanggungan Laboratorium Mahasiswa/
 /Notice System/
STEP 6: Associate Service Capabilities with Resources and Methods
 Start : Kebutuhan kandidat kapabilitas layanan adalah metode POST
untuk meneruskan dokumen aplikasi ke sumber daya yang dinamai
menurut proses bisnis itu sendiri.

13.  Get Details: kandidat kemampuan layanan ditambahkan dengan metode
GET dan sumber daya /Berkas/.
 Get Details: kemampuan layanan terkait dengan kombinasi metode GET
plus /Berkas/ sumber daya. Kandidat kemampuan layanan Confer dan
Update History masing-masing memerlukan data input yang akan
memperbarui data sumber daya, dan karena itu diperluas dengan metode
POST pendahuluan dan sumber daya /Admin Laboran/

14. STEP 7: Apply Service-Orientation
Dokumentasi proses bisnis yang aplikasi kami gunakan sebagai
masukan untuk proses pemodelan layanan yang dapat memberi kami tingkat
pengetahuan tentang pemrosesan dasar yang diperlukan oleh masing-masing
kandidat kemampuan layanan REST yang diidentifikasi.
STEP 8: Identify Service Composition Candidates
STEP 9: ANALYZE PROCESSING REQUIREMENTS
1. Notifikasi merupakan tindakan pelaporan yang dilakukan pada resource
yang berpusat pada bisnis utilitas
2. Verify Application merupakan logika pemrosesan yang perlu dijalankan
untuk memproses tindakan verifikasi jadwal sidang dan resource
/Application/SIMTA yang dicakup pada kandidat kemampuan layanan

15. STEP 10: Define Utility Service Candidates (and Associate Resources and
Methods)
Menggali catatan dari langkah-langkah proses sebelumnya mengenai
tindakan utilitas-sentris yang telah didokumentasikan sejauh ini.
Dikombinasikan dengan penelitian yang mereka kumpulkan dari langkah
Analisis Persyaratan Pemrosesan, mereka melanjutkan untuk menentukan dua
layanan utilitas berikut

16. STEP 11: Define Microservice Candidates (and Associate Resources and
Methods)
1. Logika pemrosesan non-agnostik (tujuan tunggal) yang diidentifikasi
sebelumnya untuk menentukan apakah ada unit logika ini yang memenuhi
syarat untuk enkapsulasi oleh layanan mikro terpisah.
2. Model layanan mikro dapat memperkenalkan arsitektur implementasi
layanan yang sangat independen dan otonom yang dapat cocok untuk unit
logika dengan tuntutan pemrosesan tertentu
STEP 12: Apply Service-Orientation
Langkah ini adalah pengulangan Langkah 7 yang disediakan di sini
khusus untuk setiap kandidat layanan utilitas baru yang mungkin muncul dari
penyelesaian Langkah 9 dan 10.

17. 7. Tunjukkan arsitektur final
STEP 13: Revise Candidate Service Compositions
STEP 14: Revise Resource Definitions and Capability Candidate
Grouping
Setiap logika pemrosesan baru yang diidentifikasi dalam langkah-
langkah sebelumnya dapat menghasilkan peluang untuk menambah atau
merevisi kumpulan sumber daya yang dimodelkan sejauh ini.