MAKALAH DESAIN SISTEM WAKTU NYATA

DISUSUN OLEH

HERU SETIAWAN ( K1110854 ) MOHAMMAD JUMEIDI ( K11108002 ) LUFI AFRIYANTIKA LARANDIPA ( K11108034 ) PUTRI YULI UTAMI ( K111048 )

PROGRAM STUDI SISTEM KOMPUTER FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM UNIVERSITAS TANJUNGPURA PONTIANAK 2012

KATA PENGANTAR Puji dan syukur kami panjatkan kehadirat Allah SWT yang telah memberikan ramhat serta kemudahan-Nya kepada kami, sehingga kami dapat menyelesaikan makalah ini. Pembuatan makalah ini dengan maksud untuk menyelesaikan tugas matakuliah Sistem Waktu Nyata serta menambah pengetahun tentang teknologi computer khususnya di bidang system waktu nyata. Dalam pembuatan makalah ini tidak lepas dari bantuan dan doa dari berbagai pihak. Oleh karena itu pada kesemapatan ini, kami mengucapkan terimakasih yang sebesarbesarnya kepada: 1. Ibu Irma Nirmala, S.T 2. Bapak dan Ibu kami atas segala dorongan moril dan spiritualnya. 3. Semua teman teman atas segala motivasinya untuk kami. Kami menyadari bahwa dalam menyelesaikan makalah ini banyak kekurangan dan jauh dari kesempurnaan. Oleh karena itu kritik dan saran yang bersifat konstruktif sangat kami nantikan demi memperbaiki kekurangan yang ada. Akhir kata kami berharap semoga makalah ini bermanfaat bagi kita semua. Amin.

Pontianak, April 2012

Penyusun

1. Metode Desain Sekarang ini penggunaan metode desain yang sesuai sangat penting dalam keberhasilan produksi perangkat lunak yang baik. Kegiatan awal pengembangan perangkat lunak biasanya melibatkan penelitian dan analisis sebelum desain nyata dibuat. Artinya desain harus membantu mencari cara terbaik untuk mendapatkan hasil yang memenuhi keinginan. Secara khusus, sistem real-time memiliki beberapa bagian khusus yang menuntut dukungan kuat melalui fase desain ke implementasi. Berikut ini merupakan metode yang dibutuhkan dalam mendasain sebuah sistem waktu nyata. Guidance for code structuring Data definitions Identification of tasks Task sequence model with initial priority settings Intertask dependencies and communication needs Highlight critical sections Reveal potential deadlock situations Guide the production of test data Offer flexible/adaptable implementations Assistance during debugging

Memilih sebuah metode desain merupakan aspek penting yang harus di ambil. Hal ini akan mempengaruhi dalam pengembangan sistem waktu nyata selanjutnya. 2. Penggunaan Diagram dalam Desain Langkah lanjutan setelah membuat desain adalah melakukan pemograman atau yang sering disebut dengan coding. Tetapi ada tahapan lain yang dapat membantu mempermudah dalam desain sebelum melakukan coding yaitu dengan membuat diagram desain dari program tersebut terlebih dahulu. Diagram ini biasanya dalam bentuk flowchart. Sederhananya, dua dimensi atau model grafis dari program sehingga membantu dalam keberhasilan pengembangan program berbasis teks. Berikut ini alasan untuk menggunakan diagram dalam membuat sebuah desain.

Communication with others Abstraction of relevant aspects Intellectual discipline Temporal spatial mapping Record of decisions Unambiguous representation

Setelah diagram desain selesai dibuat maka perlu di ubah ke dalam bentuk bahasa pemograman. Beberapa development software telah menyediakan penerjemah otomatis yang dapat menghasilkan kode standar dari bahasa deskripsi grafis, tetapi ini masih terbatas dalam kualitas dan ruang lingkup.

3. Data Flow Diagram ( DFD ) Dan Implementasinya. Selama era bahasa pemograman COBOL, pemodelan aliran data untuk sistem pengolahan data yang besar sudah baik, tetapi masih ada sejumlah masalah ketika ingin mencobanya kedalam real-time sistem. Langkah pertama desainer adalah menyusun diagram konteks.. DFD merupakan urutan tindakan, bukan seperti garis produksi pabrik atau pipa aliran data.

