Goresan Kata

Nasib terbaik adalah tidak dilahirkan, yang kedua dilahirkan tapi mati muda, dan yang tersial adalah umur tua. Rasa-rasanya memang begitu. Bahagialah mereka yang mati muda.. Soe Hok Gie

Selasa, 06 Desember 2011

PEMROGRAMAN TERSTRUKTUR



PEMROGRAMAN TERSTRUKTUR
Pemrograman Terstruktur merupakan suatu tindakan untuk membuat program yang berisi instruksi-instruksi dalam bahasa komputer yang disusun secara logis dan sistematis supaya mudah dimengerti, mudah dites, dan mudah dimodifikasi.
Pemrograman terstruktur adalah bahasa pemrograman yang mendukung pembuatan program sebagai kumpulan prosedur. Prosedur-prosedur ini dapat saling memanggil dan dipanggil dari manapun dalam program dan dapat mengunakan parameter yang berbeda-beda untuk setiap pemanggilan. Bahasa pemrograman terstruktur adalah pemrograman yang mendukung abstraksi data, pengkodean terstruktur dan kontrol program terstruktur. Sedangkan Prosedur adalah bagian dari program untuk melakukan operasi-operasi yang sudah ditentukan dengan menggunakan parameter tertentu.

Ide pemrograman terstruktur pertama kali diungkapkan oleh Prof Edsger Djikstra dari Universitas Eindhoven sekitar tahun 1965. Dalam papernya, Djikstra mengusulkan peniadaan perintah GOTO pada pemrograman terstruktur. Berbeda dengan pendapat HD Millis yang mengungkapkan bahwa pemrograman terstruktur tidak tergantung pada ada tidaknya GOTO tetapi lebih pada struktur program itu sendiri. Dari pernyataan keduanya, memberikan gambaran tidak adanya definisi yang jelas untuk pemrograman terstruktur. Tetapi dapat digaris bawahi bahwa pemrograman terstruktur merupakan suatu proses untuk mengimplementasikan urutan langkah untuk menyelesaikan suatu masalah dalam bentuk program.

Tujuan dari pemrograman terstruktur adalah:

1.       Meningkatkan kehandalan suatu progam,
2.       program mudah dibaca dan ditelusuri,
3.       menyederhanakan kerumitan program,
4.       pemeliharaan program, dan
5.       meningkatkan produktivitas pemrograman.

Pemrograman terstruktur bercirikan:

1.         mengandung teknik pemecahan yang tepat dan benar,
2.         memiliki algoritma pemecahan masalah yang sederhana, standar dan efektif,
3.         memiliki struktur logika yang benar dan mudah dipahami,
4.         terdiri dari 3 struktur dasar yaitu urutan, seleksi dan perulangan,
5.         menghindari penggunaan GOTO,
6.         biaya pengujian rendah, Source Program penterjemah Machine Languages Komputer dan Pemrograman
7.         memiliki dokumentasi yang baik,
8.         biaya perawatan dan dokumentasi yang dibutuhkan rendah.




Langkah-langkah untuk membuat program yang baik dan terstruktur adalah:
1. Mendefinisikan Masalah
2. Menentukan Solusi
3. Memilih Algoritma
4. Menulis Program
5. Menguji Program
6. Menulis Dokumentasi
7. Merawat Program
8. Pengenalan Komputer

1.               Data Flow Diagram (DFD)
simbol dfdData Flow Diagram (DFD) adalah suatu diagram yang menggunakan notasi- notasi untuk arus dari data sistem, yang penggunaannya sangat membantu untuk memahami sistem secara logika, terstruktur dan jelas. Atau DFD bisa juga dikatakan sebagai suatu model logika data atau proses yang dibuat untuk menggambarkan dari mana asal data dan kemana tujuan data yang keluar dari sistem, dimana data disimpan, proses apa yang menghasilkan data tersebut dan interaksi antara data yang tersimpan dan proses yang dikenakan pada data tersebut. DFD ini sering disebut juga dengan nama Bubble chart, Bubble diagram, model proses, diagram alur kerja, atau model fungsi. DFD ini adalah salah satu alat pembuatan model yang sering digunakan, khususnya bila fungsi-fungsi sistem merupakan bagian yang lebih penting dan kompleks dari pada data yang dimanipulasi oleh sistem. Dengan kata lain, DFD adalah alat pembuatan model yang memberikan penekanan hanya pada fungsi sistem. DFD ini merupakan alat perancangan sistem yang berorientasi pada alur data dengan konsep dekomposisi dapat digunakan untuk penggambaran analisa maupun rancangan sistem yang mudah dikomunikasikan oleh profesional sistem kepada pemakai maupun pembuat program. DFD terdiri dari context diagram dan diagram rinci (DFD Levelled). Context diagram berfungsi memetakan model lingkungan (menggambarkan hubungan antara entitas luar, masukan dan keluaran sistem), yang direpresentasikan dengan lingkaran tunggal yang mewakili keseluruhan sistem. DFD levelled menggambarkan sistem sebagai jaringan kerja antara fungsi yang berhubungan satu sama lain dengan aliran dan penyimpanan data, model ini hanya memodelkan sistem dari sudut pandang fungsi. Berikut ini merupakan simbol-simbol yang biasa digunakan di DFD :









