Kemacetan di Jalan Raya

Read More

Sistem Berorientasi Objek (OOP)

I.PENDAHULUAN

Berorientasi Objek (Object Oriented) merupakan paradigma baru dalam rekayasa perangkat lunak yang memandang sistem sebagai sekumpulan objek-objek yang saling berinteraksi.

Metoda Berorientasi-Objek memberikan sekumpulan teknik untuk menganalisis, mendekomposisi dan memodularisasi arsitektur sistem perangkat lunak.

Sistem sendiri didefinisikan sebagai kumpulan dari beberapa elemen (modul) yang saling berhubungan (berinteraksi) untuk mencapai suatu tujuan/output (output disesuaikan dengan kebutuhan pengguna).

Sedangkan sistem yang berorientasi objek diurai kedalam sejumlah/sekumpulan obyek(konsep, abstrak, benda) dalam dunia nyata yang saling berkomunikasi dan melaksanakan sejumlah pelayanan secara desentralisasi.
Setiap obyek membungkus (encapsulate) sejumlah prosedur dan data yang berinteraksi dengan obyek lainnya melalui suatu pesan (message).

II.PEMBAHASAN

1.   Konsep Dasar

Konsep dasar dari Pemrograman Berorientasi Objek Pemrograman orientasi-objek menekankan konsep berikut:

Kelas — kumpulan atas definisi data dan fungsi-fungsi dalam suatu unit untuk suatu tujuan tertentu. Sebagai contoh 'class of dog' adalah suatu unit yang terdiri atas definisi-definisi data dan fungsi-fungsi yang menunjuk pada berbagai macam perilaku/turunan dari anjing. Sebuah class adalah dasar dari modularitas dan struktur dalam pemrograman berorientasi object. Sebuah class secara tipikal sebaiknya dapat dikenali oleh seorang non-programmer sekalipun terkait dengan domain permasalahan yang ada, dan kode yang terdapat dalam sebuah class sebaiknya (relatif) bersifat mandiri dan independen (sebagaimana kode tersebut digunakan jika tidak menggunakan OOP). Dengan modularitas, struktur dari sebuah program akan terkait dengan aspek-aspek dalam masalah yang akan diselesaikan melalui program tersebut. Cara seperti ini akan menyederhanakan pemetaan dari masalah ke sebuah program ataupun sebaliknya.

Objek - membungkus data dan fungsi bersama menjadi suatu unit dalam sebuah program komputer; objek merupakan dasar dari modularitas dan struktur dalam sebuah program komputer berorientasi objek.

Abstraksi - Kemampuan sebuah program untuk melewati aspek informasi yang diproses olehnya, yaitu kemampuan untuk memfokus pada inti. Setiap objek dalam sistem melayani sebagai model dari "pelaku" abstrak yang dapat melakukan kerja, laporan dan perubahan keadaannya, dan berkomunikasi dengan objek lainnya dalam sistem, tanpa mengungkapkan bagaimana kelebihan ini diterapkan. Proses, fungsi atau metode dapat juga dibuat abstrak, dan beberapa teknik digunakan untuk mengembangkan sebuah pengabstrakan.

Enkapsulasi - Memastikan pengguna sebuah objek tidak dapat mengganti keadaan dalam dari sebuah objek dengan cara yang tidak layak; hanya metode dalam objek tersebut yang diberi izin untuk mengakses keadaannya. Setiap objek mengakses interface yang menyebutkan bagaimana objek lainnya dapat berinteraksi dengannya. Objek lainnya tidak akan mengetahui dan tergantung kepada representasi dalam objek tersebut.

