Oleh: jalaludinweb | 10 November 2008

DFD Versus UML ?!

uml2

DFD (Data Flow Diagram) / DAD (Diagram Arus Data) ?

DAD (Diagram Arus Data) adalah suatu modeling tool yang memungkinkan sistem analis menggambarkan suatu sistem sebagai suatu jaringan kerja proses dan fungsi yang dihubungkan satu sama lain oleh penghubung yang disbut alur data.

Fungsi DAD :

1. DAD membantu para analis sitem meringkas informas tentang sistem, mengetahui hubungan antar sub-sub sistem, membantu perkembangan aplikasi secara efektif.

3. DAD dapat menggambarkan sejumlah batasan otomasi untuk pengembangan alternative sistem fisik.

Komponen-komponen DAD

Ada beberapa simbol yang digunakan dalam DFD yang merupakan karakteristik dari suatu sistem, yaitu :

  1. Terminator (External Entity)

Terminator disimbolkan dalam bentuk persegi panjang, yang mewakili entity luar dimana sistem berkomunikasi. Biasanya notasi ini melambangkan orang atau kelompok orang misalnya organisasi diluar sistem, grup, departemen, perusahaan pemerintah, dan berada di luar kontrol sistem yang dimodelkan. Pada sejumlah kasus dapat merupakan sistem lain, sebagai contoh : sistem komputer yang berkomunikasi dengan sistem yang dimodelkan.

  1. Proses

Proses disimbolkan dalam bentuk lingkaran. Melambangkan suatu proses dari data yang dimasukkan ke dalam sistem yang mengubah input menjadi output. Pemberian nama pada proses dengan menggunakan kata kerja transistif (membutuhkan objek).

  1. Penyimpanan Data (Data Store)

Data store disimbolkan dengan garis sejajar, yang digunakan untuk memodelkan kumpulan data atau paket data. Penyimpanan kadangkala didefinisikan sebagai suatu mekanisme diantara dua proses yang dibatasi oleh jangka waktu tertentu.Data store dapat berupa fie/database yang tersimpan dlm disket, harddisk, dll.

  1. Alur data (Data Flow)

Data Flow disimbolkan dengan tanda anak panah, alur ini mengalir diantara proses, data store, dan terminator. Alur data menunjukkan arus data yang dapat berupa masukkan untuk sistem atau hasil proses sistem.

Ada beberapa konsep alur data yang perlu diperhatikan, yaitu : (Jogiyanto,1999)

§ konsep paket dari data (packed of data)

Bila dua atau lebih data mengalir dari suatu sumber yang sama ketujuan yang sama, maka harus digambarkan sebagai suatu alur data tunggal.

§ Konsep alur data menyebar (diverging data flow)

Alur data menyebar menunjukkan sejumlah tembusan dari alur data yang sama dari sumber yang sama ketujuan yang berbeda.

§ Konsep alur data mengumpul (converging data flow)

Alur data yang mengumpul menunjukkan beberapa alur data yang berbeda dari sumber data yang berbeda bergabung bersama-sama menuju tujuan yang sama.

Panah yang bergerak dari penyimpanan berarti : penggunaan data paket tunggal, paket kelompok dan lain-lain. Sedangkan panah yang bergerak ke penyimpanan mendeskripsikan penulisan, perubahan atau penghapusan satu atau lebih paket yang dimasukkan ke penyimpanan sebagai bagian dari paket lama, atau merupakan paket baru, atau satu atau lebih paket dihapus, atau dipindahkan dari penyimpanan, atau merupakan satu atau lebih paket dimodifikasi atau berubah.

Tingkatan DAD

  1. Diagram Konteks

Dimulai dengan diagram konteks yang merupakan level tertinggi (top level), diagram yang menggambarkan hubungan antar system dengan entitas diluar system, merupakan system secara keseluruhan.

  1. Diagram Nol (Zero)

Merupakan proses-proses yang ada didalam system berupa pecahan dari diagram konteks, diagram nol (zero) merupakan rincian dari diagram konteks.

  1. Diagram Rinci/detail/primitive

Menggambarkan rincian tiap proses yang terdapat pada diagram nol, dimana proses rinci ini dapat dipecahkan sampai pada proses yang paling rinci.

UML (Unified Modeling Language) ?

Unified Modeling Language (UML) adalah penerus dari object-oriented analysis and design (OOA&D) methods yang muncul pada akhir ’80 an dan awal ’90 an. UML secara langsung menggabungkan methods dari Booch, Rumbaugh (OMT), dan Jacobson, tetapi menjadi lebih berkembang daripada itu semua. UML berkembang melalui sebuah proses standarisasi yang dilakukan oleh OMG (Object Management Group) dan sekarang memakai standar dari OMG.