Terminal/Entity

Terminator atau entity mewakili entitas eksternal yang berkomunikasi dengan sistem yang sedang dikembangkan. Terminator dapat berupa orang, sekelompok orang, organisasi, departemen di dalam organisasi, atau perusahaan yang sama tetapi di luar kendali sistem yang sedang dibuat modelnya. Terminator dapat juga berupa departemen, divisi atau sistem di luar sistem yang berkomunikasi dengan sistem yang sedang dikembangkan.

Komponen ini perlu diberi nama sesuai dengan dunia luar yang berkomunikasi dengan sistem yang sedang dibuat modelnya, dan biasanya menggunakan kata benda, misalnya Bagian Penjualan, Dosen, Mahasiswa.

Proses
Merupakan Merupakan kegiatan kegiatan atau atau pekerjaan pekerjaan yang yang dilakukan dilakukan oleh oleh orang orang atau atau mesin mesin komputer komputer, dimana dimana aliran aliran data data masuk masuk, ditranformasikan ditranformasikan ke ke aliran aliran data data keluar.

Data Store
Data store ini biasanya berkaitan dengan penyimpanan-penyimpanan, seperti file atau database yang berkaitan dengan penyimpanan secara komputerisasi, misalnya file disket, file harddisk, file pita magnetik. Data store juga berkaitan dengan penyimpanan secara manual seperti buku alamat, file folder, dan agenda. Data store diberi nama sesuai dengan nama file penyimpanannya misalnya mahasiswa, matakuliah, dosen, dataregistrasi, dll.
Alur Data
Suatu data flow / alur data digambarkan dengan anak panah, yang menunjukkan arah menuju ke dan keluar dari suatu proses. Alur data ini digunakan untuk menerangkan perpindahan data atau paket data/informasi dari satu bagian sistem ke bagian lainnya.

Contoh DFD :








                                                                                                                                   
2.       Entity Relation Diagram
Entity relationship adalah suatu cara memodelkan suatu data ditingkat konseptual dalam perancangan basis data.  Model Entity-Relationship merupakan alat modeling data yang populer dan banyak digunakan oleh para perancang database. 
Berdasarkan tipe konsepnya, data model dibagi menjadi dua kategori yaitu Conceptual (High Level) Data Model dan Physical (Low Level) Data Model

Model Entity-Relationship

Model E-R diperkenalkan pertama kali oleh P.P. Chen pada tahun 1976, walau model ini sudah ketinggalan jaman akan tetapi dalam penerapannya ER masih merupakan model yang efektif dalam upaya menggambarkan persepsi dari pemakai karena berisi objek-objek dasar yang disebut sebagai entitas dan hubungan antar entitas-entitas yang disebut relationship.  Adapun model E-R dinotasikan sebagai berikut :
Simbol
Arti
Uraian
 http://mugi.or.id/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/oke.Visio/entitas.jpg
 Entitas
Entitas/Entity adalah sesuatu yang dibedakan dalam dunia nyata, diman informasi yang berkaitan dengannya dikumpulkan.  Entity set (Himpunan entitas) adalah kumpulan dari entity yang sejenis, berupa proyek, kendaraan, pegawai, konsumen, pemasok, penjualan dan lain sebagainya.
 http://mugi.or.id/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/oke.Visio/relationship.jpg
 Relationship
Hubungan yang terjadi antara satu atau lebih entity.  Relationship tidak mempunyai keberadaan fisik kecuali yang diwarisi dari hubungan antara entity tersebut. 
 http://mugi.or.id/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/oke.Visio/atribut.jpg
 Atribut
Karakteristik dari entity atau relationship yang menyediakan penjelasan detail tentang entity atau relationship tersebut.  Nilai atribut (Attribute value) adalah suatu data aktual atau informasi tertentu yang disimpan pada tiap atribut di dalam suatu entitas atau relationship (Nonkey attribute).  Identifier (key) digunakan untuk menentukan suatu entity secara unik.  Descriptor (nonkey attribute) digunakan untuk menspesifikasikan  karakteristik dari suatu entity yang tidak unik.
 http://mugi.or.id/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/oke.Visio/key.jpg
 Key Atribut (Atribut Kunci)
Atribut yang digunakan untuk menentukan suatu entity secara unik.
 http://mugi.or.id/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/oke.Visio/weak-entity.jpg
 Weak Entity
 Lihat penjelasan tentang weak entity
 http://mugi.or.id/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/oke.Visio/iden.jpg
Identifying Relationship
 Lihat penjelasan tentang weak entity
 http://mugi.or.id/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/oke.Visio/multivalue.jpg
Multivalued Atribut
 Lihat penjelasan tentang weak entity
 http://mugi.or.id/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/oke.Visio/discriminasi.jpg
Discriminating atribut pada weak entity
 Lihat penjelasan tentang weak entity

 






Derajat Relationship

Terdapat 3 macam derajat dari relationship, yaitu :
  • Unary Degree (derajat satu),
             Bila satu entity mempunyai relasi terhadap dirinya sendiri.  Digambarkan sebagai berikut :
http://mugi.or.id/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/oke.Visio/unary.jpg
  • Binary degree (derajat dua) dan
Bila satu relasi menghubugkan dua entity, digambarkan sebagai berikut :
http://mugi.or.id/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/oke.Visio/binary.jpg

  • Ternary degree (derajat tiga)
Bila satu entity menghubungkan lebih dari dua entity. Digambarkan sebagai berikut :
http://mugi.or.id/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/oke.Visio/ternary.jpg

Cardinality Ratio Constraint

Berfungsi untuk menjelaskan jumlah hubungan/relationship dari entity-entity yang berpastisipasi.  Terdapat 3 macam CRC yaitu :
  • Hubungan 1 : 1 (One to One Relationship)
Yaitu suatu entity yang berada di himpunan A berhubungan dengan paling banyak dengan satu entity pada himpunan B, dan entity pada himpunan B berhubungan dengan paling banyak satu entity di himpunan A, digambarkan sebagai :
http://mugi.or.id/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/oke.Visio/onetoone.jpg
  • Hubungan 1 : M (One to Many/Many to One Relationship)
Yaitu suatu entity pada himpunan A dapat berhubungan dengan sejumlah entity pada himpunan B, tetapi entity yang berada pada himpunan B hanya dapat berhubungan dengan hanya satu entity dari himpunan A atau sebaliknya.  Digambarkan sebagai :
http://mugi.or.id/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/oke.Visio/1tomany.jpg      http://mugi.or.id/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/oke.Visio/manyto1.jpg
  • Hubungan M : N (Many to Many Relationship)
             Yaitu suatu entity yang berada di himpunan A dapat berhubungan dengan banyak entity di himpunan B, dan sebaliknya. Digambarkan sebagai :
http://mugi.or.id/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/oke.Visio/manytomany.jpg

 Notasi Bentuk Lain

Bentuk lain dari Cardinality Ratio Constraint dapat ditunjukan dalam beberapa bentuk hubungan antar entitas ke entitas, entitas ke relationship, maupun sebaliknya yang digambarkan sebagai berikut :
Simbol
Uraian
Simbol
Uraian
 http://mugi.or.id/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/oke.Visio/11.jpg
 Hubungan satu ke satu
 http://mugi.or.id/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/oke.Visio/14.jpg
Hubungan satu
(optional)
 http://mugi.or.id/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/oke.Visio/12.jpg
 Hubungan satu atau lebih
 http://mugi.or.id/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/oke.Visio/15.jpg
Hubungan many
(optional)
http://mugi.or.id/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/oke.Visio/13.jpg
Hubungan many


 Participation Constraint

Berfungsi untuk menjelaskan keberadaan suatu entity yang tergantung dengan entitas lainnya.  Terdapat dua macam Participation Constraint yaitu
  • Total Participation
               Yaitu keberadaan suatu entity tergantung pada entity lain, yang digambarkan dengan dua garis penghubung antara entity dengan relationshipnya.
  • Partial Participation
                Dimana keberadaan suatu entity tidak tergantung pada entity lain, digambarkan cukup dengan satu garis penghubung.

Weak Entity

Suatu entity yang mungkin memiliki suatu atribut yang bukan miliknya, dimana keberadaannya tergantung dari entity lain.  Entity lain tersebut dikatakan sebagai Identifying Owner dan relationshipnya dinamakan Identifying Relationship.  Weak entity selalu memiliki Total Participation Constraint dengan Identifying Owner.

Entity Relationship (E-R) Diagram

 Entity-Relationship Diagram melengkapi penggambaran grafik dari struktur logika, dengan kata lain E-R diagram menggambarkan arti dari aspek data seperti bagaimana entity-entity, atribute-atribute dan relationship-relationship disajikan.  Langkah-langkah pembuatan E-R Diagram :
  1. Tentukan entity-entity yang diperlukan disesuaikan dengan permintaan pemakai;
  2. Tentukan relationship antar entity-entity;
  3. Tentukan Cardinality ratio dan Participation Constraints
  4. Tentukan atribut-atribut yang diperlukan dari setiap entity
  5. Tentukan primary key diantara atribut-atribut
  6. Buatlah penamaan entity, atribut dan relationship yang unik, dan hindari penamaan yang sama untuk objek yang berbeda

 Penggunaan Model E-R dalam Perancangan Database

Model E-R sangat berperan penting dalam perancangan database, Model ini digunakan pada tahap Conceptual Design, yaitu tahap kedua dari perancangan database.  Tahapan pertama adalah pengumpulan dan analisa permintaan dari pemakai, tahap kedua dilakukan penerapan conceptual design dimana model E-R ini digunakan, pada tahap ini data disajikan dalam bentuk diagram. 
Dengan penggunaan diagram ini, dapat terlihat jelas hubungan entity dengan entity dan atribut yang diperlukan di dalam suatu entity.  Tahapan berikutnya adalah logical design, dalam tahap ini diagram E-R ditransformasikan ke dalam bentuk database, dengan sebelumnya ditentukan dahulu model database apa yang dipilih.  Tahap akhir dari perancangan database adalah tahap physical design, yaitu tahap untuk menentukan organisasi file dari database dan mendefinisikan penyimpanan data secara fisik.  Tahapan-tahapan ini digambarkan sebagai berikut :
 http://mugi.or.id/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/oke.Visio/konseptual.jpg

Perancangan Entity Relationship dengan bantuan program Microsoft Visio 2007

     Merancang model E-R dalam praogram aplikasi seperti Microsoft Visio 2007 dapat menggunakan 2 cara yaitu :
  1. Dengan bantuan shape Basic Flowchart
  2. Dengan bantuan shape Database Model Diagram

 Basic Flowchart

 Pada visio penggunaan shape basic flowchart dapat membantu untuk merancang suatu E-R diagram dengan cepat yang tata cara penggunaannya sebagai berikut :
  1. Pada menu File pilihlah NewGetting Started .. untuk memilih template categories yang dikehendaki
  2. Setelah menu Template Categories muncul pilihlah Flowchart template klik icon Basic Flowchart, klik Create
  3. Pilihan simbol yang sesuai dengan icon shape adalah sebagai berikut :
 
Simbol E-R
Nama
Icon Pada Basic Flowchart
http://mugi.or.id/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/oke.Visio/entitas.jpg
Entitas
Process
http://mugi.or.id/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/oke.Visio/relationship.jpg
relationship
Decision
http://mugi.or.id/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/oke.Visio/atribut.jpg
Atribut
Terminator
http://mugi.or.id/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/oke.Visio/atribut.jpg
Key Atribut
Terminator dengan menggunakan underlin

Adapun contoh dari E-R diagram yang menggambarkan database suatu perusahaan dapat digambarkan dengan bantuan basic flowchart adalah sebagai berikut :
http://mugi.or.id/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/oke.Visio/er1.jpg





Model dari E-R diagram tersebut di atas dapat juga di buat dalam bentuk notasi lain seperti yang diterangkan sebelumnya, yaitu dengan menggambarkan suatu relationship antar entity ke entity lain, yang menggambarkan suatu E-R dari sistem e-commerce yang digambarkan sebagai berikut :

http://mugi.or.id/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/oke.Visio/er2.jpg
























Refrensi :

1.       Mengenal Entity Relationships Diagram dan Implementasinya di Visio, Oke Hendradhy

2.       Silberschatz,et al. 2003. Operating system Concept. John Willey & Sons,Inc.
3.       Kadir, Abdul. Pemrograman Dasar Cobol untuk IBM PC. Yogyakarta: ANDI, 1991.
4.       mti.ugm.ac.id
5.       en.wikipedia.org


Tidak ada komentar:

Poskan Komentar