Polimorfisme melalui pengiriman pesan. Tidak bergantung kepada pemanggilan subrutin, bahasa orientasi objek dapat mengirim pesan; metode tertentu yang berhubungan dengan sebuah pengiriman pesan tergantung kepada objek tertentu di mana pesa tersebut dikirim. Contohnya, bila sebuah burung menerima pesan "gerak cepat", dia akan menggerakan sayapnya dan terbang. Bila seekor singa menerima pesan yang sama, dia akan menggerakkan kakinya dan berlari. Keduanya menjawab sebuah pesan yang sama, namun yang sesuai dengan kemampuan hewan tersebut. Ini disebut polimorfisme karena sebuah variabel tungal dalam program dapat memegang berbagai jenis objek yang berbeda selagi program berjalan, dan teks program yang sama dapat memanggil beberapa metode yang berbeda di saat yang berbeda dalam pemanggilan yang sama. Hal ini berlawanan dengan bahasa fungsional yang mencapai polimorfisme melalui penggunaan fungsi kelas-pertama.

Dengan menggunakan OOP maka dalam melakukan pemecahan suatu masalah kita tidak melihat bagaimana cara menyelesaikan suatu masalah tersebut (terstruktur) tetapi objek-objek apa yang dapat melakukan pemecahan masalah tersebut. Sebagai contoh anggap kita memiliki sebuah departemen yang memiliki manager, sekretaris, petugas administrasi data dan lainnya. Misal manager tersebut ingin memperoleh data dari bag administrasi maka manager tersebut tidak harus mengambilnya langsung tetapi dapat menyuruh petugas bag administrasi untuk mengambilnya. Pada kasus tersebut seorang manager tidak harus mengetahui bagaimana cara mengambil data tersebut tetapi manager bisa mendapatkan data tersebut melalui objek petugas adminiistrasi. Jadi untuk menyelesaikan suatu masalah dengan kolaborasi antar objek-objek yang ada karena setiap objek memiliki deskripsi tugasnya sendiri.

1.1               Diagram Use Case

Use Case merupakan sebuah teknik yang digunakan dalam pengembangan sebuah software atau sistem informasi untuk menangkap kebutuhan fungsional dari sistem yang bersangkutan, Use Case menjelaskan interaksi yang terjadi antara ‘aktor’ – inisiator dari interaksi sistem itu sendiri dengan sistem yang ada, sebuah Use Case direpresentasikan dengan urutan langkah yang sederhana.
Aktor adalah sesuatu atau seseorang yang ada di luar sistem dan ikut berperan serta dalam aktifitas sistem. Aktor bisa berupa: End User, perangkat hardware, bahkan sistem yang lain. Setiap use case merupakan sebuah seri yang lengkap dari sebuah event kejadian, dilihat dari sudut pandang aktor.
fokus dari sebuah use case adalah menjelaskan bagaimana mencapai sebuah tujuan atau goal. Dalam pengembangan software, dibutuhkan banyak use case untuk mendefinisikan scope dari sebuah system. derajat formalitas dari sebuah sistem yang dikembangkan menentukan level detail yang dibutuhkan dari sebuah use case.
Use Case sebaiknya jangan dicampuradukan dengan fitur dari sistem, sebuah use case mungkin berhubungan dengan satu atau lebih fitur sistem, sebuah fitur mungkin terelasi dengan satu atau lebih use case.
elemen-elemen yang ada di dalamnya.

1. Actor:
elemen aktor diumpamakan adalah sebuah peran dari ‘user’ sebuah sistem. aktor ini bisa berupa ‘human user’ atau bahkan bisa sebuah sistem yang lain. karakteristik dari sebuah aktor antara lain:
+ Aktor merupakan elemen eksternal dari sistem
+ Aktor berinteraksi dengan sistem, aktor boleh menggunakan fungsionalitas dan menerima informasi yang disediakan oleh sistem, aktor dapat memberikan informasi kepada sistem.
+ Aktor dapat berbentuk class, maka aktor bisa memiliki instance atau objek yang merepresentasikan aktor yang lebih spesifik.

