Kamis, 24 November 2011

MAKALAH TENTANG SISTEM TERSTRUKTUR ERD DAN DFD


Daftar Isi

BAB I PENDAHULUAN………………………………….……………………..............
Tahapan Rencana Pendahuluan  ………………………………………..……………......  1
Tahapan Analisis Sistem ……………………………………………………………. 2

BAB II ISI…………………………………………………………………….........         
 Pengertian ER .....................…………………………………..…..........            2
Komponen-komponen ERD ……………..…….........................................           3
Pengertian DFD ................................…………………………………….          3
            Komponen-komponen DFD ……………………………………………..            3
BAB III PENUTUP……………………………………………………………..          
            Daftar pustaka……………………………………………………....            ………            4









Tahapan Rencana Pendahuluan



Tahapan rencana pendahuluan adalah dengan
menentukan lingkup sistem yang akan ditangani yang
dijabarkan dalam bentuk DFD (Data Flow Diagram)
konteks atau diagram konteks. DFD adalah representasi
grafik dari sebuah sistem yang menggambarkan
komponen-komponen sebuah sistem, aliran-aliran data di
antara komponen-komponen yang ada, asal, tujuan dan
penyimpanan data sebagai sebuah proses. Tujuan DFD
konteks untk memberikan pandangan umum sistem yang
berinteraksi dengan lingkungan.














Tahapan Analisis Sistem




Analisis sistem merupakan penjabaran lebih
detail dari DFD konteks yang disebut sebagai DFD
analisis atau DFD model. Pada tahap ini diperoleh
informasi detail tentang kebutuhan pengguna sistem
informasi yang nantinya dipakai sebagai bahan untuk
menyusun DFD sistem baru.










Pengertian ERD


- ERD (Entity Relationship Diagram) adalah gambaran mengenai berelasinya antarentitas.
- Sistem adalah kumpulan elemen yang setiap elemen memiliki fungsi masing-masing dan secara bersama-sama mencapai tujuan dari sistem tersebut.
- ‘Kebersama-sama’-an dari sistem di atas dilambangkan dengan saling berelasinya antara satu entitas dengan entitas lainnya
- Entitas (entity/ entity set), memiliki banyak istilah di dalam ilmu komputer, seperti tabel (table), berkas (data file), penyimpan data (data store), dan sebagainya










Komponen-komponen ERD
1.  Entitas dan Atribut
- Entitas adalah tempat penyimpan data, maka entitas yang digambarkan  dalam ERD ini merupakan data store yang ada di DFD dan akan menjadi file data di komputer
- Entitas adalah suatu objek dan memiliki nama. Secara sederhana dapat dikatakan bahwa jika objek ini tidak ada di suatu enterprise (lingkungan tertentu), maka enterprise tersebut tidak dapat berjalan  normal.
- Contoh, entitas ‘MAHASISWA’ harus ada di lingkungan perguruan tinggi, begitu juga dengan entitas ‘DOSEN’, ‘MT_KULIAH’, dan sebagainya
- Di dalam entitas ‘MAHASISWA’ berisi elemen-elemen data (biodata mahasiswa) yang terdiri atas NPM, NAMA, KELAS, ALAMAT, dan sebagainya. NPM, NAMA, KELAS, dan ALAMAT disebut dengan atribut (field)
- Gambar memperlihatkan bahwa atribut-atribut NPM, NAMA, ALAMAT, dan TGL_LAHIR harus ada di dalam biodata seorang mahasiswa.
- Atribut-atribut TINGGI_BADAN, dan WARNA_RAMBUT adalah atribut-atribut yang boleh tidak ada di dalam biodata mahasiswa (karena tidak penting).
- Sedangkan atribut NAMA_DOSEN adalah atribut yang tidak boleh ada di entitas mahasiswa
- Pada akhirnya, entitas ini akan menjadi file data (yang bersifat master file) di dalam komputer. Master file adalah file utama (yang harus ada, dan sifatnya jarang berubah)
2. Relasi
- Relasi adalah penghubung antara satu entitas (master file) dengan entitas lain di dalam sebuah sistem komputer. Pada akhirnya, relasi akan menjadi file transaksi (transaction file) di komputer
- Secara kalimat logis, contoh relasi yang terjadi di sebuah perpustakaan adalah : “Anggota meminjam buku,” atau “Anggota mengembalikan buku.” Dalam hal ini, Anggota dan Buku adalah entitas, meminjam dan mengembalikan adalah transaksi (relasi antara anggota dan buku).



















