Perancangan Arsitektur Perangkat Lunak

1.  Konsep Perancangan Perangkat Lunak

Perancangan perangkat lunak merupakan salah satu proses lanjutan pengembangan perangkat lunak yang menghasilkan model atau prototype yang menampilkan ketegasan , komoditas dan mudah dipahami yang dapat memenuhi kebutuhan.  Tahapan ini dapat di implementasikan menggunakan bahasa pemrograman.

2. Prinsip Desain secara umum

     

1. Abstraction 

    

Abstraction (abstraksi) terkait dengan bagaimana berfokus dalam memandang

 objek dan mengambil hal yang penting dari objek tersebut. Tiga macam
abstraksi yang dikenal adalah : abstraksi prosedur, data, dan kontrol (iterasi). 

2.	Coupling & Cohesion

Coupling merupakan ketergantungan antar modul sedangkan cohesion

merupakan keterikatan antara elemen penyusun modul. 

3.	Decompositon & modularization

Prinsip ini menekankan pada penguraian (decompose) perangkat lunak yang

‘besar’ menjadi modul-modul atau elemen-elemen dimana masing-masing
elemen memiliki fungsi dan tanggung jawab masing-masing.

  

4.	Encapsulation

Prinsip encapsulation berarti detail dari sebuah abstraksi tidak diketahui atau

tidak dapat diakses oleh entitas yang lain di luarnya. 

5.	Separation of interface and implementation

Dari sisi komponen perangkat lunak, prinsip ini berarti akses kepada sebuah

komponen dari komponen yang lain melalui public interface yang telah
didefinisikan pada komponen yang akan diakses tersebut.  

6.	Sufficiency, completeness & primitiveness

Sufficiency dan completeness berarti abstraksi yang dilakukan telah

menangkap semua karakteristik yang diperlukan sedangkan primitivenessartinya desain dapat diimplementasikan. 

7.	Separation of concern

Prinsip ini terkait dengan arsitektur, dimana terdapat beberapa architectural

view yang memudahkan stakeholder dalam mengelola kompleksitas perangkat
lunak. 

3. Prinsip Desain Berorientasi Objek

Desain berorientasi objek memiliki prinsip umum ditambah dengan prinsip lain yang
dikembangkan berdasarkan konsep berorientasi objek seperti pewarisan (inheritance)
dan polimorfisme. Beberapa prinsip yang akan dibahas adalah Single Responsibility
Principle, Open Closed Principle, Liskov Subtitution Principle, Dependency Inversion
Principle dan Interface Segregation Principle [3].Single Responsibility Principle (SRP), merupakan prinsip dimana sebuah kelas
(class) hanya memiliki satu alasan untuk berubah. Artinya bahwa sebuah kelas hanya
memiliki sebuah tanggung jawab tertentu. Contoh sebuah tanggung jawab adalah
sebuah method / perilaku. Ketika sebuah kelas memiliki banyak method dengan
perilaku yang bermacam-macam, maka akan tercipta ketergantungan antar method di
dalam kelas tersebut. Akibatnya, perubahan di satu method, akan mempengaruhimethod yang lain.Open Closed Principle (OCP), menekankan bahwa pengembangan/perluasan yang
dilakukan pada entitas perangkat lunak seperti kelas dan modul semestinya melaluiextension bukan melalui penyuntingan kode program. Sebagai contoh extension adalah
menggunakan konsep pewarisan ataupun polimorfisme  Liskov Subtitution Principle (LSP), adalah prinsip dimana supertipe (supertype)
dapat mensubstitusi subtipe (subtipe). Jika diterapkan pada pewarisan, maka superclass
harus dapat mensubstitusi subclass-nya. Artinya di sini bahwa hubungan antarasubclass dan superclass harus memenuhi kaidah “IS-A”Dependency Inversion Principle (DIP) merupakan prinsip yang menekankan pada
penggunaan abstraksi. Artinya, ketergantungan yang dibangun pada hubungan antar
kelas semestinya kepada kelas abstrak atau interface, bukan pada kelas konkrit
(concrete class).
Prinsip yang terakhir, Interface Segregation Principle (ISP), adalah sebuah prinsip
yang memandu pembuatan interface. Prinsip ini tidak menyarankan pembuataninterface yang terlalu banyak method yang tidak perlu. Lebih baik, method-methodyang tidak berkaitan dipisahkan dalam interface yang lain. 

 