2. Use Case:
Class Use Case digunakan untuk merepresentasikan unit fungsionalitas  atau pelayanan yang diberikan oleh sebuah sistem / bagian sistem, Use Case dinotasikan dengan simbol elips atau oval. dalam diagram, Use Case digambar didalam simbol kotak yang merepresentasikan sistem. Use Case memiliki karakteristik:
+ Use Case merupakan interaksi atau ‘dialog’ antara sistem dan aktor, termasuk pertukaran pesan dan aksi yang dilakukan oleh sistem.
+ Sebuah use case diinisiasikan oleh aktor dan bisa melibatkan lebih dari satu aktor.
+ Use Case memiliki instance atau objek yang disebut dengan ‘skenario’ yang merepresentasikan interaksi yang spesifik.

2.   Kelebihan Dan Kekurangan

Kelebihan

1. Meningkatkan produktivitas
2. Meningkatkan kecapatan pengembangan
3. Meningkatkan Kualitas
4. Kemudahan dalam pemeliharaan

Kekurangan

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.

III. PENUTUP

Kesimpulan

Dengan system berorientasi objek, akan lebih mempermudah dalam interaksi di perangkat-perangkat yang semakin banyak jenis dan system pengoperasiannya

Dimana semua data dan fungsi di dalam paradigma ini dibungkus dalam kelas-kelas atau objek-objek. Menjadikan sistem ini dinilai lebih mudah dan fleksibel

DAFTAR PUSTAKA

http://joinsucess.blogspot.com/2010/12/analisa-perancangan-sistem-berorientasi.html

http://rizqi04.blogspot.com/2011/11/sistem-berorientasi-objek-oop.html

http://prayoga.wordpress.com/category/metodologi-berorientasi-objek/

http://id.wikipedia.org/wiki/Pemrograman_berorientasi_objek

http://id.wikipedia.org/wiki/UML

Read More

Sistem Terstruktur DFD dan ERD

Latar belakang masalah

Tujuan makalah ini dibuat adalah agar para pembaca mengerti tentang DFD (data flow diagram) dan juga ERD (entitiy relationship diagram)  dan agar pembaca mengerti cara membuat DFD dan ERD dengan baik dan benar, Anda pasti sering mendengar tentang DFD. DFD (Data Flow Diagram) merupakan suatu cara atau metode untuk membuat rancangn sebuah sistem yang mana berorientasi pada alur data yang bergerak pada sebuah sistem nantinya.. Dalam pembuatan Sistem Informasi, DFD sering digunakan. DFD dibuat oleh para analis untuk untuk membuat sebuah sistem yang baik. Dimana DFD ini nantinya diberikan kepada para programmer untuk melakukan proses coding. Dimana para programmer melakukan sebuah coding sesuai dengan DFD yang dibuat oleh para analis sebelumnya. Tools yang digunakan pada pembuatan DFD (Data Flow Diagram) yaitu EasyCase, Power Designer. adalah menyediakan cara untuk mendeskripsikan perancangan basis data pada peringkat logika.

Tujuan penulisan

Tujuan dibuatnya makalah ini agar pembaca mengerti cara membuat dan menggunakan DFD (data flow diagram) dan ERD (entity relationship diagram). Dan agar pembaca bisa mengerti apa kelemahan dan kelebihan dari penggunaan DFD dan ERD. Dan juga agar pembaca mengetahui kegunaan dari DFD dan ERD.

Data Flow Diagram (DFD)

Data Flow Diagram (DFD) adalah suatu diagram yang menggunakan notasi-notasi untuk menggambarkan arus dari data sistem, yang penggunaannya sangat membantu untuk memahami sistem secara logika, tersruktur dan jelas.

Tujuan dari dibuatnya Data Flow Diagram (DFD) adalah untuk memudahkan penggambaran dari suatu system yang ada secara logika tanpa memperhatikan lingkungan fisik dimana data tersebut mengair atau lingkungan fisik dimana data tersebut disimpan.

Keuntungan dari Data Flow Diagram (DFD):

a.  Dapat menggambarkan system secara terstruktur dengan memecah-mecah proses menjadi level yang lebih rendah (decomposition).

b.  Dapat menunjukkan arah data pada system.

c.   Dapat menggambarkan system parallel.

d.  Dapat menunjukkan simpanan data.