UML disebut sebagai bahasa untuk permodelan, bukan sebuah method. Hampir semua methods mengandung, paling tidak dalam beberapa prinsip, dua dari sebuah bahasa permodelan dan sebuah proses. Bahasa permodelan tersebut (terutama yang berbasis grafis) adalah sebuah notasi yang menggunakan methods untuk mengekspresikan sebuah rancangan. Proses tersebut adalah tuntunan yang mereka lakukan dalam setiap langkah untuk merancang sesuatu.

Bagian daripada proses untuk UML dari beberapa buku hanyalah bersifat sketsa saja. Lebih jauh lagi beberapa orang menyatakan kalau mereka menggunakan sebuah method pada kenyataannya mereka menggunakan UML, tetapi tidak benar-benar mengikuti proses yang terjadi. Jadi dalam berbagai cara, UML merupakan bagian yang paling penting dari method. Itu merupakan kunci utama dari komunikasi yang ada. Ketika kita akan membahas design kita pada seseorang, UML dapat kita gunakan untuk menjelaskan design kita kepada seseorang tersebut, bukan proses yang kita gunakan.

Ada tiga orang yang juga mengembangkan sebuah unified process, mereka menyebutnya Rational Unified Process (RUP). Kita tidak harus menggunakan Rational Unified Process dalam rangka menggunakan UML mereka benar-benar terpisah. Dalam artikel ini, walau bagaimanapun kita membicarakan sedikit mengenai proses teknik-teknik yang digunakan oleh bahasa permodelan dalam pelaksanaannya. Masih dalam artikel ini kita juga menggunakan langkah-langkah dasar dan istilah-istilah dari RUP, tetapi artikel ini bukanlah membahas RUP.

Sekitar era ’80 an, konsep-konsep mengenai object sudah mulai dipublikasikan dan digunakan dalam applikasi nyata. Smalltalk sudah mulai digunakan untuk mengaplikasikan konsep mengenai object tersebut dan lahirlah C++.

Seperti pada banyak pengembangan dalam software, konsep object tersebut digerakkan oleh bahasa-bahasa pemrograman. Banyak orang mencari-cari bagaimana sebuah method design dapat diaplikasikan menurut konsep object-oriented. Design methods menjadi sesuatu yang sangat populer pada industri pengembangan software pada ’70 an dan ’80 an. Beberapa merasa kalau teknik-teknik yang membantu dalam analisa dan design yang baik juga sangat berguna dalam pengembangan berdasarkan object-oriented.

Buku-buku yang berpengaruh pada object-oriented analysis dan design methods muncul antara tahun 1988 dan 1992 :

  • Sally Shlaer dan Steve Mellor menulis sepasang buku (1989 dan 1991) pada analysis dan design; materi dalam buku-buku itu telah berevolusi dalam pendekatan Recursive Design mereka (1997).
  • Peter Coad dan Ed Yourdon juga menulis sepasang buku yang mengembangkan Coad’s lightweight dan pendekatan prototype-oriented untuk methods. Lihat Coad dan Yourdon (1991a dan 1991b), Coad dan Nicola (1993), dan Coad dan lain-lain (1995)
  • Komuniti smalltalk di Portland, Oregon, menghasilkan Responsibility-Driven Design (Wirfs-Brocket 1990) dan Class-Responsibility-Collaboration (CRC) cards (Beck dan Cunningham 1989).
  • Grady Booch telah bekerja keras dalam mengembangkan Rational Software yang disebut Ada systems. Buku karangannya menampilkan beberapa contoh (dan ilustrasi karton terbaik dalam dunia buku-buku tentang methods). Lihat Booch (1994 dan 1996).
  • Jim Rumbaugh memimpin sebuah team pada lab penelitian di General Electric, yang mana menghasilkan sebuah buku yang sangat terkenal mengenai sebuah method yang disebut Object Modeling Technique (OMT). Lihat Rumbaugh (1991) dan Rumbaugh (1996).
  • Jim Odell berdasarkan dari buku-bukunya (yang ditulis bersama dengan James Martin) menggambarkan perjalanan karirnya dalam business information systems dan Information Engineering. Hasilnya adalah sebuah konsep yang matang dalam buku-buku tersebut. Lihat Martin dan Odell (1994).
  • Ivar Jacobson membuat bukunya berdasarkan pengalamannya pada telephone switches dari Ericsson dan memperkenalkan konsep penggunaan kasus-kasus pada saat pertama kali. Lihat Jacobson (1992 dan 1995).

Cara kerja UML adalah dengan mendefinisikan notasi dan sebuah meta-model.

Notasi tersebut adalah model-model yang direpresentasikan dalam bentuk grafis, ini adalah syntax untuk bahasa permodelan. Untuk contohnya, notasi class diagram mendefinisikan bagaimana item-item dan konsep-konsep seperti class, association, dan multiplicity direpresentasikan.