Pengertian DFD


Data flow Diagram (DFD) adalah diagram yang menggunakan notasi-notasi untuk menggambarkan arus dari sistem. DFD sering digunakan untuk menggambarkan sustu sistem yang telah ada atau sistem baru yang akan dikembangkan secara logika tanpa mempertimbangkan lingkungan fisik dimana data tersebut mengalir (misalnya lewat telpon, surat, dan sebagainya) atau lingkungan fisik dimana data tersebut akan disimpan (misalnya file kartu, harddisk, tape, diskette, dan lain sebagianya).
Simbol-sombol yang digunakan di DFD mewakili maksud tertentu, yaitu:
1. External entity (kesatuan Luar) atau boundary (batas sistem)
Setiap sistem pasti memiliki batas sistem  (boundary) yang memisahkan suatu sistem dengan lingkungan luarnya. Kesatuan luar (external entity) merupakan kesatuan di lingkungan luar sistem yang dapat berupa orang, organisasi atau sistem lainya yang berada di lingkungan luarnya yang memberikan input atau menerima output dari sistem.


atau

2. Data flow (arus data)
Arus  data di DFD diberi simbol panah. Arus data ini mengalir diantara proses, simpanan, dan kesatuan luar.

3. Process (proses)
Suatu proses adalah kegiatan atau kerja yang dilakukan oleh orang, mesin atau komputer dari hasil suatu arus data yang masuk ke dalam proses untuk dihasilkan arus data yang akan keluar dari proses.

atau

4. Data store (simpanan data)
Simpanan data (data store) merupakan simpanan dari  data yang dapat berupa suatu file atau database di komputer, suatu arsip atau catatan manual dan lain sebagainya.












Komponen-komponen DFD


















DAFTAR PUSTAKA

MAKALAH TENTANG UML


Daftar Isi

BAB I PENDAHULUAN………………………………….……………………..............
            Definisi …….……………………………………………………..……………...... 1

BAB II ISI…………………………………………………………………….........         
            Bagian – bagian UML …………………………………………………..…..........   2
Tujuan UML……………………………………..…….........................................    3
            Langkah-langkah UML………………………………………………………….     3
            Tool UML………………………………………………………………………..     3
BAB III PENUTUP……………………………………………………………..          
            Daftar pustaka……………………………………………………....                        4








Unified Modeling Language (UML)


1.  Pendahuluan Dan Definisi

Unified Modeling Language (UML) adalah bahasa spesifikasi standar untuk mendokumentasikan, menspesifikasikan, dan membangun system.

Unified Modeling Language (UML)  adalah himpunan struktur dan teknik untuk pemodelan desain program berorientasi objek (OOP) serta aplikasinya. UML  adalah metodologi untuk mengembangkan sistem OOP dan sekelompok perangkat tool untuk mendukung pengembangan sistem tersebut. UML mulai diperkenalkan oleh Object Management Group, sebuah organisasi yang telah mengembangkan model, teknologi, dan standar OOP sejak tahun 1980-an. Sekarang UML  sudah mulai banyak digunakan oleh para praktisi OOP. UML  merupakan dasar bagi perangkat (tool) desain berorientasi objek dari IBM.


UML  adalah suatu bahasa yang digunakan untuk menentukan, memvisualisasikan, membangun, dan mendokumentasikan suatu sistem informasi. UML dikembangkan sebagai suatu alat untuk analisis dan desain berorientasi objek oleh Grady Booch, Jim Rumbaugh, dan Ivar Jacobson Namun demikian UML dapat digunakan untuk memahami dan mendokumentasikan setiap sistem informasi. Penggunaan UML dalam industri terus meningkat.  Ini merupakan standar terbuka yang menjadikannya sebagai bahasa pemodelan yang umum dalam industri peranti lunak dan pengembangan sistem. Singkatnya  Unified Modelling Language (UML) adalah sebuah “bahasa” yg telah menjadi standar dalam industri untuk visualisasi, merancang dan mendokumentasikan sistem piranti lunak. UML menawarkan sebuah standar untuk merancang model sebuah sistem.

