MAKALAH

KONSEP ARSITEKTUR PERANGKAT LUNAK

DISUSUN
OLEH KELOMPOK :
* Muhammad Khatami (200155201025)
* Zikri Maulana (200155202001)
* Zhia Ul Haque (200155201190)
* Rezi Juanda (200155201158)
* Saifuddin (200155201167)

DOSEN PEMBIMBING : Nun Sina ST.,M.KOM

FAKULTAS KOMPUTER DAN MULTIMEDIA (FKOM)

TEKNIK INFORMATIKA
UNIVERSITAS ISLAM KEBANGSAAN INDONESIA
UNIKI 2021
 KATA PENGANTAR

Assalamu’alaikum warahmatullahi wabarakatuh.

Segala puji syukur kami panjatkan kepada Tuhan Yang Maha Esa. Atas rahmat dan karunia-
Nya, kami dapat menyelesaikan tugas penulisan makalah mata kuliah Rekayasa Perangkat Lunak
tepat waktu. Tidak lupa shalawat serta salam tercurah kepada Rasulullah SAW yang syafa’atnya kita
nantikan kelak.
Penulisan makalah berjudul “Konsep Arsitektur Perangkat Lunak” dapat diselesaikan karena
bantuan banyak pihak. Selain itu, kami juga berharap agar pembaca mendapatkan sudut pandang baru
setelah membaca makalah ini.
Penulis menyadari makalah masih memerlukan penyempurnaan, terutama pada bagian isi.
Kami menerima segala bentuk kritik dan saran pembaca demi penyempurnaan makalah. Apabila
terdapat banyak kesalahan pada makalah ini, kami memohon maaf.
Demikian yang dapat kami sampaikan. Akhir kata, semoga makalah Rekayasa Perangkat
Lunak ini dapat bermanfaat.

Assalamu’alaikum warahmatullahi wabarakatuh

ACEH, 29 NOV 2021

Penulis
 DAFTAR ISI

KATA PENGANTAR.............................................................................................................................2
DAFTAR ISI............................................................................................................................................3
BAB I.......................................................................................................................................................4
PENDAHULUAN...................................................................................................................................4
1.1 LATAR BELAKANG...................................................................................................................4
1.2 RUMUSAN MASALAH...............................................................................................................4
BAB II......................................................................................................................................................5
PEMBAHASAN......................................................................................................................................5
2.1 PENGERTIAN..............................................................................................................................5
2.2 LAYERING...................................................................................................................................6
2.3 A QUALITY FOCUS (FOKUS KUALITAS)..............................................................................6
2.4 PROCESS.....................................................................................................................................6
2.5 METHODS....................................................................................................................................6
2.6 TOOLS...........................................................................................................................................7
2.7 RAGAM ARSITEKTUR PERANGKAT LUNAK......................................................................7
A. Data Centered Architectures.......................................................................................................7
B. Data Flow Architectures.............................................................................................................8
C. Call and Return Architectures.....................................................................................................9
D. Layered architectures................................................................................................................12
E. Event-based, Implicit Invocation..............................................................................................13
F. Repositories...............................................................................................................................14
G. Table Driven Interpreters..........................................................................................................16
H. Heterogeneous Architectures...................................................................................................17
BAB III..................................................................................................................................................18
PROSES PEMBANGUNAN SISTEM.................................................................................................18
3.1 PENGERTIAN HTML................................................................................................................18
3.2 MENENTUKAN TEMA WEB...................................................................................................18
3.3 MEMPERSIAPKAN TOLLS YANG AKAN DIGUNAKAN...................................................18
3.4 CONTOH NGODING WEB PORTOFOLIO.............................................................................20
1. Kode Lab: index.html................................................................................................................20
2. Kode Lab: style.css....................................................................................................................21
3. Outputnya...................................................................................................................................24
BAB IV..................................................................................................................................................25
PENUTUP.............................................................................................................................................25
 4.1 KESIMPULAN............................................................................................................................25
4.2 SARAN........................................................................................................................................25
DAFTAR PUSTAKA............................................................................................................................25
 BAB I

PENDAHULUAN
1.1 LATAR BELAKANG

Pengembangan suatu perangkat pada era sekarang sudah begitu marak dilakukan oleh
sebagian besar developer program. Perangkat lunak yang dihasilkan juga berbagai macam jenis serta
fungsinya dan manfaat yang dirasakan oleh para user atau brainware dari setiap program. Program
yang dibuat pada saat ini banyak sekali memberikan kemudahan pada setiap user baru yang
menggunakan program tersebut. Selain itu setiap tahun selalu muncul sebuah teknologi baru atau
transformasi baru dari program yang ditawarkan kepada usernya. Kemudahan akses serta
pengoperasian selalu diincar oleh para user. Selain itu kecocokan program dengan bidang user juga
sangat diperhitungkan.

Namun dengan kemajuan teknologi yang begitu cepat melesat, membuat user tidak
kebigungan dalam menentukan program atau aplikasi yang dirasanya tepat. Dari uraian diatas relevan
dengan kondisi yang saat ini sedang terjadi pada lingkungan bisnis. Uraian diatas menunjukkan
dimana user selalu mengincar sebuah teknologi program yang dapat digunakan dengan mudah. Selain
itu munculnya teori tentang Desain Perangkat Lunak membuat developer menjadi mudah
mengidentifikasi kebutuhan dari user. Selain itu dari penerapan Desain Perangkat Lunak ini membuat
program yang dihasilkan dapat tepat sasaran pada setiap bidang kebutuhan dari user. Karena adanya
Desain Perangkat Lunak ini membuat user diberikan kemudahan dalam menentukan program yang
digunakan.

