KD 7
ARSITEKTUR PERANGKAT LUNAK
1. PENGENALAN ARSITEKTUR PL
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.
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.
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.
lainnya. Jika dilihat dari segi Interaksi Manusia dan Komputer, maka dengan FOKUS KUALITAS programmer akan mengetahui bentuk dari aplikasi yang akan bangun.
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).
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.
4) TOOLS
RAGAM ARSITEKTUR
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.
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)
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, dan lain-lain.
Klien menggunakan protokol data manipulasi untuk bekerja dengan data. Misalnya SQL untuk memasukkan, memilih, deleteing data, dan lain-lain. 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
2. Data Flow Architectures
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".
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 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.
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.
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 5.3
Gambar 5.4 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.
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. Event-based, Implicit Invocation
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.
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.
6. Repositories
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.
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).
7. Table Driven Interpreters
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."
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.)
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.
2. PENGENALAN STRUKTUR CHART DIAGRAM
Struktur chart berfungsi untuk mendefinisikan dan mengilustrasikan organisasi dari sistem informasi secara berjenjang dalam bentuk modul dan submodul. Struktur chart juga menunjukkan hubungan elemen data dan elemen kontrol antara hubungan modulnya. Struktur chart dapat memberikan penjelasan lengkap dari sistem dipandang dari elemen data, elemen kontrol, modul dan hubungan antar modul. Sebuah bagan struktur menggambarkan :
Ukuran dan kompleksitas sistem, dan
Sejumlah fungsi mudah dikenali dan modul dalam fungsi masing-masing dan
Apakah setiap fungsi diidentifikasi adalah entitas dikelola atau harus dipecah menjadi
komponen yang lebih kecil.
Sebuah bagan struktur juga digunakan untuk diagram elemen terkait yang terdiri dari aliran run atau thread. Hal ini sering dikembangkan sebagai diagram hirarkis , tetapi representasi lain diijinkan. Representasi harus menjelaskan rincian dari sistem konfigurasi ke subsistem dan tingkat terendah dikelola. Sebuah bagan struktur yang akurat dan lengkap adalah kunci untuk penentuan item konfigurasi, dan representasi visual dari sistem konfigurasi dan antarmuka internal. Selama proses konfigurasi kontrol, bagan struktur digunakan untuk mengidentifikasi dan artefak yang terkait bahwa perubahan yang diusulkan dapat mempengaruhi.
mengkonseptualisasikan bagaimana masing-masing dapat dipecah menjadi tugas yang lebih kecil. Akhirnya, program ini dipecah ke titik di mana daun pohon merupakan metode sederhana yang dapat dikodekan dengan hanya beberapa laporan program.
Struktur chart umumnya dipakai dalam perencanaan top-down programming (Alat bantu ini sering juga disebut hirarki atau tingkatan, atau chart atau visual table of contents-VTOC). Pada saat ini tidak ada standar yang digunakan dalam struktur chart, dan teknik yang akan dikemukakan dibawah ini, yang bekerja cukup baik,serta kenapa digunakan sebagai alat diambil dari berbagai variasi sumber. Contoh structure chart : php
2.2. Komponen Stucture Chart
Produk dari Perancangan Terstruktur adalah Structure Chart yang memperlihatkan komponen-komponen prosedural program, pengaturan hierarkinya dan data yang menghubungkan komponen-komponen tersebut.
2.3. Model Bagan Terstruktur
Bagan terstruktur adalah mendefinisikan dan Mengilustrasikan Organisasi dari system informasi secara berjenjang dalam bentuk modul dan submodul.
2.4. Elemen Struktur Chart Diagram terdiri dari : 1. Elemen data
2. Elemen control 3. Modul
3. TRANSFORMASI DFD KE STRUKTUR CHART DIAGRAM
Untuk masalah sederhana pembuatan structure chart untuk menggambarkan
rancangan modul program dapat dilakukan tanpa harus memodelkan hasil analisis terlebih dahulu.
Tetapi untuk masalah yang cukup besar dan kompleks pembuatan rancangan modul program harus dilakukan setelah hasil analisis selesai dimodelkan.
Tahap Pembuatan Structure Chart dari DFD :
3. Ubah DFD level rinci menjadi modul-modul lainnya sesuai dengan fungsinya dengan pendekatan Transform Analysis dan atau Transaction Analysis.
4. Evaluasi dan perbaiki structure chart yang diperoleh dengan memperhatikan coupling, cohesion dan lain-lain.
Transform Analysis
Model aliran informasi yang digunakan untuk merancang program dengan mengenali komponen-komponen fungsional utama serta masukan dan keluarannya.
Dalam DFD sebuah transformasi direpresentasikan oleh sebuah jaringan yang berbentuk linier.
Untuk mengubah DFD berbentuk Transformasi dengan cara :
1. Bagi DFD menjadi tiga kelompok bagian yaitu bagian Input,pusat transformasi dan keluaran.
2. Gambarkan bagian pusat transformasi, input dan output dari DFD masing-masing sebagai sebuah komponen fungsional (Modul).
Tempatkan pusat transformasi atau komponen fungsional yang baru sebagai modul pemanggil di level atas dari structure chart dan tempatkan yang lainnya di level berikutnya sebagai modul yang akan dipanggil.