Sampai era tahun 1990 puluhan metodologi pemodelan berorientasi objek telah bermunculan di dunia. Diantaranya adalah: metodologi booch, metodologi coad, metodologi OOSE, metodologi OMT, metodologi shlaer-mellor, metodologi wirfs-brock, dsb. Masa itu terkenal dengan masa perang metodologi (method war) dalam pendesainan berorientasi objek. Masing-masing metodologi membawa notasi sendiri-sendiri, yang mengakibatkan timbul masalah baru apabila kita bekerjasama dengan kelompok/perusahaan lain yang menggunakan metodologi yang berlainan.

Dimulai pada bulan Oktober 1994 Booch, Rumbaugh dan Jacobson, yang merupakan tiga tokoh yang boleh dikata metodologinya banyak digunakan mempelopori usaha untuk penyatuan metodologi pendesainan berorientasi objek. Pada tahun 1995 direlease draft pertama dari UML (versi 0.8). Sejak tahun 1996 pengembangan tersebut dikoordinasikan oleh Object Management Group (OMG ).


Bagian-bagian UML

Bagian-bagian utama dari UML adalah view, diagram, model element, dan general mechanism.

a. View

View digunakan untuk melihat sistem yang dimodelkan dari beberapa aspek yang

berbeda. View bukan melihat grafik, tapi merupakan suatu abstraksi yang berisi

sejumlah diagram.

Beberapa jenis view dalam UML antara lain: use case view, logical view, component view, concurrency view, dan deployment view.

·         Use case view

Mendeskripsikan fungsionalitas sistem yang seharusnya dilakukan sesuai yang diinginkan external actors. Actor yang berinteraksi dengan sistem dapat berupa user atau sistem lainnya.

View ini digambarkan dalam use case diagrams dan kadang-kadang dengan activity diagrams. View ini digunakan terutama untuk pelanggan, perancang (designer), pengembang (developer), dan penguji sistem (tester).

·         Logical view

Mendeskripsikan bagaimana fungsionalitas dari sistem, struktur statis (class, object,dan relationship ) dan kolaborasi dinamis yang terjadi ketika object mengirim pesan ke object lain dalam suatu fungsi tertentu.

View ini digambarkan dalam class diagrams untuk struktur statis dan dalam state, sequence, collaboration, dan activity diagram untuk model dinamisnya. View ini digunakan untuk perancang (designer) dan pengembang (developer).

·         Component view

Mendeskripsikan implementasi dan ketergantungan modul. Komponen yang merupakan tipe lainnya dari code module diperlihatkan dengan struktur dan ketergantungannya juga alokasi sumber daya komponen dan informasi administrative lainnya.

View ini digambarkan dalam component view dan digunakan untuk pengembang (developer).

·         Concurrency view

Membagi sistem ke dalam proses dan prosesor. View ini digambarkan dalam diagram dinamis (state, sequence, collaboration, dan activity diagrams) dan diagram implementasi (component dan deployment diagrams) serta digunakan untuk pengembang (developer), pengintegrasi (integrator), dan penguji (tester).


·         Deployment view

Mendeskripsikan fisik dari sistem seperti komputer dan perangkat (nodes) dan bagaimana hubungannya dengan lainnya.

View ini digambarkan dalam deployment diagrams dan digunakan untuk pengembang (developer), pengintegrasi (integrator), dan penguji (tester).


b. Diagram

Diagram berbentuk grafik yang menunjukkan simbol elemen model yang disusun untuk mengilustrasikan bagian atau aspek tertentu dari sistem. Sebuah diagram merupakan bagian dari suatu view tertentu dan ketika digambarkan biasanya dialokasikan untuk view tertentu. Adapun jenis diagram antara lain :

·         Use Case Diagram

Use case adalah abstraksi dari interaksi antara system dan actor. Use case bekerja dengan cara mendeskripsikan tipe interaksi antara user sebuah system dengan sistemnya sendiri melalui sebuah cerita bagaimana sebuah system dipakai. Use case merupakan konstruksi untuk mendeskripsikan bagaimana system akan terlihat di mata user. Sedangkan use case diagram memfasilitasi komunikasi diantara analis dan pengguna serta antara analis dan client.

