Object-Oriented Reengineering Patterns and Techniques Wahyu Andhyka Kusuma, S.Kom Materi 1 Introduction OORP.

Presentasi berjudul: "Object-Oriented Reengineering Patterns and Techniques Wahyu Andhyka Kusuma, S.Kom Materi 1 Introduction OORP."— Transcript presentasi:

1 Object-Oriented Reengineering Patterns and Techniques Wahyu Andhyka Kusuma, S.Kom kusuma.wahyu.a@gmail.com081233148591 Materi 1 Introduction OORP

2 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

3 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

4 1.4 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

5 1.5 Jadwal Perkuliahan

6 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

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

8 1.8 Biaya Perangkat Lunak requirement design coding testing delivery x 1 x 5 x 10 x 20 x 200 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 yang digunakan.

9 1.9 Pengembangan Selanjutnya 17.4% Corrective (fixing reported errors) 18.2% Adaptive (new platforms or OS) 60.3% Perfective (new functionality) data from [Lien78a] 4.1% Other Bagian terbesar dari biaya perbaikan atau pengembangan tergantung fungsionalitas baru

10 1.10 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

11 1.11 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, reusability, maintainability … Tapi ini tidak murah dan mudah

12 1.12 Bagaimana dengan komponen? Komponen dapat menjadi sangat rapu Sampai ada lem yang menyatukannya

13 1.13 process-oriented structured methods, information engineering, data-oriented methods, prototyping, CASE-tools – Bukan OO ! 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

14 1.14 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

15 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

16 1.16 Gejala Umum Kekurangan Pengetahuan 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 Kekurangan Pengetahuan 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 Process symptoms Terlalu lama untuk memproduksi mulai dari awal Membutuhkan bug fixes Memperbaiki dependensi dari sistem difficulties separating products perubahan kecil tapi membutuhkan waktu sangat lama Process symptoms 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 Code symptoms duplicated code code smells  big build times

17 1.17 Permasalahan Umum Permasalahan Arsitektur 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 Permasalahan Arsitektur 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 Peluang Refactoring 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 Peluang Refactoring 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

18 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

19 1.19 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]

20 1.20 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]

21 1.21 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

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

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

24 1.24 Reengineering Life-Cycle

25 1.25 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

26 1.26 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

27 1.27 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

28 1.28 Ringkasan Reuse Reengineering Reengineering Patterns Reverse Engineering Reverse Engineering Patterns

29 © Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Introduction1.29 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. 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.