e.  Dapat menunjukkan kesatuan luar.

Kekurangan dari Data Flow Diagram (DFD) adalah.

a.  Tidak menunjukkan proses perulangan (loop).

b.  Tidak menunjukkan proses keputusan (decision).

c.   Tidak menunjukkan proses perhitungan.

Bentuk-bentuk dari Data Flow Diagram (DFD):

a.  Physical DFD

Physical DFD adalah DFD yang menekankan bagaimana proses dari suatu system diterapkan. Bentuk DFD ini digunakan untuk menggambarkan suatu system yang ada. Keuntungan dari bentuk DFD ini adalah proses suatu system yang ada akan lebih dapat digambarkan dengan jelas dan dapat dikomunikasikan dengan lebih mudah kepada pemakai system atau user sehingga akan mempermudah programmer di dalam menganalisis system maupun memperoleh gambaran yang jelas.

b.  Logical DFD

Logical DFD adalah DFD yang menekankan proses-proses apa saja yang dibutuhkan suatu system. Bentuk ini digunakan untuk menggambarkan suatu system baru yang dikembangkan secara logika dengan penerapan secara fisik. Keuntungan dari bentuk ini adalah penghematan waktu didalam penggambaran diagramnya, karena system yang akan diusulkan belum tentu diterima oleh pemakai system atau user. Biasanya pendesain system juga akan mengusulkan beberapa alternative system baru.

Simbol-simbol pada DFD

A.   Kesatuan Luar (External Entity)

Merupakan kesatuan luar (entity) dilingkungan luar sistem yang dapat berupa sekelompok orang, divisi, organisasi, atau sistem lainnya yang berada dilingkungan luarnya yang akan memberikan input atau menerima output dari sistem. Suatu kesatuan luar dapat disimbolkan dengan suatu notasi kotak atau segi empat.

                                                                   

B.     Proses

Adalah kegiatan atau kerja yang dilakukan oleh orang, mesin atau komputer dari hasil suatu arus data yang masuk dalam proses untuk dihasilkan arus data yang akan keluar dari proses atau untuk mengubah input menjadi output. Suatu proses dapat ditunjukkan dengan simbol lingkaran.

C.    Data Flow (Aliran Data)

Data mengalir melalui sistem, dimulai dengan sebagian input dan diubah atau diproses menjadi output. Arus data (Data Flow) diberi simbol dengan suatu garis panah.

D.   Data Storage (Penyimpanan Data)

Data disimpan untuk keperluan berikutnya. Simpanan data di DFD disimbolkan dengan sepasang garis horisontal paralel yang tertutup di salah satu ujungnya.

Entity Relationship Diagram (ERD)

Entity Relationship Diagram (ERD) adalah diagram yang dipakai untuk mendokumentasikan data-data yang ada dengan cara mengidentifikasi tiap jenis entitas (entity) beserta hubungannya (relationship). Metode ini digunakan untuk menjelaskan suatu skema database. Terdapat dua macam ERD, yaitu conceptual ERD dan physical ERD. Beberapa elemen yang ada di dalam Entity Relationship Diagram (ERD) adalah sebagai berikut.

a.  Entity / Entitas

Entitas merupakan objek yang dapat bersifat fisik atau bersifat konsep dan dapat dibedakan satu dengan yang lainnya berdasarkan attribute yang dimilikinya. Suatu entitas disebut juga dengan file.

 

b.  Relationship

Relationship adalah hubungan antara dua entitas atau lebih. Tiga jenis relationship yaitu Obligatory, Non-obligatory, dan Dependency

·         Obligatory, obligatory dapat disebut juga mandatory. Obligatory adalah keadaan dimana semua anggota dari semua entitas harus berpartisipasi atau memiliki hubungan dengan etitas yang lain.

·         Non-obligatory, non-obligatory adalah keadaan dimana tidak semua anggota dari suatu entitas harus berpartisipasi atau memiliki hubungan dengan entitas yang lain.

