Machine Translated by Google

everse Engineering adalah everse Forward Engineering

Ira D. Baxter Michael Mehlich
Semantic Designs, Inc.
12636 Research Blvd, #C-214
Austin, TX 78759-2200
{ idbaxter,mmehlich } @ semdesigns.com

Abstrak tems sulit untuk dimodifikasi dan modifikasi sulit untuk divalidasi.

Reverse Engineering difokuskan pada tugas yang

menantang untuk memahami kode program lama tanpa
memiliki dokumentasi yang sesuai. Menggunakan perspektif
rekayasa ke depan transformasional, kami memperoleh
wawasan bahwa sebagian besar kesulitan ini disebabkan
oleh keputusan desain yang dibuat selama pengembangan
sistem. Keputusan seperti itu "menyembunyikan" fungsi
program dan persyaratan kinerja dalam sistem $nul dengan
menerapkan penyempurnaan berulang melalui lapisan
abstraksi, dan optimasi penyebaran informasi, yang keduanya
mengubah representasi dan memaksa entitas program
tunggal untuk menghasilkan banyak tujuan. Untuk dapat
merekayasa balik; kita pada dasarnya harus membalikkan
keputusan desain ini. Mengikuti pendekatan transformasional,
kita dapat menggunakan transformasi dari metodologi metode
rekayasa maju dan menerapkannya "mundur" ke kode
rekayasa balik ke spesifikasi yang lebih abstrak. Karena
sebagian besar kode yang ada tidak dihasilkan oleh sintesis
transformasional, ini menghasilkan desain transformasional
formal yang masuk akal daripada desain aktual penulis asli.
Produk sampingan dari proses rekayasa balik transformasional
adalah database desain untuk program yang kemudian dapat
dipertahankan untuk meminimalkan kebutuhan rekayasa balik
lebih lanjut selama sisa masa pakai sistem. Konsekuensi dari
perspektif ini adalah keyakinan bahwa metode pengenalan
rencana tidak cukup untuk rekayasa balik. Sebagai contoh,
sebuah fragmen kecil dari sistem operasi real-time direkayasa ulang menggunakan pendekatan ini.
1 Pendahuluan
Praktik rekayasa perangkat lunak cenderung berfokus pada
desain dan implementasi produk perangkat lunak tanpa
mempertimbangkan masa pakainya, biasanya 10 tahun atau lebih
(lihat [ 161). Namun, upaya utama dalam organisasi rekayasa
perangkat lunak dihabiskan setelah pengembangan (lihat misalnya
[5, 61) pada pemeliharaan sistem untuk menghilangkan kesalahan
yang ada dan menyesuaikannya dengan persyaratan yang berubah.
Sayangnya, sistem perangkat lunak yang matang seringkali
memiliki dokumentasi desain yang lengkap, salah atau bahkan
tidak ada. Hal ini membuat sulit untuk memahami apa yang sedang
dilakukan sistem, mengapa ia melakukannya, bagaimana pekerjaan
itu dilakukan, dan mengapa ia dikodekan seperti itu. Akibatnya matang sys
Untuk sistem yang baru dikembangkan, masalah dapat dikurangi
dengan mendokumentasikan sistem secara menyeluruh dan
memelihara dokumentasi bersama dengan sistem. Idealnya,
dokumentasi sistem menggambarkan produk dan desain lengkap,
termasuk alasannya.
Sebagian besar informasi desain yang ditangkap bersifat informal
(tidak dapat diinterpretasikan oleh mesin). Sementara ini berharga
untuk pengelola perangkat lunak, informasi informal tunduk pada
interpretasi yang luas, dan kegunaan dibatasi oleh masalah
pengembang perangkat lunak yang berbeda menggunakan
interpretasi yang berbeda dari deskripsi yang sama.
Deskripsi formal desain (dan alasannya) dengan semantik yang
tepat dapat mengatasi masalah komunikasi ini. Bahkan dapat
memungkinkan kita untuk memodifikasi desain daripada kode (lih.
[3]) dan, dengan demikian, untuk memodifikasi sistem perangkat
lunak menggunakan alat semiotomatis. Pengembangan
transformasional perangkat lunak (lihat misalnya [ 10, 113) dipandu
oleh kriteria kinerja (lihat misalnya [9]) tampaknya menjadi cara
yang tepat untuk mendapatkan deskripsi desain seperti itu .
Dalam pengaturan yang ideal seperti itu tidak akan ada alasan
untuk rekayasa balik. Namun, banyaknya perangkat lunak yang ada
yang harus dipertahankan memaksa kita untuk menghadapi masalah
ini.
Teknologi rekayasa balik saat ini berfokus pada perolehan
kembali informasi dengan menggunakan alat analisis (lih. [4]) dan
dengan mengabstraksi program dari bawah ke atas dengan
mengenali rencana dalam kode sumber (lih. [7, 14, IS, 171). Tujuan
utama dari alat tersebut pada dasarnya adalah untuk membantu
pengelola memahami program (lih. [ 131). Sementara kami percaya
pada kegunaan dari pendekatan ini sebagai bagian dari toolkit dan
visi yang lebih besar, mereka cukup memadai untuk tugas pemulihan
desain. Alat analisis, meskipun berharga, hanya menyediakan
beberapa informasi desain yang berasal dari struktur kode, bukan
dari maksud atau konstruksinya. Pengenalan rencana murni tidak
mungkin cukup kuat untuk mendorong rekayasa balik karena alasan
berikut: kode lama ditulis menggunakan pengkodean yang agak
rumit untuk mencapai efisiensi yang lebih baik,
0 semua pola rencana yang diperlukan dalam semua variasi
harus disediakan terlebih dahulu untuk aplikasi tertentu, dan

104
._ 0-8186-8162-4J97 $10.00 0 1997 IEEE
Machine Translated by Google
0 konsep abstrak yang berbeda dipetakan ke kode yang
sama dalam satu aplikasi.
Yang lebih penting, alasan utama melakukan reverse engineering
adalah untuk memodifikasi sistem perangkat lunak; memahami itu
hanya prasyarat yang diperlukan untuk melakukannya . Kami
menganggap pengembangan transformasional dengan modifikasi
tanda daripada kode sebagai sarana untuk mencapai modifikasi
kremental, karena memberi kami banyak teori dan teknik untuk
melaksanakannya ( lihat [I, 21). Untuk sistem yang ada, ini
menyiratkan kebutuhan untuk merekonstruksi desain transformasi
yang masuk akal yang dapat digunakan untuk mendapatkan kode
dari spesifikasi abstrak sistem yang sesuai, yaitu kita ingin
menerapkan transformasi kembali dari program ke spesifikasinya.
Merekam transformasi ini (bersama dengan alasan untuk
menerapkannya) kemudian memungkinkan kita untuk memodifikasi
desain, bukan hanya kode program.
Berikut ini kami mengeksplorasi rekayasa maju dan mundur
secara lebih rinci dan memberikan contoh untuk kode assembler
warisan rekayasa terbalik transformasional ke konsep tingkat tinggi.
2 Rekayasa Maju Dalam praktik
rekayasa ke depan saat ini, persyaratan informal entah
bagaimana diubah menjadi spesifikasi semi-formal menggunakan
notasi domain tanpa mendasari semantik yang tepat seperti
misalnya diagram aliran data, diagram hubungan entitas, deskripsi
bahasa alami, atau notasi informal atau semiformal spesifik masalah
lainnya .
Program kemudian dibangun secara manual (yaitu dengan cara
yang rawan kesalahan) dari spesifikasi oleh agen kreatif,
programmer.
Tersembunyi dalam konstruksi kreatif program dari spesifikasi
ini adalah seperangkat keputusan desain yang jelas dan tidak jelas
tentang bagaimana mengkodekan bagian-bagian tertentu dari
spesifikasi dengan cara yang efisien menggunakan mekanisme
implementasi yang tersedia untuk mencapai kriteria kinerja
(mengapa dari keputusan desain). Sebagai contoh, fragmen
spesifikasi yang memerlukan pengambilan asosiatif menggunakan
kunci numerik dapat diimplementasikan menggunakan tabel hash,
sehingga menghasilkan waktu reaksi sistem yang baik. Keputusan
ini biasanya tidak didokumentasikan.
Seiring waktu, kode program dimodifikasi untuk menghilangkan
kesalahan dan menyesuaikan sistem dengan persyaratan yang
berubah. Persyaratan dapat berubah untuk memungkinkan
penggunaan kunci alfanumerik dan untuk dapat menangani
sejumlah besar data, dan implementasi direvisi untuk menggunakan
B-pohon berbasis disk. Sayangnya, seringkali perubahan ini terjadi
tanpa tercermin dengan benar dalam spesifikasi. Kesenjangan
antara spesifikasi asli dan program menjadi lebih besar dan lebih
besar. Hasilnya adalah kode program tanpa spesifikasi yang tepat
dan dengan informasi desain yang tidak dapat dipercaya (seperti
komentar yang menjelaskan tabel hash!). Kode menjadi sulit untuk
dipahami dan, dengan demikian, sulit untuk dipertahankan.
Untuk mengatasi kekurangan ini, penting untuk mengubah
spesifikasi terlebih dahulu dan kemudian mencerminkan perubahan
dalam kode program. Prasyarat yang diperlukan untuk ini adalah untuk
105
memiliki informasi yang dapat dipercaya tentang hubungan antara
spesifikasi dan kode program. Desain dan alasannya
menggambarkan bagaimana dan mengapa hubungan ini; namun,
mereka tidak didokumentasikan dalam praktik saat ini.
Ada dua pendekatan yang diketahui untuk mengurangi
kesenjangan antara spesifikasi dan program.
Yang pertama adalah pengembangan perangkat lunak dengan
penyempurnaan bertahap yang memperkenalkan deskripsi
perantara dari sistem antara spesifikasi dan kode program akhir.
Deskripsi antara harus mencerminkan keputusan desain utama
selama konstruksi, yang membantu untuk memahami perangkat
lunak dan desainnya. Namun, pendekatan ini memiliki beberapa
kelemahan penting: langkah-langkah pengembangan masih manual,
terlalu besar untuk tidak memuat keputusan desain yang
tersembunyi, tidak ada alasan yang secara langsung terkait dengan
langkah-langkah tersebut, hubungan antara deskripsi hanya dapat
dibangun dengan posteriori, dan masih banyak lagi dokumen yang
harus dipelihara untuk memasukkan perubahan persyaratan sistem.
Terlepas dari kekurangan ini, pendekatan penyempurnaan
bertahap tidak terlalu buruk. Akibatnya menyerang mereka
membawa kita ke pendekatan kedua: pengembangan
transformasional perangkat lunak di mana langkah-langkah
pengembangan manual yang cukup besar digantikan oleh
transformasi yang melestarikan kebenaran formal yang lebih kecil
yang masing-masing mencerminkan keputusan desain kecil atau optimasi.
Prasyarat yang diperlukan untuk pendekatan ini adalah memiliki
spesifikasi formal yang mungkin berisi notasi domain (misalnya
untuk domain tujuan umum dari deskripsi logis dan diagram aliran
data dan untuk domain aplikasi khusus seperti misalnya pengelolaan
uang dan pinjaman) dengan memberi mereka semantik dasar yang
tepat. Berdasarkan ini kode program kemudian dapat diturunkan
dengan membuat langkah-langkah implementasi kecil menggunakan
transformasi mempertahankan kebenaran formal yang mengarah
dari spesifikasi yang lebih abstrak ke spesifikasi yang lebih konkret.
Kode program akhir kemudian benar dengan konstruksi sehubungan
dengan spesifikasi persyaratan formal. Setiap transformasi jatuh ke
dalam salah satu dari tiga kategori: penyempurnaan (yaitu peta
konsep dari tingkat abstrak ke tingkat yang lebih konkret), optimasi
(yaitu peta untuk mengurangi sumber daya yang digunakan pada
tingkat abstraksi menurut beberapa kriteria), dan trans jittering.
formasi (yang pada akhirnya memungkinkan penerapan
penyempurnaan dan pengoptimalan). Keputusan untuk menerapkan
transformasi tertentu merupakan informasi desain yang penting.
Transformasi yang diterapkan ditambah dengan alasan pemilihannya
adalah informasi desain yang "menjelaskan" kode. Ini disebut
desain transformasional kode dari spesifikasi.
Pemilihan transformasi untuk diterapkan pada spesifikasi
tertentu secara umum masih merupakan proses kreatif tetapi
berpedoman pada kriteria kinerja yang ingin dicapai. Pemilihan
transformasi yang dipandu ini memungkinkan proses pengembangan
didukung oleh sistem semiotomatis yang berisi repertoar besar
transformasi yang tersedia dengan menerapkannya untuk mencapai
atau setidaknya mendekati kriteria kinerja.
Machine Translated by Google
Transformasi yang diperlukan untuk rekayasa perangkat lunak
praktis terdiri dari semua keputusan desain yang secara implisit
digunakan oleh pengembang perangkat lunak saat ini termasuk teknik
seperti berikut (lihat misalnya [ 11, 12, 131): Dekomposisi - Sebagian
besar masalah dapat didekomposisi menjadi submasalah yang
secara umum adalah mungkin dengan cara yang berbeda.
Struktur hierarki kode yang sebenarnya hanya mewakili satu
pilihan tertentu dari kumpulan kemungkinan dekomposisi.
GeneralizatiodSpecialization - Jika komponen yang berbeda
serupa, dimungkinkan untuk membangun versi yang lebih
umum yang terdiri dari keduanya sebagai kasus khusus.
Sebaliknya untuk alasan efisiensi, mungkin merupakan pilihan
yang baik untuk mengkhususkan suatu komponen untuk
aplikasi (bagian dari) tertentu.
Pilihan representasi -Untuk dapat mengimplementasikan tipe
data tingkat tinggi dalam kode program, seringkali diperlukan
untuk mengubah representasinya . Sebuah contoh umum
adalah representasi dari set dengan daftar.
Pilihan algoritme - Konsep tingkat tinggi dapat
diwujudkan oleh algoritme dalam berbagai cara. Pilihan
antara yang mungkin ditegakkan dengan kriteria kinerja
yang tidak terdokumentasi dengan baik atau bahkan
tidak terdokumentasi yang harus dipenuhi.
Interleaving - Untuk alasan efisiensi mungkin berguna untuk
mewujudkan konsep yang berbeda di bagian kode yang sama
atau struktur data yang sama.
Delokalisasi - Konsep tingkat tinggi tertentu dapat tersebar di
seluruh kode yang memperkenalkan detail yang mengganggu
dalam konsep lain (lihat studi tentang efek delokalisasi pada
pemahaman di [W.
Berbagi Sumber Daya - Kode yang disisipkan sering
memungkinkan konsep yang berbeda untuk berbagi beberapa
sumber daya seperti misalnya kondisi kontrol, hasil data
perantara, fungsi, nama, dan sumber daya komputasi lainnya.
Data caching'Memoization - Jika Beberapa data, yang harus
dihitung , sering dibutuhkan Atau komputasinya mahal , data
tersebut layak untuk di - cache, yaitu untuk memo untuk
digunakan kembali nanti.
Optimasi - Untuk mencapai kode yang sangat efisien (karena
kebutuhan untuk memuaskan misalnya memori atau kendala
waktu reaksi) banyak optimasi yang berbeda digunakan.
Optimalisasi tersebut terdiri dari - program melipat dan
membuka (inlining)
kode,
- penggunaan sifat aljabar fungsi , - penggabungan
perhitungan dengan menyusun atau menggabungkan
fungsi, - evaluasi parsial (sering dalam bentuk konteks-
penyederhanaan dependen), -
pembedaan hingga, - akumulasi
hasil, - penyederhanaan dan
eliminasi rekursi, - fusi loop,
106
- optimasi biasanya dilakukan oleh kompiler yang baik
(gerakan kode, eliminasi subekspresi umum,
penghapusan tedundansi parsial), dan
- optimasi khusus domain seperti misalnya meminimisasi
mesin keadaan terbatas yang mengenali bahasa
tertentu.
Semua keputusan desain ini mungkin tumpang tindih dan mungkin
tidak terlokalisasi selama konstruksi kode program dari spesifikasi.
Apakah metode ini dilakukan secara mekanis oleh alat atau secara
informal oleh pembuat program cerdas, sistem perangkat lunak yang
dihasilkan sangat sulit untuk dipahami.
Pendekatan pengembangan perangkat lunak transformasional
memiliki keuntungan yang memungkinkan perekaman otomatis dari
keputusan desain yang dibuat selama derivasi kode program akhir
dari spesifikasi formal. Asalkan pemilihan transformasi yang diterapkan
selama pengembangan ini dipandu oleh kriteria kinerja yang akan
dicapai dan hubungan antara pemilihan dan kriteria kinerja dicatat,
kami mendapatkan desain lengkap beserta alasannya sebagai produk
pengembangan perangkat lunak. Kode itu sendiri hanyalah produk
sampingan yang benar berdasarkan konstruksi.
Merekam informasi desain ini memungkinkan kita untuk
memodifikasi spesifikasi alih-alih kode dan kemudian memodifikasi
desain untuk mendapatkan implementasi baru dari spesifikasi yang
dimodifikasi. Sifat formal dari transformasi membuat modifikasi desain
tersebut dapat didukung oleh alat semiotomatis yang meningkatkan
keandalan dan mengurangi biaya pemeliharaan sistem.
3 Rekayasa Terbalik Jika semua
perangkat lunak yang ada telah dikembangkan menggunakan
sistem transformasi yang merekam desain dan rasio rasionya, maka
tidak perlu merekayasa balik kode apa pun. Namun, kita harus
membuat konsesi dengan kenyataan. Sejumlah besar perangkat
lunak yang dikembangkan secara konvensional ada dan sistem seperti
itu akan terus dikembangkan untuk waktu yang lama.
Sistem ini memiliki kesalahan dan permintaan terus-menerus untuk
peningkatan fungsi dan persyaratan kinerjanya. Modifikasi adalah
sebuah keniscayaan. Ini berarti bahwa ada kebutuhan mendasar
untuk memahaminya. Karena sepuluh dirancang dengan buruk dan
memiliki dokumentasi yang tidak lengkap, tidak ada, atau, lebih buruk
lagi, salah tanpa informasi desain, ini adalah tugas yang menantang.
Saat ini pendekatan utama untuk memahami terdiri dari mencoba
mengenali rencana (fragmen kode yang mengimplementasikan
konsep pemrograman) dari bawah ke atas dari program ke deskripsi
yang lebih abstrak (lih. [ 141). Pada dasarnya, ini dilakukan dengan
pencocokan pola pada representasi internal kode (misalnya pohon
sintaksis abstrak) yang mengarah pada pendeteksian pola rencana
atau konsep tingkat yang lebih tinggi dalam kode tingkat yang lebih
rendah.
Pendekatan ini memiliki kelemahan utama: Itu tergantung pada
pengembangan semua (atau setidaknya semua rencana penting) dalam
Machine Translated by Google

sikap yang mungkin terjadi pada kode yang ingin kita pahami. Sayangnya
rencana ini dapat (dan telah) direalisasikan dalam berbagai cara karena
interaksi antara banyak keputusan desain yang mungkin (yaitu transformasi).
Bayangkan sebuah array logis dari struktur; itu dapat diimplementasikan
sebagai array struktur atau struktur array.
Kode untuk mengurutkan array akan terlihat sangat berbeda tergantung
dari pilihan implementasinya. Serangkaian rencana untuk penyortiran
entah bagaimana harus memperhitungkan semua kemungkinan representasi
data yang berbeda.
Jadi, untuk mendeteksi rencana dalam kode lama, kita harus dapat
mendeteksi semua realisasi berbeda dari rencana yang sama.
Namun sayangnya kita membutuhkan pola yang berbeda untuk mendeteksi
realisasi yang berbeda ini; dan semua pola ini harus ada terlebih dahulu
untuk dapat merekayasa balik kode, yang tidak mungkin karena banyaknya
realisasi yang dapat dibayangkan, semuanya memecahkan masalah yang
sama.
Lebih buruk lagi, kita harus memperhitungkan bahwa rencana yang
ingin kita kenali saling terkait, terdelokalisasi (lih. [SI), dan berbagi sumber
daya. Jadi kita harus menemukan pola rencana dalam kode yang terjalin
dengan pola rencana lain yang keduanya mungkin tersebar di seluruh kode
program.
Jadi, untuk melakukan tugas rekayasa balik secara efektif, kita harus
menggunakan beberapa kreativitas untuk mendeteksi dan memisahkan
konsep tingkat tinggi dalam kode; tugas yang secara umum tidak dapat
dilakukan terlebih dahulu dengan menyediakan sejumlah pola rencana
standar yang wajar bahkan bersama-sama dengan aturan pencocokan pola
yang begitu canggih.
Masalah-masalah ini dapat diatasi dengan dua pendekatan yang
berbeda. Yang pertama adalah mengizinkan seorang reverse engineer
serta menangkap kemungkinan desain . Tidak perlu mendefinisikan
untuk menambahkan rencana lebih lanjut, mewujudkan pola, dan mungkin lebih jauh
aturan jalinan* untuk memungkinkan pengenal rencana mendeteksi realisasi
aktual yang dapat ditemukan dalam kode. Namun, untuk dapat memelihara
sistem, kami tidak hanya tertarik pada rencana yang diwujudkan dalam
kode tetapi juga pada desain dan alasannya yang dapat mengarah dari
rencana ke realisasinya dalam kode yang sebenarnya. Dengan demikian,
rekayasa balik tidak hanya harus menyediakan pola rencana untuk realisasi
rencana yang sebenarnya, tetapi juga transformasi dan pembenaran untuk
menerapkannya, yaitu ia harus merekayasa perangkat lunak dan mencapai
solusi tertentu. yang telah digunakan dalam kode.
Sebagai pendekatan alternatif, kita dapat mencapai efek yang sama
dengan menggunakan transformasi kecil ke belakang (formasi trans ini
mungkin atau mungkin belum disediakan oleh mesin transformasi maju)
dan mengabstraksikan kode langkah demi langkah yang hasil akhirnya
adalah abstrak. rencana (atau satu set rencana) sesuai dengan kode yang
diberikan. Pada dasarnya, transformasi diterapkan mundur "jitter" kode ke
dalam bentuk di mana rencana kanonik lebih mudah ditemukan.
Rencana abstrak semacam itu mungkin sudah ada dalam sistem atau
mungkin pengetahuan domain baru yang dikembangkan selama proses
rekayasa balik. Dengan merekam langkah-langkah transformasi (terbalik)
yang digunakan untuk mencapai rencana itu, kami memperoleh desain
yang masuk akal yang dapat digunakan sebagai dasar formal untuk
memelihara sistem rekayasa balik dengan mempertahankan desain.
Melakukannya akan menghindari kebutuhan untuk melakukan rekayasa
balik berulang kali pada sistem selama masa pakainya, yang disebabkan
oleh modifikasi kode yang terus-menerus.
Sebagai keuntungan sampingan , pendekatan rekayasa balik
transformasional memungkinkan kita memperoleh pengetahuan domain

Eunction ReverseEngineer(Code,SetOfTransforms) mengembalikan DesignHistory

mulai
// Tegaskan: Transformasi berbentuk LHS => RHS
DesignHistory:=kosong; // belum ada informasi desain
Program Abstrak:=Kode; // keadaan awal ulangi

{ // Komponen pengenalan rencana:

MatchingTransformations:=MatchRightHandSides(SetOfTransforms,~stractCode);
Tampilan (Transformasi Pencocokan); 1;

{ // Pengetahuan yang hilang disisipkan di sini:

ChosenTransform:=InteractivelyChoose(MatchingTransformations); jika
ChosenTransform=DONE lalu kembalikan DesignHistory;

lain jika ChosenTransform=NONE maka

{ ChosenTransform:=NewlyDefinedTransform();
SetOfTranforms:=union(SetOfTransforms,ChosenTransfo~); 1;

AbstractCode:=ApplyTransformInverse(ChosenTransform,AbstractCode);
DesignHistory:=tambahkan(DesignHistory,ChosenTransform); 1; akhir ; akhir ;

Gambar 1: Model Sederhana Transformasi Rekayasa Terbalik

*Perhatikan bahwa aturan jalinan pada dasarnya adalah transformasi maju. Transformasi ini harus diterapkan pada pola yang ada untuk mendapatkan pola
baru yang saling terkait.

107
Machine Translated by Google

pengetahuan domain terlebih dahulu. Sampel termasuk konsep baru
yang diidentifikasi oleh reverse engineer bersama dengan implementasi
seperti yang ditemukan dalam kode. Informasi ini juga dapat digunakan
untuk mengembangkan dan memelihara sistem lain; yaitu kita mendapatkan
tambahan pengetahuan yang dapat digunakan oleh seorang forward engine
turun.
Sementara kami berpendapat bahwa rekayasa balik transformasional
harus jauh lebih efektif daripada pengenalan rencana murni, meskipun
pengenalan rencana memiliki tempatnya. Pertama, teknologi pencocokan
pola yang sama yang menjadi dasar pengenalan rencana digunakan oleh
setiap komponen penulisan ulang sistem transformasi (lihat gambar 1).
Kedua, rencana mungkin dapat " menggabungkan" bagian penting dari
sistem yang ada, memberikan petunjuk kuat tentang beberapa aspek
kode . Petunjuk-petunjuk ini dapat digunakan sebagai petunjuk-petunjuk
untuk memandu penerapan kebalikan dari transformasi. Sebagai contoh,
menemukan perhitungan yang memetakan string ke bilangan asli adalah
petunjuk bahwa hashing sedang terjadi, dan transformasi terkait tabel
hash harus dicoba.
manual ke contoh nyata. Tujuan kami di sini bukan untuk secara khusus
melaksanakan tugas ini, atau untuk menyediakan algoritme yang tepat ,
melainkan untuk menyoroti berbagai keputusan dan bagaimana
menanganinya secara transformasional. Secara khusus, kami ingin
menegaskan bahwa pengenalan rencana tidak dapat menangani tugas
ini, dan transformasi terbalik dapat. Kami tidak mengklaim bahwa proses
ini otomatis. Kami berasumsi bahwa reverse engineer memiliki
pengetahuan domain masalah informal yang cukup besar, dan secara
bertahap memberikan panduan ke alat yang mencatat transformasi yang
digunakan untuk pemeriksaan dan pemeliharaan selanjutnya.
Contohnya adalah kode tangan, kode assembler Mo torola 6809
warisan yang sangat disetel dari sistem operasi tahun 1980-an yang
ditulis oleh salah satu penulis. Kami akan membalikkan mesin dari
sumber perakitan kembali ke abstraksi yang diwakili kode. Pengetahuan
domain yang digunakan oleh insinyur terkait dengan kode sistem operasi,
khususnya untuk semaphore. Sedikit informasi ini memberikan fokus
yang cukup besar pada proses.

Membandingkan rekayasa balik transformasional dengan rekayasa
maju transformasional, kami melihat bahwa keduanya membutuhkan
pengetahuan domain dan mesin transformasi semi-otomatis yang dipandu
oleh beberapa kriteria tambahan untuk mengurangi upaya yang diperlukan
untuk mengembangkan produk, yaitu desain sistem.
Dengan demikian, kita dapat dengan jelas
menyimpulkan bahwa: Reverse engineering membutuhkan
pengetahuan dan infrastruktur yang sama dengan forward engineering.
Rekayasa terbalik 'hanya' menerapkan transformasi maju mundur, yaitu
secara terbalik.
4 Rekayasa Terbalik Warisan
Tujuan dari kode ini adalah untuk melepaskan sumber semaphore
untuk memungkinkan menunggu lain, tugas prioritas mungkin lebih tinggi
untuk akhirnya memperoleh semaphore dan melanjutkan.
Memiliki beberapa pengetahuan domain tentang
sinkronisasi tugas (termasuk setidaknya sinkronisasi
dengan semaphore) dan tidak tertarik pada bagaimana
tugas prioritas tertinggi membuat prosesor berjalan, kami
berharap untuk melihat sesuatu seperti kode abstrak
berikut: procedure RT-UnLock(x: ptr to Semaphore)
mulai // buka semaphore yang ditentukan
V(X) ; // melepaskan pengembalian unit sumber
daya ; // kembali ke akhir pemanggil asli ;
Saya
Saya

Contoh: Semaphore Fragmen kode aktual yang ingin kami rekayasa balik disediakan di
Pada bagian ini kami menunjukkan bahwa rekayasa balik bawah ini. (Pembaca tidak perlu memeriksa iccare sepenuhnya, karena
transformasional layak dalam praktik dengan menerapkannya kami akan mengabstraksikannya segera di halaman berikutnya). Kita

RT: Buka Kunci ; membuka blok kode yang semaphore-nya di (X) intds ; mengunci dunia
sejenak inc scb:count,x ; adaresource
yang mengantri ? ; b/ stx
bgt RT:ITSX tidak, selesai
itempx merilispointer
; simpan
ke semaphore ldx scb:tcbq,x ; pointer ke TCB untuk mengaktifkan ldd
stx itemd ; simpan pointer ke tcb:nexttcb,x
TCB untuk mengaktifkan
; temukan penunjuk
ldx itempx
ke ;TCB
pointer
setelah
ke
semaphore std scb:tcbq,x ; hapus
ke TCBtugas dari
untuk antrian
siap SCB ldx itemd ; pointer
dijalankan

RT:ITSC ; masukkan tugas di (X) ke dalam antrian siap dan alihkan konteks jika diperlukan ; Tegaskan: interupsi
dinonaktifkan di sini jsr RT:ITIQ ; masukkan tugas ke dalam antrian siap ldx RT:TCBQ ; apakah kita masih tugas
prioritas tertinggi ? cmpx RT:CTCB
#RT:ISCH
; ... ?; tidak,
beq RT:ITSX
alihkan tugas
; b/ ya,paksa
berikan
jmpkontrol
RT:Sintke; pemanggil
dengan interupsi
ldx ke
penjadwal tugas RT: ITSX inten ; aktifkan interupsi dan kembali ke pemanggil

rts
Gambar 2: Fragmen Kode Assembler Motorola 6809 Legacy

108
Machine Translated by Google

smart reverse engineer menentukan itu adalah kode yang dia
minati dengan mendekode label perakitan, dan melakukan
beberapa analisis aliran kontrol.
Komentar kode di sini asli. (Komentar dalam kode yang diubah
secara informal berasal dari ini.
Kami tidak benar-benar mengharapkan sistem transformasi untuk melakukan ini.)
Kode ini berisi beberapa keputusan desain yang beberapa di
antaranya kami pertimbangkan secara lebih rinci di bawah ini.
Untuk kode ini, penting untuk mengetahui bahwa melepaskan
sumber semaphore disisipkan dengan penjadwalan prioritas; untuk
alasan efisiensi tugas saat ini "secara sukarela" menyerahkan
prosesor asalkan itu bukan lagi tugas prioritas tertinggi. Jadi, agar
dapat merekayasa balik kode ini, kita harus memiliki (atau
mengembangkan) beberapa pengetahuan tentang penjadwalan
prioritas (masalah yang melampaui cakupan makalah ini).
Karena jarak antara kode assembler dan kode program
prosedural yang ingin kami abstraksi cukup besar, kami melakukan
langkah mundur pertama menggunakan domain perantara yang
terkadang digunakan oleh kompiler untuk menerjemahkan dari
kode prosedural tingkat yang lebih tinggi ke assembler: register
transfer bahasa (RTL) . Untuk melakukan itu, kita dapat
menerapkan Transformset langsung berikut dari transformasi
pemurnian mundur:
panggilan subrutin; + subrutin jsr + target jmp target goto ; +
rts kembali; + jmp
goto x+offset; + ldx #variabel x:=alamat(variabel) offset,^
; + variabel
ldx x: =variabel;
variabel stx: =x; + ldx offset,^ x: =x->offset; + variabel
+ ldd offset,^ d:
Transformasi ini khusus untuk M6809 . Jelas, transformasi ini
adalah aturan pencocokan pola sederhana yang dapat diterapkan
ke kode assembler yang ada secara sederhana dan otomatis.
Sejarah desain harus menangkap aplikasi dari semua ini; itu dapat
menangkap mereka sebagai satu set daripada urutan linier karena
tidak ada persyaratan urutan nyata.
Sebelum melihat kode RTL yang dihasilkan untuk contoh kita,
mari kita perkenalkan empat transformasi pengoptimalan sederhana
(yang merupakan transformasi ekivalensi dan, dengan demikian,
dapat digunakan di kedua arah untuk tujuan kita): [penghapusan
subekspresi umum] kode ( ekspresi) + variabel :=ekspresi;
code(variab1e) di mana variabel adalah variabel baru yang
tidak muncul di tempat lain dalam kode program dan tidak
ada penetapan ke variabel yang muncul dalam ekspresi di dalam
kode [daftar penggantian nama seumur hidup]
variabel baru: =expressionl; kode
(variabel baru e) ; variabel:
=ekspresi2; + vari ab1 e : = ekspresi
on1 ; kode ( vari ab1 e) ; variabel:
=ekspresi2; di mana variabel
baru adalah variabel baru yang
tidak muncul di tempat lain dalam program [penghapusan tugas
mati]
variabel:=ekspresi; + jika variabel tidak DAN

=x->offset;
(x->offset) :=d; int-enable:=true; + inten + std offset,^
int-enable:=false; digunakan lagi dalam eksekusi kode sebelum nilai diberikan
+intds (x->offset) : =x-
>offset+l; + inc offset,x cc:=bandingkan(x->offset,O) ; cc : padanya di lain waktu [bandingkan pengenalan] (ekspresi1 relasi
e) ; =+ variabel cmpx jika cc=O lalu=bandingkan (x vari
ke label fi; +beq ab1if
label
ekspresi2)
label jbgt cc>O lalu goto label fi;

+ bandingkan ( ekspresil , ekspresi2) relasi 0

Transformasi ini berguna untuk sebagian besar tugas rekayasa

balik perakitan. Kami menyatakan bahwa model sederhana
pencocokan pola struktural yang digunakan oleh sebagian besar
mesin pengenalan rencana tidak bekerja untuk ini; analisis aliran
, data diperlukan.
Menerapkan transformasi pemurnian dan pengoptimalan
mundur dapat membawa kita ke kode RTL berikut:

RT-UnLock: // membuka blok kode yang semaphore-nya ada di register X // mengunci dunia sebentar //
int-enable:=false; (x->scb- melepaskan unit sumber daya
count) :=(x->scb-count)+l; if (x->scb-count>O) lalu ke
RT-ITSX fi; tugas siap:=(x->scb-tcbq); // arahkan ke TCB untuk
mengaktifkan (x-zscb-tcbq):=ready-task->tcb:nexttcb; // hapustugas dari antrian SCB // tunjuk ke TCB untuk
membuat siap dijalankan x:=ready-task;

RT-ITSC: // masukkan tugas X ke dalam antrian dan alihkan konteks jika diperlukan // masukkan tugas ke
TCBQ=RT-CTCB) lalu ke RT-ITSX fi; x:=alamat(RT-ISCH); gotodalam RT-SInt;
antrian siap panggil RT-ITIQ; jika (RT-

// masih prioritas tertinggi? // tidak, paksa

sakelar tugas // dengan interupsi ke
penjadwal // aktifkan interupsi // kembali ke
RT-ITSX: int-enable:=true; kembali; pemanggil

Gambar 3: Kode Legacy Assembler Ditransformasikan ke Register Transfer Language (RTL)

109
Machine Translated by Google

Untuk dapat merekayasa balik lebih lanjut, kami menggunakan
pengetahuan domain kami untuk mendeteksi beberapa pengoptimalan
yang tidak jelas yang telah digunakan selama pengembangan kode:
0 Pernyataan goto RT-SInt; sebenarnya tidak menunjukkan
kelanjutan dari RT-ITSC tetapi merupakan panggilan yang
dioptimalkan dari subrutin dengan putaran kembali berikut ;.
Jadi itu harus diganti dengan pernyataan panggilan RT-SInt;
kembali;.
0 RT-ITSC sendiri adalah subrutin yang kebetulan terletak di akhir
RT-UnLock tetapi dapat dipanggil dari tempat lain dalam kode
program (yang tidak ditampilkan dalam fragmen program ini).
Artinya kita harus mengganti aliran kontrol dari RT-UnLock ke
RT-ITSC, yang disebabkan oleh penambahan pencacah
program di prosesor, dengan panggilan ke RT-ITSC sebagai
subrutin diikuti dengan pengembalian:.
0 RT-ITSX merupakan kelanjutan untuk RT-UnLock dan RT-ITSC
dalam kondisi tertentu. Ini adalah subrutin terless parame
untuknya sendiri. Jadi melompat ke sana ( menggunakan goto
RT- ITSX ;) harus diganti dengan panggilan RT-ITSX; kembali;.
Demi kesederhanaan, kami mengurutkan kode sederhana dari
prosedur ini ke dalam pemanggil.
Ada konvensi tersembunyi dalam kode untuk parameter ke
prosedur RT-UnLock dan RT-ITSC (dan RT-SInt) yang
ditempatkan di
register X. Untuk dapat merekayasa balik ke prosedur
parametrik, kita harus mendeteksi fakta ini. Kemudian kita bisa
mengganti label: code re turn; dengan label prosedur (x)
memulai pengembalian kode ; akhir; asalkan tidak ada
pernyataan goto di seluruh kode program yang masuk atau
keluar dari tubuh prosedur, yaitu kode. Ini termasuk pernyataan-
goto untuk diberi label. Sejalan dengan itu, untuk prosedur ini
kami mengganti call la bel ; di sisi pemanggil dengan label
panggilan (x) ;.
Selain itu menggunakan transformasi ekivalensi yang jelas
[if-then-else with procedure return] if condition then codel;
kembali; fi;
kode2; kembali; +
jika kondisi maka
kodel;
kalau tidak
kode2;
fi;
kembali;
jika tidak ada pernyataan goto yang masuk atau keluar codel
I atau code2
dan beberapa transformasi pengoptimalan yang diberikan di atas kita
mendapatkan kode program berikut:

jrocedure RT-Buka Kunci(x)

mulai // buka blok kode yang semaphore- nya ada di register X int-enable:=false; // mengunci
dunia sejenak (x->scb-count) := (x->scb-count)+l; // lepaskan unit
count>O)
sumbermaka
daya //jika
tidak
(x->scb-
ada tugas menunggu int-
enable:=true; // aktifkan interupsi else // tugas menunggu ready-task:=(x->scb-tcbq);
mengaktifkan (x->scb-tcbq):=ready_task-
// arahkan ke TCB untuk
>tcb:nexttcb:exttcb; // hapus tugas dari antrian panggilan SCE RT-ITSC(ready-task); fi; kembali; akhir ;

prosedur RT-ITSC(x)
mulai // masukkan tugas X ke dalam antrian dan alihkan konteks jika diperlukan
panggil RT-ITIQ (x) if // masukkan tugas ke dalam antrian siap // kita
(RT-TCBQ=RT-CTCB) lalu int- masih tugas dengan prioritas tertinggi // aktifkan
enable:=true; kalau tidak interupsi // tugas lain adalah prioritas tertinggi // paksa
alihkan tugas dengan panggilan penjadwal
panggil RT-SInt(alamat(RT-ISCH)); fi; kembali;
akhir ;

Gambar 4: Kode Bahasa Transfer Register yang Tidak Dioptimalkan

Sekarang mari kita coba untuk mendapatkan wawasan yang lebih
dalam tentang prosedur RT-ITSC. Untuk melakukan itu kita harus
mengetahui sesuatu tentang organisasi antrian siap (yang tidak mungkin
hanya dengan melihat fragmen program yang dapat kita tangani dalam
makalah ini):
Gading dalam antrian siap dipesan dengan memperhatikan
prioritasnya, yaitu gading dengan prioritas tertinggi berada di awal
antrian sedangkan gading dengan prioritas terendah berada di awal antrian.
ority tusk dapat berada di akhir antrian . Penunjuk ke seluruh antrian
identik dengan penunjuk ke gading pertama dalam antrian.
Melihat ke prosedur RT-ITSC kita melihat pemeriksaan apakah
tugas RT-CTCB saat ini sama dengan tugas prioritas tertinggi di kepala
antrian siap RT-TCBQ. Jadi, penjadwal tugas (yang mengubah konteks
program untuk menjalankan tugas dengan prioritas tertinggi) adalah

110
Machine Translated by Google

dipanggil jika dan hanya jika tugas dengan prioritas tertinggi bukan tugas
saat ini (yang disebut prosedur). Ini berarti bahwa solusi mencerminkan
fakta bahwa pengalihan konteks ke tugas lain itu mahal dan oleh karena itu
harus dihindari jika tugas lain hanya yang sekarang. Namun, kami tidak
tertarik untuk mendapatkan program yang sangat efisien
kode tetapi dalam mendapatkan deskripsi abstrak dari prosedur, yaitu kita
tidak harus menghindari panggilan ke uler terjadwal untuk alasan efisiensi.
Dengan tambahan pengetahuan tentang int-enable=true setelah memanggil
RT-SInt, kita dapat menyederhanakan RT-ITSC menjadi:

prosedur RT-ITSC(x)
mulai // masukkan tugas X ke dalam antrian dan alihkan konteks jika diperlukan
panggil RT-ITIQ (x) // masukkan tugas ke dalam antrian siap
panggil RT-SInt(alamat(RT-ISCH)); // paksa sakelar tugas dengan panggilan penjadwal // tugas
saat ini mungkin mendapatkan prosesor
kembali;
akhir ;

Gambar 5: Kode Pengalihan Tugas yang Tidak Dioptimalkan untuk RT-ITSC

Inlining prosedur RT-ITSC ke RT-Unloc k kemudian memungkinkan kita Melakukan beberapa transformasi ekuivalensi lebih lanjut pada pernyataan
untuk memindahkan pernyataan int-enable : =true; dari dalam pernyataan if dan kondisinya, kita memperoleh kode berikut:
if hingga akhir prosedur.$

procedure RT-UnLock(x) begin //

buka blok kode yang semaphorenya ada di register X int-enable:=false; (x->scb-count) :=(x->scb-
count)+l; jika (x->scb-count<=O) maka // mengunci dunia sejenak // melepaskan unit
sumber daya // tugas menunggu ready-task:=(x-
>scb-tcbq); // arahkan ke TCB untuk
mengaktifkan (x->scb-tcbq):=ready-task->tcb:nexttcb; // hapus tugas RT-SInt(address(RTL1SCH)
(x) panggil dari antrian SCB panggil RT-ITIQ
); fi;
int-enable:=true; kembali; akhir;
// masukkan tugas ke dalam antrian siap //
paksa alihkan tugas dengan panggilan penjadwal

// aktifkan interupsi

Gambar 6: Kode Sederhana untuk RT-UnLock

Karena kurangnya ruang dalam makalah ini, kami tidak dapat menyajikan jenis yang digunakan, yaitu "semaphore" dan "tugas' bersama dengan
detail rekayasa balik lebih lanjut dari kode ini. prosedur terkait. Melakukan itu akhirnya dapat membawa kita ke kode
Namun, langkah selanjutnya harus memulihkan data abstrak berikut:

prosedur RT-UnLock(x: ptr ke semaphore) mulai // membuka

semaphore yang ditentukan
int-enable:=false; panggil // mengunci dunia sejenak // melepaskan unit
Semaphore.Release(x); // menunggu sumber daya
Task.InsertIntoReadyQueue(Semaphore.Remove(x))
tugas if (Semaphore.Desired(x))
// masukkan tugas ke
laludalam
panggil
antrian siap panggil
Task.ContinueHighestPriorityTask0; fi; int-enable:=true; kembali; akhir ;
// lanjutkan tugas dengan prioritas tertinggi

// aktifkan interupsi

Gambar 7: Kode untuk RT-UnLock dengan Tipe Data yang Dipulihkan

Mengabstraksi ini dalam domain sinkronisasi tugas kemudian akan kode asli. Kami mencatat bahwa mengganti transformasi yang
membawa kita ke kode abstrak yang diharapkan yang telah disajikan di menyatukan kode penjadwalan prioritas dengan kode spin lock akan
awal bagian ini. memungkinkan kami untuk membuat ulang Prosedur buka kunci

Merekam semua transformasi yang digunakan dalam proses ini semaphore yang direvisi untuk beberapa Prosesor. Ini Tepatnya _
memungkinkan kita untuk menerapkannya kembali ke kode ini untuk mereproduksi

t Penyelarasan ini tidak berarti bahwa prosedur RT-ITSC menjadi usang. Prosedur mungkin (dipanggil) dari tempat tambahan dalam sistem operasi.
tPerhatikan, bahwa int-enable=true valid setelah memanggil RT-SInt yang berarti kita dapat menambahkan pernyataan int-enable : =true; secara
langsung
mengikuti panggilan tanpa mengubah arti kode program.

113
Machine Translated by Google
jenis tugas pemeliharaan yang kami inginkan untuk
mendukung rekayasa balik.
Sekarang mari kita segera mempertimbangkan masalah besar yang
mungkin muncul ketika mencoba merekayasa balik kode menggunakan
pola rencana dan melihat secara khusus pada penjadwalan prioritas.
Mari kita asumsikan bahwa ada beberapa pengetahuan domain dan
pola rencana terkait tentang penjadwalan prioritas. Pada tingkat abstrak,
kita mungkin menemukan, misalnya, rencana prosedural berikut untuk
menambahkan tugas tambahan ke dalam antrian siap dan (menjadwal
ulang tugas:
Task.InsertIntoReadyQueue(tugas,prioritas);
Task.RunHighestPriorityTask();
Namun, dalam kode assembler kami menemukan sesuatu yang kira-
kira sesuai dengan rencana yang disempurnakan berikut (yang menuntut
penggunaan kelas implementasi tertentu untuk antrian prioritas):
Task.InsertIntoReadyQueue(tugas,prioritas); jika Tugas.Saat ini0
= Task.FirstTaskInReadyQueue0 lalu
Tugas.LanjutkanCurrent0; else
Task.ContinueHighestPriorityTask0; fi;
Siapa yang menghasilkan rencana yang disempurnakan ini? Bisakah
kita mengharapkannya menjadi bagian dari domain yang ada tentang
penjadwalan prioritas? Penyempurnaan tambahan mana dari rencana
awal yang kami perlukan untuk mencakup solusi yang digunakan dalam
kode lama lainnya untuk penjadwalan prioritas?
Jawaban atas pertanyaan-pertanyaan ini adalah: Tidak ada yang
dapat memberikan sebelumnya semua kemungkinan penyempurnaan
rencana yang dapat ditemukan dalam kode lama. Ini berarti bahwa kita
membutuhkan generator penyempurnaan rencana kreatif, yaitu mesin
transformasi maju semi-otomatis. Tapi kemudian, mengapa kita tidak
membuat penyempurnaan rencana ke belakang (sesuai permintaan)
dengan merekayasa balik kode menggunakan transformasi maju ke arah
sebaliknya?
5 Pekerjaan Terkait Upaya
yang cukup besar telah diinvestasikan dalam pengenalan rencana.
Programmer's Apprentice (lihat [ 141) masih merupakan salah satu yang
paling canggih, mewakili rencana ("klise") menggunakan data dan aliran
kontrol. Representasi ini memberikan beberapa kemandirian bahasa dan
memaksimalkan kemampuan untuk mencocokkan klise dengan kode yang
dipesan secara arbitrer. PA pada dasarnya mencoba untuk menyusun
(dengan tumpang tindih) program secara rekursif dengan klise untuk
menjelaskannya. Kami berharap contoh kami secara meyakinkan
menunjukkan bahwa ubin rekursif tidak dapat menjelaskan bahkan fragmen
kode yang kecil.
Masalah yang sulit dengan sekumpulan besar rencana adalah biaya
untuk mencocokkannya dengan program yang berpotensi sangat besar.
Pencocokan grafik yang efisien (lihat misalnya [15]) dan pemecah
kepuasan kendala (lihat misalnya [ 191) telah diimplementasikan untuk membantu
112
mencocokkan rencana dengan kode. Kedua jenis matcher ini dapat
digunakan untuk efek yang baik dalam sistem transformasi. Namun, kami
berharap untuk menghindari masalah “big-bang” dalam menjelaskan
seluruh program sekaligus dengan melakukan pemulihan tambahan,
menyimpan hasil sesi sebelumnya dalam sejarah desain, dan menggunakan
kembali desain untuk pemeliharaan. The Maintainer's Assistant (MA) (lihat
[ 181) menyerang masalah pemeliharaan perangkat lunak dengan
menggunakan metode transformasional, menggunakan representasi inti
untuk program yang diturunkan dari kalkulus lambda. Ini memberikan
dasar yang sangat baik dengan semantik yang jelas, sehingga
memungkinkan transformasi serius untuk diterapkan pada kode asli. MA
tampaknya digunakan untuk porting dan terjemahan daripada penjelasan
dan modifikasi.
6 Catatan Penutup Alasan untuk
melakukan reverse engineering adalah untuk mempertahankan kode
warisan. Oleh karena itu, seharusnya tidak difokuskan pada pemahaman
program tetapi pada pemeliharaan sistem sebagai gantinya. Ini harus
dilakukan dengan cara yang membebaskan kita dari rekayasa balik sistem
berulang kali karena modifikasi yang dilakukan pada kodenya dari waktu
ke waktu.
Oleh karena itu, reverse engineering harus difokuskan pada pemulihan
desain. Karena kita membutuhkan dukungan alat yang canggih untuk
melakukan pemeliharaan sistem secara efisien, desain yang dipulihkan
harus didasarkan pada metode formal.
Kita telah melihat bahwa rekayasa balik transformasional adalah
pendekatan yang layak untuk memulihkan desain seperti itu. Ini berarti
bahwa kita pada dasarnya membutuhkan pengetahuan dan infrastruktur
domain yang sama seperti yang kita butuhkan untuk rekayasa ke depan
transformasional yang dapat memberi kita desain selama konstruksi
sistem. Semua domain, notasinya, dan transformasi terkait dalam setiap
domain serta antara domain yang diperlukan untuk rekayasa maju juga
diperlukan untuk merekayasa balik kode warisan untuk menutupi desain
yang hilang.
Rekayasa balik transformasional dapat dengan mudah dibentuk
secara bertahap yang memungkinkan kita untuk merekayasa balik hanya
bagian-bagian kode yang diperlukan untuk tugas pemeliharaan yang
sebenarnya. Seiring waktu semakin banyak bagian dari kode yang akan
diabstraksikan dan level abstraksi akan semakin tinggi dan mungkin
semakin tinggi sampai kita mendapatkan spesifikasi persyaratan abstrak
dari keseluruhan sistem.
Semua ini dapat didukung secara efektif oleh mesin transformasi
berbasis domain yang dapat menerapkan transformasi untuk wards dan
backwards dan dapat memodifikasi penghitungan penambahan desain.
Sistem seperti itu, yang disebut Sistem Pemeliharaan Desain (DMS), yang
ditujukan untuk menangani perangkat lunak ukuran komersial, saat ini
sedang dikembangkan di Semantic Designs. Kami berharap dapat
melaporkan pengalaman nyata tahun depan.
Machine Translated by Google
Referensi
[ 11 ID Baxter. Pemeliharaan Transformasional dengan Penggunaan
Kembali Sejarah Desain. Tesis PhD, University of California di
Irvine, 1990.
[2] ID Baxter. Desain Sistem Pemeliharaan. Komunikasi ACM
35(4):73-89, 1992.
[3] ID Baxter. Desain (Bukan Kode!) Pemeliharaan. Dalam: Lokakarya
ICSE-17 tentang Transformasi Program untuk Evolusi Perangkat
Lunak, 1995.
[4] VR Basili dan HD Mills. Memahami dan Mendokumentasikan
Program. Transaksi IEEE pada Rekayasa Perangkat Lunak
8(3):270-283, 1982.
[5] B. Boehm. Ekonomi Rekayasa Perangkat Lunak. Prentice Hall,
1981.
[6] T. Guimaraes. Mengelola Belanja Penyewaan Utama Program
Aplikasi. Komunikasi ACM 26(10):739-746, 1983.
[7] V. Kozaczynski, JQ Ning, dan A. Engberts. Pengenalan dan
Transformasi Konsep Program . Transaksi IEEE pada Rekayasa
Perangkat Lunak 18( 12): 1065-1075, 1992.
[8] S. Letovsky dan E. Soloway. Rencana Terdelokalisasi dan
Pemahaman Program. Perangkat Lunak IEEE 3(3):41-49, 1986.
[9] RD McCartney. Sintesis Algoritma dengan Kendala Kinerja Ph.D.
tesis, Brown University, 1987.
[ 101 JM Tetangga. Pendekatan Draco untuk Membangun
Perangkat Lunak dari Komponen. Transaksi IEEE pada
Rekayasa Perangkat Lunak 10(5):564-574, 1984.
113
[ 1 11 HA Partsch. Spesifikasi dan Transformasi Program :
Pendekatan Formal untuk Pengembangan Perangkat Lunak.
Springer, 1990.
[12] S. Rugaber, K. Stirewalt, dan L. Wills. Masalah Interleaving dalam
Pemahaman Program. Dalam: Working Conference on Reverse
Engineering, hlm. 166175, 1995.
[ 131 S. Rugaber. Buku Putih tentang Rekayasa Terbalik. Georgia
Institut Teknologi, 1994.
[ 141 C. Rich dan L. Wills. Murid Programmer. ACM Pers, 1990.
[15] C. Rich dan L. Wills. Mengenali Desain Program: Pendekatan
Parsing Grafik. Perangkat Lunak IEEE 7( 1):82-89, 1990.
[ 161 T. Tamai dan Y. Torimitsu. Seumur Hidup Perangkat Lunak dan
Proses Evolusinya dari Generasi ke Generasi. Prosiding Konferensi
1992 tentang Pemeliharaan Perangkat Lunak, November 1992,
IEEE Computer Society Press.
[ 171 P. Tonella, R. Fiutem, G. Antoniol, dan E. Merlo. Meningkatkan
Pemulihan Arsitektur Berbasis Pola dengan Analisis Aliran: Mosaik
- Studi Kasus. Dalam: Working Conference on Reverse Engineering,
hlm. 198-207, 1996.
[ 181 MP Ward dan KH Bennett. Metode Formal untuk Sistem Warisan.
Jurnal Pemeliharaan Perangkat Lunak: Penelitian dan Praktik,
7(3):203-220, 1995.
[19] S. Woods dan A. Quilici. Beberapa Eksperimen Untuk Memahami
Bagaimana Skala Algoritma Pengenalan Rencana Program.
Dalam: Working Conference on Reverse Engineering, hlm. 21-30,
1996.