·         Class Diagram

Class adalah dekripsi kelompok obyek-obyek dengan property, perilaku (operasi) dan relasi yang sama. Sehingga dengan adanya class diagram dapat memberikan pandangan global atas sebuah system. Hal tersebut tercermin dari class- class yang ada dan relasinya satu dengan yang lainnya. Sebuah sistem biasanya mempunyai beberapa class diagram. Class diagram sangat membantu dalam visualisasi struktur kelas dari suatu system.

Class memiliki  tiga area pokok :

1.Nama  (dan stereotype)
2. Atribut
3. Metoda

Atribut dan metoda dapat memiliki salah satu sifat berikut :

-          Private, tidak dapat dipanggil dari luar class yang bersangkutan

-          Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak yang mewarisinya

-          Public, dapat dipanggil oleh siapa saja


·         Component Diagram

Component software merupakan bagian fisik dari sebuah system, karena menetap di komputer tidak berada di benak para analis. Komponent merupakan implementasi software dari sebuah atau lebih class. Komponent dapat berupa source code, komponent biner, atau executable component. Sebuah komponent berisi informasi tentang logic class atau class yang diimplementasikan sehingga membuat pemetaan dari logical view ke component view. Sehingga component diagram merepresentasikan dunia riil yaitu component software yang mengandung component, interface dan relationship.


·         Deployment Diagram

Menggambarkan tata letak sebuah system secara fisik, menampakkan bagian-bagian software yang berjalan pada bagian-bagian hardware, menunjukkan hubungan komputer dengan perangkat (nodes) satu sama lain dan jenis hubungannya. Di dalam nodes, executeable component dan object yang dialokasikan untuk memperlihatkan unit perangkat lunak yang dieksekusi oleh node tertentu dan ketergantungan komponen.

·         State Diagram

Menggambarkan semua state (kondisi) yang dimiliki oleh suatu object dari suatu class dan keadaan yang menyebabkan state berubah. Kejadian dapat berupa object lain yang mengirim pesan. State class tidak digambarkan untuk semua class, hanya yang mempunyai sejumlah state yang terdefinisi dengan baik dan kondisi class berubah oleh state yang berbeda.


·         Sequence Diagram
Sequence Diagram digunakan untuk menggambarkan perilaku pada sebuah scenario. Kegunaannya untuk menunjukkan rangkaian pesan yang dikirim antara object juga interaksi antara object, sesuatu yang terjadi pada titik tertentu dalam eksekusi sistem.

·         Collaboration Diagram

Menggambarkan kolaborasi dinamis seperti sequence diagrams. Dalam menunjukkan pertukaran pesan, collaboration diagrams menggambarkan object dan hubungannya (mengacu ke konteks). Jika penekannya pada waktu atau urutan gunakan sequencediagrams, tapi jika penekanannya pada konteks gunakan collaboration diagram.

·         Activity Diagram

Menggambarkan rangkaian aliran dari aktivitas, digunakan untuk mendeskripsikan aktifitas yang dibentuk dalam suatu operasi sehingga dapat juga digunakan untuk aktifitas lainnya seperti use case atau interaksi.


Tujuan Penggunaan UML

a. Memberikan bahasa pemodelan yang bebas dari berbagai bahas pemrograman dan proses rekayasa.

b. Menyatukan praktek-praktek terbaik yang terdapat dalam pemodelan.

c. Memberikan model yang siap pakai, bahsa pemodelan visual yang ekspresif untuk mengembangkan dan saling menukar model dengan mudah dan dimengerti secara umum.

d. UML bisa juga berfungsi sebagai sebuah (blue print) cetak biru karena sangat lengkap dan detail. Dengan cetak biru ini maka akan bias diketahui informasi secara detail tentang coding program atau bahkan membaca program dan menginterpretasikan kembali ke dalam bentuk diagram (reserve enginering).



Langkah-Langkah Penggunaan UML