Tentu saja, ini semua mengarah kepada pertanyaan apakah sebenarnya yang dimaksud dengan sebuah association atau multiplicity atau bahkan sebuah class. Para pengguna umumnya menyarankan beberapa definisi-definisi informal, tetapi banyak orang menginginkan informasi yang lebih daripada itu semua.

Ide dari bahasa spesifikasi dan design yang tepat adalah sangat relevan dalam bidang sebuah formal method. Didalam sebuah teknik, design, dan specifications telah direpresentasikan dengan menggunakan turunan dari predicate kalkulus. Definisi tersebut telah dimatematikakan dengan tepat dan tidak ada duanya. Walau bagaimanapun nilai dari definisi ini bukanlah merupakan sesuatu yang universal. Walaupun kita dapat membuktikan bahwa program tersebut dapat membuktikan sebuah spesifikasi matematika yang benar, tidak mungkin ada sebuah cara untuk membuktikan kalau spesifikasi matematika itu dapat memenuhi syarat yang dibutuhkan sebuah system.

Design adalah tentang menemukan masalah-masalah kunci yang dihadapi pada development. Formal methods sering kali membuat putus asa dengan cara banyak memberikan detil-detil yang tidak penting. Juga formal methods sangat sulit untuk dipelajari dan dimanipulasi, juga lebih sulit dihadapi daripada bahasa pemrograman. Dan kita juga tidak dapat menjalankannya.

Kebanyakan methods object-oriented mempunyai sedikit kekakuan, notasi mereka lebih berdasarkan intuisi daripada definisi yang formal. Dalam keseluruhannya, ini semua tampak tidak menimbulkan kerusakan. Methods ini mungkin informal, beberapa orang menemukan kalau semua ini masih berguna dan kegunaannya itulah yang diperhitungkan.

Walau bagaimanapun, orang-orang yang menggunakan methods OO selalu mencari jalan untuk meningkatkan methods yang kaku tersebut tanpa mengurangi kegunaannya. Salah satu cara untuk melakukannya adalah dengan mendefinisikan meta-model : sebuah diagram, yang biasanya adalah sebuah diagram class, yang mendefinisikan notasi tersebut. (**)

A. Hasil konsorsium berbagai organisasi yang dijadikan standar baku dalam OOAD –Object Oriented Analysis & Design – adalah UML.

B. Notasi grafis yang dibakukan –open standart—dikontrol oleh OMT –Object Management Group—sebuah badan yang telah membakukan CORBA –Commont Object Request Broker Architecture.

C. Kontribusi UML dalam perusahaan-perusahaan :

· Digital Equioment Corp.

· Hawlet Packard Company

· I-Logic

· Intell Corp.

· IBM

· Icon Computing

· Microsoft

· Rational Software

· Dll…

D. Karakter UML:

· Sketsa

Jembatan dalam mengkomunikasikan system sehingga akan memiliki gambaran yang sama tentang system

· Cetak Biru (Blueprint)

Mengetahui informasi detail tentang coding program –forward engineering—dan membaca program serta menginterpretasikan kembali ke dalam diagram –reserve engineering.

Fungsi Reserve Engineering: Apabila terjadi situasi dimana code program yang tidak terdokumentasikan –karena dokumentasi hilang atau belum dibuat sama sekali– membutuhkan modifikasi (pemeliharaan)

· Bahasa Pemrograman

UML dapat menterjemahkan diagram menjadi code program yang siap untuk dijalankan.

E. UML dibangun atas model 4+1 view:

[1]. Use Case View:

* Mendefinisikan perilaku eksternal system

** Mengemudikan proses pengembangan perangkat lunak

*** Mendefinisikan kebutuhan system karena mengandung semua view yang lain yang medeskripsikan aspek-aspek tertentu dari rancangan system.

“Informasi yang terkandung menjadi daya tarik bagi end-user, analist dan tester.”

[2]. Design View:

* Mendeskripsikan Struktur Logika yang mendukung fungsi-fungsi yang dibutuhkan Use Case.

Komponen:

– Definisi komponen program

– Class-class utama bersama spesifikasi data, perilaku dan interaksinya.

“Informasi yang terkandung menjadi perhatian programmer karena menjelaskan secara detil fungsionalitas system akan diimplementasikan”

[3]. Implementation View:

* Menjelaskan komponen-komponen fisik dari system yang akan dibangun

Komponen: – Termasuk disini diantaranya file exe, library, & database.

“Informasi yang terkandung relevan dengan aktifitas-aktifitas seperti manajemen, konfigurasi dan integrasi sistem”

[4]. Process View:

* Berhubungan dengan hal-hal yang berkaitan dengan concurrency di dalam sistem.

[5]. Deployment View:

* Menjelaskan tentang komponen-komponen fisik yang didistribusikan ke lingkungan fisik.

Contoh: Seperti Jaringan Komputer tempat sistem akan dijalankan.

“Process & Deployment View menunjukan kebutuhan non fungsional langsung dari sistem. Seperti: kesalahan dan hal-hal yang berhubungan dengan kinerja.”

Keterangan:

1. Use case view memegang peranan khusus untuk mengintegrasikan konten ke view yang lain.

2. Kelima view tidak berhubungan dengan diagram yang dideskripsikan di UML.

3. Setiap view berhubungan dengan perspektif tertentu system akan diuji. (**)

Saya kira perusahaan-perusahaan besar pada umumnya mempunyai standar proses pengembangan software yang secara umum biasanya disebut SDLC (Software Development Life Cycle). Di beberapa perusahaan yang manajemen TI nya sudah mapan, SDLC tersebut biasanya diterapkan secara konsisten baik untuk pengembangan software oleh pihak internal, maupun pengembangan software yang melibatkan pihak eksternal (outsourcing). SDLC yang diterapkan secara ketat secara tidak langsung akan meningkatkan kualitas software yang dihasilkan. Bagian dari SDLC juga mensyaratkan adanya dokumentasi software yang baik.

Apakah SDLC saja serta keberadaan dokumentasi software sudah cukup? Jawabannya biasanya baru diketahui setelah ada masalah-masalah berkaitan dengan software aplikasi yang sudah pernah dibuat. Beberapa permasalahan tipikal diantaranya adalah sebagai berikut:

  1. Dokumentasi software ternyata tidak lengkap, ada bagian penting dari software yang tidak dijelaskan dengan cukup, sehingga sulit untuk memahaminya.
  2. Format dan struktur dokumen berbeda-beda
  3. Cara pemodelan berbeda-beda. Mungkin ada yang masih menggunakan flowchart + ER Diagram saja, ada yang menambahkan Data Flow Diagram (DFD), ada yang mencampur adukan UML dengan DFD, atau ada yang secara penuh sudah menerapkan UML.

Permasalahan-permasalahan tersebut di atas akan menghambat tujuan-tujuan sebagai berikut:

  1. Melakukan modifikasi software menjadi sulit dilakukan. Kadang perusahaan ingin melakukan modifikasi kecil dari software yang sudah dibuat dan sudah diluar masa garansi. Tapi sulit dilakukan karena hambatan dokumentasi.
  2. Melakukan pengembangan lebih lanjut menggunakan vendor lain. Dokumentasi yang buruk, yang hanya dimengerti oleh pembuatnya saja, menyulitkan dipahami oleh pihak lain yang akan meneruskan pekerjaan tersebut.
  3. Melakukan integrasi dengan aplikasi lain. Ketika sistem berkembang dan ada tuntutan integrasi, dokumentasi yang buruk mungkin akan menyulitkan untuk memahami struktur data, cara berkomunikasi data, apalagi kalau ada keperluan modifikasi algoritma untuk mencapai tujuan integrasi.

Bagaimana solusinya? Sederhana!

Buatlah standar (template) dokumentasi pengembangan software aplikasi di perusahaan anda. Standar dokumentasi berbeda dengan standar proses pengembangan (SDLC).

Semua pengembangan software, baik yang dilakukan oleh pihak internal maupun cara outsource harus membuat dokumentasi sesuai standar tersebut. Hal yang harus diingat adalah:

Jangan membuat standar dokumentasi yang bentuknya tidak biasa. Saya sarankan untuk mengadopsi dari suatu standar, lalu lakukan penyesuaian minor. Untuk pemodelannya, saya menganjurkan untuk menggunakan UML secara penuh.

Nah, kalau ini sudah tercapai, anda buka dokumen software manapun selalu sama bentuknya dan kelengkapannya cenderung lebih terjamin karena mengikuti template yang sudah ada. (*) <Posted by Asep Jalaludin>

<Sumber:https://jalaludinweb.wordpress.com,kupalima.wordpresom, jogjagenit.wordpress.com, http://www.ristinet.com&gt;

Semoga bermanfaat.


Responses

  1. DFD Versus UML

    Btw Btw kelebihan dan kekurangna masing2 kok ga disebutin yah? terus kira2 lebih bagus yang mana?
    Soalnya judulnya DFD Versus UML

  2. kalau boleh tolong add dunk ke email saya (ann3_cantik@yahoo.co.id)tentang skripsi menggunakan UML beserta softwarenya ya mas. thax b4

  3. makasih gan infonya

  4. Good post. I am facing a few of these issues as well.

    .


Tinggalkan Balasan

Isikan data di bawah atau klik salah satu ikon untuk log in:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s

Kategori

%d blogger menyukai ini: