Structured Analysis vs Object-Oriented Analysis Posted on : 1/16/2008 01:50:00 PM

Nie artikel sbnernya pernah aku tulis n post utk forum ilmu komputer nya Unmul di www.fmipa-unmul.web.id/forum ~ sayang last time I checked tu forum sepertinya kehapus (ato dihapus). Berhubung tu artikel sayang bangedd klo ngga di-index google (bagus loo isinya... ^_^ hehehe, promosi), makanya aku re-post di sini. Semoga bermanfaat.

NB : maaf beberapa dialog ilustrasi sengaja kutulis dengan bahasa banjar samarinda (this is my lingua franca). aku ngga pengen men-translate-nya utk menjaga originalitas, disamping pertimbangan karna bahasa banjar samarinda tu mudah dipahami bahkan oleh orang2 yg ngga pernah ndenger gimana itu bahasa banjar...

ok, let's go...
___________________

Kadang muncul suatu pertanyaan, apa sih bedanya structural analysis dengan object-oriented analysis? Klo structural (sebenarnya istilah ini kurang tepat sih - tapi berhubung Ed Yourdon -- master zen nya software designer -- jg memakai istilah 'structured analysis' ini, maka it's okay lah...), tools perancangannya makae DFD. Sedangkan klo object-oriented biasanya make notasi UML.

*sebenarnya poin mendasar dari perbedaan antara DFD dan UML itu 'cuman' di sudut pandang analisis doank... Jadi begini,

DFD

utk mendaftar keperluan sistem, analis yg makae DFD sebagai tools nya selalu berpijak pada TOPIK UMUM dari sistem, baru kemudian mikirin detailnya. sebagai contoh, misal -- mo bikin aplikasi perpus. Yg didaftarin dulu itu adalah kegiatan2 utama-nya dulu seperti :
1. Ada pendaftaran anggota
2. Ada pencatatan buku
3. Ada transaksi

n setelah itu, baru dipikirin detailnya :
1. eh, di pendaftaran anggota ada :
>> 1.1. isi biodata
>> 1.2. bikin kartu perpus
>> 1.3. ada juga perpanjangan anggota
2. trus, di pencatatan buku sekalinya ada :
>> 2.1. pembelian buku
>> 2.2. penerimaan buku sumbangan
>> 2.3. kategorisasi
>> 2.4. katalogisasi
3. en di transaksi ternyata ada :
>> 3.1. peminjaman
>> 3.2. pengembalian
>> 3.3. perpanjangan
>> 3.4. denda

nah, acuannya dari topik umum. Makanya di tahapan mbikin DFD paling awal jatohnya slalu disuruh bikin Context Diagram...

trus klo UML ?

UML

berbeda dengan orientasi struktural, analisis berorientasi object menganalisis kebutuhan sistem acuannya dari object2 sistem. Apa aja object dalam sistem perpustakaan? menentukan mana yg object di sini sama aja kya menentukan rangkaian kalimat itu mana2 aja bagian S.P.O.K.

1. buku adalah object
2. anggota juga object
3. petugas perpus (?) hmm, sepertinya object jg. tp lebih tepat klo dibilang *subject*. ditampung aja doeloe...

pengertian object di sini sebenarnya bisa dianalogikan sbg "apa-apa n siapa2 aja sih yg dipengaruhi ama sistem informasi" - trus secara konkuren juga dipikirkan "apa-apa aja n siapa aja yg *mempengaruhi* sistem informasi itu"?

akhirnya didapatlah daftar object seperti di atas itu. Trus, stlh itu, utk masing-masing object itu trus dipikirkan "kegiatan/event" apa yg berhubungan dgn object tersebut.
1. Buku
>> 1.1. dipinjam
>> 1.2. dibalikin
>> 1.3. diperpanjang masa pinjamnya
>> 1.4. dikategorikan
>> 1.5. dikatalogkan (didata spek nya, n mgkn ditulis sinopsisnya)
>> 1.6. disumbangkan dari anggota
>> 1.7. dihilangkan/dirusak/di-embat ^_^
>> 1.8. dibeli dari toko buku
>> 1.9. dimutasi ke sekolah2 (kedaluwarsa, mgkn...)

trus anggota bisa ngapain aja?:
2. Anggota
>> 1.1. minjem buku
>> 1.2. mbalikin buku
>> 1.3. merpanjang masa pinjam
>> 1.4. nyumbangin buku
>> 1.5. nyolong buku (ini mungkin kan? maka tulislah!)
>> 1.6. nyari-nyari buku di katalog online
>> 1.7. mesan buku/request (kali aja buku yg mo dipinjam sedang dipinjam anggota lain)
>> 1.8. oia, ndaftar
>> 1.9. dapet kartu anggota
>> 1.10. perpanjangan masa keanggotaan
>> 1.11. nghilangin kartu, jd harus bikin baru
>> 1.12. ... sementara ini dulu ... ntar ditambah

*satu kelebihan perspektif analisis berorientasi object ini, utk dapetin analisa sistem secara lengkap kita cukup NANYA sama object2nya (tentu nanya nya ke object yg bisa berbicara)...

T : "waal, ikam anggota perpus klo?"
J : "hi-ih"
T : "beapa aja ikam biasanya di sana?"
J : "emmm.... pacaran ^_^"
T : "oooo..."

... berarti ada yg harus ditambah dalam event-list di atas... :
>> 1.12. pacaran di dalam perpus...

hehehe...

oke, dilanjut...
sekarang kita mulai nanya2in petugas perpus sbg object ketiga. (proses wawancara d sini sengaja di-off-the-record-kan). n akhirnya didapat event-list nya sbb :

3. petugas
>> 3.1. nyatet registrasi anggota
>> 3.2. perpanjangan anggota
>> 3.3. bikinkan kartu anggota
>> 3.4. ndata buku
>> 3.5. nyusun buku di rak2 yg sesuai kategori
>> 3.6. ngerapikan buku
>> 3.7. nyapu perpus
>> 3.8. minjemkan buku
>> 3.9. nerima buku yg dibalikin
>> 3.10. nagih buku yg lom dibalikin
>> 3.11. syarikin bubuhannya yg ngilangin buku, tuntut suru nggantiin...
>> 3.12. ndenda anggota
>> 3.13. nerima buku sumbangan anggota
>> 3.14. beli buku

>> 3.15. sumbangin buku2 yg kda payu, rewa, kuno, yg kda-bangedd-deh-ach-utk-layak-dibaca-hare-gene...

>> 3.16. apa lagi ya laennya. Nyusul aja dulu dah...

nah, dari event list di atas, tentu kesannya lebih mudah kan utk gathering fakta dengan acuan Object-Oriented Analysis & Design ketimbang structural? Iya. bener... Tp kekurangannya juga ada (bukan kekurangan sih sbnernya, lebih tepatnya KONSEKUENSI) -- fakta yg didapat bisa jadi melebar dari scope sistem, jadi musti dikelompokin, trus didefinisiin mana2 yg layak utk "di-interface-kan" dalam aplikasi komputerisasi, mana2 yg tetep dibiarin "dijalanin secara manual"... Masa nyapu2 perpus mau dikomputerkan? kan kada kawa tuh...

Klo udah, u bisa mulai menuangkannya ke notasi UML, dengan diagram use-case (gambar aktor -- object sistem -- ngapa2-in aja). N ke class diagram: object ini punya atribut apa2 aja, trus event (istilah resmi-nya : methods) nya apa-apa aja...

Secara sederhana, yg dari atas sampe bawah ini aku ceritakan nih gini :
Analisis struktural, dengan DFD, itu orientasinya TOP-DOWN analysis. dari atas dispesialisasikan ke bawah. sedangkan analisis object, dengan UML, itu orientasinya BOTTOM-UP. dari bawah digeneralisasikan ke atas. hasil akhirnya bisa dibilang sama.

Trus kenapa ada OOAD? kyanya lebih sederhana DFD deh...

hal ini tiada lain tiada bukan akibat seringnya terjadi gap ketika proses analisis dilaksanakan. Untuk bisa mendapatkan DFD yg benar2 udah mencakup semua aspek yg terjadi dalam suatu sistem informasi, sulit bangedd klo ngga dibantu ama client yg benar2 menguasai jalannya proses bisnis dalam aliran sistem informasi itu. Klo pendekatan kita makae yg struktural, jenis pertanyaan nya akan menjadi kira-kira seperti ini :

T : mas, di perpus ini kegiatan2 yg biasa dilakukan apa aja?
J : yah, biasa lah mas.. masa ngga tau.
T : apa2 aja mas, tolong ceritakan. saya mo bikin sistemnya nih.
J : ya ada pendaftaran anggota, peminjaman, pengembalian, ya kadang nerima sumbangan, ya kadang nyetak kartu...
T : klo yg berkaitan dengan buku apa aja mas?
J : wah klo itu sih setau saya cuman mendata buku yg masuk, trus mengklasifikasikannya, di kode kan, udah...
T : ndak ada yg laen kah mas? apa cuman itu aja?
J : bah hay, unda nie kda terlalu tau proses bisnis nya. ikam wani mbayar unda brapa grang?
T : wah nggak gitu mas, kami kan cuman mau analisis, utk kelengkapan persiapan mbikin aplikasi komputerisasi perpus nya mas...
J : oo, ikam ternyata programmernya. wah banyak duitnya tuh. bagi2 pang. kan unda udah mbantuin tadi... lah? jangan skhen-chee ikam... kita kan kawalan... xixixi...

ya begitulah, nyaris semua tahap analisis sistem informasi, utk semua tema, ketika interaksi dengan user untuk minta daftar kebutuhan sistemnya, user BANYAK yang ngga tau proses bisnis yg terjadi d sana itu apa2 aja.. klo ditanya "apa yg dia butuhkan", yg dijawab malah "apa yg dia inginkan"..

makanya semua praktisi pengembangan sistem perangkat lunak banyak yg memilih pendekatan object. klo di-istilahkan itu mirip dengan "pendekatan personal". man-to-man... analis ngga membebani user dengan pertanyaan2 seputar proses bisnis yg ada dalam konteks sistem informasi yg mo dikembangkan, melainkan "hanya" menanyakan seputar "apa yang mereka lakukan dalam kesehariannya"...

begitulah kira-kira filosofinya...
______________________________

oia, ini ada kutipan bagus dari situs nya Yourdon tadi : “A good painter knows when to stop painting,” -- dia bikin artikel menarik yang judunya "Just Enough Structural Analysis" yg bs didonlot dalam versi PDF di sini. hehehe, very inspiring, IMHO... (kadang pengen bangedd punya dosen yg 'gaul' kya dia itu. kultur akademis kita masih terlalu baku. terlalu protokoler...) -- mgkn ttg ini akan aku bahas di postingan lain deh...

Bye, n happy wednesday...