Setiap proses transformasi membaca data dari yang ditunjuk masukan stream, melakukan transformasi, dan kemudian output hasil. Skema penjadwalan dasar untuk transformasi data adalah sepenuhnya sinkron, dengan setiap proses dipicu oleh kedatangan item data masukan sungai. Kekurangan dari skema DFD adalah kegagalannya untuk menentukan waktu dan fungsi dari setiap transformasi data komponen. Atas dasar hal tersebut maka sangat disarankan untuk mempertahankan deskripsi tekstual dengan masing-masing transformasi data. Paragraf ini dikenal sebagai proses spesifikasi. Selanjutnya partisi dari diagram konteks ke tingkat-1 DFD (PSpecs) atau mini-spesifikasi. Dengan cara ini spesifikasi yang lebih lengkap dapat diarahkan disetiap saat. Dekomposisi progresif dari proses transformasi data dilakukan pada lapisan demi lapisan, sampai deskripsi dicapai yang mudah dapat diekspresikan secara langsung di bahasa pemrograman. Dengan demikian, diagram konteks diperluas ke dalam DFD level-1, yang kemudian dipecah menjadi tingkat-2 DFD, yang pada gilirannya membusuk ke tingkat-3 dan sebagainya yang diperlukan. Mempertahankan konsistensi lengkap antara diagram konteks dan diagram aliran data yang berasal jelas penting. Awalnya ini terbatas pada pememeriksaan bahwa semua terminator disertakan di semua tingkat, tetapi kemudian juga melibatkan semua aliran data internal. Kapan harus berhenti desain kegiatan dan beralih ke implementasi kode bervariasi dengan setiap situasi. Jika aplikasi relatif akrab sedang dikerjakan ulang, kebutuhan untuk analisis rinci dan penataan desain luas kurang jelas. Sebuah hasil penting dari analisis dan desain fase pengembangan perangkat lunak adalah diri pendidikan, belajar tentang aplikasi, tujuan dan perilaku yang diinginkan. Jadi ketika berhadapan dengan skenario akrab, kegiatan ini dapat dengan aman disingkat. Ketika membusuk diagram konteks ke tingkat bawah DFD, seringkali

berguna untuk mempertimbangkan arsitektur perangkat keras mungkin atau lingkungan eksekusi. Jadi, jika lingkungan dimaksudkan terdiri dari platform jaringan beberapa, itu Adalah masuk akal untuk membagi DFD dan PSpecs mereka untuk memenuhi situasi ini. Arus data antara subsistem kemudian mendapatkan diwakili oleh fisik saluran atau soket IP.

Impelementasi penggunaan DFD tidak sulit dengan menggunakan bahasa pemrograman tingkat tinggi. Beriktu ini contoh penggunaan DFD.

4. Analisa Dan Desain Untuk Struktur System Waktu Nyata Diagram konteks awal menetapkan perimeter dari sistem yang akan dikembangkan, dengan semua sumber data eksternal dan tertanam. Hal ini memberikan desainer kesempatan untuk mulai berpikir tentang struktur data dan tingkat perkiraan aliran yang akan memberikan beberapa nilai untuk beban pengolahan yang mungkin ditemui. Pada saat yang sama, terutama ketika dihadapkan dengan medan aplikasi yang tidak diketahui dan terstruktur 'sudut pandang "analisis dapat membantu dalam membangun lebih akurat fungsional sistem persyaratan. Metode Yourdon, dengan real-time ekstensi, berhasil menyatukan tiga desain pendekatan dengan metodologi diagram yang berbeda. Setelah menggambar sebuah diagram konteks sistem, DFD tingkat atas dapat diturunkan, partisi sistem ke dalam unit utamanya fungsional, atau subsistem. Pemisahan ini sebenarnya bisa didorong oleh kebutuhan praktis untuk mendistribusikan perangkat lunak melalui platform diskrit beberapa, atau memisahkan pengolahan memuat diantara host yang tersedia. Atau, Anda bisa mulai dengan: 'Masukan', 'Proses', 'Output' jika tidak ada pedoman yang bermanfaat lainnya datang ke pikiran! Sebuah fragmentasi lebih lanjut kemudian dapat dilakukan untuk menghasilkan lebih rinci tingkat

