Welcome to my blog

Selasa, 10 Januari 2012

SISTEM TERSTRUKTUR

Diposting oleh ncil24 di 18.31

SISTEM TERSTRUKTUR

(DFD DAN ERD)

Kata Pengantar

Dengan mengucap puji syukur kehadirat Allah SWT atas berkat dan karuniaNya yang diberikan kepada kita semua, izinkanlah kami mengucapkan syukur yang sebesar-besarnya sehingga makalah ini bisa dapat diselesaikan dengan baik.

Adapun makalah ini menjelaskan tentang “ SISTEM TERSTRUKTUR” yang berfokus mnjelaskan “DFD dan ERD”. Apa itu pengertian dan definisinya, maupun penjelasan terperinci tentang SISTEM TERSTUKTUR (DFD dan ERD), dan komponen-komponennya.

Pendekatan terstruktur mengenalkan penggunaan alat-alat dan teknik-teknik untuk mengembangkan sistem yang terstruktur. Tujuan pendekatan terstruktur adalah agar pada akhir pengembangan perangkat lunak dapat memenuhi kebutuhan user, dilakukan tepat waktu, tidak melampaui anggaran biaya, mudah dipergunakan, mudah dipahami dan mudah dirawat. Teknik terstruktur, merupakan pendekatan formal untuk memecahkan masalah-masalah dalam aktivitas bisnis menjadi bagian-bagian kecil yang dapat diatur dan berhubungan untuk kemudian dapat disatukan kembali menjadi satu kesatuan yang dapat dipergunakan untuk memecahkan masalah.

ERD (Entity Relationship Diagram) adalah gambaran mengenai berelasinya antarentitas. DFD (Data flow Diagram) adalah diagram yang menggunakan notasi-notasi untuk menggambarkan arus dari sistem. DFD sering digunakan untuk menggambarkan suatu 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).

Penyusun menyadari bahwa baik isi maupun cara penyusunan makalah ini belum sempurna. Oleh karena itu,segala saran,tegur sapa,dan kritik membangun sangat penyusun harapkan. Demikianlah mudah-mudahan makalah ini berguna dan dapat dimanfaatkan sebaik-baiknya.

DAFTAR ISI

Halaman Judul

Kata Pengantar

Daftar Isi

BAB I PENDAHULUAN

1.1 Konsep perancangan terstruktur

1.2 Pendekatan pengembangan sistem terstruktur

1.3 Pendekatan terstruktur

1.4 Teknik struktur Dalam hubungannya dengan pengembangan sistem informasi dan software
aplikasi sistem informasi

1.5 Ciri-ciri utama yang mendukung pendekatan terstruktur

1.6 Alat-alat pengembangan sistem yang berbentuk Diagram

BAB II LATAR BELAKANG

2.1 Pengertian ERD

2.2 Komponen-komponen ERD

2.3 Pengertian DFD

2.4 Komponen-komponen DFD

2.5 Bentuk DFD

2.6 PHYSICAL DATA FLOW DIAGRAM (PDFD)

2.7 Syarat pembuatan pedoman bagaimana menggambar DFD baik PDFD ataupun LDFD

2.8 Perbedaan DFD dengan BAGAN ALIR

2.9 Keterbatasan DFD

Kesimpulan

Daftar Pustaka

BAB I

Pendahuluan

1.1 Konsep Perancangan Terstruktur

Karena banyak terjadi permasalahan-permasalahan di pendekatan klasik, maka kebutuhan akan pendekatan pengembangan sistem yang lebih baik mulai terasa dibutuhkan. Sayangnya sampai sekarang masih banyak orang yang tidak menyadari bahwa hanya dengan mengikuti tahapan di life cycle saja tidak akan membuat pengembangan sistem informasi menjadi berhasil. Oleh karena itu diperlukan suatu pendekatan pengembangan sistem yang baru yang dilengkapi dengan beberapa alat dan teknik supaya membuatnya berhasil. Pendekatan ini yang dimulai dari awal tahun 1970 disebut dengan pendekatan terstruktur (structured approach). Pendekatan terstruktur dilengkapi dengan alat-alat (tools) dan teknik-teknik (techniques) yang dibutuhkan dalam pengembangan sistem, sehingga hasil akhir dari sistem yang dikembangkan akan didapatkan sistem yang strukturnya didefinisikan dengan baik dan jelas.

Konsep pengembangan sistem terstruktur bukan merupakan konsep yang baru. Teknik perakitan di pabrik-pabrik dan perancangan sirkuit untuk alat-alat elektronik adalah dua contoh dari konsep ini yang banyak digunakan di industri-industri. Konsep ini memang relatif masih baru digunakan dalam mengembangkan sistem informasi untuk dihasilkan produk sistem yang memuaskan pemakainya. Melalui pendekatan terstruktur, permasalahan-permasalahan yang komplek di organisasi dapat dipecahkan dan hasil dari sistem akan mudah untuk dipelihara, fleksibel, lebih memuaskan pemakainya, mempunyai dokumentasi yang baik, tepat pada waktunya, sesuai dengan anggaran biaya pengembangannya, dapat meningkatkan produktivitas dan kualitasnya akan lebih baik (bebas kesalahan). Salah satu tools dan teknik dalam pengembangan sistem terstruktur adalah menggunakan DFD (Data Flow Diagram = Diagram Arus Data, DAD).

1.2 Pendekatan Pengembangan Sistem Terstruktur

Terdapat beberapa pendekatan untuk mengembangkan sistem yaitu:

1.Dipandang dari metodologi yang digunakan:

Ø Ø Pendekatan Klasik (Classical Approach) mengembangkan sistem dengan mengikuti tahapan
- tahapan di system life cycle.

Ø Pendekatan Terstruktur (Structured Approach) menyediakan sistem tambahan berupa alat-alat dan teknikteknik untuk mengembangkan sistem disamping tetap mengikuti ide dari system life cycle.

2. Dipandang dari sasaran yang dicapai:

Ø Pendekatan Sepotong (Piecerneal Approach) merupakan pendekatan pengembangan sistem yang menekankan pada suatu kegiatan atau aplikasi tertentu saja, tanpa memperhatikan posisi dan sasaran keseluruhan organisasi

Ø Pendekatan Sistem (Systems Approach) memperhatikan sistem informasi sebagai satu kesatuan terintegrasi untuk masing-masing kegiatan atau aplikasinya.

1.3 Pendekatan Terstruktur

1.4 Teknik terstruktur dalam hubungannya dengan pengembangan sistem informasi dan software aplikasi sistem informasi

Dalam hubungannya dengan pengembangan sistem informasi dan software aplikasi sistem informasi, teknik terstruktur terbagi menjadi :

�� Pemrograman terstruktur adalah proses yang berorientasi kepada teknik yang digunakan untuk merancang dan menulis program secara jelas dan konsisten

�� Desain terstruktur merupakan salah satu proses yang berorientasi teknik yang digunakan untuk memilah-milah program besar ke dalam hirarki modul-modul yang menghasilkan program komputer yang lebih kecil agar mudah untuk diimplementasikan dan dipelihara (dirubah)

�� Analisis Terstruktur Modern merupakan teknik yang berorientasi kepada proses yang paling populer dan banyak digunakan dewasa ini.

�� Pemodelan Data merupakan suatu teknik yang berorientasi kepada data dengan menunjukkan sistem hanya datanya saja terlepas dari bagaimana data tersebut akan diproses atau digunakan untuk menghasilkan informasi.

�� Rekayasa Informasi merupakan perpaduan dari pemodelan data dan proses, juga memberikan penekanan baru terhadap pentingnya perencanaan sistem informasi.

1.5 Ciri-ciri utama yang mendukung pendekatan terstruktur

�� memanfaatkan alat-alat pemodelan
menggunakan model untuk menjelaskan berbagai sistem, sub sistem untuk ditelaah dan dievaluasi oleh pelanggan dan pengembang (sebagai alat komunikasi, eksperimentasi atau prediksi)

�� merancang berdasar modul

modularisasi adalah proses yang membagi suatu sistem menjadi beberapa modul yang dapat

beroperasi secara independent

�� bekerja dengan pendekatan top-down

dimulai dari level atas (secara global) kemudian diuraikan sampai ke tingkat modul (rinci)

�� dilakukan secara iterasi

dengan iterasi akan didapat hasil yang lebih baik, terlalu banyak iterasi juga akan menurunkan hasilnya dan menunjukkan bahwa tahap sebelumnya tidak dilakukan dengan baik

�� kegiatan dilakukan secara paralel

pengembangan subsistem-subsistem dapat dilakukan secara paralel, sehingga akan memperpendek waktu pengembangan sistem

�� menggunakan CASE (Perangkat Lunak Pendukung Proses Pengembangan)

dengan CASE (computer aided software engineering) memungkinkan analis dapat membangun sistem dan menghasilkan executable secara otomatis

1.6 Alat-alat pengembangan sistem yang berbentuk Diagram

a.Diagram HIPO (Hierarchy plus Input-Proces-Output)

b.Diagram aliran data (DFD/Data Flow diagram)

c.Diagram keterhubungan entitas (ERD/Entity Relationship Diagram)

d.Diagram Perubahan status (STD/State Transition Diagram)

e.Structured Chart

f. Diagram SADT (Structured Analysis and Design Techniques)

g.Diagram Warnier/Orr

h.Diagram Jakson’s

i. Diagram UML

BAB II

Latar Belakang

2.1 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

2.2 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).

2.3 Pengertian DFD

Data Flow Diagram (DFD) adalah Ide dari suatu bagan untuk mewakili arus data dalam suatu sistem bukanlah hal yang baru. Pada tahun 1967, Martin dan Estrin memperkenalkan suatu algorima program dengan menggunakan simbol lingkaran dan panah untuk mewakili arus data. E. Yourdan dan L. L. Constantine juga menggunakan notasi simbol ini untuk menggambarkan arus data dalam perancangan program. G.E. Whitehouse tahun 1973 juga menggunakan notasi semacam ini untuk membuat model-model system matematika. Penggunaan notasi dalam diagram arus data ini sangat membantu sekali untuk memahami suatu sistem pada semua tingkat kompleksitasnya seperti yang diungkapkan oleh Chris Gane dan Trish Sarson. Pada tahap analisis, penggunaan notasi ini sangat membantu sekali di dalam komunikasi dengan pemakai sistem untuk memahami sistem secara logika. Diagram yang menggunakan notasi-notasi ini untuk menggambarkan arus dari data sistem sekarang dikenal dengan nama diagram arus data (data flow diagram, DFD).

DFD sering digunakan untuk menggambarkan suatu 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, microfile, harddisk, tape, diskette dan lain sebagainya). DFD merupakan alat yang cukup populer sekarang ini, karena dapat menggambarkan arus data di dalam sistem dengan terstruktur dan jelas. Lebih lanjut DFD juga merupakan dokumentasi dari sistem yang baik.

Data flow Diagram (DFD) adalah diagram yang menggunakan notasi-notasi untuk menggambarkan arus dari sistem. DFD sering digunakan untuk menggambarkan suatu 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 FD 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.

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.

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.

2.4 Komponen-komponen DFD

KESATUAN LUAR

Setiap sistem pasti mempunyai batas sistem (boundary) yang memisahkan suatu sistem dengan lingkungan luarnya. Sistem akan menerima input dan menghasilkan output kepada lingkungan luarnya. Kesatuan luar (external entity) merupakan kesatuan (entity) di lingkungan luar sistem yang dapat berupa orang, organisasi atau sistem lainnya yang berada di lingkungan luarnya yang akan memberikan input atau menerima output dari sistem. Kesatuan luar ini kebanyakan adalah salah satu dari berikut ini :

a. Suatu kantor, departemen, atau divisi dalam perusahaan teatpi di luar sistem yang sedang
dikembangkan

b. Orang atau sekelompok orang di organisasis tetapi di luar sistem yang sedang dikembangkan

c. Suatu organisasi atau orang uang berada di luar organisasi seperti misalnya langganan, pemasok

d. Sistem infromasi yang lain di luar sistem yang sedang dikembangkan

e. Sumber asli dari suatu transaksi

f. Penerima akhir dari suatu laporan yang dihasilkan oleh system

Suatu kesatuan luar dapat disimbolkan dengan suatu notasi kotak atau suatu kotak dengan sisi kiri dan atasnya berbentuk garis tebal, juga dapat diberi identifikasi dengan huruf kecil di ujung kiri atas.

ARUS DATA

Arus data (data flow) di DFD diberi simbol suatu panah. Arus data ini mengalir diantara proses (process), simpanan data (data store) dan kesatuan luar (external entity). Arus data ini menunjukkan arus dari data yang dapat berupa masukan untuk sistem atau hasil dari proses sistem dan dapat berbentuk sebagai berikut ini :

a. Formulir atau dokumen yang digunakan di perusahaan

b. Laporan tercetak yang dihasilkan oleh system

c. Tampilan atau output di layar komputer yang dihasilkan oleh system

d. Masukan untuk computer

e. Komunikasi ucapan

f. Surat-surat atau memo

g. Data yang dibaca atau direkamkan ke suatu file

h. Suatu isian yang dicatat pada buku agenda

i. Transmisi data dari suatu komputer ke komputer yang lain

Arus data sebaiknya diberi nama yang jelas dan mempunyai arti. Nama dari arus data dituliskan disamping garis panahnya.

Di dalam menggambar arus data di DFD perlu diperhatikan beberapa konsep penggambarannya sebagai berikut :

1. Konsep paket dari data (packet of data) Bila dua atau lebih data mengalir dari suatu sumber yang sama ke tujuan yang sama, maka harus dianggap sebagai suatu arus data yang tunggal. Mengapa ? karena dua atau lebih data tersebut mengalir bersama-sama sebagai suatu paket. Data yang mengalir bersama-sama harus ditunjukkan sebagai satu arus data, walaupun misalnya terdiri dari beberapa dokumen.

2. Konsep arus data menyebar (diverging data flow) Arus data yang menyebar menunjukkan sejumlah tembusan dari arus data yang sama dari sumber yang sama ke tujuan yang berbeda.

3. Konsep arus data mengumpul (converging data flow) Arus data yang mengumpul menunjukkan beberapa arus data yang berbeda dari sumber yang berbeda bergabung bersama-sama menuju ke tujuan yang sama Arus data pengiriman merupakan hasil dari gabungan arus data faktur dan slip pengepakan. Arus data mengumpul ini jarang dibuat di DFD.

4. Konsep sumber dan tujuan arus data Semua arus data harus dihasilkan dari suatu proses atau menuju ke suatu proses (dapat salah satu atau kedua-duanya, yaitu berasal dari suatu proses menuju ke bukan suatu proses atau berasal dari bukan suatu proses tetapi menuju ke suatu proses atau berasal dari suatu proses dan menuju ke suatu proses). Konsep ini penting karena arus data adalah salah satu dari hasil suatu proses atau akan digunakan untuk melakukan suatu proses.

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. Untuk physical data flow diagram (PDFD), proses yang dapat dilakukan oleh orang, mesin atau komputer, sedang untuk logical data flow diagram (LDFD), suatu proses hanya menunjukkan proses dari komputer. Suatu proses dapat ditunjukkan dengan simbol lingkaran atau dengan simbol empat persegi panjang tegak dengan sudut-sudutnya tumpul.

1. Identifikasi proses

Identifikasi ini umumnya berupa suatu angka yang menunjukkan nomor acuan dari proses dan ditulis pada bagian atas di simbol proses.

2. Nama proses

Nama proses menunjukkan apa yang dikerjakan oleh proses tersebut. Nama dari proses harus jelas dan lengkap menggambarkan kegiatan prosesnya. Nama dari proses biasanya berbentuk suatu kalimat diawali dengan kata kerja (misalnya menghitung, membuat, membandingkan, memverifikasi, mempersiapkan, merekam dan lain sebagainya). Nama dari proses diletakkan di bawah identifikasi proses di simbol proses.

3. Pemroses

Untuk PDFD yang menunjukkan proses tidak hanya proses dari komputer, tetapi juga proses manual, seperti proses yang dilakukan oleh orang, mesin dan lain sebagainya, maka pemroses harus ditunjukkan. Pemroses ini menunjukkan siapa atau dimana suatu proses dilakukan. Untuk LDFD yang prosesnya hanya menunjukkan proses komputer saja, maka pemroses dapat tidak disebutkan. Untuk LDFD bila pemroses akan disebutkan dapat juga untuk menyebutkan nama dari program yang melakukan prosesnya. Suatu proses terjadi karena adanya arus data yang masuk dan hasil dari proses adalah juga merupakan arus data lain yang mengalir. Berikut ini adalah berbagai kemungkinan arus data dalam suatu proses

a. Suatu proses yang menerima sebuah arus data dan menghasilkan sebuah arus data

b. Suatu proses yang menerima lebih dari satu arus data dan menghasilkan sebuah arus data

c. Suatu proses yang menerima satu arus data dan menghasilkan lebihdari sebuah arus data umumnya kesalahan proses di DFD adalah sebagai berikut :

1. Proses mempunyai input tetapi tidak menghasilkan output. Kesalahan ini disebut dengan black hole (lubang hitam), karena data masuk kedalam proses dan lenyap tidak berbekas seperti dimasukkan ke dalam lubang hitam yang dalam sekali. Kesalahan lubang hitam tampak pada proses nomor 1.

2. Proses menghasilkan output tetapi tidak pernah menerima input dan kesalahan ini disebut dengan miracle (ajaib), karena secara ajaib dihasilkan output tanpa pernah menerima input. Proses nomor 2 merupakan kesalahan jenis ini.

SIMPANAN DATA

Simpanan data (data store) merupakan simpanan dari data yang dapat berupa sebagai berikut ini :

a. Suatu file atau database di sistem computer

b. Suatu arsip atau catatan manual

c. Suatu kotak tempat data di meja seseorang

d. Suatu tabel acuan manual

e. Suatu agenda atau buku

Simpanan data di DFD dapat disimbolkan dengan sepasang garis horisontal parallel yang tertutup di salah satu ujungnya LDFD, penjelasan ini dapat digunakan untuk identifikasi dari simpanan data yang berguna sebagai acuan dalam merancang database.

Di dalam penggambaran simpanan data di DFD perlu diperhatikan beberapa hal, sebagai berikut :

1. Hanya proses saja yang berhubungan dengan simpanan data, karena yang menggunakan atau merubah data di simpanan data adlah suatu proses.

2. Arus data yang menuju ke simpanan data dari suatu proses menunjukkan proses update terhadap data yang tersimpan di simpanan data. Update dapat berupa proses :

a. menambah/menyimpankan record baru atau dokumen baru ke dlm simpanan data

b. menghapus record atau mengambil dokumen dari simpanan data

c. merubah nilai data di suatu record atau di suatu dokumen yg ada di simpanan data

3. Arus data yang berasal dari simpanan data ke suatu proses menunjukkan bahwa proses tersebut menggunakan data yang ada di simpanan data. Untuk media simpanan data berupa simpanan luar komputer (disk atau tape) berarti data dari suatu record di file sedang untuk simpanan data berupa media manual berarti mengambil suatu formulir atau dokumen untuk dilihat isinya dari suatu simpanan data.

4. Untuk suatu porses yang melakukan kedua-duanya, yaitu menggunakan dan update simpanan data dapat dipilih salah satu penggambaran sebagai berikut ini

a. Menggunakan sebuah garis dengan panah mengarah kedua arah yang berlawanan dari simpanan data

b. Menggunakan arus data yang terpisah

Untuk menghindari garis arus data yang saling berpotongan sehingga membuat gambar di DFD menjadi ruwet, maka simpanan data atau kesatuan luar dapat digambar lebih dari sebuah. Misalnya DFD sebagai berikut :

Supaya gambar dari DFD tidak ruwet karena banyaknya garis arus data yang saling berpotongan, maka kesatuan luar dan simpanan data dapat digambarkan lebih dari sebuah. Duplikasi dari kesatuan luar dapat diidentifikasikan dengan suatu garis miring (/) atau dengan asterik (*). Sedang duplikasi dari simpanan data dapat diidentifikasi dengan garis vertikal (|) atau dengan asterik (*). Dengan menggambarkan ulang kesatuan luar dan simpanan data lebih dari sebuah, maka garis-garis arus data yang berpotongan dapat dihindari, sehingga DFD akan tampak tidak terlalu ruwet, seperti sebagai berikut ini :

2.5 Bentuk DFD

Terdapat 2 bentuk DFD, yaitu DFD fisik (Physical Data Flow Diagram) dan DFD logika (Logical Data Flow Diagram). DFD fisik lebih menekankan pada bagaimana proses dari sistem diterapkan sedang DFD logika lebih menekankan proses-proses apa yang terdapat di sistem.

2.6 PHYSICAL DATA FLOW DIAGRAM (PDFD)

PDFD lebih tepat digunakan untuk menggambarkan sistem yang ada (sistem yang lama). Penekanan dari PDFD adalah bagaimana proses-proses dari sistem diterapkan (dengan cara apa, oleh siapa dan dimana), termasuk proses-proses manual. Dengan menggunakan PDFD, bagaimana proses sistem yang ada akan lebih dapat digambarkan dan dikomunikasikan kepada pemakai sistem, sehingga analis system akan dapat memperoleh gambaran yang jelas bagaimana sistem tersebut bekerja. Untuk memperoleh gambaran bagaimana sistem yang ada diterapkan, PDFD harus memuat sebagai berikut :

1. Proses-proses manual juga digambarkan

2. Nama dari arus data harus menunjukkan fakta penerapannya semacam nomor formulir dan medianya (misalnya telpon atau surat). Nama arus data mungkin juga menerangkan tentang waktu mengalirnya (misalnya harian atau mingguan). Dengan kata lain, nama dari arus data harus memuat keterangan yang cukup terinci untuk menunjukkan bagaimana pemakai sistem memahami kerja dari sistem.

3. Simpanan data dapat menunjukkan simpanan non komputer, misalnya kotak in/out yang berfngsi sebagai buffer dari proses serentak yang beroperasi dengan kecepatan berbeda, sehingga ada sebuah data yang harus menunggu di buffer.

4. Nama dari simpanan data harus menunjukkan tipe penerapannya apakah secara manual atau komputerisasi. Secara manual misalnya dapat menunjukkan buku catatan, meja pekerja atau kotak in/out. Sedang secara komputerisasi misalnya menunjukkan file urut, file ISAM, file database dan lain sebagainya.

5. Proses harus menunjukkan nama dari pemroses (processor), yaitu orang, departemen, sistem komputer atau nama program komputer yang mengeksekusi proses tersebut. LOGICAL DATA FLOW DIAGRAM (LDFD) LDFD lebih tepat digunakan untuk menggambarkan sistem yang akan diusulkan (sistem yang baru). LDFD tidak menekankan pada bagaimana sistem diterapkan, tetapi penekanannya hanya pada logika dari kebutuhan-kebutuhan sistem, yaitu proses-proses apa secara logika yang dibutuhkan oleh sistem. Karena sistem yang diusulkan belum tentu diterima oleh pemakai sistem dan biasanya sistem yang diusulkan terdiri dari beberapa alternatif, maka penggambaran sistem secara logika terlebih dahulu tanpa berkepentingan dengan penerapannya secara fisik akan lebih mengena dan menghemat waktu penggambarannya dibandingkan dengan PDFD. Untuk sistem komputerisasi, penggambaran LDFD yang hanya menunjukkan kebutuhan proses dari sistem yang diusulkan secara logika, biasanya proses-proses yang digambarkan hanya merupakan proses-proses secara komputer saja.

2.7 Syarat Pembuatan

Pedoman bagaimana menggambar DFD baik PDFD ataupun LDFD adalah sebagai berikut ini :

1. Identifikasikan terlebih dahulu semua kesatuan luar (external entity) yang terlibat di sistem. Kesatuan luar ini merupakan kesatuan (entity) di luar sistem, karena di luar bagian pengolahan data (sistem informasi). Kesatuan luar ini merupakan sumber arus data ke sistem informasi serta tujuan penerima arus data hasil dari proses sistem informasi, sehingga merupakan kesatuan di luar sistem informasi.

2. Identifikasikan semua input dan output yang terlibat dengan kesatuan luar.

3. Gambarlah terlebih dahulu suatu diagram konteks (context diagram). DFD merupakan alat untuk structured analysis. Pendekatan terstruktur ini mencoba untuk menggambarkan sistem pertama kali secara garis besar (disebut dengan top level) dan memecah-mecahnya menjadi bagian yang lebih terinci (disebut dengan lower level). DFD yang pertama kali digambar adalah level teratas (top level) dan diagram ini disebut context diagram. Dari context diagram ini kemudian akan digambar dengan lebih terinci lagi yang disebut dengan overview diagram (level 0). Tiaptiap proses di overview diagram akan digambar secara lebih terinci lagi dan disebut dengan level 1. Tiap-tiap proses di level 1 akan digambar kembali dengan lebih terinci lagi dan disebut dengan level 2 dan seterusnya sampai tiap-tiap proses tidak dapat digambar lebih terinci lagi.

2.8 Perbedaan DFD dengan BAGAN ALIR

DFD sangat berbeda dengan bagan alir (flow-chart). Perbedaannya adalah sebagai berikut :

1. proses di DFD dapat beroperasi secara paralel, sehingga beberapa proses dapat dilakukan serentak. Hal ini merupakan kelebihan DFD dibandingkan dengan bagan alir yang cenderung hanya menunjukkan proses yang urut. Kenyataannya kegiatan-kegiatan proses dapat dilakukan secara tidak urut, yaitu secara parallel atau serentak, sehingga DFD dapat menggambarkan proses semacam ini dengan lebih mengena.

2. DFD lebih menunjukkan arus data di suatu sistem, sedang bagan alir sistem lebih menunjukkan arus dari prosedur dan bagan alir program lebih menunjukkan arus dari algoritma.

3. DFD tidak menunjukkan proses perulangan (loop) dan proses keputusan (decision), sedang bagan alir menunjukkannya.

2.9 Keterbasan DFD

Walaupun DFD mempunyai kebaikan-kebaikan, yaitu dapat menggambarkan sistem secara terstruktur dengan memecah-mecah menjadi level lebih rendah (decomposition), dapat menunjukkan arus data di sistem, dapat menggambarkan proses paralel di sistem, dapat menunjukkan simpanan data, dapat menunjukkan kesatuan luar, tetapi DFD juga mempunyai keterbatasan. Keterbatasan DFD adalah sebagai berikut :

1. DFD tidak menunjukkan proses perulangan (loop)

2. DFD tidak menunjukkan proses keputusan (decision)

3. DFD tidak menunjukkan proses perhitungan

Kesimpulan

ERD (Entity Relationship Diagram) adalah gambaran mengenai berelasinya antarentitas. Komponen-komponen ERD ada Entitas dan Relasi. 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 computer. 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. 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 computer.

Daftar Pustaka

http://www.gangsir.com/download/3-PendekatanPengembanganSistemTerstruktur.pdf

http://avfah.wordpress.com/2010/01/29/pengertian-erd-dan-dfd/

http://elearning.gunadarma.ac.id/docmodul/pengantar_analisis_&_perancangan_sistem_terstruktur/bab4-pendekatan_terstruktur.pdf

http://www.unhas.ac.id/rhiza/arsip/Arsitektur%20Komputer/sist%20dan%20analisis%20sist/_Microsoft_Word_-_Modul_4_APSI_-_Pendekatan_Perancangan_Ters.pdf

TOP

SISTEM BERORIENTASI OBJEK

Diposting oleh ncil24 di 18.30

sistem berorientasi objek

Kata Pengantar

Adapun makalah ini menjelaskan tentang “SISTEM BERORIENTASI OBJEK=>UML”. Apa itu pengertian dan definisinya, maupun penjelasan terperinci tentang sistem berorientasi objek (UML).

Analisis berorientasi objek / Object-oriented analysis (OOA) adalah pendekatan yang digunakan untuk mempelajari objek yang sudah ada untuk mengetahui apakah mereka dapat digunakan kembali atau diadaptasi untuk pemakaian baru, atau menentukan satu objek baru atau yang dimodifikasi yang akan digabung dengan objek yang sudah ada ke dalam suatu aplikasi komputasi bisnis yang sangat berharga.

Analisis sistem berorientasi fokus pada pendefinisian struktur statis dan model sistem informasi yang dinamis. Ada beberapa bahasa pemrograman yang berdasarkan pendekatan berorientasi objek, diantaranya Visual Basic, C++, Powerbuilder, Object Pascal (seperti di Delphi), Smalltalk, Java dan Unified Modeling Language (UML).

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. Selebihnya penyusun jelaskan di halaman pendahuluan secara terperinci.

DAFTAR ISI

Halaman Judul

Kata Pengantar

Daftar Isi

BAB I PENDAHULUAN

1.1 Pendahuluan Dan Definisi Analisis Sistem Berorientasi Objek

1.2 Latar Belakang

1.3 Pengertian UML

1.4 Konsepsi Dasar UML

1.5 Langkah-Langkah Penggunaan UML

Kesimpulan

Daftar Pustaka

BAB I

Pendahuluan

1.1 Pendahuluan Dan Definisi Analisis Sistem Berorientasi Objek

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

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.

1.2 Latar Belakang

Saat ini piranti lunak semakin luas dan besar lingkupnya, sehingga tidak bisa lagi dibuat asal-asalan.Piranti lunak saat ini seharusnya dirancang dengan memperhatikan hal-hal seperti scalability,security, dan eksekusi yang robust walaupun dalam kondisi yang sulit. Selain itu arsitekturnya harus didefinisikan dengan jelas, agar bug mudah ditemukan dan diperbaiki, bahkan oleh orang lain selain programmer aslinya. Keuntungan lain dari perencanaan arsitektur yang matang adalah dimungkinkannya penggunaan kembali modul atau komponen untuk aplikasi piranti lunak lain yang membutuhkan fungsionalitas yang sama.

Pemodelan (modeling) adalah proses merancang piranti lunak sebelum melakukan pengkodean (coding). Model piranti lunak dapat dianalogikan seperti pembuatan blueprint pada pembangunan gedung. Membuat model dari sebuah sistem yang kompleks sangatlah penting karena kita tidak dapat memahami sistem semacam itu secara menyeluruh. Semakin komplek sebuah sistem, semakin penting pula penggunaan teknik pemodelan yang baik.

Dengan menggunakan model, diharapkan pengembangan piranti lunak dapat memenuhi semua kebutuhan pengguna dengan lengkap dan tepat, termasuk faktor-faktor seperti scalability, robustness, security, dan sebagainya.

Kesuksesan suatu pemodelan piranti lunak ditentukan oleh tiga unsur, yang kemudian terkenal dengan sebuan segitiga sukses (the triangle for success). Ketiga unsur tersebut adalah metode pemodelan (notation), proses (process) dan tool yang digunakan.

Memahami notasi pemodelan tanpa mengetahui cara pemakaian yang sebenarnya (proses) akan membuat proyek gagal. Dan pemahaman terhadap metode pemodelan dan proses disempurnakan dengan penggunaan tool yang tepat.

1.3 Pengertian UML

Apa itu UML ?

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.

Dengan menggunakan UML kita dapat membuat model untuk semua jenis aplikasi piranti lunak, dimana aplikasi tersebut dapat berjalan pada piranti keras, sistem operasi dan jaringan apapun, serta ditulis dalam bahasa pemrograman apapun. Tetapi karena UML juga menggunakan class dan operation dalam konsep dasarnya, maka ia lebih cocok untuk penulisan piranti lunak dalam bahasabahasa berorientasi objek seperti C++, Java, C# atau VB.NET. Walaupun demikian, UML tetap dapat digunakan untuk modeling aplikasi prosedural dalam VB atau C.

Seperti bahasa-bahasa lainnya, UML mendefinisikan notasi dan syntax/semantik. Notasi UML merupakan sekumpulan bentuk khusus untuk menggambarkan berbagai diagram piranti lunak.

Setiap bentuk memiliki makna tertentu, dan UML syntax mendefinisikan bagaimana bentuk-bentuk tersebut dapat dikombinasikan. Notasi UML terutama diturunkan dari 3 notasi yang telah ada sebelumnya: Grady Booch OOD (Object-Oriented Design), Jim Rumbaugh OMT (Object Modeling Technique), dan Ivar Jacobson OOSE (Object-Oriented Software Engineering).

Sejarah UML sendiri cukup panjang. Sampai era tahun 1990 seperti kita ketahui 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 group/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 – http://www.omg.org). Tahun 1997 UML versi 1.1 muncul, dan saat ini versi terbaru adalah versi 1.5 yang dirilis bulan Maret 2003. Booch, Rumbaugh dan Jacobson menyusun tiga buku serial tentang UML pada tahun 1999. Sejak saat itulah UML telah menjelma menjadi standar bahasa pemodelan untuk aplikasi berorientasi objek.

1.4 Konsepsi Dasar UML

Dari berbagai penjelasan rumit yang terdapat di dokumen dan buku-buku UML. Sebenarnya konsepsi dasar UML bisa kita rangkumkan dalam gambar dibawah.

Abstraksi konsep dasar UML yang terdiri dari structural classification, dynamic behavior, dan model management, bisa kita pahami dengan mudah apabila kita melihat gambar diatas dari diagrams. Main concepts bisa kita pandang sebagai term yang akan muncul pada saat kita membuat diagram. Dan view adalah kategori dari diagaram tersebut.

Lalu darimana kita mulai ? Untuk menguasai UML, sebenarnya cukup dua hal yang harus kita perhatikan:

1. Menguasai pembuatan diagram UML

2. Menguasai langkah-langkah dalam analisa dan pengembangan dengan UML

Tulisan ini pada intinya akan mengupas kedua hal tersebut.

UML mendefinisikan diagram-diagram sebagai berikut:

· Use Case Diagram untuk memodelkan proses bisnis.

· Conceptual Diagram untuk memodelkan konsep-konsep yang ada di dalam aplikasi.

· Sequence Diagram untuk memodelkan pengiriman pesan (message) antar objects.

· Collaboration Diagram untuk memodelkan interaksi antar objects.

· State Diagram untuk memodelkan perilaku objects di dalam sistem.

· Activity Diagram untuk memodelkan perilaku Use Cases dan objects di dalam system.

· Class Diagram untuk memodelkan struktur kelas.

· Object Diagram untuk memodelkan struktur object.

· Component Diagram untuk memodelkan komponen object.

· Deployment Diagram untuk memodelkan distribusi aplikasi.

Use Case Diagram

Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Sebuah use case merepresentasikan sebuah interaksi antara aktor dengan sistem. Use case merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, meng-create sebuah daftar belanja, dan sebagainya.

Seorang/sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan sistem untuk melakukan pekerjaan-pekerjaan tertentu.

Use case diagram dapat sangat membantu bila kita sedang menyusun requirement sebuah sistem, mengkomunikasikan rancangan dengan klien, dan merancang test case untuk semua feature yang ada pada sistem.

Sebuah use case dapat meng-include fungsionalitas use case lain sebagai bagian dari proses dalam dirinya. Secara umum diasumsikan bahwa use case yang di-include akan dipanggil setiap kali use case yang meng-include dieksekusi secara normal.

Sebuah use case dapat di-include oleh lebih dari satu use case lain, sehingga duplikasi fungsionalitas dapat dihindari dengan cara menarik keluar fungsionalitas yang common.

Sebuah use case juga dapat meng-extend use case lain dengan behaviour-nya sendiri. Sementara hubungan generalisasi antar use case menunjukkan bahwa use case yang satu merupakan spesialisasi dari yang lain.

Class Diagram

Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek dan merupakan inti dari pengembangan dan desain berorientasi objek. Class menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut (metoda/fungsi).

Class diagram menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain.

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

Class dapat merupakan implementasi dari sebuah interface, yaitu class abstrak yang hanya memiliki metoda. Interface tidak dapat langsung diinstansiasikan, tetapi harus diimplementasikan dahulu menjadi sebuah class. Dengan demikian interface mendukung resolusi metoda pada saat run-time.

Sesuai dengan perkembangan class model, class dapat dikelompokkan menjadi package. Kita juga dapat membuat diagram yang terdiri atas package.

Hubungan Antar Class

1. Asosiasi, yaitu hubungan statis antar class. Umumnya menggambarkan class yang memiliki atribut berupa class lain, atau class yang harus mengetahui eksistensi class lain. Panah navigability menunjukkan arah query antar class.

2. Agregasi, yaitu hubungan yang menyatakan bagian (“terdiri atas..”).

3. Pewarisan, yaitu hubungan hirarkis antar class. Class dapat diturunkan dari class lain dan mewarisi semua atribut dan metoda class asalnya dan menambahkan fungsionalitas baru, sehingga ia disebut anak dari class yang diwarisinya. Kebalikan dari pewarisan adalah generalisasi.

4. Hubungan dinamis, yaitu rangkaian pesan (message) yang di-passing dari satu class kepada class lain. Hubungan dinamis dapat digambarkan dengan menggunakan sequence diagram yang akan dijelaskan kemudian.

Statechart Diagram