·         Dependency, dependency adalah suatu keadaan diman syatu entitas didefinisikan secara sebagian (partial) oleh entitas lainnya. Agar terjadi hubungan ini, setiap entitas harus memiliki suatu identifier.

c.   Attribute

Attribute adalah informasi singkat atau karakteristik yang terdapat didalam sebuah entitas.

 

d.  Cardinality

Cardinality digunakan untuk menandai sebuah entitas yang muncul dalam relasi dengan entitas lainnya.

Bagaimana cara pembuatan DFD

Penamaan Yang Jelas

1.Setiap entitas diberi nama yang sesuai dengan suatu kata benda.

2.Nama aliran data dalam kata benda karena menunjukkan seseorang, tempat          atau sesuatu.

3.Proses diberi nama menggunakan format kata kerja - kata sifat - kata benda untuk proses-proses yang rinci.

4.Penyimpanan data diberi nama dengan suatu kata benda.

Memberi nomor pada proses

1.Nomor yang diberikan pada proses tidak harus menjadi nomor urut.

2.Penomoran dimaksudkan sebagai identifikasiproses dan memudahkan penurunan                                         (level yang lebih rendah) ke proses berikutnya.

3.Untuk proses primitif selain diberi nomor juga diberi tanda khusus (biasanya tanda *) untuk menyatakan bahwa proses tersebut tidak dirinci lagi.

Pengggambaran kembali

1.Ukuran dan bentuk lingkaran tetap sama.

2.Panah yang melengkung dan lurus tidak jadi masalah.

Cara pembuatan ERD

• Menentukan Entity
• Disini kita dituntut untuk menentukan dengan cermat sebuah entity yang ada dalam suatu proyek atau masalah. Entity berguna untuk menentukan peran, kejadian, lokasi, hal nyata dan konsep penggunaan untuk database
•  Menentukan Relasi
• Setelah kita berhasil membuat Entity, langkah selanjutnya adalah menentukan relasi antar entity. Relasi apa yang terdapat antara Entity A dan B, apakah entity A dan B memiliki relasi "one to one", "one to many", atau "many to many".
• Gambar ERD sementara
• Jika sudah mengetahui Entity beserta Relasinya, sekarang kita buat dulu gambar ERD sementara. Entity digambarkan dengan persegi, relasi digambarkan dengan garis.
• Isi kardinalitas
• Kardinalitas menentukan jumlah kejadian satu entitas untuk sebuah kejadian pada entitas yang berhubungan. Contohnya antara Entitas Buku, Distributor dan Pengarang, kardinalitas yang ada berupa:
• Satu pengarang dapat menulis banyak buku
• Satu buku ditulis satu pengarang
• Banyak buku di distribusikan oleh satu distributor.
• Dari sini kita bisa mengetahui harus memberi relasi apa. One to one kah?, dsb.
• Tentukan Primary Key (Kunci Utama)
• Menentukan Primary Key pada masing-masing entity. Primary Key adalah atribut pada entity yang bersifat unik. Jadi setiap entity hanya memiliki satu Primary Key saja. Contoh: Entity Buku memiliki Primary Key bernama kode buku. Kode Buku ini bersifat unik, karena masing-masing buku memiliki kode yang berbeda-beda.
• Tentukan pula Foreign Key (Kunci Tamu) pada masing-masing Entity. Foreign Key adalah Primary Key yang ada dalam Entity yang lain. Contoh pada Entity Pengarang misalnya terdapat atribut kode buku, yang mana, kode buku merupakan Primary Key dari Entity buku.

•  Gambar ERD berdasarkan Primary Key
• Menghilangkan relasi "many to many" dan memasukkan Primary dan Foreign Key pada masing-masing entitas. Relasi many to many antar entity perlu dihilangkan dengan cara menambah atribut baru antara 2 entity yang memiliki relasi many to many.
• Menentukan Atribut
• Jika sudah melakukan step diatas, sekarang saatnya menentukan atribut pada masing-masing Entitas. Telitilah dalam menentukan atribut.
• Pemetaan Atribut
• Apabila atribut telah ditentukan, sekarang pasang atribut dengan entitas yang sesuai.
• Gambar ERD dengan Atribut
• Mengatur ERD seperti langkah 6 dengan menambahkan atribut dan relasi yang ditemukan.
• Periksa Hasil
• Periksa lagi ERD. Apakah ERD sudah menggambarkan system yang akan dibangun? Jika belum, check kembali dari awal.