Berikut ini adalah tips pengembangan piranti lunak dengan menggunakan UML:
1. Buatlah daftar business process dari level tertinggi untuk mendefinisikan aktivitas dan proses yang mungkin muncul.
2. Petakan use case untuk tiap business process untuk mendefinisikan dengan tepatfungsionalitas yang harus disediakan oleh sistem. Kemudian perhalus use case diagram danlengkapi dengan requirement, constraints dan catatan-catatan lain.
3. Buatlah deployment diagram secara kasar untuk mendefinisikan arsitektur fisik sistem.
4. Definisikan requirement lain (non-fungsional, security dan sebagainya) yang juga harus disediakan oleh sistem.
5. Berdasarkan use case diagram, mulailah membuat activity diagram.
6. Definisikan objek-objek level atas (package atau domain) dan buatlah sequence dan/atau collaboration diagram untuk tiap alir pekerjaan. Jika sebuah use case memiliki kemungkinan alir normal dan error, buatlah satu diagram untuk masing-masing alir.
7. Buarlah rancangan user interface model yang menyediakan antarmuka bagi pengguna untuk menjalankan skenario use case.
8. Berdasarkan model-model yang sudah ada, buatlah class diagram. Setiap package atau domain dipecah menjadi hirarki class lengkap dengan atribut dan metodanya. Akan lebih baik jika untuk setiap class dibuat unit test untuk menguji fungsionalitas class dan interaksi dengan class lain.
9. Setelah class diagram dibuat, kita dapat melihat kemungkinan pengelompokan class menjadi komponen-komponen. Karena itu buatlah component diagram pada tahap ini. Juga,definisikan tes integrasi untuk setiap komponen meyakinkan ia berinteraksi dengan baik.
10. Perhalus deployment diagram yang sudah dibuat. Detilkan kemampuan dan requirement piranti lunak, sistem operasi, jaringan, dan sebagainya. Petakan komponen ke dalam node.
11. Mulailah membangun sistem. Ada dua pendekatan yang dapat digunakan :
  Pendekatan use case, dengan meng-assign setiap use case kepada tim pengembang tertentu untuk mengembangkan unit code yang lengkap dengan tes.
  Pendekatan komponen, yaitu meng-assign setiap komponen kepada tim pengembang tertentu.
12. Lakukan uji modul dan uji integrasi serta perbaiki model berserta codenya.  
Model harus selalu sesuai dengan code yang aktual.
13. Piranti lunak siap dirilis.

Tool Yang Mendukung UML

Saat ini banyak sekali tool pendesainan yang mendukung UML, baik itu tool komersial maupun
opensource. Beberapa diantaranya adalah:
• Rational Rose (www.rational.com)
• Together (www.togethersoft.com)
• Object Domain (www.objectdomain.com)
• Jvision (www.object-insight.com)
• Objecteering (www.objecteering.com)
• MagicDraw (www.nomagic.com/magicdrawuml)
• Visual Object Modeller (www.visualobject.com)








DAFTAR PUSTAKA

Perbedaan Sistem Berorientasi Object dan Sistem Terstruktur

 KATA PENGANTAR
Puji dan Syukur Penulis Panjatkan ke Hadirat Tuhan Yang Maha Esa karena berkat limpahan Rahmat dan Karunia-Nya sehingga penulis dapat menyusun makalah ini tepat pada waktunya. Makalah ini membahas mengenai “Perbedaan Sistem Berorientasi Object dan Sistem Terstruktur”.
Dalam penyusunan makalah ini, penulis banyak mendapat tantangan dan hambatan akan tetapi dengan bantuan dari berbagai pihak tantangan itu bisa teratasi. Olehnya itu, penulis mengucapkan terima kasih yang sebesar-besarnya kepada semua pihak yang telah membantu dalam penyusunan makalah ini, semoga bantuannya mendapat balasan yang setimpal dari Tuhan Yang Maha Esa.
Penulis menyadari bahwa makalah ini masih jauh dari kesempurnaan baik dari bentuk penyusunan maupun materinya. Kritik konstruktif dari pembaca sangat penulis harapkan untuk penyempurnaan makalah selanjutnya.
Akhir kata semoga makalah ini dapat memberikan manfaat kepada kita sekalian.


                                                                                                                     Penyusun

Irena herningtyas irianti