kedua DFD berdasarkan transformasi data sebelumnya. Pendekatan pemodelan data bisa, Namun, menawarkan alternatif dari diagram konteks sebagai langkah pertama dalam desain proses. Penjelasan tingkat tinggi pada awalnya dikembangkan melibatkan realworld entitas dan hubungan mereka. ERD yang jauh dari praktis pelaksanaan, dan berfungsi untuk memilah kebingungan dan ketidakpastian pada tahap awal proyek. Pada dasarnya ada tiga langkah dasar dari tahap implementasi akhir DFD : 1. Direct implementation of the DFD in executable code. 2. Expansion of the data processes into structure charts, sequenced by the input and output streams. 3. Introduction of event-driven control processes.

5. Stored Pemodelan Data - Pemodelan EAR Metode diagram ketiga yang termasuk dalam Yourdon SA / S dikenal dengan Entity Relationship Diagram (ERD). Metode ini mendukung analisis dan penataan dari kuasi-data statis yang sering berada di tengah computer berbasis aplikasi. Hal ini semakin menjadi dengan munculnya internet dan sentralisasi database perusahaan. Untuk memahami dan memodelkan cara kerja interaktif yang kompleks, sistem perlu mengidentifikasi komponen utama dan hubungan keduanya. Hubungan antara kelompok berarti bahwa ketika salah satu anggota diubah, anggota terkait kelompok lain akan terpengaruh. Analisis ini umumnya dilakukan dengan menggunakan Entitas Atribut Hubungan (EAR) yaitu pemodelan yang juga memainkan pusat di on-line, sistem interaktif, jelas bahwa real-time programmer harus tidak mengabaikan ERD!

6. Transformasi ERD ke DFD Sebuah deskripsi ERD dapat digunakan dalam salah satu dari dua keadaan. Yang paling umum adalah untuk menganalisis dan menggambarkan database komponen yang memegang data untuk sistem. Dalam hal ini ERD akan menerjemahkan ke dalam script SQL untuk menangani penciptaan, memperbarui dan query yang melibatkan database. Situasi lain memerlukan transformasi dari sebuah awal ERD model, yang meliputi sistem yang lengkap atau sebagian, dalam bentuk ekspresi lebih dekat dengan implementasi. Untuk ini, tidak ada aturan yang diterima secara universal. Jika file diskrit digunakan di tempat pada database yang terpusat, atau bila hubungan tabel dapat diwakili secara terpisah tanpa rancu, gambar di bawah ini menggambarkan sebuah fragmen ERD dan DFD terkait untuk menghasilkan penambahan permintaan kepada pemasok. Entitas dalam sebuah ERD dapat mewakili data, atau perangkat terminator, di mana kuasi-stabil data dipertahankan untuk sistem. Jika hubungan antara dua entitas yang kompleks, bahkan melibatkan pengenalan atribut lagi, transformasi data DFD dapat direalisasikan dengan menggunakan tabel lain ( lookup ), yang memasok pemetaan. Hubungan antara dua entitas menjadi fungsi aktif melayani permintaan. Ketika hal ini terjadi tidak ditentukan oleh ERD model, hanya asumsiny adalah bahwa setiap perubahan padadata akan memicu riak tindakan di seluruh model untuk menetralkan semua tabel.

7. Normalisasi Data set sering mengandung dependensi fungsional yang membatasi nilai-nilai yang diperbolehkan. Dengan demikian, variabel tidak bisa mengubah nilai-nilainya secara mandiri. Bahkan nilai dari variable utama dapat digunakan untuk menentukan nilai nilai non primary item. Dalam penyimpanan data, penting untuk meminimalkan kuantitas dan merasionalisasikan hubungan antar data. Pada sistem database, menyimpan data berlebihan atau secara berulang merupakan hal yang tidak efisien dan mungkin akan menyebabkan masalah. Hal ini telah dibahas oleh Codd (1971) dan Chen (1976) yang menyatakan bahwa hubungan antar data dapat dinormalisasikan untuk memenuhi beberapa kondisi tertentu dan

mengurangi, atau bahkan menghilangkan redundansi sehingga data dapat disajikan dalam kondisi sebagai berikut: 1NF First Normal Form, item instances listed in simple attribute relation table may contain redundant data. 2NF Second Normal Form, same as 1NF but with non-prime attributes fully dependent on whole primary key attribute(s). 3NF Third Normal Form, same as 2NF but with no functional dependencies between non-prime attributes. BCNF BoyceCodd Normal Form, same as 3NF but with multiple primary key relation tables, the keys are interdependent. 4NF Fourth Normal Form, same as BCNF but no multi-valued dependencies.