Daftar Pustaka

http://www.scribd.com/doc/25209413/Entity-Relationship-Diagram

http://pcbolong.blogspot.com/2011/04/diagram-alir-data-dad-data-flow-diagram.html

http://abcde.web.id/view.php?judul=Yang%20dimaksud%20diagram%20arus%20data%20%28Data%20Flow%20Diagram%29

http://id.wikipedia.org/wiki/Data_flow_diagram

Read More

UML (Unified Modeling Language)

 

BAB 1

PENDAHULUAN

Objek Adalah kombinasi antara struktur data dan perilaku dalam satu entitas dan mempunyai nilai tertentu yang membedakan entitas tersebut.

Unified Modeling Language (UML) adalah sebuah bahasa pemodelan yang telah menjadi standar dalam industri software untuk visualisasi, merancang, dan mendokumentasikan sistem perangkat lunak. Bahasa Pemodelan UML lebih cocok untuk pembuatan perangkat lunak dalam bahasa pemrograman berorientasi objek (C++, Java, VB.NET), namun demikian tetap dapat digunakan pada bahasa pemrograman procedural.

BAB 2

ISI

Sejarah Unified Modeling Language (UML)

Tahun 1994, Grady Boch dan James Rumbaugh bergabung untuk menggunakan metode berorientasi objek. Ivan Jacobson bergabung pada tahun 1995, dan mereka bertiga fokus membuat suatu bahasa pemodelan objek standar sebagai ganti dari pendekatan atau metode objek standar. Berdasarkan kerja mereka dan hasil kerja lainnya pada industri, Unified Modeling Language (UML) versi 1.0 dirilis pada tahun 1997.

Unified Modeling Language (UML) tidak menentukan metode untuk sistem-sistem pengembangan, tetapi sudah diterima luas sebagai standar untuk pemodelan objek. Object Management Gorup/OMG, badan standar industri, mengadopsi UML pada bulan November 1997 dan terus bekerja sama untuk meningkatkannya berdasarkan kebutuhan industri. Pada saat ini, salah satu industri telah merilis sebuah sofware yang mendukung UML yaitu Visual Paradigm 6.4 Interprise edition. Berbagai industri juga bermunculan dan mendukung penggunaan UML dengan berbagai produk, diantaranya Rational Rose, SmartDraw, dan lain-lain.

Konsep Pemodelan Menggunakan Unified Modeling Language (UML)

Pemodelan menggunakan Unified Modeling Language merupakan metode pemodelan berorientasi objek dan berbasis visual. Karenanya pemodelan menggunakan UML merupakan pemodelan objek yang fokus pada pendefinisian struktur statis dan model sistem informasi yang dinamis daripada mendefinisikan data dan model proses yang tujuannya adalah pengembangan tradisional. UML menawarkan diagram yang dikelompokan menjadi lima perspektif berbeda untuk memodelkan suatu sistem. Seperti satu set blue print yang digunakan untuk membangun sebuah rumah.

Komponen UML

UML memiliki berbagai jenis diagram (model) yang berhubungan dengan stake holder pada sebuah pembangunan perangkat lunak. Stake holder tersebut adalah :

Analis

Disainer

Koder

Tester

QA

Pelanggan

Penulis teknis

Diagram Dasar dalam Unified Modeling Language (UML)

Berikut ini adalah penjelasan mengenai berbagai diagram UML serta tujuannya:

1.Model Use Case Diagram

Use Case Diagram secara grafis menggambarkan interaksi antara sistem, sistem eksternal, dan pengguna. Dengan kata lain Use Case diagram secara grafis mendeskripsikan siapa yang akan menggunakan sistem dan dalam cara apa pengguna (user) mengharapkan interaksi dengan sistem itu. Use Case secara naratif digunakan untuk secara tekstual menggambarkan sekuensi langkah-langkah dari setiap interaksi.

2.Diagram Struktur Statis

UML menawarkan dua diagram untuk memodelkan struktur statis sistem informasi, yaitu:

a.Class Diagram: menggambarkan struktur object sistem. Diagram ini menunjukan class object yang menyusun sistem dan juga hubungan antara class object tersebut

b.Object Diagram: serupa dengan class diagram, tetapi object diagram memodelkan isntance object actual dengan menunjukan nilai-nilai saat ini dari atribut instance. Object Diagram menyajikan ?snapshot/potret? tentang objek sistem pada point waktu tertentu. Diagram ini tidak digunakan sesering Class Diagram, tetapi saat digunakan dapat membantu seorang developer memahami struktur sistem secara lebih baik.

3.Diagram Interaksi

Diagram interaksi memodelkan sebuah interaksi, terdiri dari satu set objek, hubungan-hubungannya, dan pesan yang terkirim di antara objek. Model diagram ini memodelkan behavior (kelakuan) sistem yang dinamis dan UML memiliki dua diagram untuk tujuan ini, yaitu:

a.Diagram rangkaian/Sequence Diagram: secara grafis menggambarkan bagaimana  objek berinteraksi dengan satu sama lain melalui pesan pada sekuensi sebuah use case atau operasi. Diagram ini mengilustrasikan bagaimana pesan terkirim dan diterima di antara objek dan dalam sekuensi atau timing apa.

b.Diagram kolaborasi/Collaboration Diagram: serupa dengan diagram rangkaian/sekuensi, tetapi tidak fokus pada timing atau sekuensi pesan. Diagram ini justru menggambarkan interaksi (atau kolaborasi) antara objek dalam sebuah format jaringan.

Diagram rangkaian maupun diagram kolaborasi merupakan isomorphic artinya kita dapat mengubah dari satu diagram ke diagram lain.

4.Diagram State/State Diagram

UML memiliki sebuah diagram untuk memodelkan behavior objek khusus yang kompleks (statecahrt) dan sebuah diagram untuk memodelkan behavior dari sebuah use case atau sebuah metode, yaitu:

a.Diagram statechart: digunakan untuk memodelkan behavior objek khusus yang dinamis. Diagram ini mengilustrasikan siklus hidup objek-berbagai keadaan yang dapat diasumsikan oleh objek dan event-event (kejadian) yang menyebabkan objek beralih dari satu state ke state lain.

b.Diagram aktivitas/Activity Diagram: secara grafis digunakan untuk menggambarkan rangkaian aliran aktivitas baik proses bisnis maupun use case. Activity diagram dapat juga digunakan untuk memodelkan action yang akan dilakukan saat sebuah operasi dieksekusi, dan memodelkan hasil dari action tersebut.

5.Diagram Implementasi

Diagram implementasi juga memodelkan struktur sistem informasi, yaitu:

a.Diaram komponen/Component Diagram: digunakan untuk menggambarkan organisasi dan ketergantungan komponen-komponen software sistem. Komponen diagram dapat digunakan untuk menunjukan bagaimana kode pemrograman dibagi menjadi modul-modul (atau komponen).

b.Diagram penguraian/Deployment: digunakan untuk mendeskripsikan arsitektur fisik dalam istilah ?node? untuk hardware dan software dalam sistem. Diagram ini menggambarkan konfigurasi komponen-komponen software real-time, prosesor, dan peralatan yang membentuk arsitektur sistem.

 

DAFTAR PUSTAKA

http://www.freewebs.com/henderi/apps/blog/show/311725

http://eraindrop.wordpress.com/2009/09/23/uml-%E2%80%93-analisis-perancangan-berorientasi-objek/

http://www.scribd.com/doc/26601970/SISTEM-BERORIENTASI-OBJEK

Read More