Statechart diagram menggambarkan transisi dan perubahan keadaan (dari satu state ke state lainnya) suatu objek pada sistem sebagai akibat dari stimuli yang diterima. Pada umumnya statechart diagram menggambarkan class tertentu (satu class dapat memiliki lebih dari satu statechart diagram).

Dalam UML, state digambarkan berbentuk segiempat dengan sudut membulat dan memiliki nama sesuai kondisinya saat itu. Transisi antar state umumnya memiliki kondisi guard yang merupakan syarat terjadinya transisi yang bersangkutan, dituliskan dalam kurung siku. Action yang dilakukan sebagai akibat dari event tertentu dituliskan dengan diawali garis miring. Titik awal dan akhir digambarkan berbentuk lingkaran berwarna penuh dan berwarna setengah.

Activity Diagram

Activity diagrams menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang, bagaimana masing-masing alir berawal, decision yang mungkin terjadi, dan bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi.

Activity diagram merupakan state diagram khusus, di mana sebagian besar state adalah action dan sebagian besar transisi di-trigger oleh selesainya state sebelumnya (internal processing). Oleh karena itu activity diagram tidak menggambarkan behaviour internal sebuah sistem (dan interaksi antar subsistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas dari level atas secara umum.

Sebuah aktivitas dapat direalisasikan oleh satu use case atau lebih. Aktivitas menggambarkan proses yang berjalan, sementara use case menggambarkan bagaimana aktor menggunakan sistem untuk melakukan aktivitas.

Sama seperti state, standar UML menggunakan segiempat dengan sudut membulat untuk menggambarkan aktivitas. Decision digunakan untuk menggambarkan behaviour pada kondisi tertentu. Untuk mengilustrasikan proses-proses paralel (fork dan join) digunakan titik sinkronisasi yang dapat berupa titik, garis horizontal atau vertikal.

Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu.

Sequence Diagram

Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk pengguna, display, dan sebagainya) berupa message yang digambarkan terhadap waktu. Sequence diagram terdiri atar dimensi vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait).

Sequence diagram biasa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah yang dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu. Diawali dari apa yang men-trigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan.

Masing-masing objek, termasuk aktor, memiliki lifeline vertikal. Message digambarkan sebagai garis berpanah dari satu objek ke objek lainnya. Pada fase desain berikutnya, message akan dipetakan menjadi operasi/metoda dari class. Activation bar menunjukkan lamanya eksekusi sebuah proses, biasanya diawali dengan diterimanya sebuah message.

Untuk objek-objek yang memiliki sifat khusus, standar UML mendefinisikan icon khusus untuk objek boundary, controller dan persistent entity.

Collaboration Diagram

Collaboration diagram juga menggambarkan interaksi antar objek seperti sequence diagram, tetapi lebih menekankan pada peran masing-masing objek dan bukan pada waktu penyampaian message. Setiap message memiliki sequence number, di mana message dari level tertinggi memiliki nomor 1. Messages dari level yang sama memiliki prefiks yang sama.

Component Diagram

Component diagram menggambarkan struktur dan hubungan antar komponen piranti lunak, termasuk ketergantungan (dependency) di antaranya.

Komponen piranti lunak adalah modul berisi code, baik berisi source code maupun binary code, baik library maupun executable, baik yang muncul pada compile time, link time, maupun run time. Umumnya komponen terbentuk dari beberapa class dan/atau package, tapi dapat juga darikomponen-komponen yang lebih kecil. Komponen dapat juga berupa interface, yaitu kumpulan layanan yang disediakan sebuah komponen untuk komponen lain.

Deployment Diagram

Deployment/physical diagram menggambarkan detail bagaimana komponen di-deploy dalam infrastruktur sistem, di mana komponen akan terletak (pada mesin, server atau piranti keras apa), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisikal Sebuah node adalah server, workstation, atau piranti keras lain yang digunakan untuk men-deploy komponen dalam lingkungan sebenarnya. Hubungan antar node (misalnya TCP/IP) dan requirement dapat juga didefinisikan dalam diagram ini.

1.5 Langkah-Langkah Penggunaan UML

Langkah-langkah pembuatan UML (1):

Ø Buatlah daftar business process dari level tertinggi untuk mendefinisikan aktivitas dan proses yang mungkin muncul.

Ø Petakan use case untuk tiap business process untuk mendefinisikan dengan tepat fungsionalitas yang harus disediakan oleh sistem. Kemudian perhalus use case diagram dan lengkapi dengan requirement, constraints dan catatan-catatan lain.

Ø Buatlah deployment diagram secara kasar untuk mendefinisikan arsitektur fisik sistem.

Ø Definisikan requirement lain (non-fungsional, security dan sebagainya) yang juga harus disediakan oleh sistem.

Ø Berdasarkan use case diagram, mulailah membuat activity diagram.

Langkah-langkah pembuatan UML (2):

Ø 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.

Ø Buarlah rancangan user interface model yang menyediakan antarmuka bagi pengguna untuk menjalankan skenario use case.

Ø 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.

Ø 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.

Langkah-langkah pembuatan UML (3):

Ø Perhalus deployment diagram yang sudah dibuat. Detilkan kemampuan dan requirement piranti lunak, sistem operasi, jaringan, dan sebagainya. Petakan komponen ke dalam node.

Ø 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.

Ø Lakukan uji modul dan uji integrasi serta perbaiki model berserta codenya. Model harus selalu sesuai dengan code yang aktual

Ø 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)

KESIMPULAN