UML vs DFD

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 menggabungkanmethods 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 methodsmengandung, 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

D.   Karakter UML :

·    Sketsa adalah Jembatan dalam mengkomunikasikan system sehingga akan memiliki gambaran yang sama tentang system

·   Cetak Biru (Blueprint) untuk 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:

·         Use Case View:

o   Mendefinisikan perilaku eksternal system

o   Mengemudikan proses pengembangan perangkat lunak

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

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

·         Design View:

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

·         Komponen:

o   Definisi komponen program

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

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

·         Implementation View:

o   Menjelaskan komponen-komponen fisik dari system yang akan dibangun

o   Komponen Termasuk disini diantaranya file exe, library, & database.

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

·         Process View:

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

·         Deployment View:

o   Menjelaskan tentang komponen-komponen fisik yang didistribusikan ke lingkungan fisik. Contoh: Seperti Jaringan Komputer tempat sistem akan dijalankan.

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

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.

2.       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 :

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

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

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

D.      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 :

·         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

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

·         Diagram Nol (Zero)

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

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