Object-Oriented Reengineering Patterns and Techniques Wahyu Andhyka Kusuma, S.Kom
[email protected] 081233148591
Materi 1 Introduction OORP
Topik • Tujuan dari perkuliahan • Mengapa Reengineer? – Lehman's Laws – Object-Oriented Legacy • Masalah Khusus – Keadaaan Umum – Permasalahan Arsitektur & Refactoring • Reverse and Reengineering – Definisi – Teknik – Pola
Topik • Tujuan dari perkuliahan • Mengapa Reengineer? – Lehman's Laws – Object-Oriented Legacy • Masalah Khusus – Keadaaan Umum – Permasalahan Arsitektur & Refactoring • Reverse and Reengineering – Definisi – Teknik – Pola
Tujuan Perkuliahan Tujuan utama dari perkuliahan:
• Reverse engineering and reengineering adalah kegiatan inti dari daur hidup dari semua perangkat lunak termasuk juga Object Oriented • Bagaimana Reengineering digunakan untuk mengidentifikasi masalah • Bagaimana reengineering digunakan untuk membangun kembali sistem untuk memenuhi kebutuhan baru • Banyak lightweight tools and techniques yang membantu dan digunakan dalam reengineering.
• Meskipun dengan tools tersebut seseorang tetap harus bekerja sesuai dengan tugasnya • Bagaimana suatu pattern digunakan untuk mentransformasikan kode untuk memenuhi kebutuhan baru 1.4
Jadwal Perkuliahan
1.5
Topik • Tujuan dari perkuliahan • Mengapa Reengineer? – Lehman's Laws – Object-Oriented Legacy • Masalah Khusus – Keadaaan Umum – Permasalahan Arsitektur & Refactoring • Reverse and Reengineering – Definisi – Teknik – Pola
Apa itu Legacy System ? “legacy” legacy kb. (j. -cies) warisan, harta pusaka/peninggalan. to come into a l. mewarisi. Legacy System adalah bagian dari software yang: • Anda telah inherited • valuable untuk Anda. Permasalahan yang timbul dengan legacy systems: • Pengembang asli tidak ada (dalam keadaan tertentu) • Metode yang digunakan kemungkinan sudah kadarluarsa • Pencarian dan modifikasi mungkin akan dilakukan • Dokumentasi yang mungkin sudah hilang atau tidak berlaku
Evolusi dan pengembangan selanjutnya bisa jadi sangat mahal 1.7
Biaya Perangkat Lunak •Sekitar 60% untuk biaya pengembangan, 40% biaya pengujian. •Untuk perangkat lunak berbasis pengguna (custom), biaya evolusi biasanya melebihi biaya pengembangan. •Biaya beragam tergantung pada tipe sistem yang akan dikembangkan dan kebutuhan sistem seperti unjuk kerja dan kehandalan sistem, •Distribusi biaya bergantung pada model pengembangan x 20 yang digunakan.
x 200
x 10 x5 x1 requirement coding delivery 1.8 design testing
Pengembangan Selanjutnya 4.1% Other
data from [Lien78a]
18.2% Adaptive (new platforms or OS)
17.4% Corrective (fixing reported errors)
60.3% Perfective (new functionality)
Bagian terbesar dari biaya perbaikan atau pengembangan tergantung fungsionalitas baru 1.9
Lehman's Laws Studi dari Lehman and Belady [Lehm85a] mengidentifikasi beberapa “laws” dari sistem perubahan. Continuing change • Program yang digunakan dalam dunia nyata harus selalu berubah, atau jika tidak secara bertahap tidak akan digunakan dan akan ditinggalkan Increasing complexity • Sebagai sebuah program yang terus berkembang, hal tersebut akan menjadi kompleks dan kebutuhan ekstra akan dibutuhkan untuk memelihara dan menyederhanakan strukturnya
1.10
Bagaimana tentang sebuah Obyek? Object-oriented legacy systems • OO lebih peka terhadap perubahan akan arsitektur dan desainnya Dibandingkan dengan tradisional legacy systems (AKA Structured, Fungsional) • Antara gejala dan sumber dari permasalahan adalah sama • Antara Solusi dan Detail Teknis mungkin akan berbeda Teknik dari OO menjanjikan yang terbaik • flexibility, Tapi ini tidak murah dan mudah • reusability, • maintainability • … 1.11
Bagaimana dengan komponen?
Komponen dapat menjadi sangat rapu Sampai ada lem yang menyatukannya
1.12
Modern Methods & Tools ? [Glas98a] kutipan dari Sasa Dekleva (1992) • Modern methods(*) memberikan jaminan untuk more reliable softwaree • Modern methods memberikan jaminan untuk less frequent software repair • and ... • Modern methods memberikan jaminan untuk more total maintenance time
process-oriented structured methods, information engineering, data-oriented methods, prototyping, CASE-tools – Bukan OO !
1.13
Bagaimana mengembangkan Legacy System ? Memperbaharui atau merubah Requirements akan mempengarui desain asli, dan akan membutuhkan usaha ekstra untuk beradaptasi New Functionality Hack it in ?
• • • •
duplicated code complex conditionals abusive inheritance large classes/methods
First … • refactor • restructure • reengineer
1.14
Topik • Tujuan dari perkuliahan • Mengapa Reengineer? – Lehman's Laws – Object-Oriented Legacy • Masalah Khusus – Keadaaan Umum – Permasalahan Arsitektur & Refactoring • Reverse and Reengineering – Definisi – Teknik – Pola
Gejala Umum Kekurangan Pengetahuan
Process symptoms
•
•
• • • •
Sudah tidak terpakai atau tidak ada dokumentasi Membangun dari awal Hilangnya atau tidak ada pengetahuan tentang sistem Keterbatasan pengetahuan tentang sistem Tidak ada dokumentasi testing
• • •
Terlalu lama untuk memproduksi mulai dari awal Membutuhkan bug fixes Memperbaiki dependensi dari sistem difficulties separating products perubahan kecil tapi membutuhkan waktu sangat lama
Code symptoms • •
duplicated code code smells big build times
1.16
Permasalahan Umum Permasalahan Arsitektur
Peluang Refactoring
•
•
•
• • •
Tidak ada documentation = tidak ada atau kadarluarsa Lapisan yang salah = terlalu sedikit atau terlalu banyak Tidak ada modularitas = hanya asal menggabungkan duplicated code = copy, paste & edit code duplicated functionality = fungsional yg sama di tim yang berbeda
• • •
•
Penyalahgunaaninheritance = code reuse vs polymorphism Hilangnya inheritance = Duplikasi, case-statements Operasi yang salah tempat = Operasi diluar kelas Pelanggaran encapsulation = type-casting; C++ "friends" Penyalahgunaan class = classes as namespaces
1.17
Topik • Tujuan dari perkuliahan • Mengapa Reengineer? – Lehman's Laws – Object-Oriented Legacy • Masalah Khusus – Keadaaan Umum – Permasalahan Arsitektur & Refactoring • Reverse and Reengineering – Definisi – Teknik – Pola
Sebuah Terminologi “Forward Engineering tradisional proses bergerak dari high-level abstractions dan logical mengimplementasikan desain kedalam physical didalam sistem.” “Reverse Engineering adalah sebuah proses menganalisa sebuah sistem untuk diidentifikasi komponen dari sistem dan hubungan didalamnya juga membuat representasi dari sistem didalam sebuah Form atau didalam abstraksi yang lebih tinggi.” “Reengineering ... Pengujian dan perubahan dari sebuah sistem untuk disusun kembali kedalam sebuah Form baru dan diimplementasikan kedalam suatu sistem yang baru.” — Chikofsky and Cross [in Arnold, 1993] 1.19
Tujuan dari Reverse Engineering • Mengatasi complexity – Butuh sebuah teknik khusus untuk memahami sistem yang besar dan komplek
• Menghasilkan sudut pandang yang berbeda – Menghasilkan cara yang berbeda dalam memandang sebuah sistem
• Menanggulangi informasi yang hilang – Menggali apa yang telah terjadi dan bagaimana prosesnya
• Mendeteksi efek samping – Membantu memahami efek samping dari perubahan
• Menyatukan Abstraksi – Mengidentifikasi abstraksi yang tersembunyi didalam sebuah software
• Memudahkan reuse – Mendeteksi kandidat reusable dari komponen — Chikofsky and Cross [in Arnold, 1993]
1.20
Teknik Reverse Engineering • Redocumentation – Dokumentasi yang bagus – Penambahan diagram, tabel, chart – Penambahan list atau tabel untuk cross-reference scripting
• Design recovery – software metrics – browsers, visualization tools – static analyzers – dynamic (trace) analyzers
1.21
Tujuan Reengineering • Unbundling – Memecah monolithic sistem kedalam bagian-bagian yang bisa dijual terpisah • Performance – “first do it, then do it right, then do it fast” — pengalaman menunjukkan bagaimana sistem dapat bekerja sempurna! • Port to other Platform – Arsitektur harus dibedakan untuk tiap platform tergantung dari modulny • Design extraction – Untuk mempermudah maintainability, portability, dll. • Exploitation of New Technology – contoh, new language features, standards, libraries, dll.
1.22
Teknik Reengineering • Restructuring – Konversi dari unstructured ke structured code – source code translation — Chikofsky and Cross
• Data reengineering – Integrasi dan pemusatan (penggabungan) banyak database – Menyatukan beberapa tidak konsekwennya representasi – upgrading data model — Sommerville, ch 32
• Refactoring – renaming/moving methods/classes dll.
1.23
Reengineering Life-Cycle
1.24
Reverse engineering Patterns Reverse engineering patterns menyatukan keahlian dan kemampuan dalam mengeksplorasi desain dari source code, running systems dan sumber daya. – Setiap dokumentasi yang ada biasanya tidak sesuai dengan realitanya. Contoh: Interview During Demo
1.25
Reengineering Patterns Reengineering patterns Menyatukan keahlian dan kemampuan dalam transforming legacy code untuk menyelesaikan masalah yang ada. – Masalah ini biasanya tidak terlihat didalam desain asli tetapi tergantung dari penyimpangan arsitektur termasuk juga perkembangan arsitektur Contoh: Move Behaviour Close to Data
1.26
Rangkaian Reengineering Patterns Tests: Your Life Insurance Detailed Model Capture
Initial Understanding
First Contact
Setting Direction
Migration Strategies
Detecting Duplicated Code Redistribute Responsibilities
Transform Conditionals to Polymorphism 1.27
Ringkasan • Reuse
• Reengineering • Reengineering Patterns • Reverse Engineering
• Reverse Engineering Patterns
1.28
License • http://creativecommons.org/licenses/by-sa/2.5/
Attribution-ShareAlike 2.5 You are free: • to copy, distribute, display, and perform the work • to make derivative works • to make commercial use of the work Under the following conditions: Attribution. You must attribute the work in the manner specified by the author or licensor.
Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one. • For any reuse or distribution, you must make clear to others the license terms of this work. • Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above. © Stéphane Ducasse, Serge OORPT — Introduction Demeyer, Oscar Nierstrasz
1.29
