Learn the Rules, Break The Rules, and Create the New Ones...

Hi... My name is Rizky Prihanto. You can call me RQ, or Rizky either. I am currently living on Bandung, Indonesia. Had a lot of works and research about Enterprise Information Systems (majoring on education and e-governments). I have bunch of interests (some friends call it 'freakz') about MySQL Opensource Database and now I am one of the administrator of MySQL Indonesia User Group - the opensource community initialized by Sun Microsystems Indonesia.

My Company PT Cinox Media Insani, Bandung, Indonesia. I work here since 2008 and I take responsibility as Chief of Software Architect. My job is about planning, imaginating, fantasy-ing, concepting, and build the infrastructure of the new information systems (or app engines) which going to be implemented.

This blog This is my blog that represent my current opinion, research and experiences about anything in Software Engineering. Written since 2007 (actually) and has been vaccum for a lot of while. And now I wanna ressurrect this blog (optimistically) from the long-long-hibernation with something fresh and new ideas -- still about MySQL, software engineering, development, and may be something managerial here.

About the tagline I've learned the statement above from some paper written by Kent Beck about Extreme Programming (XP) methodology -- some sort of practical software development methods which have no boundaries. That's very inspiring me a lot. I have written some article on this blog that tell my interpretation about that statement here.

My Another Blogs I have classifying my blogs into some sort of genre. The blog that you read here right now is my primary blog that tell you (majoring) about IT stuff. But if you wanna look another side of me, you can visit here, here, here,or here. Hope it'll be interesting for some of you.

Credits I would thanks to Blogger for this great blog platform. Skinpress who designed this Wordpress template (which is bloggerized by Free Blogger Templates). My appreciate is also going to you who give your generously time for visiting my blog.

Structured Analysis vs Object-Oriented Analysis

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

10 comments:

Anonim mengatakan...

matur suWuun -tau artinya g? :)
artikelnya ok, really helps!

tny dung,
OOA itu kan termasuk metode pengembangan perangkat lunak, proses2 yg ada pada OOA tuh apa ja, trus deliverables dari masing2 proses itu pa?
makasi :)

Saya mengatakan...

Saya mau nanya, OOA,OOD,dan OOP semuanya 1 paketnya?
kalau analisanya OOA,trus programnya prosedural (bukan OOP) bisa ga??

eRQee mengatakan...

@vic:
bisa donk..
OOAD ama OOP itu dasarnya nggak 1 paket.
OOP itu duluan lahir. berawal dari gimana cara 'mengelompokkan' code supaya lebih rapi, mudah dimaintenance dan obyektif.
sedangkan OOAD, itu dikembangkan untuk 'menyederhanakan' proses analisis dan desain. yang mana pas analisis itu dipake pendekatan yg berorientasi ke END USER (nggak nanya "apa sih yang kamu butuhkan?" tapi nanya "apa sih yang kamu lakukan?") dan dikelompok-kelompokkan berdasarkan aktivitas pada pelaku (END USER) itu tadi. juga pas desain, dimana desain di OOAD itu berorientasi ke DEVELOPER/pembuat sistem/coder/programmer dengan menunjukkan "spesifikasi" perangkat lunak yang nggak lagi bernuansa 'bisnis' tapi udah keliatan arsitektur aplikasinya.

OOAD itu diciptakan untuk membantu 'menjembatani' antara analisis+desain dan coding yg dulunya kalo makae pendekatan Structured Analysis itu masih kurang jelas (programmer harus ngerti proses bisnis dan business analyst harus ngerti programming).

Hanif mengatakan...

Ga ada gambarnya apa kk??bgg tulisan smw..
trz cara pake uml tu gmn??
Bgg uml class ma swquence ne

RIdho UIN05 mengatakan...

pada dasarnya OOAD ini diterapan agar alur dari prototyping nya lebih mendekati realitis.. dan bagi para end user dan pengembang sistem akan lebih mudah untuk kembali melalukan pengembangan sistem karna sifat nya yg tidak terstruktur..

nah.. perlu digunakan tools visualisasi dari sistem yang akan di rancang.. bisa seperti Rasional Rose, ArgoUML, Atolva dll..
oiya bagi yang ingin membuat sistem OO dengan menggunakan PHP bisa kamu pake ArgoUML.. free kq..

Anonim mengatakan...

matur trimakasih, artikelnya sangat membantu... ^_^
kebetulan lagi bikin skripsi TI_S1,
dari DFD pindah ke UML...

Anonim mengatakan...

analogi nya sangat mengena mas, mantap penjelasannya. dosen saia ngobrol berjam-jam ga mudeng, baca artikel ini sekali langsung maknyus...

Wiluyaningtyas Wijayanti mengatakan...

Makasih banget artikelnya membantu untuk tahu kenapa OOAD atau SSAD.

software toko mengatakan...

makasih artikelnya...membantu untuk membuat tugas...

HermanW mengatakan...

saran gan :D
bahasaNa pake bahasa formal aja gan,
biar gampang bacanya jg :D

btw, thnks infoNa :)

Posting Komentar