DAFTAR ISI

Kata Pengantar           ……………………………………………………………    2
Daftar Isi                     ……………………………………………………………    3
BAB 1 - Pengertian Pemrograman Berorientasi Objek          ……………………    4-5
BAB 2 - Pengertian Pemrograman Terstruktur           ……………………………    6-8
            -Bahasa Pemogramaan …………………………………………………..     9
BAB 3 Kesimpulan     ……………………………………………………………    10
Daftar Pustaka                        ……………………………………………………………    11















BAB 1

Pengertian Pemrograman Berorientasi Objek

Pemrograman berorientasi objek (Inggris: object-oriented programming disingkat OOP) merupakan paradigma pemrograman yang berorientasikan kepada objek. Semua data dan fungsi di dalam paradigma ini dibungkus dalam kelas-kelas atau objek-objek. Bandingkan dengan logika pemrograman terstruktur. Setiap objek dapat menerima pesan, memproses data, dan mengirim pesan ke objek lainnya.
Analisis dan disain berorientasi objek adalah cara baru dalam memikirkan suatu masalah dengan menggunakan model yang dibuatmenurut konsep sekitar dunia nyata. Dasar pembuatan adalah objek yang merupakan kombinasi antara struktur data dan perilaku dalam
satu entitas. Pengertian "berorientasi objek" berarti bahwa kita mengorganisasi
perangkat lunak sebagai kumpulan dari objek tertentu yang memiliki
struktur data dan perilakunya.

Karakteristik dari Objek

Objek
�� Identitas berarti bahwa data diukur mempunyai nilai tertentu yang
membedakan entitas disebut Objek.
�� Objek dapat kongkrit, seperti halnya arsip dalam sistem, atau
konseptual seperti kebijakan penjadualan dalam multiprocessing
pada sistem operasi.
�� Setiap objek mempunyai sifat yang melekat pada identitasnya.
�� Dua objek dapat berbeda walaupun bila semua nilai atributnya
identik.
Kelas Objek
�� Kelas merupakan gambaran sekumpulan Objek yang terbagi
dalam atribut, operasi, metode, hubungan, dan makna yang
sama.
�� Suatu kegiatan mengumpulkan data (atribut) dan perilaku
(operasi) yang mempunyai struktur data sama ke dalam satu grup.
�� Kelas Objek merupakan wadah bagi Objek. Dapat digunakan
untuk menciptakan Objek.
�� Objek mewakili fakta/keterangan dari sebuah kelas
Istilah-istilah Objek
�� Atribut : Data item yang menegaskan Objek
�� Operasi : Fungsi di dalam kelas yang dikombinasikan ke bentuk
tingkah laku kelas
�� Metode : Pelaksanaan prosedur (badan dari kode yang
mengeksekusi respon terhadap permintaan objek lain di
dalam sistem).











Pengertian Pemrograman Terstruktur

Paradigma pemrograman adalah pandangan mendasar terkait tentang formulasi sebuah solusi dalam bahasa pemrograman. Paradigma pemrograman menjelaskan tentang perspektif/pandangan pemrogram tentang program yang akan dibuatnya. Saat ini terdapat dua jenis paradigm pemrograman yaitu pemrogram berbasis object (OOP) dan pemrograman terstruktur. Dari kedua jenis paradigm ini yang sering digunakan saat ini adalah pemrograman berbasis object. Model data berorientasi objek dapat dikatakan memberi fleksibilitas yang lebih, kemudahan mengubah program, dan digunakan luas dalam teknik piranti lunak skala besar. Lebih jauh lagi, pendukung OOP mengklaim bahwa OOP lebih mudah dipelajari bagi pemula dibanding dengan pendekatan sebelumnya, dan pendekatan OOP lebih mudah dikembangkan dan dirawat.
Pemrograman terstruktur adalah suatu proses untuk mengimplementasikan urutan langkah untuk menyelesaikan suatu masalah dalam bentuk program. Paradigma ini pertama kali diungkapkan oleh Professor Edsger Djikstra dari Universitas Eindhoven sekitar tahun 1965. Prinsip dari pemrograman terstruktur adalah bahwa Apabila kita sudah sampai pada langkah tertentu, kita tidak boleh mengeksekusi langkah sebelumnya. Hal ini dikecualikan pada langkah-langkah untuk proses berulang. Sedangkan pemrograman berbasis obyek (OOP) mendasarkan pada konsep object dan interaksinya. Pada jenis paradigm ini, program bukan urut-urutan instruksi tapi diselesaikan oleh obyek-obyek yang bekerjasama untuk menyelesaikan masalah. OO sebagai tool untuk memodelkan sistem di dunia nyata (tujuan bahasa Simula-67) setiap sistem selalu dapat digambarkan melalui object-object penyusunnya dan bagaimana object-object tersebut saling berinteraksi.
Tujuan Pemrograman Terstruktur Tujuan dari pemrograman terstruktur dapat diuraikan sebagai berikut :
a. Untuk meningkatkan kualitas dan kehandalan program
b. Untuk memudahkan pemahaman terhadap isi program
c. Untuk menyederhanakan program

d. Untuk maintenance (pemeliharaan) program

e. Untuk meningkatkan produktifitas program Sifat-sifat Pemrograman Terstruktur

Sifat-sifat dari pemrograman terstruktur dapat diuraikan sebagai berikut :

a. Memuat teknik pemecahan masalah yang logis dan sistematis

b. Memuat algoritma yang efisien, efektif dan sederhana

c. Program disusun dengan logika yang mudah dipahami

d. Tidak menggunakan perintah GOTO

e. Biaya pengujian program relatif rendah

f. Memiliki dokumentasi yang baik

g. Biaya perawatan dan dokumentasi yang dbuthkan relatif rendah

Terdapat beberapa langkah pemrograman terstruktur yaitu : identifikasi masalah, analisis kebutuhan pengguna, penyusunan dan disain algoritma, coding, penyusunan program, evaluasi error, dokumentasi, dan pemeliharaan program. Identifikasi masalah dilakukan untuk memperoleh pemahaman mengenai permasalahan yang ada. Melalui pemahaman ini diharapkan dapat ditemukan solusi optimal dalam memecahkan permasalahan tersebut. Analisis kebutuhan dalam hal ini adalah menentukan spesifikasi fungsi dan fasilitas yang akan diimplementasikan pada program. Analisis kebutuhan pengguna sangat penting dilakukan karena program sepenuhnya disusun untuk memberikan solusi permasalahan pengguna. Analisis kebutuhan dilakukan untuk mengetahui siapa yang akan menggunakan program, apa saja yang akan ditampilkan dan lain-lain. Coding adalah penerjemahan algoritma kedalam kode program. Bahasa pemrograman merupakan jembatan yang menghubungkan manusia dengan komputer. Testing merupakan tahap yang paling penting dalam penyusunan program. Pada tahap ini diharapkan tidak terdapat error sehingga program tidak dapat digunakan, dan permasalahan tidak terpecahkan. Dokumentasi merupakan informasi tambahan untuk lenih memahami kode-kode yang disusun.
Berbeda dengan OOP. Suatu program disebut dengan pemrograman berbasis obyek (OOP) karena terdapat :

–  Encapsulation (pembungkusan) Encapsulation adalah mekanisme pemrograman yang membungkus kode dan data yang dimanipulasi dan menjaganya supaya terhindar dari interferensi dan penggunaan yang tidak perlu. Salah satu caranya dengan membentuk objek.
–  Inheritance (pewarisan) Inheritance memungkinkan programer meletakkan member yang sama dalam satu class dan class-class lain dapat mewarisi member tersebut. Class yang mengandung member yang sama dari beberapa class lain dinamakan superclass atau parent class. Class yang mewarisi dinamakan subclass atau child class. Inheritance menghasilkan class hierarchy.
–  Polymorphism (polimorfisme –perbedaan bentuk) Polymorphisme artinya mempunyai banyak bentuk. Dua objek atau lebih dikatakan sebagai polymorphic, bila objek-objek itu mempunyai antar muka yang identik namun mempunyai perilaku-perilaku yang berbeda
Kelebihan OO Sebagai Model Representasi
•Natural: mengikuti cara berpikir manusia (manusia memandang dunianya sebagai kumpulan object yang berinteraksi)
•Abstraksi: menjelaskan makna sebuah entitas secara cepat dan mudah

•Enkapsulasi: dapat menyembunyikan detil yang tidak perlu

•Modular: object adalah entitas yang independen

Beda nyata antara prosedural dan OOP

• Prosedural Fokus pada bagaimana cara komputer menangani masalah

• OOP Fokus pada masalah yang ditangani dengan menggunakan computer

        Tetapi, tidak ada jawaban yang benar-benar tepat jika Anda diberi pertanyaan: apakah 
sebaiknya menggunakan OOP atau Procedural Programming? Karena jawabannya sangat relatif, terutama tergantung pada aplikasi yang ingin dibuat. Jika mempertimbangkan pemeliharaan dan pengembangan aplikasi yang eļ¬sien di masa yang akan datang, mungkin dapat memilih pendekatan OOP. Tetapi, jika aplikasi tersebut merupakan program sederhana yang dapat dibuat dengan mudah dan cepat dengan function/procedure, gunakanlah pendekatan Procedural Programming. Pada pemrograman terstruktur, jika ingin membuat perubahan maka harus diubah dari awal karena ada yang namanya variable global dan variable local. Hal itu juga dapat menimbulkan kesulitan dalam mencari error. Semua itu juga tergantung pada Anda sebagai programer, untuk memilih pendekatan yang cocok dan lebih baik bagi Anda dalam mengerjakan sebuah aplikasi.
Kembali pada perbandingan antara OOP dengan Procedural Programming, keduanya memiliki struktur yang baik untuk membuat sebuah aplikasi, di mana OOP menekankan pada penggunaan object sementara Procedural Programming menekankan pada penggunaan function/procedure. Anda dapat melihat persamaannya, yaitu diperlukan kemampuan untuk menuliskan kode program secara terstruktur dan rapi, yang sangat penting untuk pembuatan aplikasi yang membutuhkan team work yang baik, ataupun untuk pengembangan aplikasi di masa yang akan datang.


Bahasa pemrograman
Bahasa pemrograman yang mendukung OOP antara lain:
  1. Visual Foxpro
  2. Java
  3. C++
  4. Pascal (bahasa pemrograman)
  5. Visual Basic.NET
  6. SIMULA
  7. Smalltalk
  8. Ruby
  9. Python
  10. PHP
  11. C#
  12. Delphi
  13. Eiffel
  14. Perl
  15. Adobe Flash AS 3.0













BAB 3
Kesimpulan
Pemrograman berorientasi objek (Inggris: object-oriented programming disingkat OOP) merupakan paradigma pemrograman yang berorientasikan kepada objek. Semua data dan fungsi di dalam paradigma ini dibungkus dalam kelas-kelas atau objek-objek. Bandingkan dengan logika pemrograman terstruktur. Setiap objek dapat menerima pesan, memproses data, dan mengirim pesan ke objek lainnya.
Pemrograman Terstruktur adalah suatu proses untuk mengimplementasikan urutan langkah untuk menyelesaikan suatu masalah dalam bentuk program.
Selain pengertian diatas Pemrograman Terstruktur adalah suatu aktifitas pemrograman dengan memperhatikan urutan langkah-langkah perintah secara sistematis, logis , dan tersusun berdasarkan algoritma yang sederhana dan mudah dipahami.











Daftar pustaka
Abdul Kadir, Dasar Perancangan Dan Implementasi Database Relasional
Yogyakarta:Penerbit Andi. 2008Hariyanto, Bambang Ir, MT,
System Manajemen Basis Data, Pemodelan, Perancangan Dan Terapannya
Bandung: Penerbit informatika. 2004Kadir, Abdul.
Catatan Kuliah Analisis dan Perancangan Sistem
Wahana Komputer.
 Menjadi Seorang Programmer Komputer, Penerbit ANDI.
Sri Dharwiyanti (2003), Pengantar Unified Modeling Language (UML), IlmuKomputer.Com.
Ir. M. FARID AZIS, M. Kom, Object Oriented Programming Php 5, halaman 118.Elex Media Komputindo.
Julius Hermawan, Analisa Desain & Pemrograman Berorientasi Obyek dengan UML dan Visual Basic.NET. ANDI dan Art