1.2 RUMUSAN MASALAH

Rumusan masalah yang akan kita bahas kali ini adalah :
1. Apa itu Arsitektur Perangkat Lunak ?
2. Apa itu Layering?
3. Apa saja Ragam Arsitektur Perangkat Lunak?
4. Bagaimana cara membangun sebuah system menggunakan HTML?
5. Bagaimana Hasil akhirnya?
 BAB II

PEMBAHASAN
2.1 PENGERTIAN
Arsitektur perangkat lunak adalah sekumpulan pernyataan yang menggambarkan komponen
perangkat lunak dan fungsi-fungsi yang ada pada komponen tersebut. Ia menggambarkan struktur
teknis, batasan-batasan, ciri-ciri, serta antarmuka pada komponen-komponen tersebut. Arsitektur
merupakan rancangan fisik sistem dan oleh karena itu membutuhkan rencana yang matang pada saat
pembuatannya (Krafzig et al, 2004).
Arsitektur perangkat lunak merupakan struktur sebuah sistem, yang meliputi elemen
perangkat lunak, sifat (property) yang tampak dari elemen itu, serta relasi di antara elemen-elemen
tersebut (Bass et al dalam Krafzig et al, 2004). Sifat yang tampak misalnya fungsi apa saja yang
disediakan oleh elemen, bagaimana kinerjanya, bagaimana penanganan kesalahannya, sumber daya
apa saja yang digunakan.
Menurut Erl (2009), ada tiga elemen yang saling berkaitan erat ketika berbicara tentang
arsitektur perangkat lunak. Pertama adalah arsitektur teknologi, yaitu desain fisik dari suatu perangkat
lunak. Kedua adalah infrastruktur teknologi, yaitu lingkungan pendukung yang termasuk di dalamnya
perangkat keras dan perangkat lunak. Ketiga adalah perangkat lunak itu sendiri. Berikut adalah
diagram sederhana yang memperlihatkan keterkaitan ketiga elemen tersebut.

Gambar 1.
Hubungan arsitektur, infrastruktur, dan perangkat lunak

Istilah “arsitektur” berasal dari istilah yang digunakan pada bidang konstruksi bangunan.
Sebuah bangunan memiliki desain fisik yang digambarkan dalam cetak biru arsitektur (architecture
blueprint) atau disebut juga spesifikasi arsitektur. Suatu bangunan berada dalam lingkungan tertentu.
Lingkungan ini bisa memberikan dukungan ataupun tidak terhadap bangunan tersebut.
Sebagai contoh, bangunan perumahan yang dididukung oleh sarana transportasi, pembangkit
tenaga listrik, dan sistem pembuangan limbah. Lingkungan pendukung inilah yang disebut
infrastruktur. Agar bangunan dapat memanfaatkan infrastruktur tersebut, desain fisiknya harus
mengintegrasikan berbagai infrasturktur tadi ke dalam arsitekturnya. Oleh karena itu, spesifikasi
arsitektur sebuah bangunan haruslah memperhatikan infrastruktur di sekitarnya. Begitu juga dengan
perangkat lunak, rancangan arsitekturnya harus memperhatikan infrastruktur di mana perangkat lunak
ini akan ditempatkan.
2.2 LAYERING

Software layer merupakan salah konsep utama yang harus diketahui, dikenali, dimengerti dan
diimplementasikan pada saat akan membangun sebuah perangkat lunak (software). Software Layer
terbagi menjadi empat lapisan, yaitu :
1. A Quality Focus
2. Process
3. Methods
4. Tools

Gambar 2.
Lapisan Perangkat Lunak Secara Umum

2.3 A QUALITY FOCUS (FOKUS KUALITAS)

Pada saat kita membangun sebuah aplikasi, Fokus pertama kali yang dibuat adalah Kita akan
membangun kualitas yang seperti apa,siapa sasaran kita, aplikasi yang dibangun siapa pengguna dan
lai-lain, Oleh karena itu FOKUS KUALITAS ini programmer akan mengetahui level sebuah aplikasi
yang dibangun. Misalnya akan dibangun APLIKASI PEMUTAR MUSIC.
Dengan berpatokan pada FOKUS KUALITAS maka Programmer
akan mengetahui sampai dimana aplikasi yang akan dibangun. File Music bisa beraneka ragam mulai
dari MP3, MP2, AUDIO TRACK, WAV, MDI dan lain-lain. Dengan mengetahui, Aplikasi ini dibuat
untuk File music apa,maka programmer akan mengetahui segala hal yang berhubungan dengan
program yang dibuat.
Apakah aplikasi yang dibuat akan mendukung untuk MP3, MP2, WAV, OGG, TRACK atau
yang lainnya. Jika dilihat dari segi Interaksi Manusia dan Komputer, maka dengan FOKUS
KUALITAS programmer akan mengetahui bentuk dari aplikasi yang akan bangun.

2.4 PROCESS

Process atau Proses adalah merupakan lapisan kedua dalam SOFTWARE LAYER, Lapisan ini
terletak setelah QUALITY FOCUS, hal ini disebabkan setelah diketahui Fokus Kualitas dari
Perangkat Lunak yang akan dibangun, maka pemrogram harus mengetahui bagaimana proses yang
harus dijalani oleh pemrograman sehubungan dengan Fokus Kualitas dari Perangkat Lunak yang
diharapkan, Proses-proses ini dilakukan terurut dan tepat, agar tidak terjadi kesalahan pada saat
sebuah aplikasi di Launching. Proses-proses yang ada akan dikerjakan sesuai dengan Kunci Proses
Area yang ada (KPA/Key Process Area).

2.5 METHODS

Methods atau Metode merupakan salah satu hal yang penting dalam Pembuatan Perangkat Lunak.
Dengan metode, pembuat program akan melakukan langkah-langkah dan tindakan-tindakan yang
sesuai dengan metode yang ada. Metode yang digunakan harus disesuaikan dengan perangkat lunak
yang dibangun, dan tujuan dari pembuatan perangkat lunak.
2.6 TOOLS

Tools merupakan alat bantu yang dapat digunakan oleh programmer dalam menyelesaikan
proyek yang ada. Mulai dari tools animasi tools multimedia, tools normalisasi dan lain-lain.
Misalnya : X3D, power designer, paintshop pro, etc.

2.7 RAGAM ARSITEKTUR PERANGKAT LUNAK

Ragam Arsitektur perangkat lunak terdiri dari : Data Centered Architectures, Data Flow
Architectures, Call and Return Architectures, Layered architectures, Event-based, Implicit
Invocation, Repositories, Table Driven Interpreters, Heterogeneous Architectures.

A. Data Centered Architectures

Arsitektur ini memiliki tujuan untuk mencapai kualitas integrability data. Istilah ini mengacu
ke sistem di mana akses dan update dari menyimpan data diakses secara luas adalah tujuan utama
mereka. Pada dasarnya, itu tidak lebih dari menyimpan data terpusat yang berkomunikasi dengan
sejumlah klien Penting untuk gaya ini adalah tiga protokol: komunikasi, definisi data dan protokol
data manipulasi. Sarana komunikasi membedakan dua subtipe: repositori dan papan tulis
- Repository: klien mengirimkan permintaan ke sistem untuk melakukan tindakan yang diperlukan
(misalnya memasukkan data)
- Papan tulis: sistem mengirimkan pemberitahuan dan data untuk pelanggan ketika data perubahan
bunga, dan dengan demikian aktif.

Gambar 3.

Salah satu contoh yang paling terkenal dari Data Centered Architectures, adalah arsitektur
database. Ada skema database yang umum (meta struktur-yaitu dari repositori) - dibuat dengan data
protokol definisi Misalnya dalam RDBMS satu set tabel yang berkaitan dengan bidang, tipe data,
kunci, dll.
 Klien menggunakan protokol data manipulasi untuk bekerja dengan data. Misalnya SQL untuk
memasukkan, memilih, deleteing data, dll. Tergantung di mana klien terletak protokol komunikasi
mungkin :
1. Sebuah komunikasi batin-proces
2. Komunikasi antar komponen di mesin yang sama
3. Komunikasi melalui jaringan, misalnya LAN, Internet, dll

Analisis Data Centered Architectures :

1. Memastikan integritas data
2. Handal, aman, dijamin testability
3. Klien independen pada sistem: kinerja dan kegunaan di sisi klien baik
4. Masalah dengan skalabilitas
5. Solusi: repositori bersama, replikasi tapi ini meningkatkan kompleksitas

B. Data Flow Architectures

Arsitektur ini memiliki tujuan untuk mencapai kualitas pemakaian ulang dan modifiability.
Gaya Data Flow Architectures ditandai dengan melihat sistem sebagai rangkaian transformasi pada
potongan-potongan berturut-turut input data. Data masuk ke sistem dan kemudian mengalir melalui
satu komponen pada suatu waktu sampai akhirnya, data ditugaskan untuk beberapa tujuan akhir
(output atau menyimpan data).
Data Flow Architectures dapat diklasifikasikan ke dalam Batch Sekuensial Architectures dan
Pipes and Filters. Dalam gaya batch berurutan setiap langkah berjalan untuk penyelesaian sebelum
langkah berikutnya mulai. Misalnya pipa baris perintah UNIX. Dalam pipa dan filter akan
menjalankan langkah-langkah gaya merangkap bagian pengolahan data secara bertahap.

Gambar 4.

Pipes and Filters :

Dalam pipa dan komponen filter gaya masing-masing memiliki satu set input dan satu set
output. Komponen membaca aliran data pada input dan menghasilkan aliran data outputnya,
memberikan contoh lengkap hasilnya dalam urutan standar. Hal ini biasanya dicapai dengan
menerapkan local transformasi untuk memasukkan aliran dan komputasi bertahap sehingga output
input dimulai sebelum dikonsumsi. Oleh karena itu komponen yang disebut "filter". Konektor gaya ini
berfungsi sebagai medium untuk sungai, transmisi output satu filter untuk masukan lain. Oleh karena
itu konektor ini disebut "pipa".
Di antara invariants penting dari gaya, filter harus independen entitas: khususnya, mereka tidak harus
berbagi negara dengan filter lainnya. Lain invarian penting adalah bahwa filter tidak mengetahui
identitas mereka hulu dan hilir filter.
Spesifikasi mereka mungkin membatasi apa yang muncul pada masukan pipa atau membuat
jaminan tentang apa yang muncul pada pipa output, tetapi mereka tidak dapat mengidentifikasi
komponen-komponen di ujung pipa tersebut. Selanjutnya, kebenaran output dan menyaring jaringan
pipa tidak boleh bergantung pada urutan filter yang melakukan pemrosesan tambahan mereka-
meskipun penjadwalan wajar dapat diasumsikan.
Spesialisasi umum dari gaya ini meliputi saluran pipa, yang membatasi topologi untuk urutan linear
filter, pipa berikat yang membatasi jumlah data yang dapat berada pada pipa, dan diketik pipa, yang
mengharuskan data yang melewati antara dua filter memiliki tipe yang didefinisikan dengan baik.

Gambar 5.
C. Call and Return Architectures

Call and Return Arhitectures memiliki tujuan untuk mencapai kualitas modifiability dan
solvabilitas. Call and Return Architectures telah menjadi gaya arsitektur dominan dalam sistem
perangkat lunak besar selama 30 tahun terakhir. Namun, dalam gaya sejumlah substyles, yang
masing-masing memiliki fitur yang menarik, telah muncul.
Arsitektur Main-Program-dan subrutin adalah paradigm pemrograman klasik. Tujuannya adalah untuk
menguraikan program menjadi potongan kecil untuk membantu mencapai modifiability.
Suatu program merupakan dekomposisi hierarkis. Ada benang tunggal biasanya control dan
masing-masing komponen dalam hirarki mendapatkan control ini (opsional bersama dengan beberapa
data) dari orang tua dan melewati itu bersama anak-anaknya.

Gambar 6.

Sistem prosedur panggilan Remote adalah sistem utama-program-dan-sub rutin yang diuraikan
menjadi bagian-bagian yang hidup di komputer yang terhubung melalui jaringan. Tujuannya adalah
untuk meningkatkan kinerja dengan mendistribusikan perhitungan dan mengambil keuntungan dari
beberapa prosesor. Dalam sistem pemanggilan prosedur remote, penugasan sebenarnya bagian untuk
prosesor ditangguhkan sampai runtime, yang berarti bahwa tugas mudah diubah untuk
mengakomodasi tuning kinerja.
 Pada kenyataannya, kecuali bahwa panggilan subroutine memerlukan waktu lebih lama untuk
menyelesaikan jika pemanggilan fungsi pada mesin remote, panggilan prosedur remote tidak dapat
dibedakan dari program utama standar dan sistem subrutin.

Berorientasi objek atau abstrak sistem data tipe adalah versi modern dari arsitektur panggilan-
dan-kembali. Paradigma berorientasi objek, seperti paradigma tipe data abstrak dari yang berevolusi,
menekankan bundling data dan metode untuk memanipulasi dan akses data (Public Interface).
Abstraksi objek Komponen bentuk yang menyediakan layanan kotak hitam dan komponen
lainnya yang meminta layanan tersebut. Tujuannya adalah untuk mencapai kualitas modifiability.

Gambar 7.

Rangkaian ini adalah enkapsulasi suatu yang menyembunyikan rahasia internal dari
lingkungannya. Akses ke objek hanya diperbolehkan melalui operasi yang disediakan,
biasanya dikenal sebagai metode, yang dibatasi bentuk prosedur panggilan. enkapsulasi ini
mempromosikan penggunaan kembali dan modifiability, terutama karena mempromosikan
pemisahan keprihatinan:
1. Pengguna jasa tidak perlu tahu, dan tidak harus tahu, apa-apa tentang bagaimana
layanan yang diimplementasikan.
2. Sistem berlapis adalah orang-orang di mana komponen ditugaskan ke lapisan
untuk mengontrol interaksi intercomponent. Dalam versi murni arsitektur ini, setiap
tingkat hanya berkomunikasi dengan tetangga terdekat

Gambar 8.
Tujuannya adalah untuk mencapai kualitas modifiability dan, biasanya, mudah dibawa. Lapisan
terendah menyediakan beberapa fungsi inti, seperti perangkat keras, atau kernel sistem operasi. Setiap
lapisan berturut-turut dibangun di atas pendahulunya, menyembunyikan lapisan bawah dan
menyediakan beberapa layanan yang lapisan atas memanfaatkan.
 Gambar 9.
D. Layered architectures

Sebuah sistem berlapis diatur secara hirarki, setiap lapisan menyediakan layanan kepada
lapisan di atasnya dan melayani sebagai klien ke lapisan bawah. Dalam beberapa berlapis Sistem
lapisan dalam yang tersembunyi dari semua kecuali lapisan luar yang berdekatan, kecuali untuk
fungsi-fungsi tertentu dipilih dengan cermat untuk ekspor. Jadi dalam sistem ini yang menerapkan
komponen-komponen mesin virtual pada beberapa lapisan dalam hirarki. (Dalam sistem berlapis
lapisan lainnya mungkin hanya sebagian buram.) Konektor didefinisikan oleh protokol yang
menentukan bagaimana lapisan akan berinteraksi. Kendala Topological termasuk membatasi interaksi
ke lapisan yang berdekatan.

Gambar 10.
Dikenal secara luas contoh sebagian besar semacam ini gaya arsitektur protokol komunikasi
berlapis. Di daerah ini masing-masing lapisan aplikasi menyediakan substrat untuk komunikasi di
beberapa level abstraksi. Rendah menentukan tingkat yang lebih rendah tingkat interaksi, terendah
biasanya didefinisikan oleh hardware koneksi. Lain appli-kation daerah untuk gaya ini meliputi
database sistem dan sistem operasi.
Sistem Layered memiliki beberapa sifat yang diinginkan. Pertama, mereka mendukung desain yang
didasarkan pada peningkatan tingkat abstraksi. Hal ini memungkinkan pelaksana untuk partisi
masalah yang kompleks menjadi urutan langkah-langkah tambahan. Kedua, mereka mendukung
peningkatan.
 Seperti pipa, karena setiap lapisan berinteraksi dengan di sebagian lapisan bawah dan atas,
perubahan fungsi satu lapisan berdampak pada paling banyak dua lapisan lainnya. Ketiga, mereka
mendukung kembali. Seperti jenis data abstrak, implementasi yang berbeda dari lapisan yang sama
bisa digunakan secara bergantian, asalkan mereka mendukung interface yang sama untuk lapisan yang
berdekatan mereka. Hal ini menyebabkan untuk kemungkinan mendefinisikan interface standar
lapisan yang berbeda pelaksana dapat membangun. (Sebuah contoh yang baik adalah ISO OSI model
dan beberapa X Window System protokol.)
Tetapi sistem berlapis juga memiliki kekurangan. Tidak semua sistem yang mudah terstruktur
secara berlapis. Dan bahkan jika sistem secara logis dapat berupa lapisan, pertimbangan kinerja
mungkin memerlukan kopling dekat antara logis tingkat tinggi fungsi dan mereka yang lebih rendah
tingkat implementasi. Selain itu bisa sangat sulit untuk menemukan tingkat yang tepat abstraksi. Hal
ini terutama benar untuk model berlapis standar. Salah satu catatan bahwa komunikasi masyarakat
telah memiliki beberapa protokol yang ada pemetaan kesulitan ke ISO kerangka: banyak jembatan
protokol tersebut beberapa lapisan.
Di satu sisi ini mirip dengan manfaat implementasi ditemukan bersembunyi dalam tipe data
abstrak. Namun, berikut ada beberapa tingkat abstraksi dan implementasi. Mereka juga mirip dengan
pipa, dalam komponen paling banyak berkomunikasi dengan satu komponen lainnya di kedua sisi.
Tapi bukannya pipa sederhana membaca / menulis protokol pipa, sistem berlapis-lapis dapat
memberikan banyak kaya bentuk interaksi. Hal ini membuat sulit untuk mendefinisikan sistem lapisan
independen (sebagaimana dengan filter)-sejak lapisan harus mendukung spesifik protokol di atas dan
bawah batas-batasnya. Tetapi juga memungkinkan lebih dekat interaksi antara lapisan, dan izin
transmisi dua arah informasi.

E. Event-based, Implicit Invocation

Secara tradisional, dalam sebuah sistem di mana komponen antarmuka memberikan koleksi
prosedur dan fungsi, komponen yang berinteraksi satu sama lain dengan eksplisit memanggil mereka
rutinitas. Namun, baru-baru ini telah ada cukup bunga dalam teknik integrasi alternatif, berbagai
dimaksud sebagai doa implisit, integrasi reaktif, dan siaran selektif. Ini gaya memiliki akar sejarah
dalam sistem berdasarkan pelaku daemon, dan jaringan packet-switched.
Ide di balik pemanggilan implisit adalah bahwa alih-alih memanggil sebuah prosedur secara
langsung, komponen dapat mengumumkan (atau siaran) satu atau lebih acara. Komponen lain dalam
sistem dapat mendaftarkan suatu kepentingan dalam suatu acara oleh mengasosiasikan prosedur
dengan acara tersebut. Ketika acara ini mengumumkan sistem itu sendiri memanggil semua prosedur
yang telah terdaftar untuk acara. Jadi pengumuman acara''`` implisit menyebabkan doa prosedur
dalam modul lain.
Sebagai contoh, dalam sistem Bidang, alat-alat seperti editor dan variabel monitor mendaftar
untuk's breakpoint peristiwa debugger. Ketika debugger berhenti di breakpoint, itu mengumumkan
suatu peristiwa yang memungkinkan sistem untuk secara otomatis memanggil metode alat tersebut
terdaftar. Metode ini mungkin sebuah gulir editor untuk garis sumber yang tepat atau menampilkan
kembali nilai dipantau variabel. Dalam skema ini, debugger hanya mengumumkan suatu peristiwa,
tetapi tidak tahu lain alat apa (jika ada) prihatin dengan peristiwa itu, atau apa yang mereka akan
lakukan ketika peristiwa yang diumumkan.
Berbicara arsitektur, komponen dalam sebuah gaya doa implicit adalah modul yang
menyediakan antarmuka kedua kumpulan prosedur (seperti tipe data abstrak) dan rangkaian peristiwa.
Prosedur dapat disebut di biasa cara. Tapi di samping itu, komponen dapat mendaftarkan beberapa
prosedur dengan kejadian dari sistem. Hal ini akan menyebabkan prosedur ini dapat dipanggil ketika
peristiwa tersebut diumumkan pada waktu berjalan. Jadi konektor dalam implicit Sistem doa termasuk
pemanggilan prosedur tradisional maupun bindings antara pengumuman acara dan panggilan
prosedur.
Pada invarian utama dari gaya ini adalah bahwa penyiar peristiwa tidak tahu komponen yang
akan terpengaruh oleh peristiwa-peristiwa. Dengan demikian komponen tidak bisa membuat asumsi
tentang urutan proses, atau bahkan tentang apa pengolahan, akan terjadi sebagai akibat peristiwa
mereka. Untuk alasan ini yang paling implisit pemanggilan, Sistem ini juga mencakup permintaan
eksplisit (yakni, pemanggilan prosedur normal) sebagai pelengkap bentuk interaksi.
Contoh sistem dengan mekanisme pemanggilan implisit abound. Mereka digunakan dalam
lingkungan pemrograman untuk mengintegrasikan alat-alat, dalam database sistem manajemen untuk
memastikan kendala konsistensi, di pengguna interface untuk memisahkan penyajian data dari
aplikasi yang mengelola data, dan oleh-diarahkan editor sintaks untuk mendukung tambahan semantic
memeriksa.
Salah satu manfaat penting dari doa implisit adalah bahwa ia menyediakan kuat dukungan
untuk digunakan kembali. Setiap komponen dapat diperkenalkan ke dalam sistem hanya dengan
mendaftar untuk peristiwa sistem itu. Manfaat kedua adalah bahwa implicit doa memudahkan sistem
evolusi. Komponen mungkin akan digantikan dengan yang lain komponen tanpa mempengaruhi
antarmuka komponen lain dalam sistem.

Sebaliknya, dalam sistem yang didasarkan pada pemanggilan eksplisit, apabila identitas dari
yang memberikan beberapa fungsi sistem berubah, semua modul lain yang impor bahwa modul juga
harus diubah.
Kelemahan utama dari doa implisit adalah bahwa komponen melepaskan kontrol atas
perhitungan yang dilakukan oleh sistem. Ketika komponen mengumumkan acara, itu tidak tahu apa
yang akan komponen lainnya menanggapinya. Lebih buruk lagi, bahkan jika tidak tahu apa
komponen-komponen lainnya tertarik pada kegiatan yang mengumumkan, tidak bisa mengandalkan
urutan di mana mereka dipanggil. Juga bisa tahu ketika mereka selesai. Masalah lain keprihatinan
pertukaran data. Kadang-kadang data dapat lulus dengan acara tersebut. Tapi dalam situasi lain sistem
acara harus bergantung pada repositori bersama untuk interaksi.
Dalam kasus ini kinerja global dan pengelolaan sumber daya dapat menjadi isu serius.
Akhirnya, penalaran tentang kebenaran dapat bermasalah, karena pengertian prosedur yang
mengumumkan acara akan tergantung pada konteks binding di mana ia dipanggil. Hal ini berbeda
dengan tradisional penalaran tentang panggilan prosedur, yang hanya perlu mempertimbangkan
Prosedur pra-dan pasca-kondisi ketika penalaran tentang doa itu.

F. Repositories

Dalam gaya repositori yang berbeda ada dua macam komponen cukup: pusat struktur data yang
mewakili negara saat ini, dan sebuah koleksi independen komponen yang beroperasi pada menyimpan
data pusat. Interaksi antara repositori dan komponen eksternal dapat bervariasi secara signifikan
antara sistem.
disiplin kontrol mengarah ke halaman utama. Jika jenis transaksi dalam aliran input transaksi
memicu proses pemilihan mengeksekusi, repositori bisa menjadi database tradisional. Jika keadaan
saat ini pusat struktur data merupakan pemicu utama memilih proses untuk mengeksekusi, yang
repositori bisa berupa papan tulis.

Gambar 11.
 Gambar diatas mengilustrasikan pandangan sederhana dari sebuah arsitektur papan tulis. Papan
Model biasanya disajikan dengan tiga bagian utama:
1. Sumber pengetahuan (The knowledge sour ces) : terpisah, paket independen dari aplikasi
tergantung pengetahuan. Interaksi antara sumber-sumber pengetahuan yang diperlukan tempat
hanya melalui papan tulis.
2. Papan tulis struktur data (The blackboard data structure) : pemecahan masalah negara data,
terorganisir menjadi tergantung aplikasi hirarki. Pengetahuan sumber melakukan perubahan papan
tulis yang mengarah bertahap untuk solusi untuk masalah tersebut.
3. Pengendalian (Control) : didorong sepenuhnya oleh negara dari papan tulis. sumber Pengetahuan
merespon oportunis ketika perubahan di papan tulis membuat mereka berlaku.
Dalam diagram tidak ada representasi eksplisit control komponen. Doa dari sumber
pengetahuan dipicu oleh keadaan papan tulis. Lokus aktual kontrol, dan karenanya pelaksanaannya,
dapat dalam sumber-sumber pengetahuan, papan tulis, modul terpisah, atau beberapa kombinasi ini.
Blackboard sistem secara tradisional telah digunakan untuk aplikasi yang memerlukan
kompleks interpretasi dari pemrosesan sinyal, seperti berbicara dan pola pengakuan. Beberapa di
antaranya yang disurvei oleh Nii. Mereka juga muncul dalam jenis lain dari sistem yang melibatkan
berbagi akses ke data dengan longgar agen ditambah.
contoh lain dari sistem repositori. Batch- sistem sekuensial dengan database global merupakan
kasus khusus. Pemrograman lingkungan sering diselenggarakan sebagai kumpulan alat bersama-sama
dengan berbagi repositori program dan fragmen program. Bahkan aplikasi yang telah secara
tradisional dipandang sebagai arsitektur jaringan pipa, mungkin lebih akurat diartikan sebagai sistem
repositori. Sebagai contoh, seperti yang akan kita lihat nanti, sementara arsitektur compiler secara
tradisional telah disajikan sebagai pipa, yang "Fase" dari kompiler modern yang paling beroperasi
pada dasar informasi bersama (Simbol tabel, pohon sintaks abstrak, dll).

G. Table Driven Interpreters

Dalam sebuah organisasi juru mesin virtual diproduksi dalam perangkat lunak. Sebuah
penerjemah mencakup pseudo-program yang diinterpretasikan dan penafsiran mesin itu sendiri.
Pseudo-program termasuk program itu sendiri dan penafsir analog negara pelaksanaannya (catatan
aktivasi). Pada mesin interpretasi meliputi definisi penafsir dan keadaan saat pelaksanaannya. Jadi
penerjemah umumnya memiliki empat komponen: mesin interpretasi untuk melakukan pekerjaan itu,
sebuah memori yang berisi pseudo-code untuk ditafsirkan, sebuah representasi dari negara control
interpretasi mesin, dan sebuah representasi dari keadaan saat ini program yang ditinjau.

Gambar 12.
Juru biasanya digunakan untuk membangun mesin virtual yang menutup kesenjangan antara
mesin komputasi diharapkan oleh semantik program dan mesin komputasi yang tersedia di hardware.
Kami kadang-kadang berbicara tentang bahasa pemrograman menyediakan, katakanlah, "Pascal
mesin virtual."
 H. Heterogeneous Architectures

Sejauh ini kita telah berbicara terutama dari "murni" gaya arsitektur. Meskipun penting untuk
memahami sifat individu dari masing-masing gaya, kebanyakan sistem biasanya melibatkan beberapa
kombinasi dari beberapa gaya.
Ada berbagai cara di mana gaya arsitektur dapat dikombinasikan. Salah satu cara adalah
melalui hirarki. Sebuah komponen dari suatu sistem yang diselenggarakan di satu gaya arsitektur
mungkin memiliki struktur internal yang dikembangkan sebuah yang sama sekali berbeda gaya.
Sebagai contoh, dalam sebuah pipa Unix individu komponen dapat diwakili secara internal
menggunakan hampir gaya apapun- termasuk, tentu saja, lain pipa dan filter, sistem.
Apa yang mungkin lebih mengejutkan adalah bahwa konektor juga, seringkali dapat secara
hirarki membusuk. Sebagai contoh, sebuah konektor mungkin pipa internal diimplementasikan
sebagai antrian FIFO diakses oleh menyisipkan dan menghapus operasi.
Cara kedua untuk gaya untuk digabungkan adalah untuk memungkinkan komponen tunggal
gunakan campuran konektor arsitektur. Sebagai contoh, komponen mungkin mengakses repositori
melalui bagian interface-nya, tetapi berinteraksi melalui pipa dengan komponen lain dalam sistem,
dan menerima informasi kontrol melalui bagian lain dari antarmuka. (Bahkan, pipa Unix dan sistem
filter melakukan hal ini, sistem berkas memainkan peran dan inisialisasi switch repositori bermain
peran kontrol.)
Contoh lain adalah "basis data aktif". Ini adalah repositori yang mengaktifkan komponen
eksternal melalui pemanggilan implisit. Dalam hal ini organisasi komponen eksternal mendaftarkan
minat dalam porsi dari database. Database secara otomatis memanggil alat yang tepat berdasarkan ini
asosiasi. (Papan tulis yang sering dibangun dengan cara ini, sumber-sumber pengetahuan terkait
dengan jenis data tertentu, dan diaktifkan setiap kali seperti itu data dimodifikasi.)
Cara ketiga untuk gaya untuk digabungkan adalah untuk benar-benar rumit satu tingkat dari
deskripsi arsitektur dalam arsitektur gaya yang berbeda sepenuhnya. Kami akan melihat contoh ini
dalam studi kasus.
 BAB III

PROSES PEMBANGUNAN SISTEM

3.1 PENGERTIAN HTML

HTML adalah adalah singkatan dari Hypertext Markup Language. HTML memungkinkan
seorang pengguna dapat membuat dan menyusun bagian heading, paragraf, link atau tautan, dan
blockquote untuk halaman sebuah website.

HTML sebenarnya bukanlah bahasa pemrograman, artinya HTML tidak punya kemampuan
untuk membuat fungsionalitas yang dinamis. Contoh kode atau script membuat paragraph.

Adapun contoh struktur dasar dari HTML yang dapat kamu pelajari dan praktekkan di
antaranya sebagai berikut ini.

<html>
<head>
<title>Dicoding Indonesia Website</title>
</head>
<body>
<main>
<h1>Dicoding Indonesia</h1>
<h2>Gudangnya developer handal</h2>
<p>Mencetak banyak lulusan terbaik khususnya para developer.</p>
<img src="logo_dicoding.png" alt="Image dicoding">
<p>Paragraph two with a <a href="https://dicoding.com">klik disini</a></p>
</main>
</body>
</html>

3.2 MENENTUKAN TEMA WEB

Bagi teman-teman yang masih bingung akan membuat web yang seperti apa, tentunya yang
pertama kali kita lakukan adalah menentukan tema web yang akan dibuat. Oke,Kami contohkan saja
website sederhana dengan tema portofolio. Di sini kita akan mencoba membuat web portofolio
menggunakan HTML5 ditambah sentuhan magic dari CSS3 agar tampilannya sedikit menarik dan
responsif.

3.3 MEMPERSIAPKAN TOLLS YANG AKAN DIGUNAKAN

Disini kita akan menggunakan tools-tools sebagai berikut ini:

1. Teks editor: VS Code atau Teks Editor Lain

2. Kode program : HTML5 dan CSS3
3. Web browser: Chrome
3.4 CONTOH NGODING WEB PORTOFOLIO
Pertama buka teks editor anda.Setelah dibuka kita akan membuat folder proyek terlebih
dahulu.Anda dapat menyimpan folder di sembarang tempat.Ok langsung saja.Kita akan membuat 2
buah file. Diantaranya index.html dan style.css.
1. Kode Lab: index.html

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<link rel="stylesheet" href="style.css">
<title>Web | Portofolio</title>
</head>
<body>
<div class="container">
<div class="sidebar">
<nav>
<ul>
<li><a href="">About</a></li>
<li><a href="">Portofolio</a></li>
<li><a href="">Blog</a></li>
<li><a href="">Contact</a></li>
</ul>
</nav>
</div>
<main class="content">
<section class="hero">
<img src="online.png" alt="">
<div class="hero-content">
<h1>Profesi</h1><br></h2>Junior Content Writer at Dicoding</h2><br><br>
<p> Lorem ipsum dolor sit amet consectetur adipisicing elit. Dignissimos, aperiam dolore
assumenda velit repellendus recusandae magni consectetur mollitia facere incidunt inventore
perspiciatis debitis doloribus ullam minima culpa voluptatem. Repellendus, option.</p>
<a href="" class="action-btn">Profile Saya</a>
</div>
</section>
</div>
<div class="footer">
<footer>
<ul>
<li><img src="instagram.png" alt=""><p>Instagram</p></a></li>
<li><img src="facebook.png" alt=""><p>Facebook</p></a></li>
<li><img src="twitter.png" alt=""><p>Twitter</p></a></li>
<li><img src="telegram.png" alt=""><p>Telegram</p></a></li>
</ul>
</footer>
</div>
</div>
</body>
</html>

2. Kode Lab: style.css

*{
margin: 0;
padding: 0;

body {
background-color: #eff1f2;
font-family: sans-serif;
}

.content {
grid-area: content;
}
.sidebar{
grid-area: sidebar;
background: linear-gradient(to right, rgba(200,107,142,1), rgba(218,105,250,1),
rgba(110,125,253,1)) ;
justify-content: center;
}
.footer {
grid-area: footer;
background: white;
}
.container {
font-size: 1.5em;
width: 100%;
height: 100;
height: 100vh;
display: grid;
grid-template-areas: "sidebar" "content" "footer";
grid-template-columns: 1fr;
grid-template-rows: 130px 800px 250px;

.content, .sidebar, .footer{

padding: 1em;
}

nav ul {
margin: 0;
padding: 0;
display: flex;
 justify-content: space-between;
text-align: center;
}

nav li{
list-style: none;
padding: 1em 0;
}

nav li a {
color: white;
font-weight: 700;
opacity: 0.6;
text-decoration: none;
transition: 0.3s;
}

nav li a:hover {
opacity: 1;
}
.hero {
max-width: 90 px;
margin: 0 auto;
text-align: center;
}

.hero img {
width: 200px;
}

.hero h1 {
font-size: 2em;
font-weight: 300;
color: #373046;
}

.hero p {
font-weight: 300;
line-height: 1.3em;
color: #98aBad;
}

.action-btn {
display: inline-block;
text-decoration: none;
color: white;
font-weight: 700;
background: #567bfb;
padding: 0.5em 2em;
border-radius: 60px;
 margin: 1em 0;
transition: 0.3s;
}

footer ul {
max-width: 640px;
margin: 2em auto;
padding: 0;
text-align: center;
display: flex;
flex-direction: row;

footer ul li {
list-style: none;
align-self: flex-end;
}

footer ul li a{
text-decoration: none;
color: #c1c6ce;
}

footer ul li img {
width: 30%;
}

footer p {
font-size: 0.8em;
}

@media (min-width: 1040px){

.container {
grid-template-areas:"sidebar content" "sidebar footer" ;
grid-template-rows: 1fr auto ;
grid-template-columns: 300px 1f;
}

nav ul{
display: flex;
justify-content: space-between;
flex-direction: column;
}
.sidebar{
background: linear-gradient( rgba(200,107,142,1), rgba(218,105,250,1),
rgba(110,125,253,1)) ;
padding-top: 10em;
}
.hero{
 text-align: left;
margin: 7em 0;
}
.hero img {
width: 200px;
float: right;
}
.hero h1{
font-size: 3em;
}
.hero p{
width: 60%;
}
footer ul {
max-width: 900px;
margin: 0 auto;
padding: 1em 0;
}

footer ul li a img {
width: 20%;
}
}

3. Outputnya
 BAB IV

PENUTUP

4.1 KESIMPULAN

Perkembangan teknologi saat ini berkembang dengan cepat. Metode-metode dalam

pengembangan suatu aplikasipun juga beragam dilakukan. Selain itu pemenuhan kebutuhan user oleh
aplikasi yang dikembangkan menjadi semakin mudah karena adanya metode desain dari perangkat
lunak yang memiliki banyak persyaratan serta poin-poin yang perlu diperhatikan. Dalam metode
desain perangkat lunak juga dimuat banyak materi dan step-step yang harus dijalankan oleh setiap
developer yang mengembangkan aplikasi tersebut. Oleh karena itu dengan adanya metode Desain
Perangkat Lunak ini dapat menghindari program yang di developer lepas dari kegunaan dari user yang
menggunakan. Selain itu dengan dilakukan desain dari perangkat lunak membuat aplikasi dapat tepat
sasaran pada user yang menggunakan.

4.2 SARAN

Menurut kami perkembangan teknologi saat ini berkembang dengan cepat, maka metode-metode
dalam pengembangan suatu aplikasipun juga beragam dilakukan.Dan juga untuk kebutuhan Pengguna
(user) oleh APK/Web yang dikembangkanpun menjadi semakin mudah.Dalam metode desain
arsitektur perangkat lunak juga dimuat banyak materi dan step-step yang harus dijalankan oleh setiap
developer yang mengembangkan aplikasi tersebut. Oleh karena itu dengan adanya metode Desain
Arsitektur Perangkat Lunak ini dapat menghindari program yang di developer lepas dari kegunaan
dari user yang menggunakan.

DAFTAR PUSTAKA

http://rinanti1.blogspot.com/2015/09/arsitektur-perangkat-lunak.html?m=1
https://www.dicoding.com/blog/contoh-coding-html-website-dalam-15-menit/
http://1.bp.blogspot.com/-_OhspgIXu50/VkARAhM2XqI/AAAAAAAAAJI/u6nCxpYHT8w/s1600/
PPL1.png