4.  Proses DesainDesain bertujuan untuk membentuk sebuah model yang siap untuk diimplementasikan
ke dalam program. Dalam membentuk model desain, terdapat serangkaian proses yang
perlu dilakukan dengan tetap berpegang pada prinsip-prinsip desain. Proses desain
menurut SWEBOK terdiri atas dua aktivitas yaitu software architectural design dansoftware detailed design. Semua kegiatan desain perlu untuk didokumentasikan dan
proses dokumentasi perlu manajemen yang baik.
Dalam desain berorientasi objek diuraikan beberapa kegiatan yang lain pada
tahapan desain . Kegiatan tersebut adalah : Mendefinisikan tujuan desain. Mendefinisikan subsistem. Pemetaan subsistem ke dalam platform yang digunakan Pengelolaan persistent data. Mendefinisikan kendali akses. Mendefinisikan kendali aliran (control flow). Mendefinisikan boundary condition.
Kegiatan-kegiatan tersebut merupakan uraian dari dua kegiatan utama pada tahap
desain. Berikutnya, akan diurakan dua kegiatan utama dari tahapan desain tersebut.  

4.1  Desain ArsitekturDesain arsitektur merupakan desain makro / struktur yang mencerminkan kualitas serta
fungsi dari perangkat lunak. Aktivitas pembentukan arsitektur merupakan aktivitas
dekomposisi, yaitu membagi perangkat lunak menjadi elemen-elemen[2]. Terdapat
panduan dalam aktivitas pembentukan desain arsitektur [5] : Memikirkan apa (what) yang akan dilakukan oleh sistem menjadi pertimbangan
utama daripada memikirkan bagaimana (how) sistem melakukan sesuatu. Desain abstrak (interface, kelas abstrak atau abstrak data type) dipertimbangkan
lebih dahulu daripada desain yang konkrit (concrete class).
 Kebutuhan non fungsional digunakan sebagai acuan dalam awal proses desain. Pemakaian ulang sebanyak mungkin elemen/komponen menjadi pertimbangan
dalam menyusun desain. Desain elemen arsitektur dilakukan dengan mengutamakan high cohesion danloose coupling. Desain disusun tidak dalam satu proses namun dalam beberapa proses yang
berulang. Desain arsitektur yang telah disusun tidak ambigu dan terlalu detail (over
detailed)
Arsitektur menggambarkan elemen-elemen penyusun perangkat lunak berikut
hubungan antar elemen tersebut atau bagaimana antar elemen saling berkomunikasi.
Hasil dari kegiatan arsitektur dapat digunakan sebagai alat evaluasi oleh para pemangku
kepentingan (stakeholders) terutama yang terkait dengan kebutuhan nonfungsional.
Setidaknya terdapat “4+1” sudut pandang (view model) dalam arsitektur perangkat
lunak yaitu logical, process, physical, development serta secenario / use case [6].
Masing-masing view tersebut dapat dimanfaatkan oleh perancang perangkat lunak
untuk membuat deskripsi mengenai arsitektur yang dipilih, dari masing-masing sudut
pandang. Use case / scenario : merupakan bentuk dari keseluruhan fungsi perangkat lunak
dan digunakan dasar acuan dari pembentukan logical, process, physical maupundevelopment view. Selain sebagai dasar acuan, scenario, menjadi alat untuk
validasi setelah keseluruhan view selesai didokumentasikan. Logical view : menggambarkan kebutuhan fungsional, yaitu kebutuhan yang
semestinya diberikan oleh sistem kepada end user. Penggambaran berupa objek
dan kelas yang menggunakan enkapsulasi maupun pewarisan. Process view : memungkinkan desainer untuk menggambarkan beberapa
kebutuhan non fungsional seperti performance dan availability. Dalam view ini
juga terdapat definisi thread of control yang mengendalikan objek maupun kelas
dalam logical view. Physical view : mengilustrasikan kebutuhan non fungsional seperti scalabilitydan reliability. Pada physical view, hal-hal yang telah didefinisikan dalamlogical, process dan development view dipetakan dalam node-node (mesinmesin fisik ataupun platform). Development view : berfokus pada organisasi perangkat lunak dalam modulmodul atau sub-sistem, yang akan diterapkan pada perangkat lunak yang
dikembangkan.
Penyusunan perangkat lunak dalam modul-modul beserta konektornya akan
membentuk struktur perangkat lunak. Dalam proyek perangkat lunak, akan dapat
ditemukan struktur-struktur yang mirip atau hampir sama dan dapat digunakan ulang
untuk proyek lain. Strukur-struktur tersebut dikenal dengan architectural style
Terdapat banyak kelompok architectural style yang telah didefinisikan. Beberapa
kelompok tersebut, beserta architectural style-nya adalah ditunjukkan pada tabel 1.
Masing-masing architectural style memiliki elemen-elemen tertentu dengan pola-pola
konektor dan aturan komunikasi antar elemen tertentu. Sebagai contoh, Model-ViewController (MVC) memeiliki elemen-elemen seperti model, view dan controller dengan
pola komunikasi 

Kelompok Arsitektur	Architectural Style
Data Flow	Pipe & Filter, Process Control
Data-Centered	Repository, Blackboard
Hierarchical	Layered, Master-Subroutine
Interaction Oriented	Model-View-Controller (MVC)
Distributed	Client-Server, Multi-tiers, Broker
Implicit Asynchronous Communication	Buffered Message-Based, Non-buffered event-based implicit invocation

5. Arsitektur Perangkat Lunak

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

 

5.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.1

Lapisan Perangkat Lunak Secara Umum

Resources : Software Engineering - A Practitioner's Approach

            Roger S. Pressman, 2003, McGraw-Hill.

 

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

5.2.2  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).

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

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

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

5.3.1 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.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 :

§ Sebuah komunikasi batin-proces

§ Komunikasi antar komponen di mesin yang sama

§ 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

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

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 4.3

5.3.3 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 5.1

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 5.2

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:

Ø  Pengguna jasa tidak perlu tahu, dan tidak harus tahu, apa-apa tentang bagaimana layanan yang diimplementasikan.

                Ø  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 terde

Gambar 5.3

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 5.4

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

 

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.

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

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

Pilihan 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 7.1

Gambar diatas mengilustrasikan pandangan sederhana dari sebuah arsitektur papan tulis. Papan Model biasanya disajikan dengan tiga bagian utama:

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

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

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

Ada, tentu saja, 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).

5.3.7 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 8.1

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

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

5.4 Pengenalan Struktur Chart Diagram

Structure Chart  ( bagan struktur ) :

organisasi dari sistem secara berjenjang dalam bentuk modul dan submodul.

Salah satu alat bantu pemecahan masalah teknik top-down

- Structure Chart menggambarkan hubungan

  elemen data dan elemen kontrol serta

  hubungan antar modulnya.

- Structure Chart penjelasan yang lengkap dari

  sistem.

5.4.1 Elemen Struktur Chart Diagram

Elemen Structure Chart Diagram terdiri dari  :

1. elemen data

2. elemen kontrol

3. modul

hubungan antar modulnya (panah)

6. Perancangan terperinci

 Perancangan terperinci adalah tahapan yang dilakukan setelah perancangan arsitektur yang menggambarkan rincian secara lengkap dari semua komponen perangkat lunak, sifat - sifatnya, hubungan, pemrosesan , struktur data dan sampai tahap implementasi

Aktifitas perancangan terperinci terdiri dari:

• Dekomposisi komponen sistem utama menjadi unit program.
• Alokasi tanggung jawab fungsional kepada unit.
• Antarmuka pengguna
• Status unit dan perubahan status
• Data dan kontrol interaksi antar unit
• Pengemasan dan implementasi data, termasuk masalah ruang lingkup dan visibilitas elemen
program
• Algoritma dan struktur data  

7. Software Design Description ( SDD)

SDD adalah hasil kerja dari pengembangan yang berisi perancangan perangkat lunak yang dapat dijadikan kesepakatan spesifikasi antara user dan pengembang sebelum konsturksi perangkat lunak.

Hal yang harus ada dalam SDD meliputi :

oJuduloNama PengembangoTanggal terakhir dokumen diperbaharuioGambaran UmumoSasaran dan BatasanoDesain ArsitekturoDesain TerperincioTonggak SejarahoDeskripsi FungsionaloKegunaanoAntarmuka PenggunaoApa yang sedang dilakukan pengembangoApa yang akan dilakukan pengembang selanjutnya 

8. Syarat - Syarat perancangan perangkat lunak yang baik :

   1.Fleksibel : hasil perancangan harus dapat menyesuaikan diri dengan kebutuhan pengguna yang sewaktu-waktu bisa       berubah.

2.Mudah ditransfer : hasil perancangan yang dapat muda diterapkan di lingkungan perangkat keras yang berbeda.

3.Mudah dimodifikasi : berkaitan dengan siklus hidup.

4.Mudah digunakan : hasil perancangan yang baik harus mampu menghasilkan pengerjaan perangkat lunak yang mudah digunakan oleh pengguna.

   5. Handal : mampu meminimalkan kesalahan yang dibuat oleh pengembang perangkat lunak

6. Aman : hasil perancangan yang baik juga harus memperhatikan segi keamanan perangkat lunak yang dirancang sehingga tidak akan membuat pengguna menjadi cemas

7. Tidak mahal : perancangan yang dibuat juga harus menyesuaikan dengan anggaran yang telah disediakan oleh pengguna.

 9. Faktor kegagalan perancangan perangkat lunak :

1.Tidak terdapat skema desain yang spesifik

2.Tidak terdapat prioritas dalam hasil perancangan

3.Kesulitan untuk mengidentifikasi kendala yang ada didalamnya

4.Kesulitan untuk memecah masalah yang besar menjadi kebagian yang lebih kecil.